This looks good to me, with some comments:

• Perhaps LICENSE.BSD is a better name so that "ls LICENSE*" works.
• The restriction on secondary licensing is unusual usage of MPLv2 and may be problematic. It in effect it prevents mixing the MPLv2 code with other codebases. Including commercial code. Unless you have specific reasons for doing this, I'd recommend against it.
• Further, according to https://www.mozilla.org/en-US/MPL/2.0/FAQ/, to enable the restriction on secondary licensing you should specify it in each source file. Simply having it present does not "attach" it.

The restriction on secondary licensing is unusual usage of MPLv2 and may be problematic. It in effect it prevents mixing the MPLv2 code with other codebases. Including commercial code. Unless you have specific reasons for doing this, I'd recommend against it.

I'm not entirely sure what you mean, but doesn't the MPL 2.0 explicitly allow mixing with BSD? From the MPL 2.0 FAQ:

Q13: May I combine MPL-licensed code and BSD-licensed code in the same executable program? What about Apache?

Yes to both. Mozilla currently does this with BSD-licensed code. For example, libvpx, which is used in Firefox to decode WebM video, is under a BSD license.

The "Secondary licenses" referred to in the MPL 2.0 seem to refer to the various (L)GPL flavours. I'm not sure how that would apply when using the BSD license instead.

Ah, you're right, sorry. It does mean various L(GPL) flavors.

The details are in section 3.3. It is confusing. The default model is that the software is compatible with secondary licenses. This is what you generally want. It means if Rubinius code is used in a GPL project, the user can re-dtsirbuted that under MPLv2 again. If you state (in the source file, not in a separate license) that the source file is not compatible with secondary licenses, this right is lost. That's my reading of it.

In any case this text only works when embedded in a source. (Otherwise it's lost when you copy individual source files.)

I'd recommend removing it and using the vanilla MPLv2.

@hintjens Ah OK. I also agree it's a better choice to move to just the MPL 2.0, for both past and future contributions. I'd rather go through the pain of getting everybody to reply than having to deal with a confusing license that may one day bite us in the butt.

Yes, custom licenses tend to be troublesome. We did this to the LGPL, for ZeroMQ, modifying it to get much the same as MPLv2 (which did not exist at the time). It's always been a source of confusion.

A simple way is to open an issue with a todo list of all contributors' names, and get everyone to comment on the issue. Here's how we did this for Zyre: zeromq/zyre#327. You can then pester people by email out of band.

@hintjens Yeah, I was thinking about something along those lines. Thanks for the info.

@hintjens thanks again for all the help. Much appreciated. And thanks @yorickpeterse for leading the effort.

How did I miss this happening? Why did it happen?

License incompatibilities just ruined my day.

@apotheon could you elaborate on what you think is incompatible with what?

disclaimer: I am not a lawyer. This is not legal advice. If you need legal advice, seek the counsel of a legal professional. I disclaim all liability for actions taken in light of my comments, offered solely as opinion.

(As Mr. Bumble of Oliver Twist said, "the law is a ass": any time I discuss my understanding of the law in any depth, I feel compelled to disclaim my statements for my own protection.)

There are many ways in which (even weakly) copyleft licenses are incompatible with other licenses. This can get extremely dangerous especially when dealing with a programming language like Ruby where, in the course of perfectly reasonable (okay, some people disagree it's reasonable, but I think most of them are using Java or C++) work, one might need to make alterations to existing, open classes. The law has not, to my knowledge, been tested on such things, and the supposed "per-file" scope of the MPL may not conceptually excuse such modification of the original work, so that activities like monkeypatching or even subclassing (either pushing changes up the chain or pulling them down) may result in an effective violation if the changes themselves must, for some reason, be used under terms incompatible with the MPL's terms.

I have to ask . . . why did you choose MPL 2.0 as the new license? What exactly was the licensing need that prompted this change? Was it the enforced source distribution?

@apotheon I suggest reading #3550.

If that's a reference to an explanation of the reason for the change, it is somewhat vague, apart from a statement about patents and a statement about "who owns what". The "and so forth" means nothing to me.

Rather than clutter up the contributor survey there, I'll share my thoughts here:

1. There are more widely compatible licenses than the MPL that deal more explicitly with patents than the Revised BSD License.
2. MPL itself does not provide any guidance on "who owns what" beyond the absolute necessities of the license's restrictions, so far as I recall (or notice on skimming the license text once more). What it does do is take a little time to explain how the MPL interacts with a few other licenses, to carve out some level of compatibility with a few, very specific licenses that are, themselves, broadly incompatible with other licenses. This is not surprising, but offers no benefit in and of itself over the Revised BSD License, which does not have the same compatibility problems, and thus does not need that explicit treatment.

Apart from that, I am not sure why you recommend reading #3550. As you can see, I am not picked out as part of the list of GitHub contributors. I think I did contribute to some documentation at one point, but I'm about as close to certain as I can be (without some serious research) that it has been obsolesced in the years since, so you should not need my permission for any relicensing as a contributor. A recent renewed interest in Rubinius might have prompted some contributions, but I have not made any yet, and am now unlikely to do so given the constraints of the new project license, so no worries about me, as a contributor, having any legal standing on the matter of relicensing.

@apotheon You are not on the list as the GitHub API did not return your username in the list of contributors.

The MPL 2.0 is a perfectly valid/fine license, probably better than most out there. If you have any specific concerns please address those either in Gitter or via an issue, it's hard to keep track of them via commit comments. So far I'm not seeing any solid arguments, other than vague statements about compatibility (which isn't even relevant since we're fully swapping over the license with permission of past contributors).

@apotheon you may find this post interesting. There are also other resources available. From my understanding, MPL-2.0 provides better protection against patent trolls and is a reasonable license. Again, IANAL and we're not having a legal debate here. More importantly, we're not debating the license. If you are a contributor, we've asked that you consent to the new license. Anyone is free to contribute or not based on their understanding of the license.

Thanks for taking the time to express your concern.

It's not a big deal. I'm just one disappointed guy. While many consider it a "perfectly valid/fine license", it does have some license incompatibility issues, and that's a big chunk of the reason I'm disappointed -- but that's surely of no concern to the larger project or community.

I'm not seeing any solid arguments

I'm not making arguments. I'm explaining why I'm disappointed by the news, because someone responded to my comment and asked.

vague statements about compatibility (which isn't even relevant since we're fully swapping over the license with permission of past contributors)

They are not vague; I gave some rather specific explanation. They're not a problem for the project relicensing per se: they're a problem for what would have been my potential use of the software, and may affect other users, in possible future edge cases (such as, perhaps, certain techniques in language design that might aim to take advantage of the unique design of Rubinius itself).

Please don't take this as some kind of campaign to change your mind or make you look bad. I made a somewhat spontaneous noise of dismay, and replied as fully and politely as I could to requests for clarification. That is all.