search

mozilla / addons

☂ Umbrella repository for Mozilla Addons ✨
Other
127 stars 41 forks source link

[Task]: Suggestions regarding licensing at AMO #14976

Closed leoheitmannruiz closed 2 weeks ago

leoheitmannruiz commented 2 months ago

Description

Hey :)

Thanks for working on AMO and taking the time to read this!

I recently looked into AMO and noticed, what I feel like is, some room for improvement regarding how licenses are handled.

It seems like one of my suggestion may require non-trivial code changes. I imagine that this makes it a lot less attractive to tackle. However, I strongly believe that implementing the suggestion is crucial and will result in a significantly clearer and more accurate licensing system.

I'm afraid I can't be of much help programming, but if there's anything else you believe I might be able to help with, please feel free to ask!

I want to thank David Hedlund for investing time and effort into this several years ago.

  1. I have proposed fixes for a few trivialities at https://github.com/mozilla/addons-server/pull/22573:

    1. The LGPL family of licenses is incorrectly called "Library" GPL.
    2. CC NC and ND licenses are incorrectly called "open source" in the docs.
    3. The name corresponding to the slug BSD-2-Clause is inconsistent among docs and code.
    4. The name corresponding to the slug BSD-2-Clause is "The BSD License".

  2. License slugs are taken from SPDX but names are not.

    To me, this seems like an unnecessary inconsistency. When using the API, you are returned a slug and a name for the license (if it is one of the seven built in licenses). The slug is an SPDX identifier, but the name is not.

    This issue is related: https://github.com/mozilla/addons/issues/5721.

  3. You need to be able choose any license from the SPDX License List.

    Apache-2.0 is not a license choice at AMO. This results in the following add-ons, which are all licensed under the same terms, declaring their license differently:

    Six years ago, https://github.com/mozilla/addons/issues/5784 was closed with the following answer:

    "Focusing on licenses that are more broadly used and accepted in the open source community instead of overwhelming users with a choice of 350 licenses will result in much cleaner licensing across the platform and will eventually be easier for users and developers."

    To me, based on the example above, it seems like "Focusing on licenses that are more broadly used and accepted" doesn't "result in much cleaner licensing across the platform".

    License choices extend beyond seven licenses. Intending for people to 'Just choose "Other" and enter [their] license name.' has and will lead to cases like the above. (https://github.com/mozilla/addons/issues/5648)

    I propose Mozilla continues to recommend the licenses they want to recommend, so as to not "[overwhelm] users with a choice of 350 licenses", but add a "drop-down menu with all SPDX licenses".

    I doubt this will lead to people opting for the BSD-3-Clause-No-Nuclear-License-2014 ;)

  4. The GPL family of licenses is oversimplified.

    The GPL family of licenses sadly drags some nifty complexity with it.

    It comes down to https://www.gnu.org/licenses/identify-licenses-clearly.html.

    To illustrate:

    The license chooser allows for the following licenses from the GPL family:

    • GNU General Public License v2.0
    • GNU General Public License v3.0
    • GNU Library General Public License v2.1
    • GNU Library General Public License v3.0

    Which correspond to the these slugs:

    • GPL-2.0-or-later
    • GPL-3.0-or-later
    • LGPL-2.1-or-later
    • LGPL-3.0-or-later

    This ambiguity has lead to cases like https://addons.mozilla.org/addon/adblock-for-firefox/, where the API responds with the slug GPL-3.0-or-later, when really the add-on is licensed under GPL-3.0-only.

    I suggest recommending:

    • GPL-3.0-only
    • GPL-3.0-or-later
    • LGPL-3.0-only
    • LGPL-3.0-or-later

    This will keep the number of recommendations the same, while steering clear of ambiguity.

    This issue is related: https://github.com/mozilla/addons/issues/5722.

  5. Theme license chooser recommends CC 3.0 licenses.

    CC 4.0 licenses were published over a decade ago.

    This issue is related: https://github.com/mozilla/addons/issues/1203.

Warmly, Leo Heitmann Ruiz

CC: @davidhedlund

Acceptance Criteria

### Milestones/checkpoints
- [ ] License names are taken from SPDX
- [ ] You are be able choose any license from the SPDX License List
- [ ] GPL family of licenses is clear of only/or-later ambiguity
- [x] Theme license chooser recommends CC 4.0 licenses

Checks

┆Issue is synchronized with this Jira Task

diox commented 2 months ago

Hi,

This issue should really have been split into 4 separate ones, as each topic doesn't have the same importance/priority. My thoughts as an engineer, not a product person:

https://github.com/mozilla/addons-server/pull/22573 makes sense. Could you edit that PR description to link to this issue ?

The points made in https://github.com/mozilla/addons/issues/5784 and https://github.com/mozilla/addons/issues/5722 still stand: the full list of SPDX licenses is too much and would only introduce confusion. Similarly I don't think we want to add the "or later" variants to our built-in list. The fact that our slugs currently point to the "or later" variant is just wrong - the name/text of the license is the source of truth here.

We could consider adding very popular licenses like Apache 2.0 License to the built-in list however.

https://github.com/mozilla/addons/issues/1203 should probably be re-opened to address the CC 4.0 licenses there.

leoheitmannruiz commented 2 months ago

This issue should really have been split into 4 separate ones, as each topic doesn't have the same importance/priority.

Makes sense, sorry. I didn't want to spam the issue tracker.

mozilla/addons-server#22573 makes sense. Could you edit that PR description to link to this issue ?

Done.

The points made in #5784 and #5722 still stand: the full list of SPDX licenses is too much and would only introduce confusion.

How do you think adding the full SPDX License List will lead to confusion?

I imagine people will have the license chooser in front of them, like it is the case currently. They'll probably find the license they use in the list, or pick one of them. If they use a license not in the list, or they're just plain curious, they choose a bullet point, which reveals a drop-down/search thingie. They can explore or, more likely, choose the license they're looking for.

Edit: The dropdown could even have a caption along the lines of "Is your license not listed above, pick it from here" to indicate that this is not for people choosing a license for their project, but for those that have already done so.

I might be very wrong of course :)

Similarly I don't think we want to add the "or later" variants to our built-in list. The fact that our slugs currently point to the "or later" variant is just wrong - the name/text of the license is the source of truth here.

I'm not sure I understand, can you please elaborate.

Do you want to change all the slugs to GPL-3.0-only?

The name currently can't be the source of truth, as it is ambiguous. You'd have to either append "only" or "or later". Same for the slug. There is not GPL-3.0 SPDX identifier. And, the text is the same for both licenses (I suppose in the case of AMO it's the link that's relevant, though that is also the same for both).

1203 should probably be re-opened to address the CC 4.0 licenses there.

Yes, please.

leoheitmannruiz commented 2 months ago

I wanted to add that many package registries use SPDX identifiers for the license field.

Four examples of the top of my head:

Please do so as well 🙏

I'm confident we can come up with a way of doing so without causing confusion.

diox commented 2 weeks ago

This took a while, but we've had a lot of conversations with Legal and Product teams behind the scenes and we've come up with a plan, which I've re-filed as https://github.com/mozilla/addons/issues/15092 because this issue was beginning to be difficult to follow.

davidhedlund commented 2 weeks ago

I want to thank David Hedlund for investing time and effort into this several years ago.

Thank you very much.