1192790 - Correct the LICENSE file requirements on the "Mozilla License Headers" page

Status: RESOLVED WONTFIX

(mozilla.org :: Licensing, task)

Description

[Ed Morley [:emorley]]

The MPL v2's exhibit A (https://www.mozilla.org/MPL/2.0/) says:

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


However on https://www.mozilla.org/MPL/headers/ the text reads:

"""
This license must be used for all new code, unless the containing project, module or externally-imported codebase uses a different license. If you can't put a header in the file due to its structure, please put it in a LICENSE file in the same directory.
"""

...which implies (a) the header really should be used unless the structure doesn't allow it, and (b) the LICENSE file must be in the same directory. 

This is incorrect, since the MPL uses the4 phrases "or desirable" and "relevant directory" - and caused confusion when I was trying to figure out if the Treeherder project could remove the boilerplate license text (which breaks some of our files) and just use the LICENSE.txt in the root of the Github repository.

A better wording may be something like:

"""
This license must be used for all new code, unless the containing project, module or externally-imported codebase uses a different license. If it is not possible or desirable to put the header in a file, please include it in a LICENSE file in an appropriate directory.
"""

Thanks :-)

Comment 1

[Gervase Markham [:gerv]]

(In reply to Ed Morley [:emorley] from comment #0)
> ...which implies (a) the header really should be used unless the structure
> doesn't allow it, and (b) the LICENSE file must be in the same directory. 

Yes, that's correct. Mozilla's policy is our (enforced) best practice. Doing other things is permitted by the MPL (and therefore the code is still validly licensed) but we don't think it's a good idea for various practical reasons, and so our license policy has a stricter standard.

If the license header breaks some of your files (the file format has no comment character - is it JSON?) then stick a LICENSE file in the same directory. If there is an entire tree of directories, all of which's files have this problem, then one at the top of that part of the tree would be OK. But the LICENSE file at the root should contain a copy of the full MPL, not of the boilerplate.

Gerv

Comment 2

[Ed Morley [:emorley]]

We have json files, files read by eg Heroku (runtime.txt ; bug 1176253), html files where it's annoying to bloat the size of the assets (or have to pre-process them to strip it out) - and then user preference as to not having to include boilerplate in each file, given our project is small webdev project and not a complex mixture of third party code that ships to end users (eg mozilla-central).

Comment 3

[Ed Morley [:emorley]]

It just seems daft to have to copy/paste the boilerplate everywhere (or have a LICENSE file in every directory), when we could just have one in the root of the repo, with a "Unless otherwise specified, this LICENSE applies to all files in this repository".

Comment 4

[Gervase Markham [:gerv]]

http://lu.is/blog/2012/03/17/on-the-importance-of-per-file-license-information/ has the best explanation of why this is a best practice, despite the possible inconvenience to us.

Gerv

Comment 5

[Ed Morley [:emorley]]

Thank you for that link :-)

In rough summary of that post, using per file:
(a) avoids the LICENSE file becoming separated from the individual files, since "files get separated from their parent projects and directories all the time"
(b) is important since "The functional, practical benefits of open source all start with someone else reusing your code, so if you’re publishing open source code at all, you should be concerned about making it easy for people to use the code you publish."
(c) however for modern frameworks (which tend to promote short files), the header text is more of an issue than it might have been in the past

Whilst [a] may be true for traditional software projects (eg someone breaks out a jpeg library from its parent repo to another repo, or the project source is repackaged in an gzip archive with the LICENSE file accidentally missing), I'm not sure it's as relevant for webdev projects. Website source tends to only be distributed in repository form (rather than as a gzip archive; particularly in a Github era) or as assets served from production. The latter is likely to have been pre-processed, in which case the per file headers are removed anyway.

Regarding [b], I'm not convinced by the reasoning. We don't open source the Treeherder repo because we specifically want people to re-use it (that's just a happy coincidence, albeit unlikely, given how specific Treeherder is to Mozilla), we open source it since (a) there's no reason not to [/I personally like open source :-)], (b) it's what Mozilla does, and (c) it means we can attract external contributors. With modern site development heavily learning on third party packages and libraries, I would think there is much less re-usable content within a modern webdev project repository, than with a traditional software repository like mozilla-central.

I think this boils down to:

P(that it impacts someone's ability to reuse code from the project) vs <inconvenience caused to those working on the project>

I would posit...

For a traditional software project:
 - P(x) is high, since:
   * the source is more likely to become separated from the LICENSE
   * there are likely people re-using the code
 - <inconvenience> is low, since:
   * average file length is longer

However for a webdev project:
 - P(x) is low, since:
   * the source is less likely to become separated from LICENSE
   * there are likely fewer people who want to re-use the code
 - <inconvenience> is higher, since:
   * average file length is short

As such, I think it's worth the trade-off for certain webdev projects.

It's worth also noting that there are several webdev projects under Mozilla's github org that used BSD deliberately to avoid the per-file requirement of MPL v1. It would be a shame for other projects to mistakenly feel that they had to avoid MPL2 for the same reason.

I won't object to this bug being WONTFIXED (I can definitely see the merits of this being the recommended best practice for many projects), so long as small webdev projects are able to follow the MPL 2.0's wording and omit the license header if they are happy with the trade-off.

Either way, thank you for increasing my understanding of this area :-)

Comment 6

[Gervase Markham [:gerv]]

(In reply to Ed Morley [:emorley] from comment #5)
> I won't object to this bug being WONTFIXED (I can definitely see the merits
> of this being the recommended best practice for many projects), so long as
> small webdev projects are able to follow the MPL 2.0's wording and omit the
> license header if they are happy with the trade-off.

Well, the license policies don't say "it's OK to use BSD", but that hasn't stopped several webdev projects from doing exactly that! :-) I have neither time nor inclination to go chasing tiny one-off webdev projects and hassling them about per-file license information. But I do think this should remain the documented and recommended best practice.

Gerv