For consistency with the composer "license" property, license terms (identifiers) should use the notation listed at the SPDX Open Source License Registry.

The taxonomy terms currently available for code are these:

  • Apache 2.0 → Apache-2.0 NOT ALLOWED
  • BSD-2-Clause-FreeBSD
  • BSD-3-Clause
  • BSD-3-Clause-Clear
  • CC0-1.0
  • GPL-2.0 → GPL-2.0-only
  • GPL-2.0+ → GPL-2.0-or-later
  • GPL-3.0 → GPL-3.0-only NOT ALLOWED
  • LGPL-2.1 → LGPL-2.1-only
  • LGPL-3.0 → LGPL-3.0-only NOT ALLOWED
  • MIT
  • Unlicense
  • WTFPL
  • X11

Those with NOT ALLOWED appended, i.e. Apache 2, GPLv3, and LGPLv3 are currently included not to break legacy entries. They need to have "NOT ALLOWED" as part of the term and should be removed from the vocabulary when we've sorted out what to do with these.

For compatibility between different versions of the GPL, see the FSF's compatibility matrix: https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility

For some, the notation is different from the notation used in SPDX Open Source License Registry. This must be changed. An → points to the correct notation.

These are the taxonomy terms for licenses that are currently allowed for non-code assets. They should be retained.

  • CC-BY-2.5
  • CC-BY-3.0
  • CC-BY-4.0
  • CC-BY-SA-2.5
  • CC-BY-SA-3.0
  • CC-BY-SA-4.0
  • OFL-1.0
  • OFL-1.1

The LWG now maintains a list of GPLv2 compatible licenses that is much easier to read than the FSF full list of GPL compatible licenses which contains information about both GPLv2 and GPLv3 compatible licenses.

The notation used on that page should also be based upon the SPDX Open Source License Registry.

I'm requesting the taxonomy terms for licenses that aren't compatible with GPLv2 be removed and the most commonly requested licenses we are approving be added.

Note

Those NOT ALLOWED are retained, with "NOT ALLOWED" appended, as removing these terms will probably also remove the associated whitelist entries (see comment #13 for an overview). This is going to break some distributions that rely on these. We shall remove those entries as soon we've sorted those distributions out.

Comments

bojanz’s picture

I might be getting this wrong, but per the discussion in #1856762: Revisit and Redefine Drupal's Policy on hosting 3rd party files and/or files that is not strictly GPL which clarifies that Drupal can be distributed under GPL v2 and v3, we might want to allow Apache 2, GPLv3, and LGPLv3 instead of deleting them?

killes@www.drop.org’s picture

not currently, the discussion is still ongoing.

kreynen’s picture

We would only need them if #1449452: Give installation profiles/distributions GPLv3+ license as option for packaged downloads was approved. As it stands, the libraries listed in #2307487: Warn distributions using non-whitelisted licenses that entries will be removed make the statement that even all code downloaded from Drupal.org is licensed as GPLv2 or later untrue.

Even if GPLv3 is eventually added as an option for distributions, the licenses will likely need to be separated between the licenses that are GPLv2 compatible vs. GPLv3 compatible. drush verify-makefile drupal-org.make would need to be updated to be able to distinguish between the whitelist entries are acceptable for the license the distribution is using.

Because of https://developer.github.com/changes/2014-04-25-user-content-security/, we are going to update all of the GitHub entries so having an accurate list of licenses would be helpful.

I updated #2307487: Warn distributions using non-whitelisted licenses that entries will be removed so that the entries with licenses that aren't GPLv2 compatible are listed.

While we haven't decided what to do with the whitelist entries, removing the tag won't impact anything other than making it less likely anyone will whitelist a library that isn't GPLv2 compatible in the future.

kreynen’s picture

Priority: Normal » Major

After reviewing the entries tagged with licenses that aren't GPLv2 compatible, most of them were actually a compatible license that wasn't an option (people selecting LGPLv3 because LPGLv2 wasn't an option). I believe all of the licenses used by existing whitelist entries are listed at https://www.drupal.org/node/1475972#whitelist-licenses.

I've also added #2308559: Update view-packaging-whitelist-items to include licenses.

Since the license tag wasn't required, we need to review the entries that weren't tagged as well.

There is absolutely no reason to have licenses that are not GPLv2 compatible as options. The list of licenses should match the list of licenses that are known to be GPLv2 compatible. Entries that use a license that we haven't approved before should get help up until the term for the licenses is added.

There have been mistakes made in what has been approved and as a result, users have been downloading code from Drupal.org that isn't GPLv2 compatible. Updating the licensing options is one small step towards improving the white list process so it is less likely a similar mistake happens in the future.

Several people are participating in a Google Hangout on 7/29.

I would like to be able to update the license tag of all of the entries to accurately reflect their GPLv2 compatible license. Entries that don't have a GPLv2 compatible license will no longer have a tag. This will give use a much better idea of the size of the problem we are dealing with.

Thanks!

geerlingguy’s picture

@kreynen - can you send me the invite/link to the Hangout? I have been following this/related issues lately, but haven't had time to do much about them yet. I agree that this is a major issue—we need to either remove the disallowed licenses, or figure out whether we can/will allow them, and make sure the code on Drupal.org is distributed legally/correctly.

dddave’s picture

@gerlingguy Done. I've also forwarded you the notes doc which I recommend to read before the hangout.

gisle’s picture

Issue tags: -licensepolicy +licensingpolicy

Holly's minutes says we should use "licensingpolicy", not "licensepolicy". Retagging.

kreynen’s picture

Priority: Major » Critical

Now that we've met w/ Holly and there is a proposed path forward, will someone with the required permission PLEASE update these terms. If you can also address #2308559: Update view-packaging-whitelist-items to include licenses, that would be even better. While it looks like there might some flexibility/changes on #2139273: Allow GPL Friendly Font Licenses and #2298275: Proposal to amend Drupal Git Repository Usage policy to allow content licensed under Creative Commons , there aren't going to be any changes that would allow #1449452: Give installation profiles/distributions GPLv3+ license as option for packaged downloads in the near future. As a result, all whitelist entries for code with a license that isn't GPLv2 compatible need to be removed. We need to give distribution maintainers time to update their projects to remove the problematic libraries, but before we do that we need to identify those libraries.

This is also holding up fixing #2248207: Something is breaking whitelisted github downloads for distros. which is holding up applying security updates to distributions.

kreynen’s picture

These are the specific edits I'm requesting...

Apache 2.0 - REMOVE
Clear BSD
CC0 - ADD
Expat (MIT)
FreeBSD
GPL 2.0
GPL 2.0 or later - ADD
GPL 3.0 - REMOVE
LGPL 3.0 - REMOVE
LGPL 2.1 - ADD
Modified BSD
Public Domain
The Unlicense - ADD
WTFPL - ADD
X11

If you want to edit LGPLv3 to be LGPLv2.1, that would be fine since most of the entries tagged as LGPLv3 were actually LGPLv2. I believe this will cover all of the GPLv2 compatible license any whitelist entry is using, but we need to review the list to confirm that. The process that's evolved for the whitelist reviews requires more scrutiny before approving a library using a license we haven't whitelisted in the past. When we determine that a new (to the whitelist) license is GPLv2 compatible, one of the whitelist maintainers will request the term be added to this taxonomy and add it to https://www.drupal.org/node/1475972#whitelist-licenses.

I've requested GPL 2.0 or later be added because it is possible to license something as only GPLv2. As @crell pointed out on yesterday's call, that would make it incompatible with a distribution wanting to use a GPLv3 license. I believe that is the only license we've been approving that would not be compatible with GPLv3 if that is every approved.

At this point I have no idea how many of the approved whitelist entries are GPLv2 only vs. GPLv2 or later, but we'll review that as well.

Thanks

greggles’s picture

Status: Active » Needs review

Thanks for your work on this, Kevin, and for making the proposed change so clear. Moving the status to "Needs review" since there's no patch for this. One question before removing, would it be useful to keep these tags long enough to remove the entries tagged with them?

killes@www.drop.org’s picture

just to be sure, you are talking about e.g. this term here:

https://www.drupal.org/taxonomy/term/33704
?

kreynen’s picture

I've already added links to the entries tagged with licenses we now don't allow to #2307487: Warn distributions using non-whitelisted licenses that entries will be removed.

The reason I'm requesting removing the tags now is that there are other entries without a tag because the license they use wasn't an option. So not having a tag just means the whitelist entry needs to be reviewed.

So the first pass will be to give every whitelist entry that is really GPLv2 compatible a tag. The entries left without a license tag will be the actual licensing problems.

At that point we'll start the process of informing maintainers using the entries that should have never been approved that they need to find another way to use the library, request that the license be changed, or find an alternative.

And finally, we'll remove the whitelist entries for GPLv2 incompatible code if there still hasn't been any progress on #1449452: Give installation profiles/distributions GPLv3+ license as option for packaged downloads.

kreynen’s picture

@killes

Yes.

Apache 2 - https://www.drupal.org/taxonomy/term/33704
GPLv3 - https://www.drupal.org/taxonomy/term/33700
LGPLv3 - https://www.drupal.org/taxonomy/term/33702 (deleted or updated to be LGPL 2.1 since that's the license most of the libraries tagged as LPGL 3 are actually licensed as)

greggles’s picture

Status: Needs review » Reviewed & tested by the community

Sounds good to me. Making this RTBC.

I know its been open for 8 days and so far I haven't seen anyone who is explicitly opposed to it, but I'd like to leave it in RTBC status for at least a few more days before taking action on it.

killes@www.drop.org’s picture

I think _adding_ the new licenses shouldn't be controversial and could be done now. We could update the others to "Foo License (don't use)" or something.

kreynen’s picture

@killes getting the new licenses added would be great. We have to update all of the GitHub entries to add the new githubusercontent.com domain they've moved to for https://developer.github.com/changes/2014-04-25-user-content-security/

Having the new entries would let us get started on that today without have to edit the nodes twice.

killes@www.drop.org’s picture

I've added all those that were marked "ADD".

tvn’s picture

Now that the Licensing Working Group exists, should this issue be moved to their queue for an 'official' review? Can someone please update issue summary with what's left to do here?

kreynen’s picture

Priority: Critical » Normal
Status: Reviewed & tested by the community » Postponed

There is already a large backlog of issues the LWG will have to deal with regarding both modules and distributions that include code that has never been GPLv2 compatible. The backlog goes back 5 years to issues like #722554: flowplayer module includes Flash player protected with GPL 3 licence. Right now, having the licenses that should have never been whitelisted in the taxonomy makes it easier to find the problematic libraries. The original requests for these to be whitelisted have all been flagged as needing review in https://www.drupal.org/project/issues/drupalorg_whitelist?status=8, but simply removing them will potentially cause problems for thousands of sites.

Since the group hasn't even met yet, I don't know what the process will be for additional changes to this taxonomy.

Is possible to grant the members of the LWG permission to maintain this taxonomy?

That way if the LWG decides to do something like #2139273: Allow GPL Friendly Font Licenses, then a member of the LWG could add that license and we could use the SIL OFL license for #2137985: Include font-awesome into whitelist?. If it is not possible to grant that permission, the LWG will continue to make requests like this as we review and update policies.

tvn’s picture

I think it is fine if LWG makes a decision on what kind of taxonomy terms should exist or say that some project needs to be unpublished for violation, and then sends a request to webmasters for execution.

apaderno’s picture

Component: Licensing » Other
apaderno’s picture

Actually, webmasters don't have the permission to add taxonomy terms to generic vocabularies used on drupal.org, nor do they have the permission to give new permissions to other users. It would make more sense to have an issue queue for requests to users with the administrator role.

apaderno’s picture

Even better, in the specific case, it would make more sense to give to the users who are part of the LWG the permission to edit the vocabulary used for the licenses.

gisle’s picture

Issue summary: View changes

Updated issue summary to include the full vocabulary.

gisle’s picture

gisle’s picture

Issue summary: View changes

Added note about possible impact on distributions.

gisle’s picture

gisle’s picture

Issue summary: View changes
Status: Postponed » Needs work

This was postponed until LWG had sorted out what licenses to whitelist as GPL-2.0-or-later compatible. That was completed some time back, and resulted in this page: https://www.drupal.org/node/1475972.

Setting back to "Needs work" as it is clear what needs to be done. There is no patch. Someone with the required level of access need to edit the taxonomy vocabulary.

apaderno’s picture

Status: Needs work » Needs review

I edited the vocabulary (https://www.drupal.org/admin/structure/taxonomy/vocabulary_58) basing on what reported in the summary.

If required, it is also possible to move the not allowed entries on the bottom of the list.

apaderno’s picture

As side note, does having - None - in the Licence form element make sense? Aren't the whitelist entries supposed to select at least a license?

gisle’s picture

I agree that having - None - in the list makes little sense.

If there is nothing tagged with it now, it should be removed, as one should not be able to select this in the future.

There are probably libraries with no license floating around - but according to https://www.drupal.org/node/1475972#whitelist-licenses "No license" is not an allowed category.

(I'll get around to get page updated with a column showing the SPDX identifiers real soon now.)

I think it is OK to have things sorted alphabetically. There are really three groups of licenses there: Those compatible with GPL-2.0-or-later, the "GPL-friendly" ones permitted for media assets but not code, and those NOT ALLOWED. As long as we can't have separators in the menu, alphabetical sorting is OK.

apaderno’s picture

I also noticed the following description, in the administration page for the vocabulary (https://www.drupal.org/admin/structure/taxonomy/vocabulary_58).

You can reorganize the terms in License using their drag-and-drop handles, and group terms under a parent term by sliding them under and to the right of the parent.

I get the vocabulary has been created as hierarchical taxonomy.

If this is not required, the entity field for the taxonomy needs to be changed. Removing the - None - item in the form element also requires changing the entity field defined as code in a custom Feature module.
If they are necessary (or deemed necessary) changes, I can open an issue report on the appropriate queue.

gisle’s picture

Status: Needs review » Fixed

The only people that should be using this in future are members of the LWG. We're all experienced and there is no need to spend resources on fine tuning the UX.

Thank you so much for your help in getting this fixed after all these years! Moving to "Fixed".

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.