Hacker News Reader

Comment by CogitoCogito | Hacker News Reader

If I want to distribute derivative works of the Linux kernel, I need to release those works to all. My competitors can take advantage of this, but in the end they are bound by similar rules. This produces a feedback loop in which contributions back may be used by everyone under pretty much equal terms.

If you assign your copyright to Google, they may make use of those changes and integrate them into further development and then _not_ release those changes or release those changes under another license. Do you see the practical difference now?

View on HN

> If I want to distribute derivative works of the Linux kernel, I need to release those works to all.

This is false. The GPL does not require you to make source code available to anybody who asks, only those you distribute the software too (in source or binary form).

If you modify a GPL'ed application and then distribute that to 3 friends, those friends have the right to ask for the (modified) source code. Nobody else does.

Incorrect, under GPLv3 if you do not distribute the source with the object, anyone with a copy of the object code is entitled to request the source code if you do not distribute the object code with the source code. I.e. if those friends give it to someone else your obligation to provide source follows the object to someone else. (This is a short and incomplete summary of section 6).

GPLv2 is even more stringent, if you do not accompany the source with the object than any third party with or without access to the object is entitled to request the source code. (This is a short and incomplete summary of section 3).

I was not commenting on GPLv3. But even so, your first paragraph does not contradict what I wrote. You're also incorrect: there is no transitivity to providing source. Section 6 makes clear that if your offer of source relies on someone else's server (i.e. you are redistributing the work but do not control the location where the source is available): "Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements". These clauses in the GPL cover you the person distributing a copy of the work, not "them" (the people who gave you a copy of the work).

You're incorrect about GPLv2. Section 3 states that if you distribute the work "in object code or executable form", you have to do one of 3 possible things:

  1. accompany the object/executable with machine readable code
  2. accompany the object/executable with a written offer of access to machine readable code
  3. accompany the object/executable with the same information you received with the object/executable. (This option is only available for non-commercial distribution)

So you're simply completely wrong about this.

So we agree we're talking about the second option in GPLv2 then right? Here is the relevant text with the relevant portion emphasized (in italics since hn doesn't have bold).

> b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

GPLv3 has transitivity not GPLv2, but GPLv2 doesn't need it because it already specified any 3rd party.

Edit: Reread what you wrote, GPLv3 b (i.e. written offers) has transitivity, I do think that GPLv3 d does not (but does distribute the source simultaneously with the binary in some sense).

Yes, if you exercise the seond option, the offer would be open to any 3rd party (i.e. it's a public server / URL).

But you only have to give the offer to whomever you give the object/executable to. So you tell them "you can get the source from foo://bar.baz/phaf" ... this just has to be a publically accessible address with no additional authentication or authorization. You are not required to announce this in any way other than in the written offer which accompanies the object/executable.

So, although in theory any third party has access to the source code, you are not being required to put it in a publically visible location, merely a publically accessible one.

[EDIT: I was saying that GPLv3 also does not have transitivity,so we agree about that ]

[EDIT: I admit that I am misleading in my final sentence ... yes, any third party has the right to access the source code, but you are not required to notify "any third party" of this fact, only those you gave the object/executable to. ]

I'm sorry I was unclear. You are correct I didn't intend to imply otherwise. My point was more specific to the case at hand. If Google distributes the code to say an end-consumer, they need to be prepared to distribute the source as well. That consumer can then provide that source to any of Google's competitors and they can make use of it in their own products. In most of these cases a company like Google would probably stop wasting time and simply make the source for any consumer products easily accessible by all.

However, Google need not provide the source to people that they do not distribute the code to (well obviously there are differences between e.g. GPLv2 and GPLv3, but whatever this isn't a legal analysis). For example, if Google uses it internally they may not need to release the source to anyone at all. They're all important points that more people need to understand, but they aren't really the ones that I was making in this thread and none of them are really specific to Google vs. other companies.

You are describing the difference between the GPL and BSD-like licenses.

You have not said anything about the difference between a BSD-like license with copyright remaining with the contributors versus BSD-like license with copyright assigned to Google.

Well if I have the copyright I can straight up sell software based upon it without telling people you made it. Or I can release your code or derivatives of it under a different license while privately selling it under other licenses for profit. If these things don't bother you, then feel free to contribute.

In fact, what I'm trying to understand exactly is if I assume that you are correct that there is no difference, then why would Google require the contribution in the first place?

edit: If this ( https://cla.developers.google.com/about/google-individual ) is the CLA in question, then you additionally agree on a patent grant to Google and those those Google distributes it to. So if Samsung takes the code and distributes it to other customers those customers and Samsung are not covered by the same grant? Why is this all centered on Google? Why is not simply a general patent grant as part of the submission to anyone receiving the code?

> In fact, what I'm trying to understand exactly is if I assume that you are correct that there is no difference, then why would Google require the contribution in the first place?

The difference isn't relevant 99% of the time, but it comes up if the maintainership of a work tries to re-license the work. Works without assigned ownership cannot practically be re-licensed, as you'd have to get individual consent from all owning parties.

This came up a lot when GPLv3 was introduced — many projects wanted to migrate from GPLv2 to GPLv3, but couldn't, because they never acquired legal ownership of contributed code, and so didn't have the right to re-license the contributors' code.

> it comes up if the maintainership of a work tries to re-license the work

Bingo! Google will relicense Fuchsia to OEMs etc. under new terms if they want to include Google services.

Well, sure. Because people who want to develop products on some platform also want some kind of warranty, which is explicitly not provided.

Google establishes with the public a warranty- and guarantee-free use license. If someone feels they've been harmed by the software, they're prevented by the open source license from suing Google, but they're (more importantly) also giving up their right to sue the individual contributors.

At the same time, vendors want to be able to hold suppliers accountable for support and warranty on products that are supplied. Permitting sublicensing allows Google to sell the software to OEMs and vendors with support agreements that allow those vendors to hold Google responsible for that support (rather than the individual contributors).

There's a lot of complaint about the sublicensing going on, but I think most vendors aren't going to build systems where they can't get support, and I don't think contributors actually want to be liable under tort law for the code they provided for free.

Then again, maybe the objection is to giving code to Google that Google can profit from. I guess that's fair, but you don't _have_ to contribute code and you're also not prevented from sublicensing and trying to turn a profit yourself.

(edit: typo)

> The difference isn't relevant 99% of the time, but it comes up if the maintainership of a work tries to re-license the work. Works without assigned ownership cannot practically be re-licensed, as you'd have to get individual consent from all owning parties.

Yeah I understand this. Hence there _is_ a difference and maybe one I don't prefer. I understand why Google would want this, but maybe I view Google's inability to relicense my code as a feature and not a bug.

In any case, I think the people involved in this back and forth essentially understand the state of things. I only seems some of us disagree on whether we should care. If people want to sign CLA's with Google that's their prerogative. If they understand what they're doing, more power to them. I don't like that Google has special preference over other actors, but that's just me.

edit:

> This came up a lot when GPLv3 was introduced — many projects wanted to migrate from GPLv2 to GPLv3, but couldn't, because they never acquired legal ownership of contributed code, and so didn't have the right to re-license the contributors' code.

Sure there are a lot of people who didn't like that, but maybe those who contributed their code under the GPLv2 never would have done so if they knew it would change to GPLv3 (not that he's more important than others, but Torvalds seems to fall in this camp)? Their wishes should be respected. Besides in those specific cases the projects could have avoided it by only accepting code licensed as "GPLv2 or later" so a CLA wasn't really required in that case anyway (though obviously that only applies to this specific GPLv2 -> GPLv3 case and not more generally).

IIRC in most cases it wasn’t so much that anyone actively disagreed with the licensing change, as that it was infeasible to even get in contact with the literally thousands of contributors — especially since many of them have left no contact details that could be used for legal correspondence.

Imagine a country with direct democracy, where a 100% consensus of all citizens is required for any law to be passed. Now imagine that a single citizen of that country decides to go live in the mountains, out of contact with the rest of the country, but still legally alive and legally a citizen, and therefore legally a "required" vote. The legislative process grinds to a halt!

This is, of course, why no government is run that way. And it's equally silly to run a FOSS project that way. Even if literally everybody likes some change, just one contributor failing to get in contact means you're stuck without the ability to make the change.

> IIRC in most cases it wasn’t so much that anyone actively disagreed with the licensing change, as that it was infeasible to even get in contact with the literally thousands of contributors — especially since many of them have left no contact details that could be used for legal correspondence.

Maybe yes and maybe no.

> ...The legislative process grinds to a halt!

You're being a bit overly dramatic. The software development process can continue just as it did before, they just can't retroactively change the license on code they do not own. It is true that maybe the project might die partially due to a lack of adoption due to people not liking the license, but he project may die for many other reasons as well. Also the project isn't gone anyway. It continues just as before.

> This is, of course, why no government is run that way. And it's equally silly to run a FOSS project that way. Even if literally everybody likes some change, just one contributor failing to get in contact means you're stuck without the ability to make the change.

There is one government, but there are many competing software projects. If one goes into decline it's not the end of the world. Besides the software project is not gone, it's still there. The fact that there are so many popular projects without the ability to change their licenses shows that the model can work just fine.

Look if you want to start a project and require a CLA be my guest. If you want to join a project with a CLA, go ahead. Just be aware that CLA's will deter some contributors. Weigh these trade-offs however you wish.

I think there is a lesson in here somewhere about the evolution of Linux as a platform, versus the evolution of Android as a platform.

In particular, it seems that the license terms of Linux caused Android to become "as open as it needs to be, and no more open".

I expect that Fucshia will take the same path as Android, as opposed to the path of core Linux.

Reply on news.ycombinator.com