Live data from Hacker News

Open Source Resistance: keep OSS alive on company time

ossresistance.com

71–80 of 93 posts

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

#71
post #46

Earlier quoted context omitted.

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

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

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

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

#72
post #67
post #52

Earlier quoted context omitted.

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

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.

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

#73
post #65
post #63

Earlier quoted context omitted.

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

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

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"

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

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

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

#75
post #28
post #19

Earlier quoted context omitted.

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

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?

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

#77
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?

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

#78
post #46

Earlier quoted context omitted.

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

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.

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

#79
post #19
post #5

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

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

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?

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

#80
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.
Post reply on HN