4 ms·
marcan_42, I will have been at Google for 10 years in January, and even back then the Open Source policies were part of the Noogler training, and the fact that
by tytso 7y ago
marcan_42, I will have been at Google for 10 years in January, and even back then the Open Source policies were part of the Noogler training, and the fact that Google would own everything you did, even on your own time, was clearly in the stated in the employement document, as well as a place for you list everything that you had worked on before you started work at Google and so was your Intellectual Property (IP).
Google's open source policies is now fully public (as of a few years ago), and I can affirm that they haven't changed substantially in the last ten years. It's all here[1], including the statement releasing code as open source under the Google copyright was very clearly documented in the IARC process[2]:
[1] https://opensource.google/docs/ https://opensource.google/docs/
[2] https://opensource.google/docs/iarc/ https://opensource.google/docs/iarc/
So I have trouble taking your complaint that "Google didn't tell me that I had an alternative" seriously. Also, from your description, a huge portion of your contributions that you listed were in the Linux and associated projects (such as Pulse Audio). So all of this would have required one, or perhaps two, requests to release OSS patches; once you have done that for one or two contributions, it's no longer necessary to ask permission for subsequent patches to a OSS project. (This is true for all Googlers.) Asking for permission to release those under GPL is trivial, and is granted as a matter of course. Lots of other Googlers have done it, without problem, and most have not complained the OSS releasing process is heavyweight. IARC is more heavyweight, yes, but it's right there in the IARC process documentation that the OSS releasing process is the preferred option, and that it is lightweight.
Before I started working at VA Linux Systems or at IBM, I had taken the class, "Law for an I/T Manager" at the MIT Sloan School. So I was very well aware of IP law issues (patents, copyright, and trade secrets), and how to read contracts, including employment contracts. So none of this took my surprise (either at VA Linux Systems or at IBM, both of which had similar provisions in the employment contract); perhaps you didn't bother to take the time to read the employment contract and perhaps you didn't bother to read the very clear web pages at Google's Open Source Program Office. I can't speak to what you experienced at your Noogler training, so it's unclear whether you weren't paying attention, or it's since been streamlined. But if you found the IARC documentation so you could submitted the IARC request, you should have found rest, and this shouldn't have been a surprise to you.
- delroth 7y ago> most have not complained the OSS releasing process is heavyweight Citation needed. I have been at Google for 6 years and I have seen many people either 1. quit in frustration at our OSS policy; 2. stop contributing to OSS projects on their free time because of frustration with our policy; 3. just ignore the OSS policy at the risk of getting fired because the precedent is that most people ignore the policy. Most people I talk with do (3), nobody will admit to it publicly though. I'm right now waiting for an IARC approval for a small HTML+Typescript that took me 6h to build on a weekend and that I want to MIT-license. This has now been pending for 2 weeks. This is completely ridiculous and it means there is just no reasonable way for someone to follow the policy while doing small side projects on the weekend. Going through the releasing process would have taken roughly the same time, except that Google would also probably not be interested in owning that code for multiple reasons.
- joshuamorton 7y ago> I'm right now waiting for an IARC approval for a small HTML+Typescript that took me 6h Why do you want IARC and not patching approval for that? Unless your intent is to make money from it in the future, there's really no need to engage in the IARC process. Patching approval is painless, and the easiest process for something that you want to be considered to exist outside of Google (its owned by you in your personal capacity, but google maintains copyright to your while-employed-by-google contributions), and doesn't require IARC or any approval other than a quick self-approval process for the first few commits. Then it requires nothing.
- delroth 7y agoFor example, because I don't want people to have to sign a CLA to contribute patches to my weekend side projects? That's incredibly dev hostile.
- joshuamorton 7y agoUnless it's changed recently, projects released under patching (again, not releasing) don't require a signed cla (edit: just checked and they don't). They're not Google owned, Google just maintains ownership of your contributions. And if you look at the releasing guidelines, they only make sense for code developed in google3 and later released. You can't actually follow the releasing process for code developed on non-google hardware, your only option is to follow the patching or iarc methods, and patching is trivially easy and doesn't require anyone to sign a cla.