Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Break up old/new license & clarify what we use #3548

Merged
merged 1 commit into from Jan 3, 2016
Merged

Break up old/new license & clarify what we use #3548

merged 1 commit into from Jan 3, 2016

Conversation

@YorickPeterse
Copy link
Member

@YorickPeterse YorickPeterse commented Jan 3, 2016

I decided to move the BSD license to a separate file as I feel uncomfortable adding any extra clauses to the MPL 2.0 license. I also feel it would be too easy to miss the BSD license at the bottom of the already long MPL 2.0 license. As far as I'm aware the BSD license does not disallow renaming license files, thus I believe we should be fine.

cc @brixen @hintjens

@brixen
Copy link
Member

@brixen brixen commented Jan 3, 2016

Thanks @YorickPeterse, that looks more clear.

Loading

brixen added a commit that referenced this issue Jan 3, 2016
Break up old/new license & clarify what we use
@brixen brixen merged commit 6b35d17 into master Jan 3, 2016
@jemc
Copy link
Member

@jemc jemc commented Jan 3, 2016

Thanks, @YorickPeterse!

Loading

hintjens
Copy link

hintjens commented on 243c0b2 Jan 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Loading

YorickPeterse
Copy link
Member

YorickPeterse commented on 243c0b2 Jan 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Loading

hintjens
Copy link

hintjens commented on 243c0b2 Jan 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Loading

YorickPeterse
Copy link
Member

YorickPeterse commented on 243c0b2 Jan 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Loading

hintjens
Copy link

hintjens commented on 243c0b2 Jan 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Loading

YorickPeterse
Copy link
Member

YorickPeterse commented on 243c0b2 Jan 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Loading

brixen
Copy link
Member

brixen commented on 243c0b2 Jan 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Loading

apotheon
Copy link

apotheon commented on 243c0b2 Jan 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

License incompatibilities just ruined my day.

Loading

brixen
Copy link
Member

brixen commented on 243c0b2 Jan 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Loading

apotheon
Copy link

apotheon commented on 243c0b2 Jan 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Loading

YorickPeterse
Copy link
Member

YorickPeterse commented on 243c0b2 Jan 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@apotheon I suggest reading #3550.

Loading

apotheon
Copy link

apotheon commented on 243c0b2 Jan 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Loading

YorickPeterse
Copy link
Member

YorickPeterse commented on 243c0b2 Jan 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Loading

brixen
Copy link
Member

brixen commented on 243c0b2 Jan 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Loading

apotheon
Copy link

apotheon commented on 243c0b2 Jan 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Loading

@brixen brixen deleted the relicense branch Jan 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants