Drupal.org packaging script overwrite LICENSE.txt file

(1) We add the LICENSE.txt file for you in generated tarballs. The license of Git checkouts in implied by the Drupal Git Repository Usage Policy (it is unconditionally "GPL version 2 or later").

(2) The distribution of a single license file is perfectly acceptable. Embedding the license into every file is recommended but not mandated by the license itself. More generally, Drupal.org discourage explicit mentions of copyright in code files, as it could be interpreted as an implicit copyright assignment. The copyright is always automatic (even when not explicitly mentioned), and the actual authors can be easily found from the Git log.

(3) All the projects hosted on Drupal.org are distributed under the "GPL version 2 or later" license. There is no exception. You cannot host GPLv3 only code on Drupal.org.

Please see http://drupal.org/licensing/faq for more information about licensing on Drupal.org.

What Damien said. ;)

We only host code that is licensed under GPL v2 _and_ later. GPL v3 only doesn't do.

I don't feel we really fully addressed this:

The way of downloading (terminal or browser) is not critical.

Conclusion: A LICENSE.txt file in pojects (contributed modules, themes..) and in the git repository is required by the GNU License.

The cvs repository had LICENSE.txt at the root and that's how we covered it. Even http://drupalcode.org/ doesn't mention a license. I'm not going to re-open this because I'm not sure of a good way to solve it (other than adding a mention of the license on the homepage).

see #1664676: Add licensing info at http://drupalcode.org

Sorry? "and" or "or", what now(?), nothing of that. An FAQ is not legally decisive. The license file is crucial. Clear, GPLv2 is compatible to GPLv3, but that is not the point. Drupal is GPLv2 licensed. Drupal is not duallicensed.

Drupal and all the code hosted on Drupal.org is distributed under the "GPL version 2 or later" license. It means "GPLv2 or any later version at the choice of the recipient". For Drupal core it is clearly stated in the COPYRIGHT.txt file:

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.

Drupal.org does not distribute nor host any GPL version 3 only code. If your intend was to publish your projects under that license, please notify us so that we can remove the project from our repositories. For more detail, please see the Usage policy that you have agreed on when you opened your Git account.

There are two ways to read "GPL version 2 or later"

* It's at the discretion of the module contributor whether the code is v2 or v3 or both
* The license must be both, and the downloader chooses which one

It is without a doubt that the Drupal project as a whole has decided the second one is the intended meaning of that sentence. If there are places where the language or documentation is unclear that should be cleaned and that is an appropriate thing to fix. However, this issue, with the title it currently has, is "won't fix."

As mentioned back in #8, the license of Drupal is very clearly "GPL version 2, or (at your option) any later version". All the code hosted on Drupal.org has to be released under the same terms, as clearly specified in the Git access agreement.

If your intend was to publish your projects under that license, please notify us so that we can remove the project from our repositories.

Moving this to a queue that would be more appropriate for wrapping this up.

I think this is already answered in #8 above, but to reiterate:

The meaning of the phrase “GNU/GPL version 2 or later”, changed on 28-06-2012 to “GNU/GPL version 2 and later” that appears in the the Drupal Git Repository Usage policy is actually explained in the text of LICENSE.txt itself.

In § 9, it says:

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. [my emphasis]

And in the section “How to Apply These Terms to Your New Programs”, the following appears.

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. [my emphasis]

Further, this is explained in Q4 in the Licensing FAQ:

You can release your work under any GPL version 2 or later compatible license, however, 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. [my emphasis]

The two versions (distinguished by “or”/“and”) of the policy, and the often used abbreviation “GPLv2+”, are all semantically equivalent.

To respond to #13: This is not dual licensing - it is single licensing (GPLv2), with an option for the downstream recipient (downloader) to re-license the project to a later version of the GPL (currently, that means GPLv3), if he/she chooses to do so. This option will typically be exercised by a downstream recipient who wants to combine the project with some code that is available under GPLv3 only.

In other words:

• You cannot have a file that is under GPLv3 only in the repo, as this is incompatible with “GPLv2 or/and later”/“GPLv2+” - where the meaning of “or”, “and” and “+” are explained in LICENSE.txt.
• All the documentation about this on Drupal.org (i.e.: The Git Repo Policy and the Licensing FAQ) are consistent.
• There is no bug to fix in the packaging system.

I am going to leave this open for discussion for two weeks. If nobody objects to the above interpretation of the terms used in that period, I think we can wrap up, close this and say that this is the official interpretation. If there are significant objections, it needs to go back to "Needs work" and we probably have to go to the Drupal.org lawyers to get a qualified legal opinion about this.

After looking at #1880876: Delete project and @CZ's Seeking new maintainer/s forum post, I think we've already lost him/her as a potential contributor. While I agree with the gist of the "official interpretation", I think there is still more work to be done documenting this in a way the average human being can actually understand it.

Contributors who are well versed in GPL licensing are often looking to leverage all of the freedoms allowed them when contributing to a project licensed as GPLv2 or/and later. They don't understand the differences between what the GPL allows and what Drupal.org allows... or the motivation for our policies.

The combination of contributors who are passionate about protecting the rights afforded to them under the GPL and the Drupal community's own confusion about our licensing and git policies tends to result is some very unproductive threads. A similar discussion about the use of or/and later happened several years ago in #1901130: Clarify GPL V2 and later-compatible licenses: make a simple table, update terms, consistency-in-docs. These misunderstandings aren't limited to new contributors. None of the employees from Phase2, Acquia, Node One, Pantheon, or Lullabot got the licensing right when implementing the whitelist for packaging 3rd party assets on Drupal.org. We still have whitelist entries for libraries that only qualified under then "GPLv3 compatibility is OK" interpretation of "VPLv2 or later".

I recently gave a presentation about licensing to the Boulder Drupal User Group which included both new and long time contributors. This is how I've started explaining both the current licensing and the proposed changes...

Truly understanding Drupal's licensing requires an understanding of the difference between the licensing on what is committed to Drupal.org vs. what is downloaded from Drupal.org. Everything committed to Drupal.org's Git repo is currently licensed GPLv2 and later (GPLv2+). This means when you commit, the code and any other assets are licensed as GPLv2 with the option of using it under GPLv3 or any future version of the GPL license.

All packaged downloads from Drupal.org are distributed with only a copy of the GPLv2 license. Since the Drupal project started, the community has tried to keep "everything" in those downloads GPLv2 compatible. Everything includes both code and non-code assets. This was done to keep licensing simple. While GPLv3 variations of Drupal core, modules, and themes could be downloaded from other sites, users should have some level of confidence that what they download from Drupal.org is GPLv2 compatible.

Similarly, anyone working on a distribution that includes Apache2 or GPLv3 code should be able to safely assume that what they checkout from Drupal's git repo is compatible with both GPLv2 and GPLv3.

This is why we don't allow code that is either strictly GPLv2 or GPLv3 to be committed.

The Licensing Working Group and the Drupal Association are currently evaluating the benefits of allowing other "GPL friendly", open licenses for non-code assets that have become increasingly popular since the original licensing and git policies were written.

We are considering allowing assets that use licenses like Creative Commons Attribution-ShareAlike for creative works distributed as text, audio, video, etc or SIL Open Font License for fonts. While not strictly GPLv2 compatible, these licenses ensure similar freedoms to the GPL and are more popular and appropriate for the type of asset being licensed.

While this would add some additional complexity to Drupal.org's licensing and git policies, it will not change the licensing of code that is committed to or downloaded from Drupal.org. That will still be GPLv2+ when it is committed and GPLv2 when it was downloaded.

The feedback on that explanation was very positive. Most of the new contributors said that it made sense, but the more important feedback was from long time contributors who admitted they didn't actually understand Drupal's licensing until it was spelled out this way.

Drupal.org's git and licensing policies are very different than other GPLv2+ projects. We need to acknowledge that and put some effort into explaining why we have policies that are more restrictive that what GPLv2+ licensing allows. While WordPress.org's Licensing references Drupal.org's documentation about all modules and themes being derivatives of core, you don't have to spend more than a few minutes looking through the code in https://wordpress.org/plugins/ to find what Drupal.org would consider a licensing violation. WordPress developers are free to mix GPLv2 only, Apache 2, GPLv2, and/or AGPLv3 license with no oversight or repercussions.

I'm not pushing for Drupal.org to follow WordPress.org's move towards allowing any code that is compatible with either GPLv2 or GPLv3, but I think there is work to be done. We need to do a better job of explaining our git and licensing policies as well as the motivations behind them.

I also don't think we've adequately addressed the lack of a LICENSE.txt in git repositories before packaging. Github was the target of a lot of criticism about the lack of license files in their repos before launching ChooseALicense.com.

While it is unlikely this is a true legal issue, the lack of a License.txt is the repo is confusing. When someone requests a Druapl.org packing whitelist entry for a project from GitHub that only includes text about which license they are use in the Readme.md, we will ask them to ask the person making the request to open an issue on GitHub asking the maintainer to include a proper License.txt file. This is in part because it is the FSF recommends, but also because when the project is cloned during packaging, the original license and copyright should remain with the project.

By not including a License.txt in each repo, Drupal.org's the proper licensing information is only downloaded. Nothing is included when using git clone or submodules. With an increasing number of project cloning between GitHub or BitBucket and Drupal.org, this is becoming a bigger problem as the projects either lack licensing in the other repos or include a License.txt is included and overwritten by Drupal.org's packaging. We should be including a License.txt in the repo and we should stop be telling contributors not to include it.

Could a) a LICENSE.txt file be automatically pushed into all repos, b some git hooks be added to block changes to these files?

The current situation is that we allow third party materials in repos. If the 3rd party materials are available under a permissive license that allows re-licensing to GPLv2+, in most cases, no action has been taken.

The best-know project that does this is jQuery Update, which contains a lot of verbatim copies of 3rd party libraries licensed under MIT and BSD licenses.

These licenses are permissive and compatible with GPLv2+. This means that when they are combined with Drupal in a "larger work" (i.e. a functional Drupal web site), they are at that point technically re-licensed as GPLv2+.

However, these permissive licenses are not completely without terms and conditions.

For instance the MIT license, it says that use and distribution of the library is subject to the following condition:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. (my emphasis)

The FreeBSD license says:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. (my emphasis)

The intent in both licenses is clearly that either a copy of the actual file LICENSE.txt in the original repo of the 3rd party material shall accompany any distribution of the software, or that substantial portions of the text from license is reproduced in the distribution.

Currently, we are breaking the terms of those licenses by requiring maintainers to remove any licensing files, such as LICENSE.txt, from repos that are hosted om Drupal.org.

This policy has also to be considered if we're going to continue to allow 3rd party materials sto be hosted on Drupal.org.