Live data from Hacker News

Open Source Resistance: keep OSS alive on company time

ossresistance.com

81–90 of 93 posts

Re: Open Source Resistance: keep OSS alive on company time

#81

> "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…

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_…

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

Re: Open Source Resistance: keep OSS alive on company time

#82

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…

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.

Re: Open Source Resistance: keep OSS alive on company time

#83

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.

Re: Open Source Resistance: keep OSS alive on company time

#84

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?…

“Sure, let me run this through the compliancy team. Just to make sure there’s no intellectual property infringement. Which repository and issue, exactly?”

[deleted]

Re: Open Source Resistance: keep OSS alive on company time

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

Re: Open Source Resistance: keep OSS alive on company time

#86
post #28

Earlier quoted context omitted.

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 mainta…

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.

Re: Open Source Resistance: keep OSS alive on company time

#87

Earlier quoted context omitted.

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.

Re: Open Source Resistance: keep OSS alive on company time

#89
post #51
post #28

Earlier quoted context omitted.

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.

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.

Re: Open Source Resistance: keep OSS alive on company time

#90
post #24

Earlier quoted context omitted.

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.

Post reply on HN