> Looks like you still cannot contribute without granting copyright ownership to Google

That is not accurate. Fuchsia uses the standard Google CLA:

"You do not surrender ownership of your contribution, and you do not give up any of your rights to use your contribution elsewhere."

https://cla.developers.google.com/about

There's a big difference between licensing code to the world under the terms of Apache 2.0, and licensing code to Google under whatever terms they feel like now or at any time in the future.

I don't think it's an important difference. If you're doing open source at all, you're losing control over what's done with your code, including allowing it to be used by competitors and "bad guys" however you define that.

See (5) and (6) in the open source definition: no discrimination against persons or groups, and no discrimination against fields of endeavor.

If you're unwilling to relinquish control, no open source license is going to be good enough. At best you might scare some risk-adverse companies away from using it, but there are still going to be a lot of people you dislike who can use your software to nefarious ends.

Is there? Apache 2.0 includes clauses for patent indemnification and allowing sub-licensing derived work.

ADDED. Looks like this comment and its replies have no relevance to the Fuchsia project: https://news.ycombinator.com/item?id=25348935

You used to not be able to contribute to most GNU projects (maybe you still can't) without assigning copyright ownership to the FSF.

I don't see what practical difference the assignment to Google will make. Without using the words "equality", "between equals" and "sharecropper", can you give an example of something you or I will not be able to do with the code that you or I would have been able to do if the copyright had remained with the contributors?

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?

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

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.

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. ]

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.

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

> 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)

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.

The FSF is a non profit organisation, Google is one of the biggest corporations. There is a big difference.

Doesn't invalidate the original post if you were to replace google with FSF. You might be fine granting ownership to the FSF, but not everyone is.

Linux itself has never been a GNU project and has never required copyright assignment. It is the combination of features (retain ownership and GPL) together that has enabled collaboration in Linux.

Are you saying that collaboration on Gnu Compiler Collection, binutils, bash, bison, CLISP, coreutils, etc, has been inhibited by the requirement for copyright assignment to the FSF?

There's a big difference between GNU and Linux in terms of their collaboration. With the exception of GCC, most of the utilities you named have been maintained by a very small group of people.

GCC itself has definitely been inhibited by the copyright assignment. There have been a few different ports that were not upstreamed specifically because of the CLA. AVR32 and C6000 come to mind off the top of my head.

As far as I am aware, the only times contributions were not incorporated were because the work was done by under the terms of an employment contract with the result that the employer ended up owning the copyright, then the employer decided not to sign the CLA.

Can you think of a single instance in which code written by an individual contributor not bound by an employment contract was prevented from being incorporated into a project that required copyright be assigned to a central entity?

I have read multiple accounts of open-source contributors who have successfully negotiated when being hired that copyright to any code written on their own time on the own hardware will remain with them (so as not to complicate their contributions to open-source projects).

I'm not sure what your point is. The exceeding majority of the work done on these foundational projects has been done as works for hire. The issue isn't the relationship between Google and Coder Jane. Its between Google and Red Hat. Its between Google and Samsung.

Intel and ARM both collaborate on GCC and Linux all the time while being fierce competitors. Google, Canonical, Red Hat, etc all contribute to Linux while being fierce competitors.

But the only companies that contribute to Android and ChromeOS are device partners, and the partner contributions are far more limited in scope.

That is a significant limitation. A considerable amount of open source software is written while people are employed, as part of their work.

Sure, but no open-source project wants contributions by contributors who do not legally own the code because in that case the actual owner of the code can petition the court to issue an injuction on the project preventing further distribution of the code till the offending code is removed from the project. (They can also sue any user of the project for damages.)

Wikipedia has to worry about the same thing, BTW: contributors who upload text whose copyright is owned by some entity who never consented to the upload, and they have policies in procedures in place to correct it when it happens.

It's not like CLA's are the only obstacle to employees contributing to the open-source projects. In fact, you might say that the main purpose of a CLA is to surface copyright-ownership problems early, when the cost of correcting them is lower.

Copyright attestation is only one small element of a CLA. I have no problem with an attestation of ownership.

I think this is why samba refuses contributions from corporations:

https://www.samba.org/samba/devel/copyright-policy.html

I agree that no project wants that situation. But many projects are willing to accept the risk of it happening, and instead have reduced friction with no CLA.

Only one datapoint, but I have refrained from contributing to GNU partly[1] because of the copyright assignment requirement, while having committed to many other open-source projects I use.

1: TBH it's hard to tease apart the cultural aspects from the legal. Most GNU projects were roughly "We'll post a tarball once in a while and not have public CVS" when I first started getting involved in OSS; projects with public CVS it was a lot easier to tell if someone was already was working on something, particularly for people as shy as I was back then; I got the impression that the "proper" thing to do would be to introduce yourself on the mailing list, propose the idea, &c. and then start working on a patch.

My particular combination of low-confidence and misanthropy steered me away from such projects.

I'm sure it has. It's an additional hurdle that developers have to clear before they get their code included upstream -- it would be extremely surprising if there weren't some number of developers who gave up at that point.

(It doesn't help that the FSF's processes for copyright assignment are incredibly clunky. It was a big deal when they started accepting scanned papers in 2012, for example.)

The FSF is not Google. Their organizational goals are different enough that the repercussions of copyright assignment are different in each of those cases.

Basically I trust the FSF to stand by the spirit of open source. I don't trust that out of Google.

Sure. I don't contribute to projects that require copyright assignment to the FSF. For one thing, it's a major hassle for new contributors. For another, I don't particularly like or trust the FSF.

To a large degree, yes. I have definitely not bothered sending patches to these projects because I can't be bothered with copyright assignment.

And that's with trust that the FSFs goals on copyright align with mine.

I don't trust Google to do what I want with my assigned copyright.

> You used to not be able to contribute to most GNU projects (maybe you still can't) without assigning copyright ownership to the FSF.

Even were that true today, the difference is that I basically trust the FSF.

With BSD-style licenses there's still a strong incentive to share code. That's why permissively-licensed projects, from Node, to PostgreSQL, to FreeBSD, work.

With GPL-style licenses, there's an incentive to avoid putting effort into development, and instead undercut other parties who did invest, and then had to share their code.

> That's why permissively-licensed projects, from Node, to PostgreSQL, to FreeBSD, work.

Sure, but there are plenty of copyleft-licensed projects that also work? This isn't a very convincing argument.

Sure, both work. It's a counter-argument to the claim that GPL is somehow superior.