715558 - (sdk-mpl2) MPL 2 upgrade: Jetpack (AddOn SDK)

Status: RESOLVED FIXED

(mozilla.org :: Licensing, task)

Description

[Gervase Markham [:gerv]]

This bug tracks the MPL 2 upgrade for the project named in the subject line.
The repo is here: https://github.com/mozilla/addon-sdk

Gerv

Comment 2

[Gervase Markham [:gerv]]

Attachment: Patch v.1

Here's a first-cut patch for you to skim-read and catch any obvious errors. If it looks good, I'll do a fork and pull request version.

Gerv

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 586427 [details] [diff] [review]
Patch v.1

This looks mostly great.

It does cause two test failures in tests of the Markdown processing code, since the tests compare the output of the processor with what they expect it to be, and the output of the processor changes when a license header is added to the input file.

I dug into the problem and have two patches that resolve those failures.  Note that one of them moves a license header in an HTML file that represents "expected output" from the top of the file to the place where the license header actually gets put by the Markdown processor.  That seems reasonable given the purpose of the file, but let me know if it's a problem.

Note: it's probably better for recording the history of the changes to commit the big relicensing patch and then commit the fixup patches separately.  When you issue a pull request on GitHub, you do so for a branch, not an individual commit, so you can make several commits on your forked copy of the repo and then request that they all be pulled.  You can even attribute the patches to me by specifying --author="myk" when committing them.

Other than those test failures, I have a couple other concerns:

1. This adds HTML comments to Markdown files that are then reflected into the documentation files the Markdown processor generates.  Ideally, these comments would not be reflected into those files, as they clutter them up.  There isn't a Markdown comment format, though, as far as I know, so I don't know a better way to do this.

Requesting feedback from wbamberg on this.

2. .properties files used for localization have had license headers added to them, although they don't really seem like code to me.  Is that intentional?

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Attachment: test fixup 1: fix API parser tests

Comment 5

[Myk Melez [:myk] [@mykmelez]]

Attachment: test fixup 2: fix API renderer tests

Comment 6

[Will Bamberg [:wbamberg]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #3)
> Comment on attachment 586427 [details] [diff] [review]
> Patch v.1
>
> 1. This adds HTML comments to Markdown files that are then reflected into
> the documentation files the Markdown processor generates.  Ideally, these
> comments would not be reflected into those files, as they clutter them up. 
> There isn't a Markdown comment format, though, as far as I know, so I don't
> know a better way to do this.
> 
> Requesting feedback from wbamberg on this.

Yes, ideally they wouldn't be included in the HTML output, but I also don't know another easy way to prevent that happening, and I don't think it's too much of a problem.

Comment 7

[Will Bamberg [:wbamberg]]

Myk: does this mean we can include material that's LGPL-licensed in the SDK now? So we don't need to re-apply this: https://github.com/mozilla/addon-sdk/commit/ce7efa17e6aa63b845ab10d1ffb1c662038f0537 in master?

(It's easily done, in case there's any doubt.)

Comment 8

[Gervase Markham [:gerv]]

Off-topic, but: currently, Mozilla policy prevents Mozilla projects shipping LGPL-only code. We aren't set up to comply with the LGPL. If we were to relax this, it would probably only be for things which are clearly defined as code libraries, and a single icon is not. I don't know what the licensor intended when licensing his icon under the LGPL, but "you can only use this icon in LGPL or GPLed projects" seems like a reasonable guess, and the AddOn SDK is not one of those.

Back to topic: I think it's OK for licensing information to pass through to generated HTML files, because we intend for those files to be licensed under that same licence.

.properties files should definitely be MPLed.

Gerv

Comment 9

[Gervase Markham [:gerv]]

Pull request issued for a branch with the relicensing plus Myk's two patches.
https://github.com/mozilla/addon-sdk/pull/322

Gerv

Comment 10

[Myk Melez [:myk] [@mykmelez]]

(In reply to Gervase Markham [:gerv] from comment #8)
> Off-topic, but: currently, Mozilla policy prevents Mozilla projects shipping
> LGPL-only code.

Is that also true for GPL- and Apache License-only code?  I was hoping that one of the benefits we would acquire by relicensing to the new version of the MPL is the ability to ship external dependencies with such licenses alongside our MPL-licensed code.

I suppose it's still a valuable benefit that the new license allows others to do so, but I was really hoping it would allow us to do so as well, since we periodically have requirements that are best satisfied by external dependencies with one of those licenses.


> Back to topic: I think it's OK for licensing information to pass through to
> generated HTML files, because we intend for those files to be licensed under
> that same licence.

To reduce package size, we've previously talked about stripping license headers from the files in the SDK when packaged for distribution, as they are not the "form of the work preferred for making modifications," since they are packaged (and in some cases generated) for distribution and use rather than modification, and thus they are all Executable Form.

That doesn't mean we don't intend for those files to be licensed under the same license, only that the means by which we would identify the license for those files is a top-level LICENSE file rather than license headers in each individual file.

The MPL 2's much shorter license header may make doing this less useful, although on the other hand we're adding it to many more files, so it may end up being just as useful.  In any case, I'd like to preserve the option.


> .properties files should definitely be MPLed.

Cool, good to know, thanks!

Comment 11

[Gervase Markham [:gerv]]

Apache-licensed code is fine - that's one of the big benefits of the new MPL. You can even copy bits of code out of Apache files and into MPLed files, once we develop a FAQ to make sure that we cross all the Ts and dot the Is in terms of respecting the Apache licence.

It's never been possible to use GPLed code in Mozilla - the GPL says you can't unless your entire app ships under the GPL, and Mozilla doesn't ship Firefox under the GPL. That doesn't change - it's a GPL thing, not an MPL thing. If someone writes GPLed code, they are basically saying "this code is for GPLed apps only", and we have to respect that. If we need some GPL code, the best thing to do is negotiate with the copyright holder. (Often, they are favourably inclined towards Mozilla.)

It's OK to not have licence text in the HTML files, but it's also OK to have it. :-)

Gerv

Comment 12

[Myk Melez [:myk] [@mykmelez]]

(In reply to Gervase Markham [:gerv] from comment #11)
> It's never been possible to use GPLed code in Mozilla - the GPL says you
> can't unless your entire app ships under the GPL, and Mozilla doesn't ship
> Firefox under the GPL. That doesn't change - it's a GPL thing, not an MPL
> thing. If someone writes GPLed code, they are basically saying "this code is
> for GPLed apps only", and we have to respect that. If we need some GPL code,
> the best thing to do is negotiate with the copyright holder. (Often, they
> are favourably inclined towards Mozilla.)

Hmm, perhaps I have misunderstood, but this suggests that others also can't include MPL2-licensed code in their GPL-licensed applications, whereas I thought the compatibility between the MPL2 and the GPL allows this (and is why it is not necessary for us to explicitly license our MPL2-licensed code under the GPL in addition to the MPL2 in order for GPL projects to make use of it, as we have intended to allow and which is why we previously tri-licensed our code).


In any case, if I understand correctly, once we relicense the SDK's code to MPL2, Apache-licensed code will be compatible with it by both license and policy, GPL-licensed code will be incompatible by both license and policy, and LGPL-licensed code will be compatible by license but incompatible by (current) policy.

Is that correct?


> It's OK to not have licence text in the HTML files, but it's also OK to have
> it. :-)

Excellent! :-)

Comment 13

[Gervase Markham [:gerv]]

People can use MPL2ed code in GPL applications, but Mozilla cannot use GPLed code in our MPL2ed application, without effectively placing it under the GPL - which we do not want to do, as we want to preserve people's ability to use it under MPLed terms.

Does that clear it up? :-)

You need to avoid overloading the word compatible. Perhaps a diagram can help. "A --> B" means "code under licence A can be used in projects under licence B.

MIT --> BSD --> Apache 2 --> MPL --> LGPL --> GPL

It is also legally true that we could use an LGPLed library in Firefox, but this is forbidden at the moment by policy, for two reasons. One of them is, we have a licensing goal that we want to be able to say to people "Cool with the MPL? Then you can ship our stuff." The second is that we have not looked into what obligations we would have under the LGPL.

Gerv

Comment 14

[Myk Melez [:myk] [@mykmelez]]

(In reply to Gervase Markham [:gerv] from comment #13)
> People can use MPL2ed code in GPL applications, but Mozilla cannot use GPLed
> code in our MPL2ed application, without effectively placing it under the GPL
> - which we do not want to do, as we want to preserve people's ability to use
> it under MPLed terms.
> 
> Does that clear it up? :-)

Yes, crystally, thanks.


> You need to avoid overloading the word compatible.

I keep using that word.  Perhaps it does not mean what I think it means. ;-)


> It is also legally true that we could use an LGPLed library in Firefox, but
> this is forbidden at the moment by policy, for two reasons. One of them is,
> we have a licensing goal that we want to be able to say to people "Cool with
> the MPL? Then you can ship our stuff." The second is that we have not looked
> into what obligations we would have under the LGPL.

Sure, and I'll take this to mean that it is also forbidden by policy to use an LGPLed library in other Mozilla products, like the Add-on SDK.


Thanks for your compatible explanations.  My understandings are now compatible with yours.  I am forever in your compatible.

Comment 15

[[github robot]]

Commit pushed to https://github.com/mozilla/addon-sdk

https://github.com/mozilla/addon-sdk/commit/9d932f7c7b540130bc08a12a450fde592127fd6b
merge fix bug 715558 - upgrade license to MPL 2; r=@mykmelez, @warner

Comment 16

[Myk Melez [:myk] [@mykmelez]]

Pull request 324 <https://github.com/mozilla/addon-sdk/pull/324> fixes some issues I discovered after landing the changes.

Comment 17

[[github robot]]

Commit pushed to https://github.com/mozilla/addon-sdk

https://github.com/mozilla/addon-sdk/commit/dcd0549e0819d6fba03c9be28b707e15c477c697
Merge pull request #324 from mykmelez/license-upgrade-fixup

add missing license headers; move headers in batch files below '@echo off' command; make line endings consistent; bug 715558 followup; r=@warner

Comment 18

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Question from someone who doesn't know things about licensing:
Does the PACKAGE_JSON template found in SDKROOT/python-lib/cuddlefish/templates.py need to be changed so that the template license mentions MPL 2?

I looked in a packed up extension built from SDK 1.5, and at the bottom of the addon's harness-options.json file, the metadata for addon-kit, api-utils, and my addon all say the license is the tri-license.

Comment 19

[Gervase Markham [:gerv]]

Wes: I'd guess so, but you should file a new bug about it :-)

Gerv

Comment 20

[Will Bamberg [:wbamberg]]

(In reply to Wes Kocher (:KWierso) (Jetpack Bugmaster) from comment #18)
> Question from someone who doesn't know things about licensing:
> Does the PACKAGE_JSON template found in
> SDKROOT/python-lib/cuddlefish/templates.py need to be changed so that the
> template license mentions MPL 2?
> 
> I looked in a packed up extension built from SDK 1.5, and at the bottom of
> the addon's harness-options.json file, the metadata for addon-kit,
> api-utils, and my addon all say the license is the tri-license.

Additional comment from someone who doesn't know about licensing: it seems weird that the addon's own 'harness-options.json' file should say that the license is the tri-license, since this is a statement about the add-on developer's code, not the SDK code itself, isn't it?

Comment 21

[Myk Melez [:myk] [@mykmelez]]

Wes: we previously agreed to remove licensing information from the package manifests, as it is duplicative and not particularly useful.  So we should remove it from that template entirely.  If you haven't filed a bug about it yet, please do so!

Will: some of the code shipped with an addon was under the tri-license and is now under the MPL2, but specifying that license in harness-options.json is indeed likely to be misleading, and we shouldn't do that.  Same bug?

Comment 22

[[github robot]]

Commit pushed to master at https://github.com/mozilla/addon-sdk

https://github.com/mozilla/addon-sdk/commit/8618882d9a9e026084b78f7dc8f4adc1b160c038
Bug 715558 adding MPL 2 header to test-shared-require.js a=me