Policy on bridge modules for non-GPL PHP libraries

It would be problematic if drupal.org could not host modules that expand functionality for end users that link to non-gpl libraries. Either through lack of enforcement or misinterpretation of the policy, this seems to be the defacto acceptable interpretation. Additionally, there hasn't been a significant negative impact of hosting these modules, otherwise we ought to have seen an uptick of licensing violation reports.

I fully support the changes proposed.

Thanks for opening this Gisle!

I disagree. People build and hand-off Drupal sites all the time. We currently build distribution tarballs on Drupal.org, which means we are distributing such pre-built sites. Mixing GPL and GPL-incompatible code when distributing it is a violation of the GPL.

The question I think hinges on whether such a bundling qualifies as "mere aggregation", which does not trigger the GPL. I would argue that "this code will not work at all without this other code" is more than "mere aggregation". It's an in-memory mixing of code, which makes it a derivative work.

The same logic applies for how Drupal modules are GPL by virtue of depending on Drupal APIs. If we drop one, we drop the other, and I am reasonably confident most here (including Dries, based on his previous statements) do not want Drupal modules to suddenly be mixed license.

Even if one could argue that it's legally permissable, there's still the question of what we allow on Drupal.org. I firmly believe it's in our interest to keep the Drupal.org distribution channel as Free Software-purist as possible where code is concerned, so distributing modules that require you to use non-free code for them to work at all is a no-fly in my book.

(As discussed before, we can/should soften our stance on assets but we're talking specifically about code here.)

How is this any different than the discussion had around #2425319: [LEGAL?] Does the use of a CDN allow mixing GPLv2 and Apache2 javascript??

People build and hand-off Drupal sites all the time.

We definitely need to determine if that is considered "distribution" from a legal standpoint.

We currently build distribution tarballs on Drupal.org

We would continue to only allow packaging of distributions to code that matched the compatibility whitelist.

I firmly believe it's in our interest to keep the Drupal.org distribution channel as Free Software-purist as possible where code is concerned, so distributing modules that require you to use non-free code for them to work at all is a no-fly in my book.

We're not proposing that we open the doors from a Free Software purist channel to one where we support modules that require non-free code. We already have that, by virtue of existing policy vagueness, non-enforcement, and lack of complaints. The proposal is that we amend our policy to match what we do in practice. Do we have any examples of where this has caused harm?

Additionally, there is an added complexity that we do not have a policy that is Free Software purist as possible wrt free vs non-free, we have a policy that everything downloaded from drupal.org can be licenced as GPLv2 or higher. The FSF would probably argue that GPLv3 is the purest license. If somebody were to build a module that requires a php library that was licensed GPLv3 only, we would not be able to host that on drupal.org. i.e. Free software + Free'er software = not on drupal.org, which I don't believe is the intent.

Though there should be some consideration of the *spirit* of the policy - i.e. if I have a bower.json file in my module that requires non GPLv2+ dependencies to be downloaded to my server.

@gisle

and as should be clear from the title, this thread is about PHP code

If that was your goal, you shouldn't use CKFinder as the example.

@Mixologic, the LWG escalated the CDN question to the DA's legal team. My understanding of their response was basically that under the strictest interpretation of the GPL, these CDN invoking modules could not be considered GPLv2... but that assumed that the javascript was functional code and not a non-functional asset. At the time, the LWG decided that we didn't want to get into differentiating between javascript that was functional vs. non-functional, so we'd allow the status quo. So projects like https://www.drupal.org/project/views_isotope continue to exist.

I feel like were getting into the minutia regarding PHP as well, but CKFinder isn't a great example of that. CKFinder is primarily javascript that calls a single PHP file directly. That PHP file accesses the server's file system. The config.php included in CKFinder does not make any calls to Drupal's API nor does it use Drupal's menu routing or permissions. It stands alone. The CKEditor Drupal module simply adds the javacript to the output. The javascript is processed by the browser.

So as far as the Drupal module is concerned, it isn't any different that a module that is allowed to load Apache2 javascript form a CDN... something we've already discussed in length.

Let's use https://www.drupal.org/project/amazons3 as the example then.

A request was made for #1491516: Add AWS PHP SDK. That request was rejected because of Apache2 license. The module now includes a dependency on https://www.drupal.org/project/composer_manager and http://cgit.drupalcode.org/amazons3/tree/composer.json which ultimately adds https://github.com/deviantintegral/aws-sdk-php/blob/drupal-amazons3/LICE... to the project.

While I don't believe https://www.drupal.org/project/amazons3 can technical be GPLv2, a user could choose to use it as GPLv3 with the Apache2 library. Since it's already being distributed via Github, I'd vote to unpublished the downloads from Drupal.org vs. making including dependencies on non-GPLv2+ compatible assets the new policy.

I'm willing to chalk any GPLv2 + Apache2 issues use to confusion over the GPLv2 and GPLv3 licensing Drupal.org requires, but if I saw a module that required a commercially licensed PHP library I'd request that be immediately removed from Drupal.org.

The only other other module project I know of that requires a PHP library with a questionable license is https://www.drupal.org/project/fb. Version 3 required a version of a library Facebook licensed at Apache2. In version 4, Facebook moved to some kind of license + usage policy https://github.com/facebook/facebook-php-sdk-v4/blob/master/LICENSE. Since that project is already abandoned, I happy to start the process of publishing that as well.

The only way I can see allowing Apache2 libraries as dependencies defined in composer.js files is if Composer remains an optional tool only used by a small percentage of sites. That is how we've treated drush make. We've allowed dependencies in module projects (and even distributions that aren't packaged) that aren't GPLv2+ compatible.

As soon as Composer becomes a standard supported by the DA either by policy or community usage/demand, I believe we have to either require Composer dependencies (and the dependencies of dependencies) be GPLv2+ compatible OR abandon our policies and adopt WordPress's approach. I believe the actual WordPress licensing policy is something along the lines of "we say we are a GPLv2 project and follow Drupal's policies, but we don't really care about licensing and will distribute code with any license to users including code incompatible licensing combinations and commercial licenses".

I'm personally against this, but I also think the Apache2 problem is only going to get worse along with...

If somebody were to build a module that requires a php library that was licensed GPLv3 only, we would not be able to host that on drupal.org.

This isn't an if. We've rejected several GPLv3 only whitelist requests. Most of those are linked to #1449452: Give installation profiles/distributions GPLv3+ license as option for packaged downloads

It's not like move to GPLv3 magically solves everything. Then anything licensed as only GPLv2 only wouldn't be allowed. To be both as open and license compliant as possible, we'd have to offer users the choice of GPLv2 or GPLv3... which is what we do. One big advantage of limiting what is downloaded from Drupal.org to GPLv2 is simplicity. I'm willing to participate in another round of "should Drupal move to GPLv3?", but that is going to require changing Dries's opinion about this. In DrupalCon LA he indicated that several large organizations using Drupal selected it because it was GPLv2 over GPLv3. He wasn't sure specifically why, but was going to follow up on that. My guess is that GPLv3 opens the door to AGPLv3.

If I was running Drupal as a service or product, the idea that a dependency change in a library defined 4 levels deep in composer.js files could be updated to include code licensed as AGPL and what I thought was a simple update might result in running code that now requires me to share code that was never distributed as a result would scare the sh*t out of me.

We are in the process of restarting the LWG with regularly scheduled meetings. This topic obviously needs more discussion, but I'm not sure trying to work through it in the issue queue is the most productive use of everyone's time.

Just saw https://www.drupal.org/project/fb_autopost highlighted on the Drupal Planet feed. It also uses version 4 of the Facebook SDK which has the "swear allegiance to Facebook" requirement.

Composer becomes a standard supported by the DA

I would like to point out that that is specifically why Im here. I work for the DA, and we are building an officially sanctioned endpoint for use with composer, and I'd like clarity on the requirements.

We've rejected several GPLv3 only whitelist requests

The distribution whitelist and "GPLv3 only" isn't the issue here. The policy / legality is absolutely clear. Drupal.org will not host or package software that contains GPLv3 only code, or any other code that cannot be distributed compatibly with GPLv2+ code.

We are discussing whether or not that requirement extends to any other mechanism that facilitates the inclusion of GPLv2+ incompatibly licensed code, including, but not limited to:

• composer via composer.json
• drush make files
• bower.json
• http links to javascript files hosted elsewhere (aka the CDN method or let the browser do the 'linking')
• Documentation on a project page instructing users to download a file and add it to their project.

Even if we were to change licenses, we'll still need clarity on whether or not this form of linking to non-compatible code is acceptable from a policy standpoint.

the LWG escalated the CDN question to the DA's legal team. My understanding of their response ...

I talked with Holly to see if that was documented somewhere, and it was apparently during a phone call, so there isn't something we can refer back to. My instincts tell me that this sort of 'linking' would not get the DA and drupal.org into trouble ( All software we *distribute* is licensed GPLv2 or later), but that we should get something, in writing, from legal counsel that advises us one way or the other.

To me, this seems to be less of a legal question and more of a policy question of whether or not *code* (could be modules/distributions/ and soon libraries #2474007: Add a “General” project type to Drupal.org) that require a secondary retrieval and installation step of incompatibly licensed code to function are allowed on drupal.org.

My personal opinion is that if we had and enforced that kind of restrictive policy on drupal.org, drupal itself would sacrifice a *lot* of value in its ability to integrate with other popular systems over which we have no control. (e.g. Facebook, AWS). *Particularly* if we are enforcing a policy of licensing compatibility (no apache, no gplv3 only) when we mean to enforce a policy of licensing *philosophy* (Free vs Commercial). Perhaps we need two whitelists - one for what we can legally redistribute (the current packaging whitelist) and one for what we philosophically agree we do not have a problem linking to? (Apache2, gplv3 only etc).

At the PHP level, taking a chunk of code out of a project that other code depends on, licensing the code that was removed as something that isn't GPLv2 compatible, and then saying the parent project IS STILL GPLv2 just isn't going to fly.

The fact that Composer makes it easy to add code back to project in isn't a great reason to change our policies. If we want Apache2 licensed PHP, we have give every module (and distribution) the option of distributing as GPLv3. It really is that simple.

UPDATE: I should add that this is my opinion, I'm not a lawyer, and the DA should run this by their legal team.

just isn't going to fly.

Are you saying that wouldnt be legal? Im pretty sure thats fine. Thats how hardware manufacturers of video cards make open source drivers that depend on closed source binary blobs. Or maybe thats not legal and nobody tries to enforce it.

We should disregard any notion of how easy, or how widespread usage of any particular mechanism may be. Thats orthogonal to the discussion. If the only tool Im using on my project page is text that says "go download the non-compatible code from this location", then we need to clarify the policy to explicitly state that it is, or is not acceptable.

Right now, it *is* acceptable, and has been for years, as a result of the policy not being clear, and/or not being enforced.

gisle: Your point that "technically you could rewrite the Apache2 library yourself so it's not really a dependency" would apply equally well to any commercial library, and we don't allow those either. Also, that question is impacted by whether the API itself is subject to the terms of the copyright license, which per Oracle vs. Google is still up in the air at this point.

As noted, the issue is only about 3rd party code. In the past, that's been an edge case because 99.9% of the downloaded code on a Drupal site came from Drupal.org. Increasingly, that is not the case and it is going to become even less of the case. Every Drupal 8 site is going to include 3rd party code just from core, and several major modules have already stated they're going to use even more 3rd party code, and we're actively working to make it easier to include 3rd party code.

Wearing my consulting agency hat for a moment (*puts on silly hat*), this concerns me. Our standard contract with our clients says that we own any code we produce for them (custom modules), and license those modules plus downloaded code from Drupal.org to the client as a combined work under GPLv2+. That is, we are distributing the combined work to our client.

If that combined work relied on a variety of 3rd party non-Drupal.org-originating libraries, that process gets much more complicated. If any of those 3rd party libraries rely on GPLv3 or Apache2 code, then the only legal way for us to distribute the combined work to our client is under GPLv3. We do not always want to do so. If any rely on a commercial libraries, then it's debatable if it's legal for us to distribute at all, and thus there may be modules on Drupal.org that end-users are allowed to use but consultants cannot, which is just a horrible situation to be in.

In the Apache2 case, it's often because people still don't realize that it's not GPLv2 compatible. I've spoken to a number of companies and projects that thought they were being ultimately permissive with Apache2 and didn't realize they were therefore incompatible with the GPL, by which I mean "Drupal and WordPress". A few have changed their license to MIT for exactly that reason after I reached out to them, including ElasticSearch.

I think we do need to escalate this question to the LWG and Dries, and and likely bring in some input from various Drupal business folks. The stakes here for Drupal businesses, and their client-relationships and contracts, are quite high. A single d.o thread is not going to reach a good conclusion.

I just want to clarify this point from #16...

Currently its author has licensed it under GPLv2+. I think the author has the legal right to do this. So far, nobody has reported it as a violation of that license. Do you think it should have been reported as a violation of GPLv2+?

While technically true, we require all code distributed from Drupal.org to be licensed as GPLv2. Including a dependency on an Apache2 library isn't a GPLv2+ legal issue. It is a Drupal.org policy issue. If we were to change to distributing everything as GPLv2+ it would MUCH more confusing. What you've downloaded might be 100% compatible with GPLv2 or one of the project may have included something that required it to be distributed as GPLv3. How would the user know? This is essential what WordPress has been doing for years. We've talked about ways we could possibly handle this for #1449452: Give installation profiles/distributions GPLv3+ license as option for packaged downloads, but that is a much more controlled environment than all module projects.

...and we're actively working to make it easier to include 3rd party code.

For me, this is really the corner we are turning that requires changes to our licensing policies or approach. I've always felt it's a bit of a grey area when a users has follow a multistep process to add a non GPLv2+ compatible library. When they go to a URL to download the project, expand the package, place or rename it in their sites/all/libraries, they have many chances to see the license the library is using. They are making a decision to include something on their site we aren't allowing on Drupal.org.

While the licensing information is often available in the composer.json, that can be buried N levels deep and is not something the users sees when installing.

That fact that it will be so much easier to end up with a site have has mixed GPLv2 and Apache2 and there are so many more Apache2 PHP libraries than there were 5+ years ago is a real issue, but one I think we should at least try to address the reason why developers are selecting Apache2. Facebook and Amazon likely chose Apache2 for specific reasons, but my guess is that many developers choose it because of the user experience of http://choosealicense.com/.

Am I concern about patents? I guess so, but Apache2 is being presented as a middle of the road option between the "do anything they want" option and the option that "requires" and "forbids" things. For some who just wants to share their code, GitHub really makes Apache2 seem more appealing.

@joshuami made a suggestion at DruaplCon LA to work with the licensing groups of other GPLv2+ PHP projects to try make more PHP developers aware of the benefits and downsides of GPL vs. Apache2. Maybe even collective request that GitHub make some changes to http://choosealicense.com/. I few posts about licensing best practices for PHP project from high profile members of the Drupal, WordPress, Symphony, Larvel, etc might go a long way towards minimizing the Apache2 issue.

I don't believe most of these Apache2 projects really have any reason to be licensed as Apache2. I think we should put some effort into attempting to fix that before we change our policies to allow a confusing mix of licenses under GPLv2+ or move to GPLv3.

This confuses a lot of people, but the use of "checked into" is intentional. Every time I do a presentation about Drupal licensing I ask what license Drupal use. Most people know it's GPL, but when asked what version of the GPL even long time contributors get that wrong. Everything committed has to compatible with both GPLv2 and GPLv3. What we distribute from Drupal.org is done only as GPLv2.

Everything committed has to compatible with both GPLv2 and GPLv3.

That is true.

What we distribute from Drupal.org is done only as GPLv2.

That is false.

https://www.drupal.org/about/licensing#q1

Drupal.org distributes code under a dual licence. It is up to the end user to decide whether or not they choose to *redistribute* what they download from us as GPLv3 or GPLv2 or even as both if they choose. If the end user adds Apache2 software, they are welcome to redistribute that code as GPLv3, as those would be compatible, both with our values, and with the terms of our licenses.

The revised version of that (still a draft) makes this a little clearer. It reads...

All PHP code committed to Drupal.org’s git repository is licensed as GPLv2 or later (often abbreviated “GPLv2+”). This means that the code is licensed under GPLv2, and there exists an option that allows downstream recipients to re-license the code to be under a later version of GPL.

This is why the packaging scripts have only ever added the GPLv2 license. Technically I think we are all saying the same thing. The difference is really whether a developer can create a Drupal module that must (at least initially) be licensed as GPLv2 when it depends on code that uses a license that isn't compatible with GPLv2.

I keep going back to the response from the DA's lawyers about a module using Apache2 or GPLv3 javascript from a CDN. While non-GPLv2 code is never committed to Drupal.org, we questioned whether the code that was committed could actually be considered GPLv2. The legal feedback was that in most cases the module can't be GPLv2, but it really depended on how the javascript was used.

Unfortunately there is no "how it's used" flexibility with PHP.

The fact that a user triggers the download of the non-GPLv2 compatible dependency after downloading the module from Drupal.org is really irrelevant. The fact that the user has the right to distribute what they've downloaded from Drupal.org and somewhere else is also irrelevant.

The issue is claiming that a module written to depend on code you know isn't compatible with GPLv2 can be considered GPLv2.

My understanding is that it cannot, but I think we are at the point the DA is going to require input from actual lawyers again.