You're right, but that's not the reason here. That's with the default filter; you can adjust the date range, or show based on lines added/removed, and I'm still not showing up even in cases when it shows less than 100 people and/or with less total lines added/removed than my commits.
One thing I love in Rust is that it purely makes use of the existing infrastructure that everybody knows - GitHub.
Every Google project uses its own repository, issue tracker, and mailing list. Even many Mozilla projects such as SpiderMonkey require some knowledge to access their infrastructure. However, almost all development in Rust are done only using GitHub. No external dependencies. One exception that is not part of GitHub would be the build bot, though it doesn't matter much.
I know that GitHub centralization is not a good sign, but Rust's all-in-one approach really lowers the barrier to entry significantly.
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.
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.
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)
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.
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.
So, given this process, there is literally no advantage to having anyone sign legal agreements, at all. I don't expect Mozilla to change, of course. :)
As for relicensing:
Both MIT and Apache require copyright notices be reproduced when you ship binaries.
I'll assume MIT since it is the more permissive (Apache also requires you give the user a copy of the license, etc).
Rust is statically linked by default, IIRC (and even shared linking often ends up with some runtime code statically linked in).
If Rust binaries include parts of the MIT code by default (I haven't looked at how the runtime and ABI support is structured), then anyone who ships those binaries would be required to reproduce the copyright notice somewhere.
You cannot take this code and relicense it at will, actually. But you can achieve the same practical effect as relicensing, as long as you reproduce the notice, so i won't get into it unless you really want me to :)
(But note that reproducing the notice is exactly the issue for runtime libraries, and without CLA's in place, you would hav to go and ask all contributors who have ever contributed to the runtime libraries in order to be able to remove that notice reproduction requirement)
> If Rust binaries include parts of the MIT code by default
> (I haven't looked at how the runtime and ABI support is
> structured), then anyone who ships those binaries would
> be required to reproduce the copyright notice somewhere.
"In addition to the UIUC license, the runtime library components of LLVM (compiler_rt, libc++, and libclc) are also licensed under the MIT License, which does not contain the binary redistribution clause. As a user of these runtime libraries, it means that you can choose to use the code under either license (and thus don’t need the binary redistribution clause), and as a contributor to the code that you agree that any contributions to these libraries be licensed under both licenses. We feel that this is important for runtime libraries, because they are implicitly linked into applications and therefore should not subject those applications to the binary redistribution clause."
"Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimers in the documentation and/or other materials provided with the distribution."
Given that it seems that LLVM chose MIT specifically to sidestep any need for end users to distribute licenses with binaries compiled via LLVM, I'd be curious to know where the discrepancy here is.
I actually wrote that wording for LLVM, so i'm happy to explain the discrepancy.
Basically, we messed up when we changed the runtime license (I said MIT license when I meant zlib license, which only requires reproduction of notices in the source code), and had to issue a policy statement on the license to make people happy.
It is not accurate, legally, in its description of the MIT license. Effectively, by this statement, we are giving permission to not reproduce the notice, even though the license would actually require it.
You don't have to take my word for it though, ask any other open source lawyer whether MIT requires notice reproduction for binaries.
:)
I would urge Rust not to make the same mistake.
(This mistake is currently being fixed in a few other "new" languages, in fact)
I'm guessing you can't go giving out concrete legal advice for free, but could you point us towards languages that are fixing this? I see that Julia's stdlib uses MIT for non-external libraries,[1] and Go uses a BSD-style license that explicitly requires distributing the license with binaries,[2] so they're both in the same boat we are. AFAICT D's stdlib uses the Boost license[3] which explicitly allows one to forgo distributing the license with compiled artifacts, but I don't know if solving this issue entirely would require the entire compiler to be licensed under Boost as well. Presuming that interpreted languages can gracefully ignore this issue, I don't know which other "new" languages we could look at for inspiration.
If you don't fix this, you end up with two situations:
1. You accidentally create copyright infringers out of a lot of folks, because the number of people who will properly reproduce the license with static binaries is small.
2. Because of #1, you expose folks to a bunch of liability they weren't expecting.
Neither is a great thing to do to your users.
Combined with the fact that you don't have CLA's that grant you explicit sublicensing rights, anyone who contributes could go off and easily have a sane case against someone for not reproducing the notice. Statutory damages for copyright infringement are up to 150k in the US, sadly.
Anyway, as for other languages, this is being fixed for Go's runtime bits (and possibly stdlib), which i can talk about, but it's not really my secret to share in the case of the other languages I know about fixing it.
> Anyway, as for other languages, this is being fixed for
> Go's runtime bits (and possibly stdlib), which i can talk
> about
Even if I have no power to change anything about Rust myself, if you care to advise I'd love to listen and potentially pass on your wisdom to the core team. And if you'd prefer a different medium than HN comments, you can find my email in my profile. :)
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.
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"
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.
