Hacker News new | ask | show | jobs
by fhs 4216 days ago
Keep in mind that contributing to Go requires that you sign a contributor license agreement, something people might not want to go through (no pun intended) for small changes.
2 comments

I believe Rust requires a CLA as well. Might be wrong, but I seem to remember getting a mail about that a while back. A rust dev that knows for sure can correct me, if necessary.
Rust does not require a CLA.
Not quite right. "Those with review privileges or direct push access are required to file a Mozilla "committer agreement". "

(FWIW: From a legal standpoint, this doesn't make any sense. Either all-in or all-out makes sense. There is no legal distinction to be drawn that the above captures, AFAIK)

See the committer agreement section 4, which covers this case: https://static.mozilla.com/foundation/documents/commit-acces...

All code committed to the Rust repository goes through someone who has signed a CLA, including this section.

Rust uses the same policies here as Firefox.

So does this mean all original code (IE not third party code) requires a CLA?

Or not?

If so, then Rust requires CLAs. Great, legally sound.

If not, this makes no legal sense. Simply having people with a CLA commit it buys you nothing, legally :)

As I said, all-in and all-out policies make sense. Pass through policies (IE i can commit code by another), you may as well have no CLA. It's just overhead with no legal benefit. The benefit of CLA's is to have legal assertions about ownership and patents, from the people who wrote the code.

So without having the people who actually wrote the code make those assertions, you get nothing legally.

In those cases, or if it isn't your goal (like the DCO folks), you might as well move to the developers certificate of origin model, and get the same benefits, without any of the overhead.

The process is as follows:

1. Any Github user submits a PR. This user is not required to have a name or a valid email address.

2. Anyone with review access to the Rust repository (disclaimer: myself included) reviews the PR and leaves a comment on the commit. A bot sees the comment and queues the PR for integration.

I can't comment on the legal implications, but the effect of this process is that there is a very low barrier to entry to contributing and likely explains why the total number of contributors (as measured by Github) is so high.

As to the issue of potential relicensing, the Rust repo is already about as permissively licensed as it gets (a dual license of MIT/Apache 2.0). As far as I understand, this already means that anyone can take the code and relicense it at will (I believe this is exactly what LibreOffice did to OpenOffice). At that point you'd probably still need to distribute the MIT license with each of the original files, but new contributions (and the project as a whole) would be covered by GPL or what have you.

The Mozilla committer agreement is not a CLA as I understand the term - it does not assign copyright to Mozilla, copyright is retained by the original author. The purpose of the document is to assert that those contributing code have the legal authority to do so. In Rust's case, those with review power are the gatekeepers responsible for ensuring the provenance of the code.
> it does not assign copyright to Mozilla

This is common to many CLAs (sane ones, at least). The Go CLA (really the Google CLA[1]) also does not assign copyright to the Go project, it gives them a license to "reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works"

[1] https://cla.developers.google.com/about/google-individual

CLA = Contributor License Agreement

No license agreement should be assigning copyright.

IE All CLA's should be licenses, not assignments.

Any project with a copyright assignment doesn't have a CLA, they have a copyright assignment. :)

BUT this allows for easier changing of the licensing.
That's a "feature"? (from a contributor perspective)
A fairly large number of projects decide to change their license later in life, but this is mostly if they start off with more "restrictive" (for lack of a better term, i know how Free software advocates feel about this) licenses, like GPLv3 or whatever, or because they discover the license doesn't work well for what they wanted.

For example, Eigen, a very widely used math library, switched licenses because they were mistaken about the implications of LGPL, and as it started getting more widely used, it started affecting usage.

Other projects grow runtime libraries, and discover they don't want licenses that require attribution for those, because then everyone who makes a binary has to ship notices, etc.

There are even simpler cases.

For example, llgo, the Go language frontend for LLVM, is being contributed to the LLVM project. This requires a license change to the same license as LLVM. Because there were no contributor agreements, every contributor had to be tracked down and asked. A bunch are either dead or not around anymore, and now those contributions have to be rewritten or excised. This has slowed them down a few months so far (at least from my view, pcc can surely correct me if it hasn't been that long)

In terms of how often this happens, i've personally helped about 50 medium-high profile open source projects change licenses, and it's not even my "real job". It's fairly common that as a project goes from nothing to having a lot of users, they end up having to change something about their licensing.

It's also a massive pain when there are no CLA's.

Sorry I should have put a sarcasm tag :P