Revisit and Redefine Drupal's Policy on hosting 3rd party files and/or files that is not strictly GPL

To clarify the current situation:

The policy hasn't changed per se; it's still "everything is GPL by default, don't check in 3rd party code, although the d.o admins can make exceptions in some cases." We've just made a lot more of those exception in Drupal 8. For contrib, that policy is not always consistently enforced because no one is actively policing modules that include jquery plugins et al.

As an aside, for PHP code at least I would very very very much like to get the 3rd party code out of our repository and use Composer instead, but that issue has been stalled for some time: #1475510: Remove external dependencies from the core repo and let Composer manage the dependencies instead (and various related issues)

One important distinction is core vs. contrib: What is ok for core does not have to be ok for contrib.
I am also moving this over to the webmasters' queue as I don't think of the code we distribute as website content.

There are three questions that have to be considered:

1) Legal: Can we legally include the code in our git repos and distribute it as tarball?

2) Infrastructure: Is it desirable to include copies of other code that could be obtained elsewhere?

3) Security: Is it desirable to include code where we cannot establish a security process?

ad 1) This is something to decide on a per-license base. We distribute all code under GPL2+, so all other code has to also conform to this license. If the code isn't licensed under that license, the person who includes this code needs to be able to re-license it under GPL2+ for inclusion on d.o. This is possible with some licenses, we could assemble a list.

ad 2) Increasing the size of our repos also increases costs of storage and distribution (bandwidth). We should keep this in mind.

ad 3) Who is going to monitor external projects for security releases in order to do a new sec release of the project that includes that?

2) Infrastructure: Is it desirable to include copies of other code that could be obtained elsewhere?

In these days of Github, I think most developers have an understanding of code existing in multiple places. I've never heard an end-user lament a module that included a bundled library, though from time to time the additional flexibility of being able to override the library through Libraries API is requested (e.g. the copy bundled with the module would be overridden by sites/all/libraries). I'd love to keep developers on drupal.org based on their merits and not risk continued defections or (worse) never contributing to drupal.org because of our policies.

3) Security: Is it desirable to include code where we cannot establish a security process?

We don't necessarily need to accept all the responsibility of 3rd-party library security, but including bundled versions of libraries is a helpful thing for our end-users as far as security is concerned. If a security update of a Drupal module is released, most users are notified of the problem through Update Status. Hardly any 3rd party libraries provide this benefit directly (other than perhaps through individual mailing lists). If we can set expectations that Drupal.org is not responsible for the security of libraries (whether downloaded separately or bundled) then we're providing our end-users a significant service by notifying users of security holes found/fixed in bundled 3rd party libraries.

Most modules don't have this problem, but I'd love if it became official policy to explicitly credit any bundled libraries on the project page. A good example might be http://drupal.org/project/views_slideshow, which bundles jquery.cycle.js, but doesn't explicitly mention its inclusion (other than saying it might conflict with jQuery Update). Maybe any project that included a 3rd party library should be required to list its bundled libraries, and link to a universal disclaimer about 3rd party code.

ad 2) Increasing the size of our repos also increases costs of storage and distribution (bandwidth). We should keep this in mind.

It's a good thing to keep in mind. Are we in danger of exceeding storage or bandwidth limits on drupal.org? Is this is a change that is beyond our current resources? Unless it's a problem for our resources, I think we have the opportunity to provide significant value to both developers and end-users by becoming more lenient in our policies.

While a lot has changed in 5 years, these are largely the same arguments against allowing this. I didn't think they were entirely valid then, but they are less valid now. I can't wrap my head around how after the massive growth in code since moving from cvs -> git, the small amount of javascript that is often driving these requests would have any noticeable impact on bandwidth or storage. Now that we allow packaging 3rd party code in distributions, including a minimized version of that code in a module makes Drupal more secure, not less.

Are we in danger of exceeding storage or bandwidth limits on drupal.org?

Even if we were, allowing the full download of 3rd party code in distributions and not allowing a minimized version in modules is using more storage and eventually more bandwidth. In many cases the library's samples, documentation, human readable source make up 75% of what is included in a download. In some cases the library download is pruned with a patch as part of the packaging, but most .make files include the full download as is.

Of the 5 most installed distributions (after core), 3 of them include CKEditor or TinyMCE. One includes Plupload. None of these prune the samples, documentation, human readable source...

http://drupalcode.org/project/openpublish.git/blob/refs/heads/7.x-1.x:/d...
http://drupalcode.org/project/openpublic.git/blob/refs/heads/7.x-1.x:/dr...
http://drupalcode.org/project/openchurch.git/blob/refs/heads/7.x-1.x:/dr...

If minimized versions of libraries are allowed to be included with the modules the result would be that those modules and minimized libraries would be packaged with distributions instead of the full versions downloaded from the URL specified in the .make. There would be a storage savings since the distribution tarballs would be much smaller. There won't be much of an impact on bandwidth until a distribution becomes as/more popular than core as a starting point, but that's (arguably) the direction we are heading.

I'll save @killes the time and make the obvious response... if 75% of the files aren't used, the distribution maintainers should be pruning the extra files as part of the packaging for storage, bandwidth, AND SECURITY.

True. However, that puts the responsibility for maintaining the files included or purged from the library on the distribution maintainer. The module maintainer is likely more familiar with the library files required as well as following the 3rd party updates more closely.

Security: Is it desirable to include code where we cannot establish a security process?

Is there a difference in security between code included in a downloadable distribution and code committed to git as part of a module? I'm going to argue that since we already allow 3rd party libraries in distributions, allowing minimized versions included in a module would make it MORE SECURE. Users downloading 3rd party code as part of a distribution do not understand whether that code came from Drupal's version control or was simply packaged into the download from a 3rd party's version control system.

Legal: Can we legally include the code in our git repos and distribute it as tarball?

We are already distributing this type of code in tarballs, so the only question is the legality of packaging from Drupal.org's git vs. pulling it in from the .make as part of the packaging.

We can also debate this using real examples that violate (or have an undocumented acception to) the policy. JQuery Update now includes 3 versions of JQuery and JQuery UI and has been downloaded more than HALF MILLION times. Why is the Drupal Community paying to distribute versions of JQuery in a contrib module when it is actively maintained and can be downloaded from other locations reliably? JQuery Update doesn't meet any of the criteria for allowing an exception, but including the libraries is it makes JQuery Update MUCH easier to install.

The ability to include libraries vs. requiring users to download code and add it to the correctly named directory in sites/all/libraries impacts both site builders's initial experience and the number of installation issues the maintainer has to deal with.. these goals have always driven the developers to make requests for exceptions or ignore the policy. I don't believe archiving those goals by including libraries in modules is incompatible with security, infrastructure, or legal concerns.

The packaging whitelist process checks both the license and the size of the files to be packaged. A common sense approach that wouldn't add new responsibilities would be that if a 3rd party library's license is approved for packaging in a distribution (even if size is still an issue), a minimized version should also be allowed in a module that's primarily purpose is:

• provide the minimized library
• support overriding the library by adding a different version of sites/all/libraries
• alter users to security updates in the 3rd party library

By limiting the primary feature of these modules to "library provider" we avoid multiple modules including the same 3rd party library.

@jenlampton Not SOLE purpose, but PRIMARY. Modules that include a library should be encouraged to provide only minmal functionality so other developers can build on them instead of working around them. JQuery Update is a perfect example of how this can be done. It doesn't provide the js files AND functionality. It's only enabled when another module depends on it or someone is doing custom JQuery work.

I already maintain and/or build on several modules that fit the 'primarily a library provider' description including:

http://drupal.org/project/isotope
http://drupal.org/project/jupload
http://drupal.org/project/popcornjs
http://drupal.org/project/popcorn_base
http://drupal.org/project/awssdk
http://drupal.org/project/phpids

Most of these require a multi step install process. Something like...

1. Download the module
2. Enable the module
3. The module will either enable and warn you via status message that it is not happy or will check for a library as a dependency and tell you it can't be enabled until you do X
4. Find the URL to download the library
5. Figure out what part of what you just downloaded you really need
6. copy directory to sites/all/libraries
7. maybe rename the directory
8. check the status or try enabling the module again

Compare with the user experience using JQuery Update...

1. Enable the module

Some of these modules pull from external urls by default, but allow overriding the external version with a local copy of the library in sites/all/libraries. That makes them much easier for most users to enable, but less reliable with a dependency on external resources always being available.

it also creates a nightmare of module dependancies, downloads, and enables for the end user. It may also prevent tight-knit integration between the module and the library, and it doesn't help in cases where the 3rd party library does need to be changed from it's publicly downloadable state

There must be some miscommunication, because what I'm suggesting would NOT do any of that.

Let's look at a real example where library was used introduced in a less than ideal way. I updated a D6 module from @funkym's sandbox to create
http://drupal.org/project/views_isotope. At the time, there weren't any other modules using the Isotope library so I just loaded it when this view format was used using the Libraries API. Worked for me, but views_isotope didn't provide any additional functionality. Now @Sjarsena is also using Isotope in http://drupal.org/project/isotope. What @Sjarsena did was MUCH better. The core isotope.module simply manages how the library is loaded. The project download also includes an example of using Isotope with Context. @Sjarsena's example doesn't get in the way of making the core Isotope module a dependency of Views Isotope. If @Sjarsena could include the Isotope files in that modules, it would make enabling Views Isotope much easier.

Isotope is a great example for another reason because the library is not a GPL compatible license, so it wouldn't be whitelisted and would remain more difficult to install. Easier installs is just yet another avantage of building of GPL compatible code as well as a reason for library developers to use these licenses.

@quicksketch is also right about the current policy deterring developer interest in contributing. Other than security fixes, I didn't touch TinyMCE after I was told I'd have to support a multistep install process EVEN if I was using a modified library. The final straw for me was when I was told I couldn't include 10k of code from PunyMCE as a starting point for TinyMCE users. My goal was to include a working WYSIWYG "out of the box". I thought this would cut down the support requests and improve the user experience, but I couldn't even get an 'official' exception for 10k of GPL code.

It looks like @quicksketch went ahead committed CKEditor before getting a response on #1856438: Provide project bundling exception for custom build of CKEditor. I hate to think how much time and frustration site builders would have been spared if I had the balls to do that in 2007. Unless @quicksketch is banned from git, I am going to do something similar w/ TinyMCE after the holidays.

The amount of code we are talking about in these minimized libraries is a small fraction of the number of files now in git. Creating modules that are easy for users to install and developers to build on while adhering to licensing of the library shouldn't require an exception to the policy... IT SHOULD BE THE POLICY.

I was told I'd have to support a multistep install process EVEN if I was using a modified library.

Who told you that? I think the policy has been that if the library has to be changed then it can be included.

why it might help

I agree entirely with the need for greater transparency around this subject.

I reiterate that for PHP code, the easy solution is also the correct solution: Let modules use Composer directly. That resolves the "two modules include the same library" problem, it resolves the 3rd party licensing problem, it resolves dependencies, it's awesome like that.

For JS code, I'm not sure. On the one hand it's definitely easier UX to have the library bundled with the module that uses it; on the other, legal issues aside it runs smack into the "two modules include it" problem, for which I don't believe we have a good solution.

http://drupal.org/node/66113 was updated with changes referencing this issue without actual consensus. I've reverted the changes for now, please forgive me if I misunderstood.

This is a big change, there are other projects that have done this recently for example see VLC they changed from MIT to GPL3 in order to do so they needed to contact the parents of some people who had died, the parents would not give permission for the code to be used and therefore those components needed to be re-written. Another project to look to is GIMP and GNOME they have both had issues etc with the maintenance of contributors.

So this is a big step/ change for the community and we need to have these things factored in. the other thing is we actually need people to take care of this? I raised this issue at Munich and there seemed to be NO-ONE at the time who had even contemplated this? That was a surprise to me as this is a big licensing change for the community and is going to need some re-education?

So all is good etc it is just making sure there is a clear understandable path and solution and mechanism and well We need to have someone at the DA all over this shite... lol and what I mean by that is one of the key components of an association in an open source project is to monitor and assist in the maintenance of licensing..

Re #12: This issue is not about relicensing core or contrib. It is about figuring out how to include 3rd party code into the download package in a way that is as convenient as possible for people who download drupal modules without putting an undue burden on module/theme maintainers.

@greggles Sorry I missed this before. Glad you're getting involved in this discussion.

I'm referring to the attempt to get a minimized version of TinyMCE into the module that happened almost 6 years ago. You can re-read the entire thread or the highlights...

http://groups.drupal.org/node/3364#comment-12473

The bottom line was made by Gerhard Killesreiter. I was told in no uncertain terms, if I committed any amount of TinyMCE my CVS account would be disabled.

Sadly, very little has changed in the 6 years since that "discussion". Developers that ignore the policy are able to create better solutions. Pointing out violations in popular modules in an attempt to get the policy changed accomplished nothing...

#1857042: [jquery_update] 3rd party libraries

The next step with the JQuery Update issue would be to report that the maintainers of the module are ignoring the fact that the module violates the policy. Let's ignore the fact that this has been pointed out several time in the last 6 years. What's supposed to happen...

maintainers who violate this policy or refuse to correct violations brought to their attention may have their project unpublished or Git access revoked.

So despite being enabled on more than 160K+ sites, JQuery Update would be unpublished and @jjeff, @Rob Loach, @mfer, @sun and possibly even @webchick would all have their git access revoked?

Seems very unlikely.

related

I've changed the issue summary to better reflect the language of the current policy which talks about "files" (i.e. "code" and "assets"). Quote:

All files checked into the repository (code and assets) must be licensed under GNU/GPL version 2 and later.

Allowing non-GPL compatible code in repos will not be possible because the GPL requires all derivatives to be licensed under GPL, and code+other code creates a derivative.

However, the mere inclusion of an asset in a repo/tarball does not create a derivative, but a composite. This is what the Joomla! licensing FAQ has to say on the matter:

In our opinion, templates are composite packages that consist of both code elements and non-code elements. We believe that the code elements of a template must be licensed under the GNU GPL because they are derivative works. However, the non-code elements are just data acted upon by the software and may be licensed in any way the author sees fit. The non-code elements include elements like Images, Movies, Animations, CSS and formatting markup. Source: http://opensourcematters.org/license-trademark-and-copyright/licensing/5...

The SIL Open Font License FAQ makes a similar point:

Question: 1.2 Can the fonts be included with Free/Libre and Open Source Software collections such as GNU/Linux and BSD distributions and repositories?

Answer: Yes! Fonts licensed under the OFL can be freely included alongside other software under FLOSS (Free/Libre and Open Source Software) licenses. Since fonts are typically aggregated with, not merged into, existing software, there is little need to be concerned about incompatibility with existing software licenses. You may also repackage the fonts and the accompanying components in a .rpm or .deb package (or other similar packaging formats or installers) and include them in distribution CD/DVDs and online repositories.

My proposal is that we stop treating non-code assets as code. Instead, assets with a license that allows the asset to be included in a GPL licensed project shall be allowed on Drupal.org.

Comment #2 points out three problem areas (legal, infrastructure, and security) with allowing non-GPL materials. Of those, I think the legal and security problems are strictly related to code, not assets. The infrastructure problem (Is it desirable to include copies of other assets that could be obtained elsewhere?) may still remain, but I think it can be handled on a case-by-case basis, or by improving the infrastructure to provide a shared library for much re-used assets (such as Font Awesome).

@gisle: is this your original research?

Even if it seems reasonable that associating code and assets would form a composite work (like music and lyrics forming a song), the GPL (at least v3) is crystal clear that if you convey a "work based on the Program", "you must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged".. (Emphasis mine.)

Cannot be clearer than that. So as soon as you are leveraging a GPL part in a work, the whole work and all its parts must be released under the GPL. The only way we could escape this is if we were not leveraging any GPL part, so that we own the copyright to all the parts we release under the GPL. I cannot believe that would be the case (many of the Javascript components that we leverage are GPL, for example).

@gisle: is this your original research?

No, the distinction between the two is is pretty standard fare in IPR-law. Here are the the textbook definitions:

A “composite work” (also sometimes referred to as a “compilation” ) is a work formed by the collection and assembling of preexisting materials or of data that are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship.

A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work”.

I don't know why you quote from GPLv3. Drupal.org uses GPLv2, which says

This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law (my emphasis).

The following is also from GPLv2:

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License (my emphasis).

The two sections quoted above from GPLv2 has been purged from GPLv3. There are many improvements in GPLv3, but they're all eclipsed by its embedded politics. The first commandment of GPLv3 is: "Thou shalt have no other licenses before me". IMHO, the GPLv3 should be regarded mainly as a tool for enforcing the politics of rms, not as an enabling tool for free software and free culture.

Please that Drupal.org does not allow any code licenced under GPLv3 only to be checked in. That is a very wise decision.

I don't know why you quote from GPLv3.

Drupal and all software distributed by Drupal.org are distributed under "GPL version 2 or any later version". So GPLv3 does apply completely here, and we cannot take decisions based on the GPLv2 alone.

Damien Tournoud wrote:

Drupal and all software distributed by Drupal.org are distributed under "GPL version 2 or any later version".

The license applied to the core and any project hosted on the Drupal.org is GPLv2. Please visit any project hosted on Drupal.org and read the file LICENSE.txt before confusing this further.

Please also read the FAQ item I linked to in #17 above, that explains how to interpret the phrase "GPL version 2 or later", viz.:

You may only check it into Drupal's Git repositories if you are releasing it under the same license as Drupal itself, that is, GPL version 2 or later, allowing users to choose between the terms of the GPL version 2 or the terms in any new versions as updated by the FSF.

I.e. users can, if they choose to, obey the terms of GPLv3 instead of GPLv2. This does not in any way oblige Drupal.org to obey such terms.

Damien Tournoud wrote:

So GPLv3 does apply completely here, and we cannot take decisions based on the GPLv2 alone.

I see no point in debating this further. You're wrong.

@gisle: you misunderstand. Drupal and all software distributed by Drupal.org is released under GPL version 2 or any later. The story really ends here.

This is simple multi-licensing, and the LICENSE.txt is only *one* of the licenses we distribute our code under.

The license the recipient is going to chose is of course at the discretion of such recipient. But all the points that you are making in this issue must apply to all the licenses we are distributing code under, and it seems clear that your points about composite work are at odd with GPLv3.

it seems clear that your points about composite work are at odd with GPLv3.

That is correct. That is why I am so pleased with Drupal.org using GPLv2+ as its license.

This is simple multi-licensing, and the LICENSE.txt is only *one* of the licenses we distribute our code under.

It is not multi-licensing. There is a single license included in the repo.

However, even if it had been a case of multi-licensing, you'd been wrong. Multi-licensing doesn't require compliance with all the multiple licenses. Just one of them will do. For instance, Wikipedia is multi-licensed under both GFDL and CC-BY. Almost all derivatives of Wikipedia is licenced under CC-BY alone, since the attribution requirements of GFDL is impossible to comply with.

Please also read the licensing FAQ: https://www.drupal.org/licensing/faq#q12

@gisle: We do distribute Drupal under GPLv2 *and* GPLv3, right now. This is simple multi-licensing. "GPL version 2 or any later" is *not* a license, it's just a way of saying "it's GPLv2 or GPLv3 at your own choice". I'm not sure where we misunderstand each other here.

And I'm not saying that anyone needs to comply to *all* the licenses. I'm just saying that if you assert something like:

Allowing non-GPL compatible code in repos will not be possible because the GPL requires all derivatives to be licensed under GPL, and code+other code creates a derivative.

However, the mere inclusion of an asset in a repo/tarball does not create a derivative, but a composite.

It must be valid for every license we distribute Drupal under. Meaning right now GPLv2 and GPLv3. It is not true for GPLv3, so this is really the end of the story. You are wrong.

And again, the LICENSE.txt file that is in the repository is only one of the license we distribute Drupal under. It is GPLv2. The canonical licensing statement is in COPYRIGHT.txt, and clearly state the multilicensing:

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or (at
your option) any later version.

The statement is reiterated in our licensing FAQ:

Drupal and all contributed files hosted on Drupal.org are licensed under the GNU General Public License, version 2 or later. That means you are free to download, reuse, modify, and distribute any files hosted in Drupal.org's Git repositories under the terms of either the GPL version 2 or version 3.

Again: Files hosted on Drupal.org is not licensed under anything but GPLv2. The "or later" addendum is a standard provision in the free software community to allow downstream compatibility (i.e. allow derivatives to be combined) with code that is only available under GPLv3 or Apache 2.0. Please see the GPL License FAQ for more information about this. I quote from note #3, which explains this rationale:

If you have the ability to release the project under GPLv2 or any later version, you can choose to release it under GPLv3 or any later version — and once you do that, you'll be able to incorporate the code released under GPLv3.

Here's how it works:

If somebody, makes a derivative (say, a distribution) of files hosted on Drupal.org and, for some reason, they choose to license it under GPLv3 only (rather than GPLv2 or later) - they're perfectly free to do so. (I think we agree on this.).

By choosing to license the derivative under GPLv3 only (rather than GPLv2 or later), the author is not permitted to include any asset in his derivative that is not available under a GPLv3 license. (I think we agree on this as well.)

So where do we disagree?

Well, I happen to think that this (forcing authors of derivatives to either choose GPLv2 or later, or exclude some assets not compatible with GPLv3) is not a problem. Certainly not a problem for Drupal.org. Maybe you think otherwise? If so, we can at least agree to disagree, and terminate this sub-thread.

I think it is great that authors of derivatives has the freedom to choose between GPLv2 and GPLv3 (and GPLv4 if that ever happens). I also think it is great that non-GPL assets can be included as "mere aggregates" in a project hosted at Drupal.org, even if those assets must be removed from any derivative that the author chooses to license under GPLv3 only.

And I certainly do not think that the term "GPLv2 or later" implies that Drupal.org carry an obligation to make everything hosted on Drupal.org available for re-licensing under GPLv3 only (and while we currently pretend we do this, everybody knows that this not true). However, I suspect we disagree on this point as well, which is OK with me.

I've also asked the FSF (i.e. licensing@fsf.org) about whether an image licenced under CC-BY-SA (a license that is not considered GPLv2 compatible) can be included in a distribution under the terms of GPLv2 as "mere aggregate". Below is their answer:

It is the position of the FSF that if a work licensed under the terms of the GNU GPL isn't dependent on a particular image in any way, that is, the software would effectively function identically with any other image, then the image could be considered as being distributed in mere aggregation with the work.

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

#4 seems to make the most common sense to me if we are discussing changes to the 3rd party policy. If I were to write a new policy, it would probably be identical to his post. I no longer contribute modules to d.org that have 3rd party libs because of the current policy. Good for me since I am paid by clients to reinvent the wheel (mostly for things like payment gateways and non-drupal templates), bad for D.org though since I am never going to bother to contribute those modules/themes back to D.org because dealing with the 3rd party lib policy is not worth the time/hassle. It's quicker for me to create a custom module/theme that will never be committed back to d.org that either DL's the required lib or includes it statically, rather than to have to create a non-functioning module, put it on d.org, and then have to deal with all the support issue queue items that would pop up because no one could figure out how to DL and install a lib to get it to work. It's simply to much hassle for both myself and the end users.

Exempting images/css files really isnt changing anything IMO other than to make it more confusing. There are so few instances where that would make a difference that it really doesnt make sense to even bother to make the policy change to begin with. How many lib files are there that are going to include just a images/css files? Like, what use case can you show where this type of policy change is actually going to improve anything compared to the existing policy?

Even a non-drupal theme/template is likely to include some sort of JS or PHP that would make it incompatible with the current no 3rd party code policy. I say, either change it completely to something similar to #4, or keep it the way it is and not add any confusion by trying to nitpick which file types can/cant be included.

There is however 1 policy that SHOULD be changed. If a module's files have been exempted in a private discussion such as IRC, in person, over skype, etc, then those private discussions should be published publicly somewhere (like in an issue queue) as it's not really fair to those who cannot read that discussion and will inevitably point out that those projects have violating files, usually with something along the lines of "But what about XYZ project, they have files that violate policy also". The most common to be used as examples are ctools and jquery update but there are hundreds of others out there that could be used as an example due to IRC discussions and what not. How are these uninformed people suppose to know these projects are exempt and for what reasons if all of that has been done "privately" and not in a public forum here on d.org. There are some cases where these HAVE been done publicly, but that is not the case for ALL of the projects which is something that should change. An example of a privately held discussion is CTools as stated by MoC in the past.

As a Drupal contributor, I've never been able to fully grasp what the policy is for third party code but after reading and following this issue, I can see it's in flux. Just doing a quick search of some drupal.org repos, I found several MIT licensed files. Here is just a brief sampling.

http://cgit.drupalcode.org/simplehtmldom/tree/simplehtmldom/simple_html_...
http://cgit.drupalcode.org/adaptivetheme/tree/at_core/scripts/onmediaque...
http://cgit.drupalcode.org/ds/tree/modules/ds_search/js/ds_search.js
http://cgit.drupalcode.org/media/tree/js/util/ba-debug.min.js

No doubt there are many more. Ideally, it would be great if contrib could include MIT licensed code or even CC images in a legitimate way but I don't know all the nuances, especially after reading through this.

crystaldawn wrote:

There is however 1 policy that SHOULD be changed. If a module's files have been exempted in a private discussion such as IRC, in person, over skype, etc, then those private discussions should be published publicly

I agree. I am very much in favour of there being complete transparency and a public record when a exception is made regarding third party material.

Currently, in this issue thread and elsewhere, a broad review of the policy is taking place. I hope that this is one of the changes that shall be implemented.

Danny Englander wrote:

Just doing a quick search of some drupal.org repos, I found several MIT licensed files.

The Expat (MIT) license is a permissive license that is considered compatible with the GPLv2 license. When materials under the MIT license is placed in a repo on Drupal.org, it is technically relicensed under GPLv2 and there is also a statement in our distribution terms that says it can be further relicensed downstream under the GPLv3 license (hence the term "GPLv2 or later", sometimes abbreviated "GPLv2+").

We now maintain a whitlelist of licenses that has permissive terms that allow relicensing to GPLv2+. The Expat (MIT) license is the third item in this list: https://www.drupal.org/node/1475972#whitelist-licenses

Having an easily accessible whitelist of allowed licenses for third party material is one of several measures that shall be implemented to bring more transparency to Drupal.org's policy on hosting 3rd party files.

@gisle: I don't understand how you can pretend that "GPL version 2 or later" is not multi-licensing, as it is clearly. The language of COPYRIGHT.txt is really crystal clear.

Also, you are missing one very important fact: Drupal.org doesn't own the copyright of *any* code. Drupal.org is distributing code, and as a consequence it is *itself* using the license. Any derivatives or composites created by Drupal.org (for example during packaging) must respect at least one of the licenses the code is distributed under by the original authors.

In addition, if the intent of Drupal.org itself is to distribute those derivatives or composites under the same terms ("GPL version 2 or later"), then those works must respect *both* licenses.

How does license.txt get into a project file? As far as I know it's an automated process that forces each project into whatever license is in license.txt that the git server places there automagically. The user has no choice in the matter of which license to use because they are not able to replace license.txt with that of their own. If they do, its overwritten (by the git server upon push) and given a warning/error message (use to be when you try to roll a release tarball, idk about now as it maybe changed) that such file should be removed from their project. At least thats the error I was given when I tried to create a new release and had accidently put in a different license.txt file from some files I had copied. Seems to me that the user doesnt have a choice other than to place licensing in their own files which is then overridden by license.txt? IDK, the whole licensing crap seems like non-sense to me. Drupal's policy as a whole on the subject is garbage to begin with IMO.

crystaldawn: You are free to disagree with something, but "the whole licensing crap seems like non-sense [sic] to me" is a statement of ignorance. Quite simply, without a clear license it is a *felony* to use code written by someone other than yourself. We need to take care that we are not inadvertently causing our users to commit a felony. If you want to argue that the current copyright system is "crap" and "nonsense" I'd be the last to disagree with you but dealing with licensing rules is a mandatory part of working with open source code.

Regarding "Drupal's policy as a whole on the subject is garbage to begin with", our current policy was vetted with an attorney years ago, and is only a little more aggressive than most other GPL-based projects. Quite simply, doing anything less than we do where PHP or JS code is concerned would be illegal. I'm sorry if you don't like it, but this is an area where "random person's opinion" doesn't mean diddlysquat. The law as understood by our attorney matters.

That said, I don't think anyone is disagreeing that when exceptions are made to the "never check in 3rd party libraries" rule they should be publicly discussed and recorded. They should. The DA is working on forming a new working group to handle such issues more effectively.

Cool story bro. Now you see why there are so many who are of the same mindset as myself (that drupal's policies almost always go overboard in whatever they are). To much lawyering, not enough coding and common sense. No one here is arguing that the gpl licensing is causing a felony and there isnt a single person here who would say that putting the sourcecode for something like winblows in Drupal's git is a bright idea as it goes against the common sense rule I just mentioned. Common sense dictates that you simply dont put other code in that doesnt jive with anything GPL'd. If I were to give the GPL a new name, it would be the CSRL, Common Sense Rule License, since that is basically all it is. Everything boils down to common sense. The GPL dictates what can/cannot be used, we dont need a lawyer to figure that out for us, it's in black and white with the GPL, either version really. So it also goes without saying, I dont need a Drupal lawyer to tell me how to use the GPL. The fact that you are aware that Drupal is different than other projects in regards to licensing speaks volumes about why I have the opinions I have. It's uncommon and unhealthy IMO. It gives an air of dictatorship (which IMO, Drupal is a large offender of), as does your own statement of saying other people's opinions mean didlysquat. It doesnt take a genius to figure out how to use the GPL let alone a lawyer.

Bottom line is, the policies are fine the way they are. I simply dont contribute to Drupal as much as I do other projects because of it's policies and I'm fine with that. If it is changed, it should be completely overhauled rather than tiptoed around to cause more confusion by trying to dictate (theres that dictatorship aura again) what filetype can be included based on the dimensions of a page/theme etc. If it's available online, dont include it in Drupal. They dont like that kind of thing. GPL or no GPL. Thats the way I see it. It works for me, it means I dont have to maintain as many modules with the current landscape of Drupal's policy. When someone asks if I will contribute XYZ module that I wrote for XYZ's API libs, I simply say no and then point them to the 3rd party clause. More money for me, less modules for Drupal so I'm not complaining with anything. Just saying that if things are going to change, they should be changed dramatically, not uglified by making it more complex than it already is.

BTW, I'm mystified why you think the GPL (any version really) is not a "clear license". It seems pretty clear to me and millions of others. It's the Drupal sugar coating that fogs up the windows making it hard to see/understand/agree with.

The Drupal Association is going to discuss licensing policy on its board meeting on August 20th. There was recently a preliminary call about licensing policy to prepare for that meeting. Holly Ross (Executive Director at the Drupal Association) just posted a comment (in another licensing issue) with a link to https://docs.google.com/document/d/15Oo68ZmgxwuhFvasyKGZRfvAU9YVE9ddSZaJadDjO2M/">the notes from that call. I am reposting the link here, since it may be of interest to those following this issue as well.

The DA's board meetings are public. Visit this page on August the 20th to listen in on the next meeting.

Update: The Drupal Association Drupal Assocation is looking to create a new Licensing Working Group (LWG).

The proposed charter for the LWG is now put up for discussion on the Legal group on groups.drupal.org.

The discussion about the proposed charter is open until 1st of November.

Moving to LWG issue queue.

(We probably need to consolidate all those separate discussions about possible amendments to the licensing policy into a single thread.)

Changing component ("Policy" was not available when I moved it.)

Drupal.org doesn't own the copyright of *any* code. Drupal.org is distributing code, and as a consequence it is *itself* using the license. Any derivatives or composites created by Drupal.org (for example during packaging) must respect at least one of the licenses the code is distributed under by the original authors.

In addition, if the intent of Drupal.org itself is to distribute those derivatives or composites under the same terms ("GPL version 2 or later"), then those works must respect *both* licenses.

This actually finally made me see the situation clearly. Drupal might be dual licensed (or not, it's not the point here), but Drupal.org can choose which of those licenses it adheres to when packaging. So it chooses to honor only the GPLV2 part. Which in turn allows non-GPL2 assets as long as the code is GPL2. So the tarballs might not be dual-licensed, even though the code it packages might be.

Adding this blast from the past #416022: Theme requires download of non-GPL files for CC licensing reasons of the DATA parts of theme to the "related issues".