AMO does not state the licence of a particular extension on that extension's page. This is bad because people can't tell if a particular addon is under a free licence or not. Also, the MPL section 3.6 says: "include a notice stating that the Source Code version of the Covered Code is available under the terms of this License, including a description of how and where You have fulfilled the obligations of Section 3.2. The notice must be conspicuously included in any notice in an Executable version, related documentation or collateral in which You describe recipients' rights relating to the Covered Code." You could argue that it's the responsibility of the addon author to include such a notice inside the addon itself. But I do think it's also our responsibility to make sure people know what the licence is on code they are downloading. Suggestions: - AMO allows authors to specify a licence in the addon entry management screen, and that information is displayed on the addon's main page. - AMO allows authors to specify a "source code URL", which might be a tarball or a link to a website, which is also published on the page. Gerv

I agree, this should be addressed. I like your two suggestions.

See also 275743

Mike: what's the status here? Is fixing this in any a.m.o. development plan? Gerv

->shaver (policy bug).

In Remora, there is an extension file viewer that was intended for reviewers but will probably be extended to the public site. Shaver had concerns about displaying the contents of files that may have restrictive licenses, so we will probably implement the license field described here. Should licenses be per-addon, per-version, or per-file? I am guessing per-file is probably the correct choice here, but just confirming. I'm thinking additem will have a select box with a list of licenses to choose from, one of which is "Other". We'll create a new table called licenses with fields for the license name, a URL to the license, and whether the license allows the files to be viewable in the web file browser. So, if that sounds good to everyone I will add that to additem and will need a list of licenses and their URLs before the launch (preferably before the beta, so soon).

Licenses should ideally be per-addon-version. If someone is downloading an addon, they want to know what terms they are downloading it under. But the author needs the capability to change the license after having released a few versions (assuming they have the rights to do so). If that's too complex, then per-addon would probably do. The terms for an installable addon may be different to the terms for any particular individual source code file. (For example, all Firefox files are under the tri-license, but official Firefox binaries are under the MoCo EULA.) I don't quite understand the "extension file viewer" - but surely reviewers can't properly review an addon unless they can see all the files within it? Gerv

(In reply to comment #7) > Licenses should ideally be per-addon-version. If someone is downloading an > addon, they want to know what terms they are downloading it under. To be clear, this bug is about specifying the _source_ license that applies to open source extensions. Terms of _use_ of the "binaries" are a EULA issue. I actually don't think that add-on distribution is in violation of the MPL, and I don't actually think that having "this is MPL" on the site meets the requirement of the license that Gerv quoted above (which uses the word "include"). So the license field as proposed here won't resolve this bug, AFAICT, and I'm wary of giving people the impression that all they need to do is check a box and add a URL to be in compliance with the MPL (or other license terms) for code they might include. (In fact, I don't think the MPL has anything at all to say about sites like AMO that act as a redistributor and are acting at the behest of the author, who is not bound by license terms on their own code at all. I'm going to resummarize this bug now so that it reflects what we're really talking about, which is letting authors optionally specify the license under which they are willing to make their extension _source_ available for others to use.)

shaver: I originally filed this bug to cover the fact that AMO does not make the terms of use for downloaded addons clear to the downloader. You may well wish to make it possible for people to see the licensing terms of the source also - and I'd heartily agree with that - but that doesn't address my original issue, and should perhaps be covered in a separate bug. Even if the MPL doesn't cover our situation as distributors of binaries, I still think it's important that people know if, for example, the addon they are about to download is free software, or under a EULA, or something else. Gerv

I like per-version licenses, since licenses can be changed. If the developer chooses one of the licenses the site knows about, the license field on the version will be the id of that license.. otherwise, we'll need a field in the add-on's localised stoof for the developer to enter a license. I don't think we need the licenses that the site knows about the be localisable as that's generally not done. Do we want our list of licenses to be very long? If it's too long, the dropdown box will be huge. I would also like a field in the licenses table as to whether the license is "free". We could use the FSF list [1] or some other list, or just make it up ourselves. Later down the track it would be cool to be able to filter advanced searches to only show free software. Soo.. licenses Public Domain (not an actual license, more a state, but I think we should include it.) MPL 1.1 - http://www.mozilla.org/MPL/ MPL/GPL/LGPL tri-license - http://www.mozilla.org/MPL/ GPL - http://www.gnu.org/licenses/gpl.html LGPL - http://www.gnu.org/licenses/lgpl.html MIT license - http://www.opensource.org/licenses/mit-license.php (there doesn't seem to be a better URL for this) Modified (3-clause) BSD License - http://www.opensource.org/licenses/bsd-license.php Beerware - http://en.wikipedia.org/wiki/Beerware [1] http://www.fsf.org/licensing/licenses/index_html

I agree with Cameron, except that I think the one person who wants to use the Beerware licence can cope with putting "Other" and pasting the URL in themselves ;-) Gerv

After extensive discussion on IRC, some points were brought up about why a drop down list (and any field really) is a bad idea. If the license indicated on AMO differs from the license in the source code (if there is one in the source at all), it will cause problems. Also, having a drop down box will make people likely to just select one without knowing what it means or having it in the code at all. Reassigning to nobody@ and TM: Future. The source viewer was given its own field and authors can explicitly allow the extension to be viewed online, so that's not connected with this license field idea anymore.

I don't think an addon developer would just click a random license without knowing what it means. We shouldn't assume addon developers randomly click things and don't care about the implications.

Indeed, there's already a way for authors to do this: mark their add-on's source as viewable and put the license in the source files where it should be. Also, they can put a summary of the license terms in their description quite easily. "Other: $URL" is very much undesirable, IMO, because it raises tons of questions about what happens when that URL starts to dangle, can be retroactively revised (counter to most copyright law). Between the source viewer and the EULA field in Remora, I think this is FIXED, though the range of things that have been requested under the aegis of this bug (usage terms, us being in violation of the MPL, source license clarity, etc.) is quite impressively broad. Rather than morph it again, I encourage people to file other, very _specific_ bugs on additional desiderata if they should have some. (wenzel: it is tragically common that people don't understand the terms of licenses they want to use, or what their choices are given the code they took as input. If they understand the license it's really easy to put it in the source files.)

> If the license indicated on AMO differs from the license in the source code > (if there is one in the source at all), it will cause problems. Sure, but that's only a reason not to have a field if such errors would be common, and it seems unlikely that authors would make mistakes that often. Most extensions on AMO don't even have licenses in their source code, in my experience, and when they do, their authors are likely to know what they say. > Also, having a drop down box will make people likely to just select one > without knowing what it means or having it in the code at all. I don't think this would be very likely, but there are ways to mitigate the problem. First, don't require the author to select a license. Second, allow the author to select "license included in source code of extension" (or the like). > it is tragically common that people don't understand the terms of licenses > they want to use, or what their choices are given the code they took as input. Sure, but that's just as much a problem for license headers in source files as it would be for a field displaying the license (although it's true that making it easier for authors to specify a license could increase the absolute number of authors specifying the wrong one). > If they understand the license it's really easy to put it in the source files. But not nearly as easy for someone else to determine the license, which is my use case (I want to know if particular extensions that I'm looking into might be able to be modified or their code reused). But it sounds like y'all aren't inclined to add a field, and the source viewer does make it easier to look through extension sources, which is how I currently do this, so I guess I'll stick with the current approach.

I very much like your suggestions, Myk. I think this would make amo quite a bit more developer friendly and promote source code openness in a manner that might encourage people to extend/improve existing add-ons. While right now we'll probably not add this, I think this would be an important thing to tackle in order to make the newly introduced "sandbox" concept a dynamic place of (derivative) creativity rather than just a mostly static heap of add-ons waiting for moderation.

(In reply to comment #14) > Indeed, there's already a way for authors to do this: mark their add-on's > source as viewable and put the license in the source files where it should be. > Also, they can put a summary of the license terms in their description quite > easily. But nobody does this. Having a dedicated field will encourage people to fill it in. > Between the source viewer and the EULA field in Remora, I think this is FIXED [snippety snip snip] No. Gerv made 2 initial requests. - AMO [should allow] authors to specify a licence in the addon entry management screen, and that information is displayed on the addon's main page. - AMO [should allow] authors to specify a "source code URL", which might be a tarball or a link to a website, which is also published on the page. The first of those 2 requests is not yet fulfilled - I suspect Gerv wanted a dedicated field. Could someone please reopen this bug?

It's true that I wanted the first of those two things, and that it isn't currently in the plan. I believe it would be useful information for downloaders, particularly those who care about the freedom or otherwise of software they use. I'll reopen the bug - although I think that, for better or for worse, the Remora team has already made a decision on this point. Gerv

Authors can already put the license terms in the description of their add-on if they choose to, as I said in comment 14. This is edited in the add-on management page, and is displayed on the add-on's main page. They can describe whatever licensing complexities they choose ("this add-on is tri-licensed, except for the library I imported that is LGPL"; "this add-on is postcard-ware"), as they see fit. I really do believe that this satisfies the requirement as filed, as described in comment 17, and as needed by authors today.

As an aside. I didn't think it was obvious that this is what the EULA field was for... bug #375087 Ciao!

As a further aside, this isn't what the EULA is for. "Use of software" and "creation of derivative works" are different issues; EULA covers the former, if there are any conditions on it, and source license terms affect the latter.