My employers have generally been fine giving me blanket permission to contribute to specific open source projects.
The framing matters: don't say "can I please do some charity work because it makes me feel good".
Say, "can I have your permission to get free rigorous review from experts in my field, and zero out all future maintenance costs for your company by contributing my fixes to the upstream open source project?"
Because that's really how it is. No employer of mine has ever said no to that. It is entirely in their interest for you to do this, you just have to help them see it.
I'm a little sad that I got laid off from a previous job for a variety of reasons, but one big one was that there were discussions of letting me open source some very big changes I had made to the Kafka Streams library.
I rewrote a lot of stuff while keeping the API mostly compatible, focusing on emphasizing non-blocking IO with backpressure semantics available if necessary. It was really cool and enabled a lot of interesting stuff involving the state store and mixing+matching blocking and non-blocking IO in a way that was still relatively performant. I think it was really neat and it's one of the projects I am most proud of because I was able to squeeze out performance in a lot of places that were non-obvious.
I was pushing to allow us to release it to Github and/or make a PR to the upstream Kafka Streams project, but sadly they did layoffs before that was completed and afterwards there was really no "champion" to do that, so it's stuck in proprietary land.
I might still do it from scratch and FOSS it, it's been long enough to where I think I wouldn't get in trouble if I rewrote it and released it (there weren't any patents or anything attached to it), and there are a few things I'd like to change anyway (like getting rid of the dependency of Vert.x). Maybe if I ever get a week off I'll do that.
Fixing a bug in something open-source should be acceptable to most employers. However, if new functionality is being added, then it becomes an entirely different conversation.
I think it is good that you were taking the legal + compliance sign-offs before pursuing it.
When I worked at Apple, they were extremely strict about contributions to FOSS stuff, even on your own time, even for simple stuff like bugfixes or opening a Github issue.
I am sure they have their reasons even if I don't agree with them, but it's made me very cautious about making PRs and the like while working at BigCos and making outside contributions to FOSS stuff.
This even more so, though, because of course I was doing it on company time, so I wouldn't really blame them for wanting to audit stuff to ensure I'm not divulging company secrets and the like.
> even on your own time, even for simple stuff like bugfixes or opening a Github issue
During a recruitment process with a company a few years ago, they quite early asked for my GH profile and complained that I hadn't much content available.
Later, they asked me to do a small exercise and put it on my GH account.
When they sent me the contract, there was a clause telling that I would work for them exclusively and would not be allowed to contribute to anything else than company projects, even in my own time.
I didn't signed, and every person in the process seemed unable to understand what was wrong.
This would be amazing to see upstreamed! I did some similar work for optimizing batch calls for the Quartz Scheduler. I left before it got merged, but was able to follow up and get it in as it was already PR'd.
Yeah, as I said I wouldn't mind reimplementing it anyway. I still more or less remember what I did so I don't think it would be too hard for me to reimplement if I get enough free time.
Kafka Streams is one of those things that I think is like 95% cool, but there are some design decisions I have mixed feelings on. One big thing is that while it does give an API for making new state stores out of the box and it's not too hard to write that, it is all dependent on blocking IO. This isn't that big of a deal with the built in RocksDB store because the latency isn't that high for it, so you can get away with everything being blocking, but if you want to substitute another store (e.g. Redis or even something like PostgreSQL), the naive version has you dealing with round trip latency for every item for a join, which can two or three orders of magnitude more expensive.
Less naively you can implement batching and the like in your driver, which is what my first version did, but you do eventually have to add blocking, and the Kafka Streams library doesn't really utilize virtual threads so you're paying the full cost of it at the end. Eventually I just found it more elegant to make Kafka Streams non-blocking-aware and adding built-in semantics for batching to automatically amortize the cost of these things.
Anyway, sorry, just kind of miss working on that project. I really should redo it.
Some employers get tangled up in just the legal review process.
Once I asked permission to submit a patch to a project and it had quite an interesting email trail. It came down to a single question: if the patch was written during hours billed to a customer for the purpose of fixing a bug in a deliverable product, and the library being patched had to be recompiled and delivered with the source code, and the contract states that all work and intellectual property associated to the product would be transferred to the customer, do we have authority to release the patch in the public domain?
I think that's a generally good approach and a fantastic example of framing things professionally but also doesn't fix the core of the problem, which I see problematic if leadership of an engineering-focused company doesn't understand immediately.
Luck with your employer also plays a big part in how you approach this too.
“Sure, let me run this through the compliancy team. Just to make sure there’s no intellectual property infringement. Which repository and issue, exactly?”
> "and make sure you own the open source IP you ship. "
In all the juridictions I have worked in, the code I ship during my work hours is owned by my employer, not me. I simply just can't decide on my own to contribute during my work hours. I need a formal agreement to work on open source code, and every single time I asked for it it took so much time (months) to run through legal department that I simply gave up or another contributor had shipped a PR in the meantime so I just gave up asking.
I think they were trying to say that you shouldn't try to commit work that is not yours to give away. There's another section down below about it, but the bullet point up top became confusing.
This point is obvious to devs with more experience but has been a real problem with some junior devs at some of my companies: They see something cool the company is doing in an internal project and think it would make a great contribution to some open source project, without thinking about the problems with using their knowledge of closed-source code to submit substantially similar code (or in some cases, copy and pasting) to an open source project.
> in Germany the employer owns all source code created during working hours by default.
Same in most countries I worked in. Generally it's not just the business hours, but also any kind of device used. If code got edited at one point on a company laptop, or during office hours, then it's the company's.
Most intellectual jobs in quant finance will also routinely enforce an intellectual property clause in their work contract, which extends appropriation to anything resulting from the knowledge you acquired at the company. Not sure if that is enforceable in practice, but it's always there.
What would be the general stance if I for example SSH'd into something I own and worked from there?
This AFAICT, isn't the case where I live, I usually have to sign something actively giving the the employer ownership (And usually it's scoped to the project), but I'm not sure if this is a formality
Even more, if you're working in your free time on something that is very much alike your dayjob (say you clone features from work), your emplyer probably owns* that too.
*: for common values of ownership in german copyright law
Depends on how you frame it, the employee still owns the work in the sense that they are the copyright holder. But the employer is granted exclusive usage rights to the work, so you wouldn't have the rights to license it to someone else as is encouraged in the article.
That would be relevant, for example, when the company goes defunct, and no one else holds any usage rights for the work.
Then you'd regain those usage rights.
That of course is iffy to make use of because you'd need to be sure that you are considered the exclusive author, and that no one else acquired these exclusive usage rights.
I wouldn't take a job where the employer wasnt publishing permissively licensed code for all but the production bits. It's demoralizing for me and would stress my soul to the brink. I'd rather be broke.
In the US, you’d definitely be broke. There just aren’t many employers willing to deal with it. All the ones I’ve worked for just use what’s available without modification.
This is a good idea, a great idea even, but I'm not sure it's a good idea to position it as "resistance".
Your job, likely, is to achieve some goal. You're the specialist who gets to decide how to achieve that goal. If open source software is part of that decision, then maintaining it is should also part of that decision. It's not radical, it's just doing your job by protecting the future stability and maintainability of things you rely on for that job.
While I agree with everything you say, the reality of most tech companies these days (based on my experience), is that they will not even invest time into maintaining their own infrastructure and libraries unless forced to do so - much less OSS. Building useless features for gaming metrics, enshitification, dark patterns, borderline malware/hype integration - all would be prioritized over foundational infra/library investments.
I've seen plenty of the evils you're talking about, managers tend to make terrible engineering decisions and then instruct their engineers to go forth and make it so. I guess what I'm saying is that, as an engineer, your value proposition is that you can shield your manager from getting mired in such details by not asking for their unqualified opinion in the first place.
Just give estimates which include time for not doing things the dumb way, and then don't do things the dumb way. When it comes time to talk about performance reviews, call it "taking ownership."
Agree. The characterization makes it seem like somebody's trying that extra attention on social media. It's sad that we're at the point where everything has to be hyperbolic
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.
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.
> 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.
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?
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.
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.
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.
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.
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?
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.
in most cases you dont need explicit permission but you need to sign a CLA (Individual Contributor License Agreement) - which kind of includes permission
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.
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.
> 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.
>> 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.
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.
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.
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
I work for a reasonably large company. We have an Open Source policy that boils down to ask your manager first, don't do it in the name of the company and don't release anything confidential.
It's never been a problem, and I feel is perfectly reasonable in the grand scheme of things.
I don't have any problem contributing to 3rd party open source projects at work time for e.g. fixing a bug, but how do you deal with your OWN open source? Let's say you have a small library you made personally, then use it at work, then find a bug during work hours. If I contribute during those work hours, I think that'd be on the gray zone.
Has anyone negotiated this during an interview? How do you do it?
I’ve never worked anywhere that actually cared about this in practice. I just did what needed doing. When I asked about how to do it “right”, I could never get any answer.
Generally in every big corporation I worked any request to work on something outside of directly writing code to the company's codebase was answered by the direct manager with "Do it in your free time", even if the justification was provided. In a profit oriented environment only immediate value is considered worth pursuing. The attitude is pretty parasitic and dictated by the constant race for higher efficiency and metrics, which comes from the very top.
I've definitely forked to fix a problem and PR'd the result upstream to fix work problems before. IT's one of the nice things in terms of being able to use/access open source. It's also why git is pretty much a first class option for package.json and cargo.toml... Just so you can direct to the fork until a change is upstreamed.
with seniority, when you get to that point in the interview process where they ask you: "so you have any questions for us?", I just ask: "what is your position of using some of my time contributing to the OSS projects this company relies on?".
Based on the answer, you decide if you want to stay.
I’ve never had luck asking permission for open source stuff, either contributing or just publishing my own stuff (which is often work-related). No one told me no, but they never approved anything either. So at some point I stopped asking and I just do what needs to be done.
Whilst not viable in every business, I do this a lot in my research, scripts I create, custom software I make for the lab, I have been fortunate to be able to plop online. It is extremely niche software (power meter, and in the pipeline, aligning photonic chips) and often simply a linux/haiku version of existing windows based software but I like to at least give a little bit back considering all the taking the institute does.
Where I use to work, you got 4 hours per week to work on your on thing, but that ended when covid hit and the company started feeling some financial pain.
Don’t give shit away for free if you expect something in return, even something altruistic like for the recipients to be nice to the gift and keep it in good shape.
I think it makes more sense for the commons to be built on mutuality and some kind of antibody against parasitic exploitation.
There is no “tragedy of the commons”. Private enterprise is the only tragedy.
Author here. I've maintained Homebrew since 2009. This manifesto is for the maintainers I know who have quietly built a sustainable OSS practice inside companies that directly or indirectly depend on their work. I'm also at the point in my career where I can say these things with fewer negative consequences than most maintainers can.
The "polite" channels (Open Source Pledge, GitHub Sponsors, Open Source Friday) ask companies nicely to contribute. I argue instead that maintainers inside those companies should just take the work time they need to maintain the open source those companies already benefit from.
Happy to take questions.
(I'm not a lawyer: please read your employment contract before acting on any of this!)
Love the manifesto. It perfectly describes the approach I adhere to and have encouraged many other engineers to adopt. Better to ask for forgiveness than permission. Open source means distributed maintenance. Many hands make light work.
The employees are able to make their own decisions and as written on the site should make sure that they are allowed to contribute - I don’t get why you think that’s a “disgrace” and not debatable
This is so crazy. Companies benefit from OSS so they need to pay? Come on. Companies benefit from OSS because the core idea of most of these licenses is exactly this - everyone can benefit even without contributing back. Don’t like it? Think this is not fair? Don’t do OSS or pick a more restrictive license.
If a company pays for your work time not work products (many contracts work like this) they have the full right to expect that during this work time you do the work explicitly ordered by them. It’s not only the law - it’s common sense.
Unfortunately there are often questions of liability. What if you commit code that later becomes subject to litigation? It's more complicated than "we don't want to". (I'm fully supportive but when legal is involved you have to be able to justify the risk).
Surely OSS is a solved problem. AI generates everything automatically. You don’t need to look at the code, so there is nothing for humans to do but prompt.
If you can do 1000x surely most projects are now essentially “complete” and bug free.
I don’t get this contradiction. Something is wrong.
My employers have generally been fine giving me blanket permission to contribute to specific open source projects.
The framing matters: don't say "can I please do some charity work because it makes me feel good".
Say, "can I have your permission to get free rigorous review from experts in my field, and zero out all future maintenance costs for your company by contributing my fixes to the upstream open source project?"
Because that's really how it is. No employer of mine has ever said no to that. It is entirely in their interest for you to do this, you just have to help them see it.
I'm a little sad that I got laid off from a previous job for a variety of reasons, but one big one was that there were discussions of letting me open source some very big changes I had made to the Kafka Streams library.
I rewrote a lot of stuff while keeping the API mostly compatible, focusing on emphasizing non-blocking IO with backpressure semantics available if necessary. It was really cool and enabled a lot of interesting stuff involving the state store and mixing+matching blocking and non-blocking IO in a way that was still relatively performant. I think it was really neat and it's one of the projects I am most proud of because I was able to squeeze out performance in a lot of places that were non-obvious.
I was pushing to allow us to release it to Github and/or make a PR to the upstream Kafka Streams project, but sadly they did layoffs before that was completed and afterwards there was really no "champion" to do that, so it's stuck in proprietary land.
I might still do it from scratch and FOSS it, it's been long enough to where I think I wouldn't get in trouble if I rewrote it and released it (there weren't any patents or anything attached to it), and there are a few things I'd like to change anyway (like getting rid of the dependency of Vert.x). Maybe if I ever get a week off I'll do that.
Fixing a bug in something open-source should be acceptable to most employers. However, if new functionality is being added, then it becomes an entirely different conversation.
I think it is good that you were taking the legal + compliance sign-offs before pursuing it.
When I worked at Apple, they were extremely strict about contributions to FOSS stuff, even on your own time, even for simple stuff like bugfixes or opening a Github issue.
I am sure they have their reasons even if I don't agree with them, but it's made me very cautious about making PRs and the like while working at BigCos and making outside contributions to FOSS stuff.
This even more so, though, because of course I was doing it on company time, so I wouldn't really blame them for wanting to audit stuff to ensure I'm not divulging company secrets and the like.
> even on your own time, even for simple stuff like bugfixes or opening a Github issue
During a recruitment process with a company a few years ago, they quite early asked for my GH profile and complained that I hadn't much content available.
Later, they asked me to do a small exercise and put it on my GH account.
When they sent me the contract, there was a clause telling that I would work for them exclusively and would not be allowed to contribute to anything else than company projects, even in my own time.
I didn't signed, and every person in the process seemed unable to understand what was wrong.
fortunately that's illegal in many jurisdictions, but i still would not sign unless they removed that passage.
i had one contract where i was able to replace the standard "we own all your work" passage into: "all your work will be released under the GPL"
This would be amazing to see upstreamed! I did some similar work for optimizing batch calls for the Quartz Scheduler. I left before it got merged, but was able to follow up and get it in as it was already PR'd.
Yeah, as I said I wouldn't mind reimplementing it anyway. I still more or less remember what I did so I don't think it would be too hard for me to reimplement if I get enough free time.
Kafka Streams is one of those things that I think is like 95% cool, but there are some design decisions I have mixed feelings on. One big thing is that while it does give an API for making new state stores out of the box and it's not too hard to write that, it is all dependent on blocking IO. This isn't that big of a deal with the built in RocksDB store because the latency isn't that high for it, so you can get away with everything being blocking, but if you want to substitute another store (e.g. Redis or even something like PostgreSQL), the naive version has you dealing with round trip latency for every item for a join, which can two or three orders of magnitude more expensive.
Less naively you can implement batching and the like in your driver, which is what my first version did, but you do eventually have to add blocking, and the Kafka Streams library doesn't really utilize virtual threads so you're paying the full cost of it at the end. Eventually I just found it more elegant to make Kafka Streams non-blocking-aware and adding built-in semantics for batching to automatically amortize the cost of these things.
Anyway, sorry, just kind of miss working on that project. I really should redo it.
I miss working at a place which allowed this.
Some employers get tangled up in just the legal review process.
Once I asked permission to submit a patch to a project and it had quite an interesting email trail. It came down to a single question: if the patch was written during hours billed to a customer for the purpose of fixing a bug in a deliverable product, and the library being patched had to be recompiled and delivered with the source code, and the contract states that all work and intellectual property associated to the product would be transferred to the customer, do we have authority to release the patch in the public domain?
Legal didn’t want to answer it.
The customer would probably prefer that you released it - that would mean next time they need a change the previous is up streamed.
Note that the resulting patch is almost assuredly not public domain and you should never use that term.
I think that's a generally good approach and a fantastic example of framing things professionally but also doesn't fix the core of the problem, which I see problematic if leadership of an engineering-focused company doesn't understand immediately.
Luck with your employer also plays a big part in how you approach this too.
“Sure, let me run this through the compliancy team. Just to make sure there’s no intellectual property infringement. Which repository and issue, exactly?”
it hurts how true this is
> "and make sure you own the open source IP you ship. "
In all the juridictions I have worked in, the code I ship during my work hours is owned by my employer, not me. I simply just can't decide on my own to contribute during my work hours. I need a formal agreement to work on open source code, and every single time I asked for it it took so much time (months) to run through legal department that I simply gave up or another contributor had shipped a PR in the meantime so I just gave up asking.
I think they were trying to say that you shouldn't try to commit work that is not yours to give away. There's another section down below about it, but the bullet point up top became confusing.
This point is obvious to devs with more experience but has been a real problem with some junior devs at some of my companies: They see something cool the company is doing in an internal project and think it would make a great contribution to some open source project, without thinking about the problems with using their knowledge of closed-source code to submit substantially similar code (or in some cases, copy and pasting) to an open source project.
I have never investigated, but I was under the impression that in Germany the employer owns all source code created during working hours by default.
Most employers that are not IT focused wont even understand what open source is or how it works. So I guess it's hopeless for many to get permission.
The linked site should probably focus on explaining benefits of open source and advocate legal guidelines for _employers_ primarily.
> in Germany the employer owns all source code created during working hours by default.
Same in most countries I worked in. Generally it's not just the business hours, but also any kind of device used. If code got edited at one point on a company laptop, or during office hours, then it's the company's.
Most intellectual jobs in quant finance will also routinely enforce an intellectual property clause in their work contract, which extends appropriation to anything resulting from the knowledge you acquired at the company. Not sure if that is enforceable in practice, but it's always there.
What would be the general stance if I for example SSH'd into something I own and worked from there?
This AFAICT, isn't the case where I live, I usually have to sign something actively giving the the employer ownership (And usually it's scoped to the project), but I'm not sure if this is a formality
> What would be the general stance if I for example SSH'd into something I own and worked from there?
That would definitevely count as company time and company device usage.
Even more, if you're working in your free time on something that is very much alike your dayjob (say you clone features from work), your emplyer probably owns* that too.
*: for common values of ownership in german copyright law
Depends on how you frame it, the employee still owns the work in the sense that they are the copyright holder. But the employer is granted exclusive usage rights to the work, so you wouldn't have the rights to license it to someone else as is encouraged in the article.
That would be relevant, for example, when the company goes defunct, and no one else holds any usage rights for the work. Then you'd regain those usage rights.
That of course is iffy to make use of because you'd need to be sure that you are considered the exclusive author, and that no one else acquired these exclusive usage rights.
I wouldn't take a job where the employer wasnt publishing permissively licensed code for all but the production bits. It's demoralizing for me and would stress my soul to the brink. I'd rather be broke.
In the US, you’d definitely be broke. There just aren’t many employers willing to deal with it. All the ones I’ve worked for just use what’s available without modification.
I'm in the US and have made a living writing open source for almost 10 years now, through ups and downs, but it's worked out.
This is a good idea, a great idea even, but I'm not sure it's a good idea to position it as "resistance".
Your job, likely, is to achieve some goal. You're the specialist who gets to decide how to achieve that goal. If open source software is part of that decision, then maintaining it is should also part of that decision. It's not radical, it's just doing your job by protecting the future stability and maintainability of things you rely on for that job.
It's also just good business sense. Companies that promote collaboration via open source are promoting the ecosystem that feeds their business.
While I agree with everything you say, the reality of most tech companies these days (based on my experience), is that they will not even invest time into maintaining their own infrastructure and libraries unless forced to do so - much less OSS. Building useless features for gaming metrics, enshitification, dark patterns, borderline malware/hype integration - all would be prioritized over foundational infra/library investments.
I've seen plenty of the evils you're talking about, managers tend to make terrible engineering decisions and then instruct their engineers to go forth and make it so. I guess what I'm saying is that, as an engineer, your value proposition is that you can shield your manager from getting mired in such details by not asking for their unqualified opinion in the first place.
Just give estimates which include time for not doing things the dumb way, and then don't do things the dumb way. When it comes time to talk about performance reviews, call it "taking ownership."
Ah yes, agreed!
Agree. The characterization makes it seem like somebody's trying that extra attention on social media. It's sad that we're at the point where everything has to be hyperbolic
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.
> 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.
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?
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.
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.
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.
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.
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'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?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.
in most cases you dont need explicit permission but you need to sign a CLA (Individual Contributor License Agreement) - which kind of includes permission
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.
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.
Have you heard of DCO (Developer Certificate of Origin)?
> 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.
Yes, but the title of this page is literally "Keep OSS alive on company time".
Good point.
>> 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.
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.
If the current state of programming has showed anything, IP and copyright law don't exists anymore.
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.
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.
This doesn't apply to every state. In California you have the California Labor Code Section 2870 which prohibits employers from stealing workers IP.
that does not apply to work done during work hours or on company equipment.
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
Luckily in California your own time is your own time.
Has that law ever been enforced ? (e.g. taking away a FOSS or other project that someone wrote in their own time)
Yeah this is a problem with the advice. On company time. They should have said "on personal time (winky face)".
I work for a reasonably large company. We have an Open Source policy that boils down to ask your manager first, don't do it in the name of the company and don't release anything confidential.
It's never been a problem, and I feel is perfectly reasonable in the grand scheme of things.
I don't have any problem contributing to 3rd party open source projects at work time for e.g. fixing a bug, but how do you deal with your OWN open source? Let's say you have a small library you made personally, then use it at work, then find a bug during work hours. If I contribute during those work hours, I think that'd be on the gray zone.
Has anyone negotiated this during an interview? How do you do it?
I’ve never worked anywhere that actually cared about this in practice. I just did what needed doing. When I asked about how to do it “right”, I could never get any answer.
Generally in every big corporation I worked any request to work on something outside of directly writing code to the company's codebase was answered by the direct manager with "Do it in your free time", even if the justification was provided. In a profit oriented environment only immediate value is considered worth pursuing. The attitude is pretty parasitic and dictated by the constant race for higher efficiency and metrics, which comes from the very top.
I've definitely forked to fix a problem and PR'd the result upstream to fix work problems before. IT's one of the nice things in terms of being able to use/access open source. It's also why git is pretty much a first class option for package.json and cargo.toml... Just so you can direct to the fork until a change is upstreamed.
with seniority, when you get to that point in the interview process where they ask you: "so you have any questions for us?", I just ask: "what is your position of using some of my time contributing to the OSS projects this company relies on?". Based on the answer, you decide if you want to stay.
Absolutely love this!
I’ve never had luck asking permission for open source stuff, either contributing or just publishing my own stuff (which is often work-related). No one told me no, but they never approved anything either. So at some point I stopped asking and I just do what needs to be done.
Whilst not viable in every business, I do this a lot in my research, scripts I create, custom software I make for the lab, I have been fortunate to be able to plop online. It is extremely niche software (power meter, and in the pipeline, aligning photonic chips) and often simply a linux/haiku version of existing windows based software but I like to at least give a little bit back considering all the taking the institute does.
Where I use to work, you got 4 hours per week to work on your on thing, but that ended when covid hit and the company started feeling some financial pain.
Every single fucking employee contract in the US mentions that the company has the right to any work done on company equipment and/or on company time.
This is such a bad idea, it's impressive.
noooo
Don’t give shit away for free if you expect something in return, even something altruistic like for the recipients to be nice to the gift and keep it in good shape.
I think it makes more sense for the commons to be built on mutuality and some kind of antibody against parasitic exploitation.
There is no “tragedy of the commons”. Private enterprise is the only tragedy.
Author here. I've maintained Homebrew since 2009. This manifesto is for the maintainers I know who have quietly built a sustainable OSS practice inside companies that directly or indirectly depend on their work. I'm also at the point in my career where I can say these things with fewer negative consequences than most maintainers can.
The "polite" channels (Open Source Pledge, GitHub Sponsors, Open Source Friday) ask companies nicely to contribute. I argue instead that maintainers inside those companies should just take the work time they need to maintain the open source those companies already benefit from.
Happy to take questions.
(I'm not a lawyer: please read your employment contract before acting on any of this!)
Great post. Also thanks for homebrew! And for your post on sandboxes... secure agentic setup!
Love the manifesto. It perfectly describes the approach I adhere to and have encouraged many other engineers to adopt. Better to ask for forgiveness than permission. Open source means distributed maintenance. Many hands make light work.
brought to you by the unemployed , or soon to be unemployed and sued.
This is an ethical disgrace and everyone involved should be ashamed.
Elaborate?
Read "Not everyone will approve of this" section. You are not free to make any of these decisions on behalf of your employer.
Won’t somebody think of the companies and their shareholders!!1
*and their employees, who depend on the company to be healthy as a central economic tenet of their employment. This really isn't debatable
The employees are able to make their own decisions and as written on the site should make sure that they are allowed to contribute - I don’t get why you think that’s a “disgrace” and not debatable
This is so crazy. Companies benefit from OSS so they need to pay? Come on. Companies benefit from OSS because the core idea of most of these licenses is exactly this - everyone can benefit even without contributing back. Don’t like it? Think this is not fair? Don’t do OSS or pick a more restrictive license.
If a company pays for your work time not work products (many contracts work like this) they have the full right to expect that during this work time you do the work explicitly ordered by them. It’s not only the law - it’s common sense.
Unfortunately there are often questions of liability. What if you commit code that later becomes subject to litigation? It's more complicated than "we don't want to". (I'm fully supportive but when legal is involved you have to be able to justify the risk).
Surely OSS is a solved problem. AI generates everything automatically. You don’t need to look at the code, so there is nothing for humans to do but prompt.
If you can do 1000x surely most projects are now essentially “complete” and bug free.
I don’t get this contradiction. Something is wrong.