Allow GPL-Compatible Licensing for Non-Derivative Code and Drupal.org General Projects

For additional context, here is a somewhat cross copy and paste of the Slack discussion mentioned above.

brianperry
10:51 AM
Hi licensing folks. For the Drupal API Client we initially added a GPL License to the project, but have received feedback that this will likely be problematic given the fact that most JavaScript projects that this will be used with use the MIT license. We'd like to change to MIT but wanted to check in here to see if there were any complications due to the fact that we're being hosted on Drupal Gitlab.

brianperry
10:58 AM
This section of the licensing page seems to imply that all Drupal contributed projects should use GPL. Wondering if that interpretation is correct, and if there is an opportunity for exceptions for general / JS projects that will be distributed via NPM and will in most cases be used outside of a Drupal codebase.

hestenet (he/him)
2:34 PM
This may have to be a discussion of an extension of question 4 - https://www.drupal.org/about/licensing#link-gpl-incompatible →
Drupal.org
Licensing
These are answers to frequently asked questions about licensing of the Drupal project.
Nov 11th, 2015 (39 kB)
https://www.drupal.org/about/licensing#link-gpl-incompatible →

2:35
The last time we updated the FAQ was before we were hosting Drupal-agnostic JS components..

effulgentsia
10:57 PM
I think it's more about question #2. IANAL but sounds to me based on the wording of that, that if someone downloads the code from drupal.org, then it's GPL. If the original code is licensed MIT and someone wants to get that code with its original MIT license, then they have to get it from somewhere else. So hosting the repo on GitHub and mirroring to Drupal GitLab could be an option? Or, drupal.org could change its policy and that FAQ accordingly.

hestenet (he/him)
12:07 AM
You could come at it from either angle, sure. Drupal interprets the GPL to mean that certain types of non-GPL assets can be included with Drupal 'in aggregate', vyt we have not historically been the source of hosting such assets, and so our policy hasn't specifically spoken to that case.
The assumption of #2 has implicitly been that code hosted by d.o was going to be Drupal code, not other independent libraries, so it was written expecting to enforce that Drupal derivative code must fall into GPL. That may not reflect the full reality of what we want to do with d.o today. (edited)
12:09
I'd generally be in favor of updating the policy to clarify the GPL requirement for Drupal-derivative code, and the allowance of GPL-compatible licenses for non-derivative code that could be included 'in aggregate' (i.e - via dependency management process) (edited)

brianperry
4:10 PM
The assumption of #2 has implicitly been that code hosted by d.o was going to be Drupal code, not other independent libraries, so it was written expecting to enforce that Drupal derivative code must fall into GPL. That may not reflect the full reality of what we want to do with d.o today
Biased here, but I think the existence of 'general' projects breaks that assumption. This for example is a library that interfaces with Drupal endpoints, but in most cases won't actually be used in a Drupal codebase. If either the fact that it exists on drupal.org, or talks to Drupal means that it has to inherit GPL I think that could limit the utility of general projects.

brianperry
4:16 PM
I'd generally be in favor of updating the policy to clarify the GPL requirement for Drupal-derivative code, and the allowance of GPL-compatible licenses for non-derivative code that could be included 'in aggregate' (i.e - via dependency management process)
Not sure if 'GPL-compatible' was a typo above. My ideal here would be a GPL requirement for derivative code, and allowing GPL incompatible licenses (MIT in this case) for non-derivative code.

brianperry
4:21 PM
Ah, the 'GPL-compatible' link seems to imply that the various licenses that fall under the distinction of MIT would be considered GPL compatible, so that makes sense to me.

hestenet (he/him)
7:11 PM
Yup. I think we're more or less on the same page.

brianperry
12:52 PM
@hestenet (he/him)
given that, what would be the best next step here? Creating a related issue in https://www.drupal.org/project/drupal_lwg → ?
New

hestenet (he/him)
1:00 PM
Yes please!
1:00
Mention my name and maybe even copy this convo.

hestenet (he/him)
2:50 PM
@brianperry
Did that issue get created?

brianperry
3:49 PM
@hestenet (he/him)
Didn't get a chance, but I'll create one no

Based on the anticipated changes outlined in this issue, I've published a release of the Drupal API Client packages under the MIT license: https://www.drupal.org/project/api_client/issues/3367042#comment-15639252 →