4 ms·

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 a

by zokier 5mo ago

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

deleted 5mo ago
[deleted]
gchamonlive 5mo ago
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.
shimman 5mo ago
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 5mo ago
  that does not apply to work done during work hours or on company equipment.
mikemcquaid 5mo ago
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.
voxic11 5mo ago
[dead]
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.
hkolk 5mo ago
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 5mo ago
  Luckily in California your own time is your own time.
- vinckr 5mo ago
  Has that law ever been enforced ? (e.g. taking away a FOSS or other project that someone wrote in their own time)
NewJazz 5mo ago
Yeah this is a problem with the advice. On company time. They should have said "on personal time (winky face)".
Aurornis 5mo ago
> 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 5mo ago
  Yes, but the title of this page is literally "Keep OSS alive on company time".
  - Aurornis 5mo ago
    Good point.
vips7L 5mo ago
If the current state of programming has showed anything, IP and copyright law don't exists anymore.
MyHonestOpinon 5mo ago
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.
phkahler 5mo ago
>> 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.

by zokier 5mo ago

deleted 5mo ago

[deleted]

gchamonlive 5mo ago

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.

shimman 5mo ago

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 5mo ago
that does not apply to work done during work hours or on company equipment.

mikemcquaid 5mo ago

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.

voxic11 5mo ago

[dead]

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.

hkolk 5mo ago

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 5mo ago
Luckily in California your own time is your own time.
vinckr 5mo ago
Has that law ever been enforced ? (e.g. taking away a FOSS or other project that someone wrote in their own time)

NewJazz 5mo ago

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

Aurornis 5mo ago

> 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 5mo ago
Yes, but the title of this page is literally "Keep OSS alive on company time".
- Aurornis 5mo ago
  Good point.

vips7L 5mo ago

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

MyHonestOpinon 5mo ago

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.

phkahler 5mo ago

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