Add explicit MPL-2.0 licence notice "Exhibit A" #87
Conversation
Unlike most other Free Software licences, the MPL explicitly says it
applies only to files with a specific notice:
1.4. "Covered Software"
means Source Code Form to which the initial Contributor has attached
the notice in Exhibit A, the Executable Form of such Source Code
Form, and Modifications of such Source Code Form, in each case
including portions thereof.
Unfortunately, this means that copying the MPL text into tree, and
setting the "license" Cargo option, leaves an ambiguous situation.
One might presume that the intent was to actually *use* the MPL for
the whole project, but the legal licence text explicitly rejects that.
Thankfully, according to the licence text, it is not actually
necessary to add the notice to *every* file:
If it is not possible or desirable to put the notice in a particular
file, then You may include the notice in a location (such as a LICENSE
file in a relevant directory) where a recipient would be likely to look
for such a notice.
So clarify this situation by adding two explicit copies of the
MPL "Exhibit A" text, one in each affected crate subtree, and declare
them to apply to everything.
Putting these in Cargo.toml puts them next to the "license =" tag.
Another possibility would be `README.md` but IMO this legal
technicality doesn't really warrant such exposure.
(Putting it in the LICENCE file, as the text itself suggests, would
mean either (i) renaming the verbatim copy of the MPL 2.0 and writing
a new file or (ii) adding it as a rubric to the top of the MPL 2.0
text in LICENCE - resulting in a LICENCE file which is not identical
to the usual MPL-2.0 text file. Neither of those seem desirable.
Putting just once it at the repository toplevel would mean it didn't
appear in .crate files, and also require explicitly stating which
subsections of the repository are covered.)
ijackson
force-pushed
the
mpl-exhibit-a
branch
from
946bcf4 to
2e494d7
Compare
|
What is the motivation for this PR? Is someone asserting the common practice of asserting the MPL in the |
I'm sorry to say, that, yes, sadly, it is insufficient. This is a highly unusual feature of the MPL. For other licences, putting the licence in the For the MPL, lthat's not the case, because the very text of the MPL itself contradicts that assumption. So doing what is right and proper for any other licence, is wrong for the MPL. (I think this is arguably a bug in the MPL.)
Section 1.4 of the MPL defines "Covered Software" to be (only) software where we have "attached the notice in Exhibit A", It gives a copyright licence only to those parts. With this MR merged, the MPL is being applied to the code in these two crates, and the licence is clear. Without ithis MR merged section 1.4 of the MPL itself states that those crates are not "Covered Software" and therefore are not subject to the rest of the permissions and restrictions in the MPL. So the licence of those programs is contradictory, unclear, or maybe there is no copyright licence. |
|
Again, what is motivating this PR? Did your lawyer flag this as a potential risk? |
|
Now I come to look at this, I think MPL is no longer relevant since we moved to CCADB. Instead I think https://www.ccadb.org/rootstores/usage#ccadb-data-usage-terms applies? |
OIC, sorry for misunderstanding your question. I'm making this MR now because we (Arti, the Tor Project's RIIR) received an MR adding direct support for The automated licence check is this way because I and my colleagues looked at the MPL text the first time we pulled in an MPL'd dependency, and concluded that without the Exhibit A text the licence is at best contradictory and at worst missing entirely. We have made similar MRs to two or three other projects, which were accepted without pushback. I think it's fair to say that I led that analysis. I am not a lawyer; I'm an engineer. But I do have some legal experience: I've been a successful litigant in person in England on multiple occasions; in some of my past roles I've asissted in-house counsel when they weren't familiar with Free Software / Open Source licence practices; I've helped with copyright review in Debian; etc. (You may also know my name as the author of the Debian Constitution.) So while I don't have credentials, I do feel that the team I'm part of is competent to make this assessment. I hope it won't be necessary for us to obtain a formal legal opinion. Thanks for your consideration. |
That looks like a permissive Free Software licence to me, very similar to MIT. I haven't diff'd the text, though. I notice that it doesn't seem to be listed in the SPDX Licence List nor at |
|
Oh you're ahead of me! |
Unlike most other Free Software licences, the MPL explicitly says it applies only to files with a specific notice:
Unfortunately, this means that copying the MPL text into tree, and setting the "license" Cargo option, leaves an ambiguous situation. One might presume that the intent was to actually use the MPL for the whole project, but the legal licence text explicitly rejects that.
Thankfully, according to the licence text, it is not actually necessary to add the notice to every file:
So clarify this situation by adding two explicit copies of the MPL "Exhibit A" text, one in each affected crate subtree, and declare them to apply to everything.
Putting these in Cargo.toml puts them next to the "license =" tag. Another possibility would be
README.mdbut IMO this legal technicality doesn't really warrant such exposure.(Putting it in the LICENCE file, as the text itself suggests, would mean either (i) renaming the verbatim copy of the MPL 2.0 and writing a new file or (ii) adding it as a rubric to the top of the MPL 2.0 text in LICENCE - resulting in a LICENCE file which is not identical to the usual MPL-2.0 text file. Neither of those seem desirable.
Putting just once it at the repository toplevel would mean it didn't appear in .crate files, and also require explicitly stating which subsections of the repository are covered.)
(Commit message text adapted from similar situations in option-ext and generational-arena