6 ms·

> It's absurd for any company to say they're going to attract passionate programmers, and then expect them to just roll over and give up projects that were star

by tytso 7y ago

> It's absurd for any company to say they're going to attract passionate programmers, and then expect them to just roll over and give up projects that were started before they even joined at the company. This is not necessarily "give up". You still own the code that was written before you joined the company. If it is an open source project, your code contributions after you start work will still be open source. They will just be owned by the company, so the resulting code will have some code owned by you, and some code owned by the company. If this is a healthy open source project (such as, say, e2fsprogs), it already has some code owned by Red Hat, some code owned by SuSE, some code by IBM, etc. So the fact that there will be some code written by you, but actually owned by Google, is (everyone repeat after me) No Big Deal. Now, it's different if your "side project" is under a proprietary license, and you hope to make $$$ some day. In that case, companies like IBM, Google, VA Linux Systems, which have a "all your IP belong to us" will be problematic for you. You can choose not to work for such a company, or you can choose to try to negotiate with the company. But for a side project which is an open source project, in general there won't be a problem. Now, if said open source project directly competes with a proprietary product sold by that company --- you had better disclose it up front during the hiring negotiations, and have a negotiation about how it should be handled. The fact of the matter is, the company doesn't have a right to your services, and you don't have a right to a job at that company. You negotiate it, just like you negotiate cash salary and equity compensation. And if you can't come to a negotiated outcome that both sides are happy with, neither side is evil; they just couldn't come to an agreement.

danShumway 7y ago
> This is not necessarily "give up". "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 joining Google means I need to stop working on it for 3-4 years, then I've effectively given up that project, in the sense that it's no longer going to be maintained or stay relevant. I'm unlikely to go back to a 3-4 year old project and pick it up again later. Most of those projects are dead. > So the fact that there will be some code written by you, but actually owned by Google, is (everyone repeat after me) No Big Deal. Sure, unless your company is Oracle and they decide X years later to say, "actually we own the code and we didn't authorize it to be Open Sourced, and that means the entire project is infringing." People are so ready to say that terms like this are no big deal. If it really doesn't matter who owns the code that gets contributed to an Open Source project, then why is it important that Google own it? If Google isn't going to exploit that code in any way, then they shouldn't have a problem with their employees retaining ownership, right? > Now, it's different if your "side project" is under a proprietary license I think it's unrealistic and unreasonable to assume that every time an employee enriches themselves outside of work, they'll be doing it in relation to an Open Source project. It's also ignores the fact that a nontrivial portion of Silicon Valley was built on top of people who didn't accept those terms. We can say this stuff is standard and it all comes down to individual choice, but we have pretty decent data that universally getting rid of noncompetes was good for the software industry. We have reasonably decent data that allowing employees to work on commercial side projects outside of work would similarly be good for the industry. Labor laws just haven't caught up yet to that point. > Neither side is evil; they just couldn't come to an agreement. I do think that these policies are unethical, that they amount to a kind of attempted takeover of employee autonomy on a level that a business owner shouldn't even be trying to restrict. However, that wasn't the argument I was making when I said this was absurd. I was just making the observation that most businesses don't have as much money as Google to throw at people or to offer them dream jobs. So most businesses who attempt this are giving up any chance of hiring the best developers, because on average the best developers won't tolerate those terms unless they come attached to Google money and a dream job. Obviously, direct competition or conflicts of interest are another story, but nobody is debating them. It's a mistake to start from, "direct conflicts of interest should be avoided", and then immediately extrapolate from there to "a business should own everything that comes out of an employee, anywhere."
- tytso 7y ago
  > "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 joining Google means I need to stop working on it for 3-4 years, then I've effectively given up that project, in the sense that it's no longer going to be maintained or stay relevant. And what I'm saying is that for an open source project, in general that doesn't happen. And if you're not sure, you negotiate that up front. I did that when I started work for IBM, for example. And it was more than just copyright issues; it included stuff like, "look, I'm one of the chairs of the ipsec working group, and I'd like you to pay for me to travel to IETF meetings so I can finish out my commitment to IETF, even though that doesn't have that much to do with the IBM Linux Technology Center". Everything is negotiable; they might say no, but you'll never know until you ask. More generally, I'm having trouble thinking of situations where you (a) can't take a side project and release it as open source, and (b) you're wanting to keep it proprietary except for "wanting to earn $$$ on a side project" while also drawing from a big company. > Sure, unless your company is Oracle and they decide X years later to say, "actually we own the code and we didn't authorize it to be Open Sourced, and that means the entire project is infringing." Nope, it doesn't work that way. Once code is released under an open source license, that can't do a "I take it back!" thing. 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 released changes (including git commits) whose copyright is owned by the company. I can use fancy legal terms like "latches" and "equitable defenses", but the principle is quite simple: "No backsies." Oracle can say that no new code will be released for Open Solaris, but they can't change their mind on the Open Solaris code already released under an open source license. Again, programmers really should understand basic IP law. It's not that complicated.... > It's also ignores the fact that a nontrivial portion of Silicon Valley was built on top of people who didn't accept those terms. Um, if it's in an employment contract, and you signed it without reading it --- sorry, but I have very little sympathy for you. If you signed it, you agreed to it.
  - 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?

by tytso 7y ago

danShumway 7y ago

> This is not necessarily "give up". "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 joining Google means I need to stop working on it for 3-4 years, then I've effectively given up that project, in the sense that it's no longer going to be maintained or stay relevant. I'm unlikely to go back to a 3-4 year old project and pick it up again later. Most of those projects are dead. > So the fact that there will be some code written by you, but actually owned by Google, is (everyone repeat after me) No Big Deal. Sure, unless your company is Oracle and they decide X years later to say, "actually we own the code and we didn't authorize it to be Open Sourced, and that means the entire project is infringing." People are so ready to say that terms like this are no big deal. If it really doesn't matter who owns the code that gets contributed to an Open Source project, then why is it important that Google own it? If Google isn't going to exploit that code in any way, then they shouldn't have a problem with their employees retaining ownership, right? > Now, it's different if your "side project" is under a proprietary license I think it's unrealistic and unreasonable to assume that every time an employee enriches themselves outside of work, they'll be doing it in relation to an Open Source project. It's also ignores the fact that a nontrivial portion of Silicon Valley was built on top of people who didn't accept those terms. We can say this stuff is standard and it all comes down to individual choice, but we have pretty decent data that universally getting rid of noncompetes was good for the software industry. We have reasonably decent data that allowing employees to work on commercial side projects outside of work would similarly be good for the industry. Labor laws just haven't caught up yet to that point. > Neither side is evil; they just couldn't come to an agreement. I do think that these policies are unethical, that they amount to a kind of attempted takeover of employee autonomy on a level that a business owner shouldn't even be trying to restrict. However, that wasn't the argument I was making when I said this was absurd. I was just making the observation that most businesses don't have as much money as Google to throw at people or to offer them dream jobs. So most businesses who attempt this are giving up any chance of hiring the best developers, because on average the best developers won't tolerate those terms unless they come attached to Google money and a dream job. Obviously, direct competition or conflicts of interest are another story, but nobody is debating them. It's a mistake to start from, "direct conflicts of interest should be avoided", and then immediately extrapolate from there to "a business should own everything that comes out of an employee, anywhere."

tytso 7y ago
> "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 joining Google means I need to stop working on it for 3-4 years, then I've effectively given up that project, in the sense that it's no longer going to be maintained or stay relevant. And what I'm saying is that for an open source project, in general that doesn't happen. And if you're not sure, you negotiate that up front. I did that when I started work for IBM, for example. And it was more than just copyright issues; it included stuff like, "look, I'm one of the chairs of the ipsec working group, and I'd like you to pay for me to travel to IETF meetings so I can finish out my commitment to IETF, even though that doesn't have that much to do with the IBM Linux Technology Center". Everything is negotiable; they might say no, but you'll never know until you ask. More generally, I'm having trouble thinking of situations where you (a) can't take a side project and release it as open source, and (b) you're wanting to keep it proprietary except for "wanting to earn $$$ on a side project" while also drawing from a big company. > Sure, unless your company is Oracle and they decide X years later to say, "actually we own the code and we didn't authorize it to be Open Sourced, and that means the entire project is infringing." Nope, it doesn't work that way. Once code is released under an open source license, that can't do a "I take it back!" thing. 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 released changes (including git commits) whose copyright is owned by the company. I can use fancy legal terms like "latches" and "equitable defenses", but the principle is quite simple: "No backsies." Oracle can say that no new code will be released for Open Solaris, but they can't change their mind on the Open Solaris code already released under an open source license. Again, programmers really should understand basic IP law. It's not that complicated.... > It's also ignores the fact that a nontrivial portion of Silicon Valley was built on top of people who didn't accept those terms. Um, if it's in an employment contract, and you signed it without reading it --- sorry, but I have very little sympathy for you. If you signed it, you agreed to it.
- 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?