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 →

Cross posting a related thread from the Starshot Demo Design System slack: https://drupal.slack.com/archives/C07CDLSD8UU/p1727204460838479

Perhaps that design system could be an opportunity to revisit and move this issue forward.

Now that I think of it, Experience Builder itself will likely force our hand on some of this. I'd imagine the current work in progress already depends on quite a bit of code licensed under MIT.

I don't think that Experience Builder is currently in violation of current d.o. policies around this. We are using MIT licensed code (e.g., React), but that doesn't prevent the Experience Builder module as a whole being licensed under GPL.

Also, I don't think the SDDS use case in #5 (being able to create an MIT-licensed Vue.js port of SDDS) strictly requires this issue to be resolved. From a technical standpoint, if the SDDS authors want to license SDDS under MIT, then so long as the SDDS code isn't derivative of any GPL code, the SDDS authors can release SDDS on GitHub with an MIT license, and then people can create a Vue.js port of that, also released on GitHub with an MIT license.

However, I still think that drupal.org should relax its policies to allow use cases like Drupal API client and SDDS to be hosted on drupal.org with an MIT license, so as not to force those projects off of drupal.org and onto GitHub.

> I don't think that Experience Builder is currently in violation of current d.o. policies around this. We are using MIT licensed code (e.g., React), but that doesn't prevent the Experience Builder module as a whole being licensed under GPL.

Admittedly out of my depth on this licensing stuff here, so apologies if I mischaracterized anything...

No apologies are necessary. We're all just trying to keep the trains running until we can finally disable more of the D7 packaging and update the Drupal.org project page UI so we're no longer assuming that a copy of the GPL license text was added to a .zip during the packaging step.

What you've already configured in GitLab using the normal/off the island approach to licensing is the correct way to handle this for now.

Chiming in here to add some background why GPL is a no-go for many/most Javascript frameworks:

The problem with React/Vue/.. any modern JS frontend is that the templates are JavaScript and transfered to client AND get bundled together typically by route or even by app. Thus any code, or components which end-up in the client-side bundle can easily "infected" by GPL as soon as some GPL library is somewhere used in the app and ends up in the client-side bundle. That would make the whole client-side JS app GPL, what is a no-go for most businesses and licenses troubles people do not want to get into (including myself). That's why in the JS frontend world permissive licenses, like MIT, are standard.

Thus, for decoupled projects, like https://www.drupal.org/project/lupus_decoupled → hosting of frontend code requires MIT. Currently that forced us to move all frontend things to github. We'd love to have things like decoupled themes on drupal.org in the future, but the license is a showstopper here atm.

> I don't think that Experience Builder is currently in violation of current d.o. policies around this. We are using MIT licensed code (e.g., React), but that doesn't prevent the Experience Builder module as a whole being licensed under GPL.

While this is not a problem for experience builder per se, it might become a problem if its used for react based frontends in the future. When Drupal provides JS/react-code, I assume it typically woudl be its own bundle, and thus not a problem. However, people might want to include this react code in some decoupled react frontends in the future, for which the GPL license woudl be a blocker again. In order to avoid blocking future integrations like this, I'd suggest to pick a more permissive license there for JS-components/libraries also.

That would make the whole client-side JS bundle/app GPL, what is a no-go for most businesses.

Right. And just to be explicit, the key reason for this is that since this is code that runs in the browser, there's no way to not "distribute" it. The owner of a website can have proprietary PHP code alongside GPL PHP code, because the website owner doesn't have to "distribute" the PHP code in order for the website to function, whereas JS code that needs to be sent to each user's browser becomes a "distribution" of that code.

In order to avoid blocking future integrations like this and to support wide-adoption, I'd suggest to pick a more permissive license for JS-components/libraries (e.g. MIT instead of GPL)

Agreed. And examples where this will become relevant for Experience Builder, but that haven't come up yet because we haven't built those parts yet are:

• JS components intended for the front-end of a website, such as SDDS or some other design system (or parts of one) ported to JSX, Vue, Svelte, etc.
• A JS library that Decoupled front-ends can use for fetching the data that's in Experience Builder and rendering a tree of components based on that data (i.e., placing all of the components within the right parents, in the right slots, and in the right order, so as to match what's been laid out by the content editor in Experience Builder).

Both of the above would need to be MIT licensed per #9, so would be separate libraries on GitHub until they're allowed on drupal.org. Or perhaps per #8 they'd already be allowed on drupal.org, so long as they're in separate projects than the primary (GPL) Experience Builder project?

@fago it's taken many years and countless discussions over the years, but I think everyone who would weigh in on these changes are now all on the same page. We went through this when JQuery updated that project's licensing back in 2012 and we revised the contributor agreement to clarify that non-code assets didn't require a GPL, but a "friendly" license that had similar clauses protecting the same freedoms as the GPL like MIT. We had the same discussion again when general projects were first offered on Drupal.org... and again with Distribution Modernization/Recipes when we looked at how Ansible treats Playbooks as non-derivative work. Every time we've had this conversation in the last 4+ years, we were "only months away from D7's EoL" when we'd no longer need to package D7 code and could rely on features like `composer license` to understand the licensing in a build... only to have the EoL deadline pushed again.

We managed to #3266927: End Install Profile Packaging on Drupal.org in August 2023 → , but the larger shift to an "off the island" approach to licensing has been on hold until Drupal.org support for D7 finally ends. The WP Engine drama should only help motivate the Drupal Association to further clarify the Drupal.org licensing and project ownership policies. My understanding has always been that what happened with WPEngine customers being blocked from updates and the Advanced Custom Field plugin being hijacked could never happen on Drupal.org.

It's worth calling out that the WordPress has always allowed plugin maintainers to mix incompatible licenses while still linking https://wordpress.org/about/license/ to Drupal.org to explain licensing inheritance and derivative works.

Fully embracing a more nuanced approach to licensing has been hampered by legacy tooling, but that finally changes in January!