After discussion on the licensing issues of JavaScript minification/aggregation (see related discussion for core at #156124: JS and CSS aggregation deletes license information and the "Speedy" project at #1536810: Adhere to licensing issues when minifying files ) we came across what is a more fundamental issue that is distinct from the minification/aggregation discussions:

  • The GPL requires that when GPL licensed code is distributed a license declaration is included.
  • Every time JavaScript code is downloaded by a web browser, this counts as a distribution.
  • Hence, we should include a license declaration with all GPL code that we include with Drupal.

Some further points to clear up the inevitable questions:

  • Drupal.org when distributing Drupal core itself (and contrib projects) includes LICENCE.txt with each download, so is itself in compliance.
  • This is about a particular Drupal site distributing GPL JavaScript code to visitors who currently have no way to discern the license of the code they are running.
  • While site builders could in theory add license declarations themselves, it seems that fixing this in Drupal itself supports the success of the Drupal project in particular, and the principles of free and open source software in general.
  • This applies to both minified and non-minified (source) code files (in the same way that licenses need to be distributed with both compiled and source for GPL projects).
  • The FSF has put together some recommendations for identifying substantive JavaScript that needs a license declaration, verses "trivial" JavaScript which does not - these are described in http://www.gnu.org/philosophy/javascript-trap.html and in some more detail at http://www.gnu.org/software/librejs/manual/html_node/JavaScript-Detectio...
  • There is a more complex question of how to deal with vendor libraries (jQuery etc) and also potential broader drupal.org contributor policy around this - please discuss this in the META issue (#1649670: [META] Improving Drupal sites JavaScript Licence Compliance).
  • There is also the issue of improving the clarity and detectability of licenses in aggregated files - this is an area where there is not yet a clear best practice, but it's probably easier to work on determining these - in the META issue (#1649670: [META] Improving Drupal sites JavaScript Licence Compliance)..
  • There is also a broader issue about providing better tools/modules and best practices for site builders to audit and present licenses for their specific site JavaScript using license declarations or JavaScript License Web Labels. This issue does not seem to directly affect core or drupal.org contributor policy however, but is more an issue for the wider site building community - again, see the META issue to flesh out ideas here (#1649670: [META] Improving Drupal sites JavaScript Licence Compliance).

The attached patch adds an example declaration for drupal.js, but we would need to add this for all non-trivial GPL JavaScript files in Drupal core. The patch includes a few supporting semantics:

  • It uses @licstart and @licend tags which allow easier license detection by LibreJS (a browser plugin to allow users to opt-out of running non-free code) as well as potentially other systems/spiders.
  • It is also protected from being removed by the most common minification systems by being the first comment in the file (UglifyJS), having an "important" comment mark "/*!" (YUI) and including the @license tag (Closure Compiler).
  • It includes a @source tag that instructs a user where to find the original source for this file, should they receive a minified version (for now it just points at drupal.org - if we prefer we could link to the specific file on drupalcode.org).
Files: 
CommentFileSizeAuthor
drupal-js-gpl.patch1.38 KBOwen Barton

Comments

nod_’s picture

This is going to be tricky to solve properly. Any way we can make this a meta and open up follow-up issues for the (numerous) parts of this issue?

Owen Barton’s picture

Good idea - I have added a separate meta issue for the broader conversation: #1649670: [META] Improving Drupal sites JavaScript Licence Compliance

This issue can be considered a sub-issue of that, focused just on adding GPL license declarations for non-vendor, non-trivial JavaScript.

Wim Leers’s picture

mfb’s picture

See also https://drupal.org/project/librejs - a contrib module which allows Drupal sites to be compliant with the LibreJS browser plugin

mfb’s picture

Issue summary: View changes

Adding links to META issue

Wim Leers’s picture

Please see #2258313: Implement JS Web License Labels to allow for JS minification, it adds license metadata to asset libraries and exposes that information according to the JavaScript Web License Labels standard.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.