Community & Support

Why drupal.org doesn't host GPL-"compatible" code

Last updated March 11, 2011.

See also the Policy on 3rd Party Libraries

While technically the GPL permits inclusion of code with GPL-"compatible" licenses in a GPL package as explained here, the Drupal policy is not to mix licenses. Drupal founder Dries explains this policy as follows:

Drupal.org's package management system automatically adds the GPL license to all packages. If we allow other licenses in Git, it is going to get messy, and sooner or later we're going to run into licensing issues. Already, we get quite a few questions about Drupal's license. If we are going to add more licenses to the mix, it is going to be harder to audit, or provide answers to such questions. So, not allowing other licenses in Git is a deliberate choice.

We've also decided against mirroring other projects in our Git repositories--unless there are good reasons to do so. So when people need a non-GPL library, it is best to instruct them to download that library from that project's website.

So, in short:

  1. Only GPL'd code/images/files
  2. But no GPL code/images/files that are available from 3rd party sites as long as the proper version to use with your module is easily accessible. Easily accessible means that the release that works can be downloaded in a compressed file of some sort. If your users have to use svn/cvs/git to get the files then that is not considered easily accessible.
Login or register to post comments

Comments

Something that may clarify this point

Posted by hotspoons on September 11, 2009 at 6:01am

I had a question regarding this tonight, and this short discussion may clarify some more complicated points not addressed by this post, so long as my logic and theory is correct. My points below also include subject matter brought up here.

So, in short (perhaps both book entries should be updated with this list?):

  • Only GPL'd code/images/files, except in cases where:
    • Modification to be compatible with Drupal was not accepted by the original author
    • The original GPL-compatible library is abandoned (perhaps a definition of this is necessary as some projects can go years without updates then suddenly come back to life)
    • A module depending on a GPL-compatible library with poor hosting/low availability
    • A resource available in a publicly-consumable format via http/ftp (zip, tar.gz, bz2, etc.), not an 'exotic' protocol like SVN, CVS, GIT, HG, etc.
  • Ways to include, link to, or execute libraries or programs (libraries from here on out) not explicitly accessible under a GPLv2 license are:
    • Write or modify a GPLv2 connector API connector to/from the library in question, so long as the library in question is GPLv2 compatible (it does not to be licensed as such); this can be included with your Drupal module
    • If this is not possible (i.e. the library in question is proprietary or explicitly does not allow GPLv2 linking), write an API connector to an external library, hosted off of Drupal.org, which is licensed in a way both compatible with the restrictive library, and compatible with beingl linked from GPLv2 (i.e. LGPLv2 or Apache license)

It may not be a bad idea in

Posted by hotspoons on September 11, 2009 at 6:18am

It may not be a bad idea in the future for drupal.org to maintain or link to a central repository for assets needed by freely distributable 3rd party modules which are not licensed under the GPLv2. This would sure save some time updating the WYSIWYG libraries. Perhaps similar to what many Linux distributions do with free vs. pseudo-free & non-free software (anyone ever enable the multiverse an universe repositories on an Ubuntu install?)

nobody click here