[827a]

> 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.

[9x39]

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?

[mrob]

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__]

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]

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

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]

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.

[__MatrixMan__]

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]

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.

[vinckr]

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]

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.

[827a]

Again, you missed the operand point: There are actually literally zero instances of companies enforcing a "we own all the code you write" clause against contributions to an open source project. For all the millions of software engineers and trillions of lines of code that have been written, there are zero cases of this happening. The reason why is because it is possible that a clause like this is unenforceable under these conditions; we don't know, its never been tried in court. It'd be a legal mess, and at the end of the day the most the company could (extremely unrealistically) lay claim to is some open source project they could already download for free (again, even that is unrealistic; more realistically is that they could lay claim to their employee's contributions, and the project would have to unwind them, but even that is extremely unlikely).

A clause like this might be unenforceable, but if you know anything about US employment contracts, you'll know: Companies will write EVERYTHING in these things. They don't give a shit. They don't care if its unenforceable. If it were socially agreeable they'd write in a clause forcing you to give up your first born child to the corporation, and then you'd say "Uh, no, you have no right to require that" and they'd say "Oh right yeah ok that's fine" and that's it. That is how employment contracts LITERALLY work. They just vibe write shit in them, because they can. Meanwhile employees treat them like like live ammo in a loaded gun the corporation is holding to their head.

Nine times out of ten if anything in an employment contract is going to be used against you, its going to be used to fire you, and that's where it ends. In that remaining 10%, its cases like "intentional corporate or international espionage where tens millions of dollars were lost to a competitor" It is actually fucking hilarious that you think anyone would want to spend the bajillions of dollars it costs to send lawyers into court because a little software engineer contributed some code to kubernetes at 4pm instead of 6pm. Bro: You're not that important. No one cares about you. Contribute the code.

[em-bee]

sorry i missed this comment and only saw it now.

There are actually literally zero instances of companies enforcing a "we own all the code you write" clause against contributions to an open source project.

the thread is about contributing to a project on company time in order to submit a change that the company needed. the fact that this work is owned by the company is not in dispute. it is 100% certain that the company owns that work because it was done in order to solve a company problem, and you most certainly got paid for it.

so the problem is not one of a company enforcing an "we own all the code you write" clause but the fact that as an employee you do not have the right to publish work the company owns, unless they give explicit permission. google for example does give explicit permission and does limit contributions to projects that have specific licenses. for example googlers are not allowed to contribute to AGPL projects.

as a project owner, i need the assurance that you do have permission from your employer. the fact that no employer has ever enforced ownership is irrelevant to me. if it is clear that you wrote that patch at work, i want to see your permission.

[zokier]

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