License issue in d.o. footer

Footer or the sidebar block on https://www.drupal.org/documentation?

In http://cgit.drupalcode.org/user_guide/tree/README.txt#n16, user_guide project uses...

Code in this project, consisting of scripts for generating output from the
source files, and code for generating automatic screen captures, is licensed
under the GNU/GPL version 2 and later license.

That's not really covering code used in documentation.

Technically @fgm is correct. Unless sample code included in the documentation is licensed as GPLv2+, a developer couldn't use that code in their project and commit it back to D.O.... but technically we can't retroactively change the license on code submitted via nodes either.

I thought we were making progress on moving to more modern, sane licensing policies when we allowed the user_guide project to commit content with a CC-SA license into git, but the licensing is still less than ideal. Because of Drupal Git Repository Usage policy, I think should assume that all code in that project is GPLv2+.

I think it's fine to specific which version of the GPL the PHP is being licensed as, but I don't see how we can retroactively apply a GPL license to javascript in documentation nodes we've been saying was being licensed as CC-SA.

I just want to add that I don't want to add a notice to the footer that spell out that JavaScript code is licensed under GPLv2+. Yes, our current policy says it is, but our current policy is wrong about this.

JavaScript libraries usually are licensed under some permissive license (MIT being the most common), and it is distruptive to all the good people of the Javascript library community that Drupal needlessly re-license our own and 3rd party JavaScript library under a copyleft license (GPLv2+) that restricts its upstream reuse.

Let us first complete the task of moving Drupal.org to more modern, sane licensing policy. Then we can work on how to document this policy in the footer and elsewhere.

IANAL, so take care, but in my understanding, it is entirely possible to relicense code we received under an MIT / BSD / Apache license to GPL-2.0+. See e.g. http://www.dwheeler.com/essays/floss-license-slide.html for an interpretation of this.

MIT and BSD are permissive licenses, and yes, it possible to re-license these to GPLv2+. We must do this with PHP code that is adapted to work with Drupal. We can do this with JavaScript code, but should not (IMHO) do it, as it is perfectly legal to use MIT-licensed JavaScript with Drupal without re-licensing, and re-licensing JavaScript creates its own set of problems.

As is clear from the the page you link to (http://www.dwheeler.com/essays/floss-license-slide.html) there is no path from Apache 2.0 to GPLv2+, only from Apache 2.0 to various flavours of LGPLv3 and GPLv3 (and later, but not earlier).

I beg to disagree on non-GPL being "more modern, sane licensing policies"

There is absolutely no plan to abandon GPLv2+ for PHP-code.

It is, IMHO, not sane to license non-code (images, text, font, icons) under GPL. The GPL is made for code, not everything. However, we currently require GPL for everything, and this is, IMNSHO, insane. The FSF seem to agree: The FSF do not recommend using GPL for non-code.

JavaScript and CSS are more tricky to find a suitable license policy for. CSS is decoration, just like images, fonts, etc., so I think it is non-code and don't think that the GPL is suitable.

There is no doubt that client-side JavaScript is code, but it is interpreted by the browser, while PHP-code is interpreted by the server - hence there is no combination of the two. I've checked out this understanding with the FSF, and they've no problem with it.

Had the JavaScript community decided to use the GPL, I would of course have wanted that our JavaScript is licensed under the GPL. However, the JavaScript community has choosen another path, and they use other licenses (MIT mostly, but also, BSD and CC BY-SA). We're not co-operating with the JavaScript free software community when we insist on changing the license on third party libraries before moving them upstream. While we can do this legally, we are making things more difficult for the upstream recipient than the original author of the software intended.

The "more modern" licensing would be GPL-3 which IMHO strikes the correct compromise between permissive licenses à la MIT

If we moved to GPLv3 (which we can do, as GPLv2+ allows us to re-license), we would dis-allow upstream recipients to use any PHP library licensed under GPLv2 with Drupal.

The beauty of GPLv2+ is that it gives the upstream recipent the option to use PHP libraries under GPLv2, GPLv3 or Apache 2.0 with Drupal. That is giving the recipent the widest range of options, while still making sure that any software distributed further upstream stay free software.

Regarding JS, though: we import and redistributue permissively-licensed content, but we also have Drupal-specific JS code, which is licensed under the GPL-2.0+ just like the PHP code.

After the license reform proposed by the LWG, all such JS can remain under GPLv2+ (and if an author wants to license his JS under GPLv2+ in the future, that is OK as well).

The gist of the reform is that non-code (images, text, fonts, icons, CSS, etc.) as well as Javascript code will keep their original license and attribution (if any) as long as that license allows free redistribution as part of a Drupal project or distribution and do not contain further restrictions on upstream use (so "Don't be evil" and similar restrictions will not be allowed). (There is however a logo exception that will allow us to have the Drupal wordmark in core without opening up for all sorts of trademark abuse).

The proposed now policy also says that all PHP code must be licensed as GPLv2+ (exactly as we do now).

And as I understand the "plugins" logic from the FSF, it means that any JS code invoked from ours (not through as webservice but locally) is contaminated by GPL too.

Can you elaborate on this. I've yet to find a place where the FSF says this, and lot of places (see below for examples) where they say something different.

First, the FSF clearly allows some components in a distribution to be under a more permissive license than GPL without becoming "contaminated by GPL" (your words). The reason they allow this is probably because overextending the GPL in some cases may be harmful. So they say that in some special cases such as "templates" ("themes" in Drupalspeak), it is recommended that you use a permissive licence for some of the components. From the GPL FAQ:

Templates are minor enough that it is not worth using copyleft to protect them. It is normally harmless to use copyleft on minor works, but templates are a special case, because they are combined with data provided by users of the application and the combination is distributed. So, we recommend that you license your templates under simple permissive terms.

They then go on to say that the JavaScript component should be under GPL (because it is non-trivial code), but they also understand that putting JavaScript under the GPL may create a problem, so they suggest repairing this by using a "an exception for JavaScript code" (i.e. an exception to be used when GPL JavaScript interacts with non-GPL components). This "exception" is IMHO a worse legal mess that the problem it has been engineered to solve. We do not this, and we have summarily reject it when it is requested.

There is no legal requirement to put JavaScript under GPL when it is distrubuted as part of a Drupal project, as it is just data. This is also recognised by the FSF in their GPL FAQ:

The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone.

So to cut a long story short. There is no legal requirement for us to re-license a JavaScript library with a permissive license in order to distribute it along with a Drupal project where the PHP code is under GPLv2+, and we avoid a lot of hairy legal problems if we just leave the original permissive license untouched.

I've sometimes heard the argument that because the JavaScript manipulates the DOM (and thus alters what is being produced by the PHP) the end result is a derivative work. However, the validity of that argument has already been tested in a US court of law, in Galoob v. Nintendo. In that case, a plugin to a Nintendo game altered the game content, and Nintendo claimed that this resulted in a derivative work which infringed their copyright. The final outcome was that the Nintendo lost, as use of plugin was similar to:

"skipping portions of a book" or fast-forwarding through a purchased movie; thus the altered game content did not constitute the creation of a derivative work

And as you are probably a aware, there exist developers that distributes so-called "freemium" modules consisting of PHP code for Drupal (which are under GPLv2+ as they are legally required to) with premium JavaScript (which are under some proprietary license). Neither the FSF nor the Drupal Association have ever claimed that this business model violates the GPL.

To conclude: There is no legal requirement on us to re-license a JavaScript library with a permissive license in order to distribute it along with Drupal, there is (IMHO) no reason to do it, and there a lot of good reasons not to do it.

Thanks to the link to the note from the FSF about the use of plugins.

Do you have a pointer to that proposed LWG change

It currently rests in a GitHub repo: http://drupal-lwg.github.io/ awaiting review by the Drupal Association.

I hope that it at some point also will posted here, and an that there is an official call for discussion by the community.

I major issue (IMHO) with our current policy is that we require all licensing information to be purged from the project repo. By removing the original MIT/BSD LICENSE.txt that third party JavaScript libraries typically come with, we also remove information about copyright and authorship that we by law (even the US recognizes moral rights in 2016) are forbidden from removing. This is not good.

fgm wrote (on GitHub):

The ToS lists the short license name as GPLv2+. However, most formalized uses of this licensing terms (notably in Composer files) rely on the SPDX code for this license which is GPL-2.0+ instead.

This works both as a (deprecated) specific license pre-SPDX 2.0, or as a license expression in SPDX 2.0 https://spdx.org/licenses/GPL-2.0+.html

We should probably use the standard SPDX form, or use both.

(I prefer to keep the discussion here on Drupal.org - rather than forking it to GitHub.)

The term "GPLv2 and later" and its abbreviation "GPLv2+" has nothing to do with the depreciated SPDX license you link to. This term (when it appears in our ToS and elsewhere) is a direct reference to a clause that is appears in section 9 of the regular GPLv2. Quote:

Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation.

So the license we use here is the regular GPL version 2.0, with an added option for downstream recipients to follow the terms of any later version of the GPL, as stipulated in section 9 of GPL version 2.0 (i.e. allowing the program to be legally combined with works licensed under GPLv3 and Apache 2.0).

The definitions given SPDX 2.0 specification is unfortunately not what we use at Drupal.org (and don't blame me, the decision about using the phrase "GPLv2 and later" was made before I became a community member).

As noted above, the phrase we use is "GPLv2 and later" (this use of "and" is consistent with the use of "and" in section 9 of GPL version 2.0).

The SPDX 2.0 specification says this about the word "and":

Conjunctive "AND" Operator
If required to simultaneously comply with two or more licenses, use the conjunctive binary "AND" operator to construct a new license expression , where both the left and right operands are a valid license expression values.

For example, when one is required to comply with both the LGPL-2.1 or MIT licenses, a valid expression would be: (LGPL-2.1 AND MIT)

Unforunately. this is is not what we mean when we say "GPLv2 and later". Our use of the conjunction "and" is based upon common sense and normal speech, while the SPDX 2.0 specification treat this common word as a binary or set theory logical operator. You may be right about this treatment making sense to "developers", but it also confuses ordinary people (like me).

Personally, I don't think it makes sense for us adopt SPDX 2.0 specification at this point in time. And if a decision is made to adopt the SPDX 2.0 specification, we first need to alter all docs including the ToS and licensing FAQ to use "or" instead of "and".

Unfortunately, the language used on Drupal.org, including important documents such as the ToS and licensing FAQ is in conflict with definitions given in the SPDX 2.0 specification. That means we're unable to officially recommend its use, or to refer to it anywhere.

If a developer decide to put the name string "GPL-2.0+" in their composer.json file, knowing that this a reference to SPDX 2.0 specification, fine! But it would (IMHO) be just be too confusing to start using a name string referring to the SPDX 2.0 specification in our official documentation, after our long history of using the word "and" in a manner that conflicts with this specification.

The Drupal project is adopting SPDX because it is what Composer use for licensing and we are using Composer, but must every licensing issue go meta and include a rehash of Drupal's "GPL everything" approach to licensing?

This issue started simply enough. Let's loop this back to the original requests and table the SPDX discussion for now.

the code license is not just about any version of the GPL, but 2.0 or later

Yes. We should be specific that the PHP is licensed as GPL and later.

the code license also applies to JS code we distribute, not just to PHP

No. We cannot relicense code after it is submitted unless we're going to get approval from a large number of people who have submitted javascript under the CC-SA license over the years. Since the approach to documentation has changed and is now managed by the DocWG, if someone wants to make a recommendation to change the DocWG approach to licensing let's do that in another issue.

To match the "and" terminology we currently use everywhere else on Drupal.org, the change to the license block would be...

"Drupal’s online documentation is © 2000-2016 by the individual contributors and can be used in accordance with the Creative Commons License, Attribution-ShareAlike 2.0. PHP code is distributed under the GNU General Public License, version 2.0 and later."

Unless anyone has an issue with that specific change, I'm going to move this back to the Drupal.org content queue so @dddave or someone over there can take action on it.

kreynen wrote:

Unless anyone has an issue with that specific change, I'm going to move this back to the Drupal.org content queue so @dddave or someone over there can take action on it.

I'm fine with that.

fgm wrote:

I think this needs to be synced with the people working on the d.o. tools, because AFAIK we are going to generate composer.json files for all repositories not containing one, and they are likely to include this license expression.

I'm fine with that as well.

I not in any way opposed to that particular expression being used in composer.json-files, I'm just wary of referring to the SPDX 2.0 specification in our ToS and FAQ without first making sure that our other documentation about licensing is consistent with it.

fgm wrote in #7:

but fonts have long definitely been programs. Since we do not distribute fonts AFAIK, this should not be an issue.

Themers regularly want to include 3rd party fonts in their repo, as do core developers. Fonts are most certainly an issue.

Part of the requests for including 3rd party fonts in the is motivated by competition from WordPress. WordPress has always allowed fonts under a "GPL friendly" license (i.e. SIL OFL) to be distributed along with PHP under GPLv2+. Drupal's extremely conservative license policy is probably hurting Drupal when we're being compared to other free software CMSes that only require the GPL for their PGP code.

IMHO, fonts are not code for people who simply want to use the binary font file to render text on a website. Font designers may work with code (I know nothing about font design), but Drupal is not a tool for font designers to design fonts. Our developer community uses fonts just as they would use icons, images and other decorative elements in mere aggregation to style the front-end of a website.