Is question 25 from MPL 2.0 FAQ correct?

Question

I'm having difficulty understanding how the text of the Mozilla Public License 2.0 reconciles with their own Frequently Asked Questions, question 25. The question and its answer are as follows:

Q25: What happens if someone doesn't use the per-file boilerplate, and just ships a copy of the full MPL 2 with their code?

The code is licensed under the plain MPL 2. It is not considered Incompatible with Secondary Licenses. Making code Incompatible with Secondary Licenses requires an active choice on the part of the licensor; it is not the default. The notice in Exhibit B is not considered "attached" merely by being present as the Exhibit B of a copy of the full MPL 2.

The only exception is if the code used to be straight MPL 1.1 and was upgraded to MPL 2, in which case it would be Incompatible with Secondary Licenses (Sec. 1.5 b).

Now, imagine a repository consisting of just 3 files:

src/
    mylibrary.h
logo.png
LICENSE  

where the LICENSE file contains the text of MPL 2.0 verbatim. Further, assume that neither logo.png nor src/mylibrary.h have any copyright/license notices: the former by virtue of being a binary file, the latter out of laziness. What is the license of this repository?

Looking at Q25 quoted above, the description "someone doesn't use the per-file boilerplate, and just ships a copy of the full MPL 2 with their code" applies here exactly; and the answer says that in this case "The code is licensed under plain MPL 2".

However, if I look at the text of the license itself, I reach a different conclusion. The clause 1.4 defines what "covered software" is: 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. So it appears that only the files that have a notice from Exhibit A "attached" are covered by the license.

The license does not define the word "attached", but there is a note after Exhibit A that offers a clue:

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, based on this wording, it appears that there are 2 ways to make a file into a "covered software": either put the text of the notice from Exhibit A into the file (presumably as a comment), or have a side-along LICENSE file in the same directory that contains the notice from Exhibit A.

It seems to me that neither of these requirements are satisfied in the example repository shown above. Even Q25 acknowledges that "the notice in Exhibit B is not considered 'attached' merely by being present as the Exhibit B of a copy of the full MPL 2", and I don't see why the same logic wouldn't apply to Exhibit A as well.

So, the big question is: Is Q25 mistaken, and it is not sufficient to merely include into a repository a full copy of MPL-2?

Answer 1

With the repository content as presented, there are two possibilities regarding the licensing status:

1. The presence of the notice in Exhibit A in the files (apart from it being in Exhibit A itself) is considered critical for applying the license. In this case, the lack of the notice means that the repository would not be licensed under the MPL license and is instead unlicensed. This despite the LICENSE file with the text of the MPL license.

2. The notice from exhibit A is not critical and the presence of the LICENSE file with the text of the MPL license is enough to infer that the intent of the author is to license the repository under the MPL license.

Which possibility is true should ultimately be determined by a judge, but the second interpretation is the most likely one. Not in the least because a LICENSE file is a customary way of stating the license that applies to a repository and stating a license in a customary way without intending to apply that license can be seen as deception of the people accessing the repository.

Adding the notice from Exhibit A to all files where it is possible should be done to ensure the license status of the file is always clear, even when it gets separated from the LICENSE file for some reason.

Answer 2

What I understand from both your explanation, the license itself and the answer to the question is that it is sufficient to add the full text if the license in the repo on a place it is expectable - like the LICENSE file in the root of the repo, to license the whole repo as MPL-2.

However, that doesn't stop both the author or third parties from (re)distributing it under other licenses - the original author compatible or incompatible license, third parties only compatible licenses.

For instance, if the author doesn't add any boilerplate in the files and add both a LICENSE.MPL and a LICENSE.GPL files in the repo, it can be assumed that all the files in the repo are licensed as, by choice of any third party, as mpl or gpl.