4 ms·

> While I wholeheartedly agree this as a general concept, I find it tricky to accomplish in practice. The problems you are describing are not actually "problem

by 827a 5mo ago

> While I wholeheartedly agree this as a general concept, I find it tricky to accomplish in practice. The problems you are describing are not actually "problems in practice", as you say. They are theoretical problems. In practice: You can just do stuff. There is no subroutine on your computer stopping the git push. In practice: Employers just write stuff in their employement contracts. They'll write everything they possibly can, to cover asses in every possible direction. If they're allowed to just write stuff, why aren't you allowed to just do stuff? Nothing matters. In practice: Roughly zero open source projects have had their IP challenged because of this technicality.

mrob 5mo ago
You might be comfortable taking that risk yourself, but if you misrepresent your FOSS contributions as your own copyright you impose that risk on third parties. Tricking people into infringing your employer's copyright is asshole behavior.
- __MatrixMan__ 5mo ago
  Has that ever happened? I'd be surprised if there was any actual burden on the upstream maintainer to care whether I was on my lunch break or whether I was on the clock when I made the fix.
  - kcexn 5mo ago
    The highest profile recent case that I can find is Rambler vs Igor Sysoev on the development of Nginx. https://news.ycombinator.com/item?id=21771144 https://news.ycombinator.com/item?id=21771144 Although in this particular case, I tend to agree with Igor as he was employed as a system administrator not a software developer so it's unlikely that there were any real contractual constraints imposed on him in relation to copyright or invention transfer.
em-bee 5mo ago
when you commit code to a project you are warranting that you have the legal right to do so. the bigger projects will not even accept your contribution done at work without an explicit permission from your employer. this is not just about you and your risk, but also about the risk for the project.
- vinckr 5mo ago
  in most cases you dont need explicit permission but you need to sign a CLA (Individual Contributor License Agreement) - which kind of includes permission
  - seba_dos1 5mo ago
    There's no need for abusive CLAs to do that, DCO (Developer Certificate of Origin) plays this role already. You have to state that you have the right to use what you're trying to contribute.
- __MatrixMan__ 5mo ago
  What does that rejection look like? Do they refuse to merge the PR until you send them a document or something? As far as I'm aware these legal dark corners are uninhabited. If you say: > I was blocked, so I fixed a bug, and rather than wasting time maintaining an internal fork in violation of the OSS project's license, I complied with that license by contributing my fix upstream. I've never met a manager or a maintainer who would suggest that you open the can of worms by contacting a lawyer about it. We all know that intellectual property is a bit of a farce, especially as applied to software that was written jointly by an employee and model that was likely trained on the OSS project in the first place. But it's not a problem unless it's a Problem, so as long as no party is injured, why make it one?
  - em-bee 5mo ago
    well except that there is no FOSS license that requires you to submit your changes upstream. so the license argument is not going to be valid in most cases. GPL only require you to share with users, so any in-house use of software does also not require you to share the code with anyone outside. AGPL might trigger sharing if the software is used in a website, but also only with users of the website, not with upstream. only the maintenance argument holds, but that is a trade-off, not a legal requirement.
zokier 5mo ago
Have you heard of DCO (Developer Certificate of Origin)?
9x39 5mo ago
The rub is if you make something really cool or valuable, your employer may find out about it and want it, and the precautions are to protect yourself and your project. Doing it "on company time", if provable, puts you at a disadvantage. Parties involved have to decide on their acceptable level of risk, right?

by 827a 5mo ago

mrob 5mo ago

You might be comfortable taking that risk yourself, but if you misrepresent your FOSS contributions as your own copyright you impose that risk on third parties. Tricking people into infringing your employer's copyright is asshole behavior.

__MatrixMan__ 5mo ago
Has that ever happened? I'd be surprised if there was any actual burden on the upstream maintainer to care whether I was on my lunch break or whether I was on the clock when I made the fix.
- kcexn 5mo ago
  The highest profile recent case that I can find is Rambler vs Igor Sysoev on the development of Nginx. https://news.ycombinator.com/item?id=21771144 https://news.ycombinator.com/item?id=21771144 Although in this particular case, I tend to agree with Igor as he was employed as a system administrator not a software developer so it's unlikely that there were any real contractual constraints imposed on him in relation to copyright or invention transfer.

em-bee 5mo ago

when you commit code to a project you are warranting that you have the legal right to do so. the bigger projects will not even accept your contribution done at work without an explicit permission from your employer. this is not just about you and your risk, but also about the risk for the project.

vinckr 5mo ago
in most cases you dont need explicit permission but you need to sign a CLA (Individual Contributor License Agreement) - which kind of includes permission
- seba_dos1 5mo ago
  There's no need for abusive CLAs to do that, DCO (Developer Certificate of Origin) plays this role already. You have to state that you have the right to use what you're trying to contribute.
__MatrixMan__ 5mo ago
What does that rejection look like? Do they refuse to merge the PR until you send them a document or something? As far as I'm aware these legal dark corners are uninhabited. If you say: > I was blocked, so I fixed a bug, and rather than wasting time maintaining an internal fork in violation of the OSS project's license, I complied with that license by contributing my fix upstream. I've never met a manager or a maintainer who would suggest that you open the can of worms by contacting a lawyer about it. We all know that intellectual property is a bit of a farce, especially as applied to software that was written jointly by an employee and model that was likely trained on the OSS project in the first place. But it's not a problem unless it's a Problem, so as long as no party is injured, why make it one?
- em-bee 5mo ago
  well except that there is no FOSS license that requires you to submit your changes upstream. so the license argument is not going to be valid in most cases. GPL only require you to share with users, so any in-house use of software does also not require you to share the code with anyone outside. AGPL might trigger sharing if the software is used in a website, but also only with users of the website, not with upstream. only the maintenance argument holds, but that is a trade-off, not a legal requirement.

zokier 5mo ago

Have you heard of DCO (Developer Certificate of Origin)?

9x39 5mo ago

The rub is if you make something really cool or valuable, your employer may find out about it and want it, and the precautions are to protect yourself and your project. Doing it "on company time", if provable, puts you at a disadvantage. Parties involved have to decide on their acceptable level of risk, right?