4 ms·

> "Giving up" is an ambiguous term here and I should have tried to be more specific. But I wasn't just referring to ownership. If I'm working on a project, and

• danShumway 7y ago
  > if it's in an employment contract, and you signed it without reading it --- sorry, but I have zero sympathy for you. Arguing that employees should read their contracts, and arguing that the terms in those contracts aren't problematic, are two entirely separate things. I agree with you on the first point, I disagree with you on the second. > So long as there is an explicit open source releasing policy, and you followed it, then you are an authorized agent of the company when you release changes This is the key part. If Oracle has a policy like Google's, and if Oracle decides to let you release that code, and if you follow the process correctly, then you're fine. In practice, this assumes a great deal. You're arguing that as long as a company a) has an official Open Source release policy, and b) agrees to let you use that policy, then there's no problem. And, sure. As long as Oracle explicitly gives you permission to contribute code to Open Source projects, nothing bad will or can happen[0]. But that's a very different thing than arguing that it's fine for employers to retain complete control over a) what that policy is, and b) what projects are allowed under it. It's like claiming that if no abuse happens, there's no problem. It's true, but doesn't mean anything. The issue is that under the terms Google proposes, there is nothing preventing abuse. You're entirely at Google's mercy over whether or not you can contribute to any project, proprietary or Open Source. The issue is that when you sign those terms, you no longer have a guarantee that you can contribute to anything. And if you operate outside of whatever policy exists, you are opening yourself up to exactly the kind of abuse I describe. That's what I was trying to argue with Oracle: not that you'll have future problems if you follow an official policy, but that Open Source licenses are not enough to save you in the absence of an official policy, and that Open Source licenses are not enough to save you if you get rejected from that official policy. > I'm saying is that for an open source project, in general that doesn't happen. Except in the case of OP, where they were forced to find a separate maintainer for their project. You're not the only person to suggest here that this never happens, but... it did. You can argue that OP should have negotiated that up front before they took the job. I would tend to agree with you on that. But outside of OP's own responsibility, is it good for anyone else, anywhere, that they were forced to abandon that project? Not, "what could they have done differently", not "do they bear any responsibility" -- is it good for the software industry as a whole that Google was able to do what it did? I would argue no. I would argue the entire history of Silicon Valley says that allowing these kinds of terms is counterproductive to maintaining a healthy software industry, and that ideally labor laws in California would treat "we own everything" clauses the same way they treat noncompete agreements. ---- [0]: Except that you won't be able to re-license later, and you won't be able to contribute to projects that force you to assign copyright, and in the case of GPL software you write you'll be bound to the same GPL terms as every other user. But those are admittedly probably minor concerns for most projects. It is worth re-asking the question though -- if code ownership doesn't matter for Open Source projects, why does Google want it? Why is it important for Google to own code contributions their employees make to Open Source projects?
  • tytso 7y ago
    My argument is that employees are responsible for reading the contract, and if the contract have terms that might be problematic for open source contribution, the employee is responsible for finding out ahead of time what the policy is. (For Google, the policy is publically available[1], so it can be read by people who aren't yet employees.) If the policy is not acceptable to you, then you shouldn't work for that company. [1] https://opensource.google/docs/ https://opensource.google/docs/ And if the policy changes --- such as for example, when Oracle suddenly changed the rules about Open Solaris, the solution is simple. You quit. Large portions of the core Solaris team left, soon after Oracle changed the rules. Bryan Cantrill left Oracle, and he's done fine for himself. He's even made talks explaining what happened when Oracle screwed over Open Solaris: "As you know people, as you learn about things, you realize that these generalizations we have are, virtually to a generalization, false. Well, except for this one, as it turns out. What you think of Oracle, is even truer than you think it is. There has been no entity in human history with less complexity or nuance to it than Oracle. And I gotta say, as someone who has seen that complexity for my entire life, it's very hard to get used to that idea. It's like, 'surely this is more complicated!' but it's like: Wow, this is really simple! This company is very straightforward, in its defense. This company is about one man, his alter-ego, and what he wants to inflict upon humanity -- that's it! ...Ship mediocrity, inflict misery, lie our asses off, screw our customers, and make a whole shitload of money. Yeah... you talk to Oracle, it's like, 'no, we don't fucking make dreams happen -- we make money!' ...You need to think of Larry Ellison the way you think of a lawnmower. You don't anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it'll chop it off, the end. You don't think 'oh, the lawnmower hates me' -- lawnmower doesn't give a shit about you, lawnmower can't hate you. Don't anthropomorphize the lawnmower. Don't fall into that trap about Oracle." -- Bryan Cantrill https://www.youtube.com/watch?v=-zRN7XLCRhc https://www.youtube.com/watch?v=-zRN7XLCRhc