[zokier]

While I wholeheartedly agree this as a general concept, I find it tricky to accomplish in practice. Ianal, but afaik in general your employer owns the ip, and as such publishing it as oss requires explicit permission. And getting that permission often is difficult, needs to go through endless red tape and legal departments etc.

> In the United States, United Kingdom, and several other jurisdictions, if a work is created by an employee as part of their job duties, the employer is considered the legal author or first owner of copyright.

https://en.wikipedia.org/wiki/Work_for_hire

That being said, I do think open source work (maintenance/development) should happen by salaried professionals instead of volunteers begging for donations. The big question is how to make that happen, how to get companies accept oss contribution as standard practice instead of something that needs separate individual negotiating.

[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)?

[Aurornis]

> Ianal, but afaik in general your employer owns the ip, and as such publishing it as oss requires explicit permission

If any of the work is related to what you do for your job this is true.

If the work is not related to the job it depends on the state. Many states have limitations on what employers can claim as their IP. Generic contracts will try to claim everything because they keep the language broad, but laws often say that an employer can't claim work you did in your free time if it wasn't related to the employer.

If you do the work during work hours or you use the company laptop, they would have a claim to it. Most companies aren't going to care, but you shouldn't get relaxed about this because you want to keep everything clean if a dispute arises.

Do the work on your own time, on your own hardware, and don't overlap the work you're hired to do or anything you might have been exposed to during your time at work.

[jonas21]

Yes, but the title of this page is literally "Keep OSS alive on company time".

[Aurornis]

Good point.

[phkahler]

>> While I wholeheartedly agree this as a general concept, I find it tricky to accomplish in practice. Ianal, but afaik in general your employer owns the ip, and as such publishing it as oss requires explicit permission.

IANAL but if you give your co-worker a copy to run, you've just used the OSS license to be able to do that right? The co-worker now has legal rights granted by the license right? Including to redistribute your changes?

This all seems really silly since pushing changes upstream is by far the best way to be sure the changes are maintained. Not to mention legal uncertainty around maintaining an internal proprietary fork.

[MyHonestOpinon]

I think the post is suggesting to follow the path of least resistance. Work on company time, try not to make many waves. If you are caught ask for forgiveness. The easy path for the company is to forgive you. If they get lawyers involved, it can get very expensive and it could become a PR nightmare for them.

[vips7L]

If the current state of programming has showed anything, IP and copyright law don't exists anymore.

[gchamonlive]

You don't need to push for full opensource to be able to contribute. You can negotiate time to help maintain oss packages the company IP relies upon and design your IP around creating agnostic modules that can later be released to the community.

[mikemcquaid]

I'd personally got specific contract carveouts for this to only apply e.g. during working hours on company equipment (or even more liberal).

The GitHub liberal IP agreement is a good example of being even more chill here.

[shimman]

This doesn't apply to every state. In California you have the California Labor Code Section 2870 which prohibits employers from stealing workers IP.

[em-bee]

that does not apply to work done during work hours or on company equipment.

[hkolk]

In the Netherlands the law is pretty straigtforward that this is a bad idea: > The "Nature of Employment" Rule: If you are hired as a software developer, almost any software you create (even in your own time) can be claimed by your employer.

We always advise our employees to request an exception for it. We are pretty relaxed about it, but we don't give out a blanket exception

[NewJazz]

Luckily in California your own time is your own time.

[vinckr]

Has that law ever been enforced ? (e.g. taking away a FOSS or other project that someone wrote in their own time)

[NewJazz]

Yeah this is a problem with the advice. On company time. They should have said "on personal time (winky face)".