Problem/Motivation

Currently everything committed to Drupal.org's git repository is licensed GPLv2 and later (GPLv2+). Adding the option for installation profiles/distributions to be packaged with third party code on Drupal.org was a huge improvement, but has resulted in requests to include code with licenses that are not compatible with GPLv2+. Currently, everything (the installation profile, modules, themes, third party libraries and all) included in the downloadable package of a distribution must be compatible with GPLv2+.

By limiting distributions to GPLv2+ on Drupal.org, we limit the libraries distributions can include. Because the GPLv2+ license allows anyone to distribution Drupal along w/ contrib modules and themes as GPLv3, distributions that want to use these additional libraries are doing so on Github.

Proposed resolution

Give distribution maintainers the option of selecting a GPLv3+ (GPLv3 and later) license for the packaged download available on Drupal.org.

Potential Problems

According to the FSF, there are more licenses are compatible with GPLv3 than the GPLv2. However, since GPLv2+ is downstream-compatible with GPLv3, distributions packaged as GPLv3+ will offer downstream recipients less freedom than distributions packaged as GPLv2+.

Since GPLv2 and GPLv3 are not compatible, distributions licensed as GPLv3+ couldn't incorporate any GPLv2 ONLY or GPLv3 ONLY code (i.e. code that is licensed without the "and/or later" clause). Also, downstream recipients would not be allowed to combine what they receive in a distribution under GPLv3+ with such code.

It should also be noted that it is very hard to find free software that is licensed under GPLv3 and later (GPLv3+). For instance, the libraries that is mentioned below under "Example Whitelist Requests from Distributions Currently Rejected" are licensed under GPLv3 or Apache 2.0 ONLY.

Workarounds

  1. Use Composer to declare the dependencies of a Drupal distribution.
  2. Reach out to the maintainer of the free software that available under GPLv3 or Apache 2.0 and request that they dual license it under GPLv2+. Many maintainers of free software care about the freedom of their users and will accommodate such a request.

Example Whitelist Requests from Distributions Currently Rejected:

Distributions Considering Moving to Github:

  • Currently none.

Distributions That Have Already Moved to Github:

Miscellaneous

We currently do all issue and code management on Github and push commits to Drupal.org with Jenkins.

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

greggles’s picture

I'm opposed to the proposal as stated. If the only motivation is to get compatibility with more *stuff* that doesn't feel like a good reason to limit the license options of our users. If GPLv3 has some benefits that we want to promote I could see switching. I'm not aware of those. This also goes against http://drupal.org/licensing/faq#q12 which was vetted by the DA and its lawyer and our community a while ago.

Crell’s picture

As the person who wrote that paragraph... :-)

There is at this time no movement to convert Drupal (and by extension anything hosted on drupal.org) to GPLv3+ instead of GPLv2+. However, there is no legal reason that we could not do so. I actually think we should do so eventually, but that's not a priority for me to push right now. :-) (Legally it would just require the DA to make a decision to do so, since the DA is legally responsible for Drupal.org, but presumably they wouldn't do so without community buy-in.)

The statement in the FAQ was not a legal commitment to not move to GPLv3, merely to state that "no we're not moving RIGHT NOW, but that option is open later." That is still the case.

redndahead’s picture

So what we are limiting is the ability for our users, or people they distribute the software to, to license the installation profiles as gpl v2 only and this is not from d.o. but if they repackage and distribute it from somewhere else. I think in theory this is limiting, but in practice it doesn't really happen, or rarely happens. Can anyone name an installation profile taken from here and distributed somewhere else as gpl v2 only code?

This issue isn't interested in drupal core or contrib just installation profiles. Although I would probably like to see us move to gpl v3 or later on that too for simplicity.

redndahead’s picture

@crell so just to make sure you feel that any changes in licensing be it core or contrib is up to the DA to decide?

So it seems that's the place to start.

Gerhard Killesreiter’s picture

Status: Active » Postponed

I don't think we should muddle with licensing right now.

redndahead’s picture

@gerhard when is a good time? I'm not taking lightly what work may have to be done to accomplish this change, but if not now then when is it good?

redndahead’s picture

I posted a request to the DA group on g.d.o it would be great to debate the pros and cons there.
http://groups.drupal.org/node/211698

Crell’s picture

redndahead: From a legal/logistical standpoint, switching code distributed from Drupal.org to GPLv3+ is something the DA has the legal authority to do. From a practical/cultural standpoint, the DA could not/would not do so without community buy-in.

redndahead’s picture

@crell Thanks for your help.

I would fully expect/hope the DA wouldn't make a decision like this without community buy-in. I hope at least people will debate it without just saying it's too hard.

geerlingguy’s picture

Subscribing, and stating that I wouldn't be opposed to moving to GPLv3... but I'm sure there will be some who are. I would definitely hope that a decision would only be made after a post about it on the Planet feed, the front page, and to the mailing lists. I agree with redndahead, though, that any time is a good time to discuss this; just not right before DrupalCon :D

Tracking this issue from a couple packing whitelist issues (which can't really be resolved until a decision is made about GPLv3):

redndahead’s picture

@geerlingguy if you could comment on http://groups.drupal.org/node/211698 that would really help.

corbacho’s picture

Status: Postponed » Active

It looks like the Apache2 license is becoming popular. There are lots of nice code out there.

Is this postponed until ... ? When is the right moment #5 Gerhard?

hswong3i’s picture

From http://www.gnu.org/licenses/quick-guide-gplv3.html and the graph with clear license compatibility flow as below:

A chart illustrating compatibility relationships between different free software licenses.  For details, see the FSF's license list page.

It show that GPLv2 project can incorporate with GPLv3 project smoothly, which according to this I would like to give an assumption:

  • If Drupal core now license as GPLv3, we don't need to enforce ALL contribution module/theme project to upgrade as GPLv3; they can stay as GPLv2, and we can still include them without any question
  • For someday later (e.g. similar as case of The Great GIT Migration of Drupal.org on 2011-02-25) we may request else contribute module/theme maintainer to upgrade their license as GPLv3 (if, this do required)
  • In between, even we re-distribute Drupal "Installation profile/distribution" into GPLv3 from entire downloadable package point of view, we can include both GPLv2+ Drupal core + GPLv2+ module/theme + Apache 2.0 libraries without legal problem
  • BTW, according to above interpretation, at least "Drupal's Git repositories" need to upgrade acceptable license as GPLv3+ or else will violate http://drupal.org/licensing/faq#q4 because we use it to hosts those downloadable packages; again, this should not affect any current project at Drupal.org, including Drupal core and contribution module/theme which are currently licensed as GPLv2+ (anyway, I don't really understand why "Drupal's Git repositories" as a community platform must "under the same license as Drupal itself")

IMHO I love Drupal's GPL-only theory so much which keep entire community in energetic and fast growing; but needs for able to include some popular libraries into Drupal as a win-win solution may also not being ignored (e.g. Twitter Bootstrap as most popular Github project on today):
Popular Forked Repositories
(see https://github.com/popular/forked)
Popular Starred Repositories
(see https://github.com/popular/starred)

For sure, I am not a FOSS license nor legal expert, so please kindly correct me if any above assumption goes wrong ;-)

btopro’s picture

want to see this if it opens up more on white list

jlyon’s picture

+1 for this. I'm interested in getting #1996750: Add CKEditor official plugins to the whitelist through, and this would help.

Damien Tournoud’s picture

We don't relicense third-party dependencies, nor should we. I'm unsure what's the problem here?

btopro’s picture

I believe it has to do with repackaging and distributing everything together. Because we would then be hosting copies of non GPLv2 code which Drupal core and drupal.org adheres to. If the policy changed to say that install profiles were gplv3, then it would be implying the ability to host and have distributed with it all the other code of various licenses. I don't believe that the other projects put on d.o. are an issue to the other projects, it's a d.o. policy issue in that "drupal" proper is v2 so these derivatives need to also be unless there's a policy change.

I agree though... not sure why all this is a problem :) Especially since D8 will have ckeditor 4.x at its core which has all kind of odd licensing (particularly in its contrib / plugin community that gets very very mixed).

redndahead’s picture

When you distribute a piece of software it has to have certain license(s). In our case we distribute our distributions as GPLv2+. All the licenses for the libraries included with the distribution have to be compatible with GPLv2+. So libraries that are licensed Apache v2 are not compatible with GPLv2+ thus they can't be included in the distributions. We don't have to relicense the libraries, but we have to be compatible. There are a lot more complexities to this than what I'm saying, for example what constitutes a part of the program and what is considered an outside library, but these things have been debated in many circles and they have come to the same conclusions that the package needs to be licensed with a compatible license.

So I'd be happy to answer any specific questions you have, but for us to add these libraries to the whitelist we need to license distributions as GPLv3+.

kreynen’s picture

Packaging only GPLv2 code with a project isn't a GPL requirement. This is a Drupal island issue. The problem is that somewhere along the line a decision was made that everything committed to the Drupal.org cvs/git repo and downloaded from Drupal.org needed to be GPLv2 compatible. While Drupal itself is licensed as GPLv2 or later, the "or later" clause doesn't apply to code hosted on Drupal.org so this rules out several licenses.

https://drupal.org/node/1475972#whitelist-licenses

While the graphics and links on http://ckeditor.com/about/license indicate that CKEditor itself is dual licensed as LGPLv3, GPLv3 and MPL2, if you dig into the code you find https://github.com/ckeditor/ckeditor-releases/blob/stable/standard/LICEN...... but I agree. This is incredibly confusing.

I've always felt like the question about dual licensing vs. relicensing was definitively decided when Drupal continued to include JQuery after they dropped their dual license on the advice of the FSF about the what the lax licensing of MIT-only allows.

https://groups.drupal.org/node/245858

The idea that all code committed to a repository or packaged for download from a domain must have the same license is really out of step with the way things work outside of the Drupal, but if the requirement is to keep the code in a distribution compatible with the license of the distribution... code with a license like Apache 2 can't be included w/ a distribution unless the distribution is licensed as GPLv3.

Much like the original request from the Drupal community for the JQuery team to dual license that project as MIT and GPLv2, several people have tried to get other projects to change their license to make it GPLv2 compatible. The award for the most persistence goes @cweagans who spent > 2 years to get the Twitter Bootstrap project to relicense as MIT... and it looks like finally SUCCEEDED!!

https://drupal.org/node/1445226#comment-6858290
https://github.com/twbs/bootstrap/issues/2054
https://github.com/twbs/bootstrap/pull/9994#issuecomment-25754638
https://github.com/twbs/bootstrap/pull/11105

Others haven't been as lucky/persistent, but going around the internet trying to keep libraries GPLv2 compatible seems like a real waste to effort when the feedback about changing the licensing for distributions seems to be that it's something that can legally happen and will eventually happen, but just not right now.

killes@www.drop.org’s picture

"The problem is that somewhere along the line a decision was made that everything committed to the Drupal.org cvs/git repo and downloaded from Drupal.org needed to be GPLv2 compatible. "

The reason for this was that we didn't want to get bothered by legal battles.

If there is a way to make sure that packaged code complies with the GPL without actually being GPL, we could consider changing this policy.

It is probably quite difficult to properly evaluate this considering that the Drupal community is distributed across quite a few jurisdictions.

kreynen’s picture

@killes please stop using GPL as if it means one thing. I don't think anyone is suggestion we try to determine if code/project meets the spirit of the GPL. We recently updated the whitelisting documentation so it's now clear that only licenses the FSF determined are GPLv2 compatible are allowed. I think the next steps would be to...

  1. add logic to the license taxonomy for the whitelist nodes so that a distribution that is licensed as GPLv2 or later would be restricted to licenses that are GPLv2 compatible (what's currently being approved)
  2. start adding whitelist entries for licenses that would allow be allowed if the distribution was using GPLv3
  3. add the ability for distribution maintainers to license their distribution as GPLv3 and indicated that prominently in the UI
  4. Allow distributions that are licensed as GPLv3 to use whitelist entries for these additional libraries

These are not trivial tasks, but I think there is enough interest that it's possible this could be accomplished after the Drupal.org D7 upgrade.

btopro’s picture

I like the branding something as GPLv3 on a distro by distro basis. I've seen several distros start packaging on github / other repo hosting services because of the inability to natively include some libraries on d.o.

Also are there any contacts at the FSF that could help point to other projects using a mix of licenses successfully? I realize there's more to it then "free licensing" but from afar if something free isn't allowed to be packaged in something else free because of the legalese of free it's kind of silly (and leads to thing like http://www.wtfpl.net/ ).

hswong3i’s picture

Another good supporting why GPLv3 for distribution (ok, even for Drupal core, too) is a good idea: https://github.com/FortAwesome/Font-Awesome/issues/1124#issuecomment-287...

After a basic studying it show that most FOSS fonts are now licensed under OFL (and optionally + GPLv3) which means that due to our current GPLv2 ONLY policy, we can never include them into core nor modules/themes nor distribution which hosted on drupal.org ;-S

kreynen’s picture

Title: Explicitly license all installation profiles as gpl v3 or later. » Give installation profiles GPLv3 license as option
Priority: Normal » Major
Issue summary: View changes

Allowing distributions to be licensed as GPLv3 wouldn't solve the font issue. I've opened #2139273: Allow GPL Friendly Font Licenses to discuss the changes required to support that. I'd like to see OFL 1.1 allowed, but let's not muddy an already confusing issue.

I'm bumping this up to major and changing the title to make it an option vs. required. Since the D7 upgrade forced a lot of reworking of the Project module and packaging scripts specific to distributions, I think now is the time to take this up again. I've made this the parent issue for the whitelist requests that would be approved if this change is made so everyone can see that this is a real issue impacting real distributions.

Let's keep this discussion specific. We're not talking about changing the licensing for the Drupal core project or even contrib modules and themes, but simply taking advantage of the "or later" clause of the current GPLv2 license the same way a distribution can on Github. By allowing distribution maintainers to choose a GPLv2 or GPLv3 license and clearly showing the license of the distribution and all packaged resources, we're not only getting caught up with the rest of the open source community, we'd actually be jumping a bit ahead providing a much better overview of the licenses included in a distribution than other repo options provide.

We'd no longer be able to guarantee that everything downloaded from Drupal.org was GPLv2, but we would be able to clearly communicate what the licensing of a download was.

btopro’s picture

We'd no longer be able to guarantee that everything downloaded from Drupal.org was GPLv2, but we would be able to clearly communicate what the licensing of a download was.

Everything NOT A PACKAGED DISTRO would still be GPLv2 though honestly allowing people to say any module / theme / distro was GPL v2 or v3 would be a big win. The distros could theoretically include non GPL v2/3 code because of compatibility but given the size of the community I don't really think it's policeable given the size of d.o. and the complexity of the legal issue.

Especially given D8's "get off the island" mindset, it would be greatly beneficial to get off this mindset instead of forcing projects like bootstrap to change how they license to be compatible with us.

geerlingguy’s picture

Agreed. Let's do it! Are there any major objections to allowing profile maintainers to choose between 2/3?

redndahead’s picture

Choosing between the two would make things a little more difficult. One of the key reasons why it's gpl v2+ is it's easy to remember and thus easy to manage. I think if there is a change then all distros should be gpl v3+ and contrib is gpl v2+.

kreynen’s picture

and thus easy to manage

Easy for who? The people actually managing the whitelist are all in favor of this change because explaining the licensing is already hard. I don't want to speak for the people who have spent years trying to convince other projects to change their licensing, but I'm guessing they would describe that process as hard as well.

I believe @redndahead has already read http://www.gnu.org/licenses/rms-why-gplv3.html since it's been referenced in other threads related to this topic. Anyone who hasn't should read that before wading into the GPLv2 vs. GPLv3 debate.

IMHO, the arguments Stallman makes for why projects should move to GPLv3 can be reversed for why a project might want to stick with GPLv2. If you want to build a distribution that allows "tivoization" and patents, then GPLv2 is the way to go. Another use case for sticking with GPLv2 might be a distribution like Spark where the primary purpose of the distribution is to encourage development that is going to be committed back to projects licensed as GPLv2.

Anyone who followed #2132659: [META] Problems with Project Release Packaging was exposed to several parts of the packaging process that would need to be updated to support multiple licenses in distributions. The changes aren't trivial, but I believe the structure already exists to support both licenses. Because there are legitimate reasons for a distribution to use either license, I think a proposal that requires changing the license for all existing distributions will meet a lot of resistance. Whether that resistance is based on legitimate concerns or misunderstandings about the licenses, it will take a lot of effort to overcome. @redndahead, haven't you been involved in enough of these discussions to concede that point?

What I'm proposing is to leave GPLv2 as the default for new and existing distributions, document the things to consider before moving a distribution to GPLv3, and leave it up to the distribution's developers to decide which license to use. We aren't forcing anyone to change, we're only giving distributions that have to move to Github to use the libraries they need/want the an option to continue using Drupal.org to package their distribution.

acouch’s picture

I like the approach from #25. Just to throw in an anecdote I'm being asked to pull one of our distros off d.o. since it has to get packaged anyway and placed on some place like github if someone wants to use it. It is hard for me to argue it against that if this doesn't get changed.

hswong3i’s picture

FileSize
26.32 KB

@kreynen: I can't agree for this more:

I don't want to speak for the people who have spent years trying to convince other projects to change their licensing, but I'm guessing they would describe that process as hard as well.

People who saying that "we can convince other projects to change their licensing" should give a look about the corresponding history and discussion on bootstrap migrate to MIT or not due to Drupal GPLv2 only policy (well, which started 2 years ago and still not yet completely solved, yet): https://github.com/twbs/bootstrap/issues/2054

I would also like to recommend people who think that "GPLv2 can encourage people to contribute, where also keep entire community in energetic; and this how's Drupal works for number of years!!" to read this post: Study: Most projects on GitHub not open source licensed (Kids these days, they just don't care)

Equally interesting, Williamson found that developers with projects on GitHub tend to shun so-called copyleft licenses such as the Gnu General Public License (GPL) – which require modified versions of the software to be released under the same license as the original – in favor of more permissive alternatives.

What I'm proposing is to leave GPLv2 as the default for new and existing distributions, document the things to consider before moving a distribution to GPLv3, and leave it up to the distribution's developers to decide which license to use.

Based on above idea personally I would also like to recommend both module/theme/distribution can choose rather GPLv2+ or GPLv3 as their PRIMARY license, in addition if project owner hope to "dual licensing" their works with MIT or Apache or etc, we also allow them to do so as SECONDARY license (well, from Drupal taxonomy point of view, just add 1 required drop down select for GPLv2+ and GPLv3, and another multiple select for else supported and recommended FOSS license). This come with multiple benefit:

  • Can keep our tradition with GPLv2+
  • No need to ask everyone to change their license once together (see even bootstrap a single project also need more than 2 years for re-license and we all understand that is not possible)
  • New/existing project can change their license whenever they feel suitable
  • At least for distribution, we can license it with GPLv3 so able to include else project without critical issue
redndahead’s picture

Easy to manage in that when someone asks for what license you can tell anyone that contrib is gplv2+. I'm willing to support anything that works towards the ability to make a project gpl v3+. I think the reasons are also well spoken.

I've been told it's up to the DA to decide to make the change and then it would be up to the infrastructure team to actually make the change. Since I've posted this to DA group on groups.drupal.org I have received no response from anyone from the DA so my guess is they don't pay attention to the drupal group. We would probably need to have someone within the DA to advocate for us.

I would probably start here: https://association.drupal.org/contact
I have run out of time to spend advocating for this so would someone like to take this up and contact the DA?

redndahead’s picture

Based on above idea personally I would also like to recommend both module/theme/distribution can choose rather GPLv2+ or GPLv3 as their PRIMARY license, in addition if project owner hope to "dual licensing" their works with MIT or Apache or etc, we also allow them to do so as SECONDARY license (well, from Drupal taxonomy point of view, just add 1 required drop down select for GPLv2+ and GPLv3, and another multiple select for else supported and recommended FOSS license).

I'll be honest this will not happen anytime in the far future. There is too much involved in this and I think it will muddy up the goal of this issue. I think it would be best if it was focused on getting the ability for a distribution to be able to choose between gpl v3 and gpl v2.

Also another reason why it won't go is because what if a contrib project is gpl v3 and someone uses it in a gpl v2 licensed distribution? It's just becomes another issue in the infrastructure teams queue. It's important to make this issue simple and very specific. That will give it the best chance of going through.

btopro’s picture

I regretfully agree w/ #32 for the most part as far as scope.

Also another reason why it won't go is because what if a contrib project is gpl v3 and someone uses it in a gpl v2 licensed distribution

I believe that could be resolved through the requirement of GPLv2 licensing. I think requiring that baseline, then allowing people to state it's dual licensed above that would be the most beneficial to the future without impacting the way things currently work. So baseline license taxonomy that requires GPLv2 and can't be changed. Ability to select an additional license for the work would resolve that in the theme and module layer without requiring the additional checks in infrastructure to ensure that all projects assembled into a distro are GPLv2 for example.

I'll try not to make assumptions but contrib licensing changing the way distro maintainers have to license stuff (going forward) would be a good problem to have in my mind. Right now we are including a mix of MIT, WTFPL, and GPLv2 in our distros.

I understand the idea of mentally being aware that all of contrib is GPLv2, I'm just curious as to whether that's a real issue or not since technically even if you license it now as GPLv2 there's a high likelihood that the entire package isn't. We also don't tell people now to my knowledge that they are downloading a mix-mash of GPLv2 and other licenses.

Could be confusing, though I think kreynen and I would argue it already is :)

redndahead’s picture

Another part of this is determining who is allowed to relicense the code. I've been told that the DA has the right to do it, but if we leave it up to the maintainers do they have the right to do it? I took over a project from someone else, but do I have the right to relicense the code that they wrote? We could add language that says the owner of the project will be able to relicense the code, but what if they go through the abandoned module process. That makes it no longer the original owners choice to hand over those rights.

I think the best thing is to blanket dual license the code as gpl v2+ and gpl v3+. Then make all contributions gpl v2+ and then it just gets relicensed by the DA. Then the gpl v3 patent issues are born by the DA and not the contributor.

kreynen’s picture

Another part of this is determining who is allowed to relicense the code.

This has already been addressed in https://drupal.org/licensing/faq#q1

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...

So the answer is anyone can distribute Drupal and any code from Drupal.org as GPLv3, but not on Drupal.org.

Dual licensing is not an answer for distributions. A distribution that includes Bootstrap should never be distributed as GPLv2. All other code on Drupal.org is essentially already dual licensed as GPLv2 and GPLv3 because of the "or later" clause.

greggles’s picture

I do not believe the DA has the right to relicense code at their discretion. I believe it would be a massive undertaking and they would be a likely coordinating point.

kreynen’s picture

The DA can't decide to relicense everything as MIT, but anyone can distribute Drupal along with anything committed to contrib as GPLv3.

I believe the DA would have to approve a change in the policy about what's committed to the Drupal git repo, but I'm intentionally trying to avoid asking for that because I believe that will take years to change.

Committing the .profile and .make and the packaged downloads that result are 2 different processes. The distributions downloads are not committed to git so it's possible to maintain the current policy about commits while allowing GPLv3 for the packaged downloads.

redndahead’s picture

@kreynen what you are missing is that they mean distribute on your own website not the drupal.org website. The d.o website is owned and managed by the DA and they have to determine the licenses distributed from their website.

@greggles I think if the d.o accepted contributions as GPL v2, but distributed as v2 and v3 then they wouldn't have to ask anyone. Since this doesn't change what peoples code were contributed under and their rights still apply. This would be no different than someone taking the code from d.o. and distributing it from their website as gpl v3

kreynen’s picture

Title: Give installation profiles GPLv3 license as option » Give installation profiles/distributions GPLv3+ license as option for packaged downloads

@redndahead I'm sorry, but I'm not missing it... I trying very hard to work within it. The current policy is clearly spelled out in https://drupal.org/licensing/faq#q4

I want to release my work under GPL version 3 or under GPL version 2-only. Can I do so and host it on Drupal.org?

No. 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...

The way I'm interpreting that is... yes, you can release your work as GPLv3+, but you cannot commit anything that you aren't willing to license as GPLv2+ to the git repo. When this was written the only way anything was packaged on Drupal.org was to commit it so there was no reason to differentiate between what was packaged for download from Drupal.org and what was committed. Now with the .make files and the whitelist, we pull code into Drupal.org from other sources and package it. The packages are not committed. I'm not asking that the .make, .profile, or anything else that's committed to git be licensed as anything other than GPLv2+ when they are committed. I'm trying to be very specific so this actually has a chance of happening and only ask that when packaging a distributions we add some way to give distribution developers the option to package that download with a GPLv3+ license so we can include resources w/ additional licenses. I've updated the title again to be even more specific about this.

2: Does the license cover just PHP, or everything?

We require that all files (PHP, JavaScript, images, Flash, etc.) hosted on Drupal.org be under the GPL. If it's in Git, then it is under the same license (GPL version 2 or later). That way there is no confusion about what license a given file is under.

- all files hosted on Drupal.org be under the GPL
- if it's in Git, then it is GPLv2+

Since GPLv3+ is still "GPL", the request still complies w/ the letter of policy as it is written. Now someone could make the case that I'm trying to find a loophole in language that doesn't specifically prohibit packaging distributions as GPLv3+ on Drupal.org. They'd be right, but I don't think I'm missing anything with regard to how we can keep the GPLv2+ policy for commits to git and still expand the licenses allowed in the whitelist for distributions to use in packaged downloads.

If the DA has a policy somewhere that states that all downloads from Drupal.org will be GPLv2+, that would be a different issue. I'm not aware of any policy like that. I realize the DA would still need to approve the changes to the packaging process, but that shouldn't require as much discussion as changing the policy about the licensing of what's committed to git.

Again, I'm not asking for legal rights distribution developers don't already have under the current GPLv2+ license. I'm just trying to keep Drupal.org as the best place to manage distributions.

redndahead’s picture

It may not explicitly say that, but I can tell you they currently do not allow anything to be distributed on d.o. using GPL v3. I have talked to other people in the da and I have talked to Dries and this is the understanding from everyone.

holly.ross.drupal’s picture

Hi all - webchick pointed out this discussion for me and I wanted to chime in a bit. Coincidentally, we are working with our fun lawyers to unravel the trademark issues around BlueCheese and get a public repo available. That is probably all the lawyer bandwidth I am going to have for the next bit of time. However, I would love to address this topic early next year if that sounds ok. My understanding is that a lack of resolution is not going to make things too difficult for folks yet. Is that true?

redndahead’s picture

I've been trying to work out this change for 2 years, a few more months won't hurt me.

As a response to my proposal to dual license I was chatting with someone today and figured out this won't work. A distribution that has an apache library won't be able to be dual licensed. That means I feel the only real viable option is to distribute distributions as GPL v3+.

My proposal:
Contributions - GPL v2+
Module downloads and git repository - GPL v2+
Distribution downloads and git repository - GPL v3+

@holly.ross.drupal when you have the time here are a few questions for the lawyers.

  1. By just saying on the d.o. website that contributions are GPL v2+ does that make it true? Is there something that the contributors need to do to opt-in? My guess is since we don't currently require people to opt-in it's not needed.
  2. If contributions are gpl v2+ is the DA able to change the license of the downloads to a different license that is gpl v2+ compatible? or do the downloads have to be gpl v2+? what about the git repository?
  3. If the DA can change the license to GPL v3 does that mean the patent clause only applies to the DA or does it apply to the contributor also?

Thank you for looking into this.

webchick’s picture

Sorry, but that proposal sounds incredibly confusing to me, from a site owner perspective.

It means that I need to understand the archaeology of how my site was constructed in order to know the license of my website's code. Did it originate from a distro? Then it's GPLv3. Was it cobbled together from drush dl modulename? GPLv2. When I have an existing distro (GPLv3) and then download new modules (GPLv2) into it, what license is my website considered under now? And if someone else built my site, or I move into an organization that has a pre-existing Drupal site, how on earth do I figure out what license applies then?

webchick’s picture

Regarding your first question though, GPLv2+ is something all d.o users with Git access need to agree to in order to obtain permissions to commit code to Drupal.org. You can find it under the "Git access agreement" fieldset on https://drupal.org/user/XXX/edit/git. The text reads:

 To use Drupal's version control systems you, as an individual, must agree to the following

    I agree to the Drupal Code Repository Terms of Service.
    I have read and will adhere to the Drupal Code of Conduct.
    I will cooperate with the Drupal Security Team as needed.
    I will only commit GPL V2+-licensed code and resources to Drupal code repositories.
    I will only commit code and resources that I own or am permitted to distribute.

So no, just saying something on the d.o website doesn't make it so, but all committers had to opt-in to GPLv2+ in order to put their code on Drupal.org, at least since the Git migration (Feb 2011), which does. Code that hasn't been touched pre-Feb 2011 got grandfathered in to GPLv2+.

redndahead’s picture

#43 I agree. I would rather have modules and distros gpl v3, but I have been down that road and have been fought against almost every time I bring it up. This was my compromise. If you feel that we can get modules and distributions gpl v3+ then that's by far better and what I had originally suggested.

#44 That answers that question then. #2 and #3 are the only questions I still have.

Crell’s picture

As the author of the Licensing FAQ and former DA Legal Affairs Director:

- Currently, you're only allowed to contribute code under GPLv2+.
- GPLv2+ includes permission to relicense under GPLv3 (or v4 if such a thing ever happens).
- The DA owns Drupal.org, and thus is distributing code copyrighted by various contributors. It does so under GPLv2+, which is the license it received.
- Thus legally, the DA could decide to start distributing code under GPLv3 and only accepting contributions under GPLv3 without written approval from anyone. They already have it, from every contributor.
- Anything else besides GPLv3 (or AGPLv3, I think) would require approval from all contributors, which I can't see happening. But GPLv3 would, legally, be quite simple.
- That means that making distribution packages GPLv3 would also be totally legal and not require additional approval from anyone.

Naturally the DA isn't going to be doing that without community buy-in and general consensus, I presume, but unanimity is not required.

As to whether that's a good idea or not, I offer no opinion at the time. But there's no legal barrier t doing so.

webchick’s picture

It would be nice to get a sense of what the gains of this would be if we ever hope to build said consensus. Other than Twitter Bootstrap (which has since been dual-licensed MIT and therefore is a non-issue now), what are the big external libraries that distributions are seriously considering moving off of Drupal.org in order to incorporate? If the issue summary could be updated with specific examples (ideally with links to discussions about it), that'd be helpful.

webchick’s picture

Also, if you're skimming this post, be very careful about taking the graph in #30 too seriously. If you click through to the article, you'll see that only reflects a small sample of some of the oldest projects in GitHub.

kreynen’s picture

Issue summary: View changes

Started adding specific examples to summary and reformatted summary.

btopro’s picture

Every distributions using CKEditor

to clarify -- 4.x version of CKEditor with it's plugin community since they are mixed licensing. If adding a plugin here's the list of possible licenses you can use:
MIT
BSD
GPL
LGPL
MPL

ONE OR MORE LICENSE TERMS THAT TOUCH THE COPY AND DISTRIBUTION OF YOUR PLUGIN. CKEDITOR ITSELF USES THE GPL, LGPL AND MPL LICENSES, SO, IF POSSIBLE, IT IS RECOMMENDED TO MATCH THIS TRIPLE-LICENSE CHOICE.

in the CKEditor example above I think the issue is the mix'ed licenses and potential for it including something we might not approve though I think that blanket meets the criteria of the info-graphic above from how I'm looking at it at least. I think the issue is that they recommend you match CKeditor licensing but it's not required on the form.

kreynen’s picture

@btopro you mentioned additional distributions #22. Can you add that info?

Bootstrap isn't switching to MIT until the 3.1 release, so that could still be issue for several months (6?). See https://github.com/twbs/bootstrap/issues/11487

Sorry, but that proposal sounds incredibly confusing to me, from a site owner perspective.

@webchick I'd argue that the distribution licensing situation is already incredibly confusing for site owners, they just don't know it.

  • Look at the licenses of CKEditor plugins https://drupal.org/comment/7737161#comment-7737161
  • How does a site owner know what license a distribution is using now? Pantheon loads distributions from Github. Are all those being distributed as GPLv2 or are they already taking advantage of the "or later" clause, packaging libraries D.O. doesn't allow (like a single CKEditor plugin), and are really a GPLv3+ distribution?

Making this change on Drupal.org gives us a chance to address the confusion by clearly labeling the distributions utilizing the "or later" clause as GPLv3+ and include a list of the licenses for the whitelisted packages the distribution is using.

I move into an organization that has a pre-existing Drupal site, how on earth do I figure out what license applies then?

The install profile/distribution is listed at the top of the admin/reports/status so that is no more of a secret than the version of Drupal the site is running. Unfortunately right now, simply knowing the name of the distribution isn't enough to know if what you are using was distributed as GPLv2+ or GPLv3+. If the distribution came from any site other than Drupal.org, the only way to know is to check the licensing on all the code.

Take https://www.acquia.com/products-services/acquia-drupal. It is labeled only as "Acquia Drupal is GPL licensed". It isn't available on Drupal.org, so the only want to really know is to manually check. In this case it is still GPLv2+, but hopefully you can see my point.

Shawn DeArmond’s picture

I have a question to which I've been unable to find a straight answer, and this conversation seems to be at least tangentially related:

What if I want to distribute my own Drupal modules or Features on, say, GitHub or BitBucket rather than on Drupal.org? What are the licenses available to use? Must it be GPL? Or can I use Apache, BSD, or another "compatible" license instead?

What about Drupal distros? That means it'll include Drupal core, and a number of contrib modules? Can I license the core/contrib part as GPL, and my own additions (Features, modules, themes) under a different license?

redndahead’s picture

An installation profile make file can be whatever you want. The code that results from the build will be gpl v2. It is pretty much accepted that the installation profile itself must be gpl v2 although I can see it being able to be a more liberal license. The key is you cannot restrict whomever downloads the software from being able to distribute it. So whatever the license is, after the software has been built they must be able to distribute it as gpl v2. So in the end I think a full installation profile would need to be gpl v2 or compatible license, for example mit, so they can distribute the software as gpl v2.

kreynen’s picture

@redndahead Unfortunately I think most of your response is wrong. IANAL, but I don't think you need to practice law to answer the first part of @Shawn DeArmond's question. https://drupal.org/licensing/faq#q7 is very clear...

If I write a module or theme, do I have to license it under the GPL?

Yes. Drupal modules and themes are a derivative work of Drupal. If you distribute them, you must do so under the terms of the GPL version 2 or later.

As @webchick already pointed out in #44, everyone w/ a git account on Drupal.org agrees to "only commit GPL V2+-licensed code and resources to Drupal code repositories". So on Drupal.org you are doubly committed by both derivative work and the git usage agreement for Drupal.org.

On Drupal.org, the only option for anything committed to git is GPLv2+.

On GitHub or BitBucket, you are only bound by the GPL which is why you can distribute your modules and theme as GPLv3 and include code w/ licenses like Apache 2.0. Beyond leveraging the "or later" clause of the GPLv2+ license, the parts of a distribution (modules, themes, install profiles, libraries, fonts, images, content, etc) that are required to be GPL vs. what could be licensed with another more or less restrictive licenses is less clear.

So whatever the license is, after the software has been built they must be able to distribute it as gpl v2

As written, that is not correct. Assuming the "distribution" was being distributed, a GPLv2 or later license would only be required for modules and themes. Since the .profile is basically a module, it would be safe to assume that would also be considered a derivate work, but the "distribution" can include code licensed with dozens of licenses even when it's distributed. Allowing distribution as part of a larger work licensed w/ GPLv2 or GPLv3 does strip the original license.

A key point is that the GPLv2+ license is ONLY required for code that's a derivative AND being distributed. You can write your own make file to build sites, use a custom install profile to start them, and not be required to share any of that code. See https://drupal.org/licensing/faq#q8

You can also include Javascript, PHP, or code written in any language in a single download with a number of GPL-compatible licenses as long as the code with the other licenses isn't considered a derivative of Drupal. Packaging code together in a single download does not automatically make everything in that download a derivative.

If your business depends on correctly interpreting what is and isn't allowed by the GPL, you should discuss this with your own lawyer. My understanding is that there isn't much case law that specifically addresses this, so most of what is discussed are legal opinions about what would happen if a case were to actually go to court which contributes why you never get a straight answer. Different groups interpret these licenses and their compatibility differently. The Drupal Association's interpretation only really impacts Drupal.org. Beyond the D.A. taking legal action, it does not change what you can do legally do in other repos.

WordPress is a good example of a PHP based project that handles some aspects of licensing the same as Drupal, but treats packaging differently. While they reference the Drupal License FAQ in http://wordpress.org/about/license/ and apply the same logic to plugins as we do to modules, they are much more flexible about the license they allow to be packaged with their themes http://make.wordpress.org/themes/guidelines/guidelines-resources/.

And everyone should be familiar with http://drupalcode.org/project/drupal.git/blob/refs/heads/8.x:/core/asset...

Licensed under the terms of any of the following licenses at your
choice:

- GNU General Public License Version 2 or later (the "GPL")
http://www.gnu.org/licenses/gpl.html
(See Appendix A)

- GNU Lesser General Public License Version 2.1 or later (the "LGPL")
http://www.gnu.org/licenses/lgpl.html
(See Appendix B)

- Mozilla Public License Version 1.1 or later (the "MPL")
http://www.mozilla.org/MPL/MPL-1.1.html
(See Appendix C)

You are not required to, but if you want to explicitly declare the
license you have chosen to be bound to when using, reproducing,
modifying and distributing this software, just include a text file
titled "legal.txt" in your version of this software, indicating your
license choice. In any case, your choice will not restrict any
recipient of your version of this software to use, reproduce, modify
and distribute this software under any of the above licenses.

Drupal is distributing CKEditor as GPLv2+, but that doesn't change the fact that CKEditor retains it's MPL license. The FSF is very clear about how this works http://www.gnu.org/licenses/license-list.html#MPL-2.0

When you receive work under MPL 2.0, you may make a “Larger Work” that combines that work with work under those GNU licenses. When you do, section 3.3 gives you permission to distribute the MPL-covered work under the terms of the same GNU licenses, with one condition: you must make sure that the files that were originally under the MPL are still available under the MPL's terms as well. In other words, when you make a combination this way, the files that were originally under the MPL will be dual licensed under the MPL and the GNU license(s). The end result is that the Larger Work, as a whole, will be covered under the GNU license(s). People who receive that combination from you will have the option to use any files that were originally covered by the MPL under that license's terms, or distribute the Larger Work in whole or in part under the GNU licenses' terms with no further restrictions.

So you can dual license code and include it in your themes and modules, but the modules, themes, and (most likely) the .profile themselves will always require a GPLv2+ license if they are distributed because they are considered derivatives of Drupal. So I believe the correct answers to @Shawn DeArmond's questions are...

What if I want to distribute my own Drupal modules or Features on, say, GitHub or BitBucket rather than on Drupal.org? Can I license the core/contrib part [of a distribution] as GPL, and my own additions (Features, modules, themes) under a different license?

No. It doesn't matter where the modules and themes are distributed from or if they are part of a distribution. Modules and themes are derivates and must be licensed as GPLv2 or later.

redndahead’s picture

@kreynen You're right the faq does state it clearly.

That is, Drupal's PHP code is under the GPL, and so all PHP code that interacts with it must also be under the GPL or GPL compatible.

Since you are self proclaimed not a lawyer too we are just making assumptions based on the things we have learned. I think you are wrong, but I am not a lawyer and you are not a lawyer so we'll have to agree to disagree until a lawyer can make that determination.

lightsurge’s picture

Trying to make sense of this for my own sanity.

So, as far as distributions go, the sort of thing that could work might be that, if a library is GPLv3 but not GPLv2 compatible, that library as part of whitelisting could be marked a 'GPLv3ifier', and if included in a distribution might show a warning to be displayed (perhaps on the project page and by a txt inserted into the tarball, and a warning to the developer on including a GPLv3-only library?) that 'this particular combination of stuff will be / is being distributed under a GPLv3 license'.

So rather than giving the impression to people that they have a choice of license for their project, which could lead to confusion, drupal.org simply bumps stuff to GPLv3 when it can only distribute your newly created combination of stuff under a particular license because the elements you're including can only be distributed, legally, as such.

kreynen’s picture

Correct. Currently we tell everyone that all code coming from Drupal.org is GPLv2+ or GPLv2 compatible, but it isn't. For a summary of the current license violating projects on Drupal.org see...

#2175005: [META] Changes are required before it will be safe to assume code from Drupal.org's git repo is really GPLv2+ or GPLv2 compatible

Right now if someone downloads the TB Sirate Starter distribution, it includes code that isn't GPLv2+ or GPLv2 compatible. That project should have been unpublished weeks ago, but it's used by almost 1,500 sites.

The current situation is that developers trying to follow the rules are limited while the developers breaking the rules make the rules themselves pretty pointless.

The goal of this change is to make it obvious to users before they download code that isn't GPLv2+ or GPLv2 compatible from Drupal.org while giving developers the same rights they have if they maintain their distribution on GitHub.

I wouldn't bump a distributions license to GPLv3 automatically, but update drush verify-makefile drupal-org.make to fail or require confirmation for distributions that tired to include a whitelisted item in their .make that required a GPLv3 license for the distribution.

lightsurge’s picture

Think TB Sirate is a different issue because it's a theme not a distribution. That case seems to suggest we need a similar mechanism for including libraries in modules/themes as we do with distributions (or banning third party code in modules/themes altogether), so at least there's some level of control over what third party code is shipping with them.

I think if it were possible to have an alert when packaging a distribution on drupal.org that a library that's included would mean the distribution would have to be licensed as GPLv3, and then if the developer answers "that's fine" to just sort that out for them - that seems great to me. It really is just a yes/no situation (if no, library just doesn't get included), since there's no other option than GPLv3.

Seems like most developers won't care less between the two licenses, it seems a shame to make it all confusing or have loud warnings (or remonstrations) everywhere.

kreynen’s picture

Think TB Sirate is a different issue because it's a theme not a distribution.

The TB Sirate Starter is the 2nd most popular distribution on Drupal.org. The only distribution that's more popular is the Commerce Kickstart. ~300 more sites have reported using TB Sirate Starter since the license issue was first reported.

https://drupal.org/project/project_distribution

Seems like most developers won't care less between the two licenses...

That's probably accurate, but it's also accurate to say that most developers and open source users don't understand the difference between GPLv2, GPLv3, Apache 2, AGPLv3, MIT, etc. If the goal was to use a license the majority of users would understand, WTFPL (http://www.wtfpl.net/) would likely be the only option.

The fact is that enough key developers not only understand the difference between GPLv2 and GPLv3, they are so passionate about keeping Drupal licensed as GPLv2+ that suggestions to move everything to GPLv3 go nowhere. One argument given to keep the GPLv2+ only policy are organizations that won't use GPLv3 licensed code. I don't think a specific organization has ever been given or any details about why they'd avoid GPLv3 so this may be a straw man argument, but it's made loudly enough that attempts to make changes to support a more inclusive licensing policy always stall.

Allowing distributions the option to use GPLv3 is a small step that doesn't require a change to the git policy and addresses an issue we already have with distributions. It doesn't change what developers are legally allowed to do, it simply gives distribution developers using Drupal.org the same option they have if they use GitHub.

Damien Tournoud’s picture

The requirement of GPL that when "conveying a work based on the Program", you "must license the entire work, as a whole, under this License" is just hurting us.

One way of getting out of this mess would be to add an additional term to the GPLv2+ works that we are distributing from Drupal.org, that would say something like:

You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code, without releasing it as a whole under the GPL as long as each part of the work is released under a free software license as defined by the FSF. This additional term doesn't have to be carried in the work.

The additional term being optional, this is still GPLv2+ compatible (so we allow other communities to distribute derivative works based on straight GPLv2+) without forcing us to re-license every free software that we distribute alongside Drupal.

Damien Tournoud’s picture

Obviously, this would be a licensing change, so it requires broad community approval, but it's for the better so it's probably doable.

lightsurge’s picture

@#59 Apologies kreynen I see what you mean. I think what's confused me is that some distributions are apparently packaging stuff together in different ways, as in your TB Sirate Starter example:

http://drupalcode.org/project/tb_sirate_starter.git/tree/refs/heads/7.x-1.x

while others are using makefiles and allowing drupal.org to package them

http://drupalcode.org/project/commons.git/tree/refs/heads/7.x-3.x

and thus getting much more useful information in the release notes that make it clear it's a distribution and not a single standalone project (i.e. lists of modules/libraries/themes etc.) https://drupal.org/node/2063047 as opposed to https://drupal.org/node/1463472

Edit: To be clear I mean, I would have thought if somebody is building a distribution they should use a makefile and have drupal.org build it, not just package in all the necessaries themselves.

Former seems the wrong way and latter seems the right way? Seems like it's not just the policing of the make files for non-GPLv2 compatible libraries, because there might not be a makefile to police. Is it against the rules for developers to package distributions on drupal.org in this way as well?

Allowing distributions the option to use GPLv3 addresses is a small step that doesn't require a change to the git policy and addresses an issue we already have with distributions. It doesn't change what developers are legally allowed to do, it simply gives distribution developers using Drupal.org the same option they have if they use GitHub.

Yea totally agree. Keeps distributions doable, those developers who don't really give a stuff apart from the basics are kept happy as well as the key developers who don't have to include such libraries if it makes them unhappy having to mark their distro GPLv3.

Making any alteration to an established license like GPLv2+ sounds like the license equivalent of hacking core... apart from the fact licenses don't receive automatic updates for flaws, so not as bad I suppose. I haven't seen much open source software bearing a 'License modified from...' title before, is the GPL license protected by a license?! Something in me wants to leave these licenses alone because I have enough to worry about and the legal speak means nothing to me ;-) Personally I'd find the idea of upgrading core to GPLv3 less daunting than custom modifying the license. But prefer the idea of distributions just being optionally GPLv3.

killes@www.drop.org’s picture

@Damien a great way to mess things up...

lightsurge’s picture

Isn't this conversation about things already being messed up? What's your solution.

Crell’s picture

Using a custom GPL "variant" would require relicensing, and near unanimous agreement among all core contributors. You're not going to get that. It's physically not going to happen. Let's not even pretend it's worth discussing.

Back to the original question...

lightsurge’s picture

Moreover, on #62 why does a project like http://drupalcode.org/project/opencivic.git/tree/refs/heads/7.x-1.x despite appearing as a Drupal installation profile end up with a distribution that looks like https://drupal.org/node/1946766 ... apparently nothing but core plus standalone, but not.

Confused (as somebody interacting, haven't created any installation profiles on d.o to know what's going on here). Seems related to this issue because it doesn't seem possible to control licensing of distributions if there's not always sanity in distributions to even first be able to detect breaking of rules.

Seems like the licensing issue depends on a control/systematic issue first?

Damien Tournoud’s picture

Using a custom GPL "variant" would require relicensing, and near unanimous agreement among all core contributors. You're not going to get that. It's physically not going to happen. Let's not even pretend it's worth discussing.

I would not dismiss that off hand. It doesn't require unanimity, we can get away with just a "significant" number. Also, because we are just talking of an additional term to GPLv2+ that is perfectly in the spirit of free software, I don't see this as impossible.

Making any alteration to an established license like GPLv2+ sounds like the license equivalent of hacking core...

The GPL explicitly support additional terms. It has this clean "extension point", if you may.

barraponto’s picture

Making an alteration to GPLv2 (or GPLv3, for that matter) is a huge NIH symptom.

Also, I feel the DA/D.o is allowed to change contributors code distribution license from GPLv2+ to GPLv3+ since the authorization to move to GPLv3+ is implicit in allowing distribution under GPLv2+. But changing it to Drupal Public License (or whatever we call the GPLv2-ish hacked license) is not implicitly allowed.

gisle’s picture

- deleted - (this comment no longer makes sense)

gisle’s picture

Issue tags: +licensepolicy

Added "licensepolicy" tag.

redndahead’s picture

@gisle that is no change from our current policy. Everything is re-licensed gpl v2+ and no 3rd party code is allowed. Even in distributions where we package all the code together it must be v2 compatible so that we can relicense everything gpl v2+ upon distribution.

gisle’s picture

@gisle that is no change from our current policy.

I know.

However, that's just our current policy (and it is often ignored: #2175005: [META] Changes are required before it will be safe to assume code from Drupal.org's git repo is really GPLv2+ or GPLv2 compatible, so I am not realy sure if it really is a policy, or just something we pretend is our policy).

However, since it is ours, we can change it if we want to (as long as the license underlying the policy is GPLv2).

Moving to GPLv3 only, and we will find ourselves locked into a license where there is no longer an option to change this policy.

And for the record. I think the current policy need to be changed. Badly. (There is even an open issue about changing it: #1856762: Revisit and Redefine Drupal's Policy on hosting 3rd party files and/or files that is not strictly GPL.)

btopro’s picture

def don't want "only" imo. I think the GPLv2+ is a better option.

lightsurge’s picture

Isn't the whole point of giving a distribution of assets a single license so that it's clear to people who want to use if it they can use it?

Imagine if a distribution has a hundred different licenses based on the libraries it is using, to have to work out for yourself what that boils down to in terms of how you can use it as a whole would be really awkward.

I thought the idea here was that if a developer were able to mark a distribution as GPLv3 rather than GPLv2, they could include assets that they wouldn't be able to include if the distribution were to be marked GPLv2 or GPLv2+. If it was as simple as distributions being either GPLv2 or GPLv3 and we had a nice big fat logo somewhere on the distribution project page signifying GPLv2 or GPLv3, that's a lot better surely than including a big fat list of licenses headed "I'm not sure if you can use this, figure it out for yourself"?

lightsurge’s picture

Ahh I think I misunderstood @gisle in #74. I thought he was saying that re-licensing distributions was unnecessary, but perhaps he means the same as me, that it shouldn't be all or nothing.

I would agree with that, because some things are possible in GPLv3 that aren't in GPLv2, and some things in GPLv2 that aren't in GPLv3.

gisle’s picture

Reply to #74:

Isn't the whole point of giving a distribution of assets a single license so that it's clear to people who want to use if it they can use it?

Is it possible to give non-bowdlerized distributions containing third party assets a single license today?

The problem we're facing is that third party assets often comes with a licence (i.e. SIL OFL or CC-BY) that is not in any way GPL-compatible. And unlike third party code, which is usually easy to integrate libraries (only requiring a trivial extra install step), third party assets are often found in rather ephemeral locations such as Deviant Art, Flickr and Instagram

Today, this often "solved" by including the asset, and do nothing (i.e. ignore the fact that the asset does not have a GPLv2+ license, and ignore the fact that the Drupal.org git licence is breeched).

This fact basically gives us three options regarding licensing third party assets:

  1. Agree on a single license and enforce it. Since third party assets is almost never licensed under a license that is GPL-compatible, enforcement will mean that a some projects currently hosted on Drupal.org containing third party assets would have to move off-site (e.g. GitHub).
  2. Allow non-GPL compatible assets as mere aggregates in projects hosted on Drupal.org. Mere aggregates is explicitly permitted by GPLv2. The downside is that downstream recipients may not be able to use included assets in derivative works. This downside may be alleviated by insisting that all non-GPL assets is documented, so that downside recipients will have up-front knowledge about the license situation.
  3. Continue today's policy of pretending everything are licensed under GPLv2+, but not enforcing this policy in all cases. The downside of that policy is that downstream recipients in many cases have no idea about the complexity of a project's multiple licenses, since there is currently no requirement saying that a project bundling non-GPL compatible assets must document this vis-a-vis downstream recipients.

Currently, Drupal.org has opted for the third option. Maybe the first or second option is a more responsible choice?

Reply to #75:

Ahh I think I misunderstood @gisle in [#69/#72]. I thought he was saying that re-licensing distributions was unnecessary, but perhaps he means the same as me, that it shouldn't be all or nothing.

To clarify: I tried to say that Drupal.org should not re-licence anything under GPLv3 only. I think that GPLv2+ (which allow downstream recipients to re-license under GPLv3 if they want to) is what we should stick to. Introducing a GPLv3 only option makes things more complex and have many unwanted side-effects.

lightsurge’s picture

Re #76

Allow non-GPL comatible assets as mere aggregates in projects hosted on Drupal.org. Mere aggregates is explicitly permitted by GPLv2.

The legality around mere aggregation sounds murky:

http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation

Do you know of any cases/examples that suggest the sorts of third party assets we might include in projects would be legally considered mere aggregates?

The downside is that downstream recipients may not be able to use included assets in derivative works.

I suppose when you mention the downstream difficulty, you're talking about situations, for example, where a piece of code might be ok to use not-for-profit, but not commercially, so even if the distribution of it on drupal.org as "mere aggregates" was legal, the actual use of it downstream may not be.

That does sound a bit of a headache. Agree that not allowing that and enforcing a single (or optional GPLv2/GPLv3) license, which re-licenses all the content of a project, will push those projects out of Drupal.org that can't comply into places like github... and that's not great, but it does also have the advantage of (if drupal.org were actually enforcing it) protecting non-devs, beginners etc., who aren't really clued up to the licensing issues, or even that what they are installing might have several licenses attached. They might even be installing projects through a web interface for their organisation's website, and through doing so land themselves in trouble with a single click.

Perhaps projects like that are better on github than on drupal.org, because github is a place for software developers, who perhaps should expect all this, whereas drupal.org is not just for software developers....

gisle’s picture

lightsurge wrote:

The legality around mere aggregation sounds murky:
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
Do you know of any cases/examples that suggest the sorts of third party assets we might include in projects would be legally considered mere aggregates?

Most FLOSS projects distributed under GPLv2 or GPLv2+ bundle third party assets that is not GPL-compatible, and I've never, ever heard anyone outside of the Drupal community object to this. This is what the Joomla! licensing FAQ for templates (= Drupal themes) 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...

Wordpress is doing the same thing as Joomla! (i.e. permitting non-code elements in repos to be licensed under a non-GPL compatible license), but this practice it is not - AFAIK - documented in a FAQ.

The SIL Open Font License FAQ makes the following point about mere aggregates:

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.

lightsurge wrote:

I suppose when you mention the downstream difficulty, you're talking about situations, for example, where a piece of code might be ok to use not-for-profit, but not commercially, so even if the distribution of it on drupal.org as "mere aggregates" was legal, the actual use of it downstream may not be.

No, I am not talking about opening up the floodgates for all sort of licenses. I certainly do not want anything licensed under someething like the CC-BY-NC (to mention a popular license that doesn't allow for-profit use) included in our repos.

While the details needs to be worked out, the way I see this resolved is that Drupal.org is to work out a fairly short list of "permitted" permissive non-GPL licenses. Currently, I only have three candidates for this short list: SIL OFL, CC-BY, and CC-BY-SA. If we go down this route (option 2 in #76), the details will of course have to be decided by the community and given the blessings of the DA, but personally, I want a very short list of licenses and that a steadfast criterion for inclusion is that the license must be free and permissive.

In practice, it means that it shall always be permitted to apply GPLv2+ to any derivative (and that any assets can always be included in further downstream distributions under that license as mere aggregates). However, downstream recipients that choose to re-license under GPLv3 only may need to remove assets that is not GPLv3-compatible from further downstream distributions, since GPLv3 doesn't allow anything that is not GPLv3-compatible in a distribution (not even GPLv2 only).

lightsurge wrote:

[having everything in a project under as single license] have the advantage of (if drupal.org were actually enforcing it) protecting non-devs, beginners etc., who aren't really clued up to the licensing issues, or even that what they are installing might have several licenses attached. They might even be installing projects through a web interface for their organisation's website, and through doing so land themselves in trouble with a single click.

If we make sure we only allow free and permissive licenses, nobody will get in trouble just by downloading and installing the software.

To get in trouble a downstream recipient must: 1) create a derivative of the code; 2) re-license the project containing both code and assets under GPLv3 only; 3) fail to remove assets from the derivative that is not compatible with GPLv3; 4) distribute the derivative to the public.

While the above four step scenario is possible, it is not something that is going to bite non-devs or beginners.

lightsurge’s picture

@gisle the examples you list explicitly limit the scope of mere aggregation to non-code elements like fonts and images, where third party assets are "just data acted upon by the software"? So that doesn't solve the problem of including the examples in the original issue, for example distributing GPLv3 licensed libraries, in GPLv2+ licensed drupal.org projects.

gisle’s picture

So that doesn't solve the problem of including the examples in the original issue, for example distributing GPLv3 licensed libraries, in GPLv2+ licensed drupal.org projects.

Correct. I posted #69 in this thread just to say that I am strongly opposed to distributing GPLv3 only libraries from Drupal.org (or anything that is GPLv3 only).

I think the original problem should be resolved like we do today - by requesting that downstream recipients that want to use GPLv3 only libraries download them themselves and combine them with our GPLv2+ code.

(My follow-ups may be off-topic, but I felt that the points raised by redndahead and yourself addressing my initial post needed to be answered.)

btopro’s picture

Is the issue that the code is re-distributed from and copies hosted on d.o.? Would there be a way to side-step part of this issue by using git sub-modules to reference remote repositories? I do a ton of distros and as much as I love the auto-packaging system I'm not sure it nets enough gain if we're getting bogged down in licensing issues as a result.

If I go and run git clone --recursive and have all the packages as 1 on my computer locally yet the repos live where they do w/ their licensing they do. I think this avoids the code hosting issue at least as far as other licensed code.

lightsurge’s picture

@btopro I think d.o. giving up on attempting responsibility for licensing clarity and just hosting projects with broken dependencies on third party libraries with conflicting licenses is worse than figuring out how to deal with it. It's bad from an end user experience perspective where users might install a module from a gui that then doesn't work, and bad from an amateur developer perspective where they might end up resolving dependencies manually or through some other automatic process when perhaps they shouldn't, because the licensing obligations haven't been met.

I think if there's no possibility of d.o. auto-packaging these projects its perhaps better not to have these projects even partially hosted on d.o., with a link to git or somesuch. i.e., it becomes unsupported.

Crell’s picture

lightsurge: There is actually a new DA group meeting soon to discuss these issues. We all agree the current situation is bad. We need to figure out what we want to, and can, do about it.

redndahead’s picture

@crell that's good to hear. Glad it's starting to progress.

gisle’s picture

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

holly.ross.drupal’s picture

Hi all - To update Crell's comment (#83) I did meet last week with a group of folks to discuss the issues and recommend a path forward. Because licensing issues are part of the Association's mandate and we are legally responsible, I am taking the recommendations of the group to the Association board at the 20 August meeting for discussion. If you are interested, here are the notes from our call, and how to join the 20 August board meeting.

joshuami’s picture

Assigned: Unassigned » joshuami

I'm going to assign this issue to me so that we keep it on the Drupal Association development radar. If we need to implement any technical changes following the board conversation, I'll assign this out to staff or look for a volunteer to jump in and help with the needed changes.

kreynen’s picture

While I still want to see this move forward, I haven't been able to finish the updates required to close #2248207: Something is breaking whitelisted github downloads for distros..

I was able to review almost 75% of the whitelist last week and found more than a dozen new licensing issues. We made some progress on #2307465: Update Whitelist License Taxonomy to Match Allowed Licenses, but are still waiting for someone to even acknowledge #2308559: Update view-packaging-whitelist-items to include licenses.

The view update would make it much easier to summarize of how GPLv2 compatible Drupal distributions really are right now before 8/20. At that point we'll at least have a better idea of how big the problem really is.

@joshuami can you help get the whitelist view updated?

joshuami’s picture

@kreyen, thank you for the links to related issues. @drumm commented on https://www.drupal.org/node/2308559. Let me know if we need to take additional steps before August 20th. If so, let me know and we can work on getting that work prioritized. Otherwise, I will assume we can let the board discussion occur first and then I will get someone started on this work.

kreynen’s picture

acouch’s picture

Issue summary: View changes
lizzjoy’s picture

Project: Drupal.org infrastructure » Drupal Licensing Working Group
Component: Packaging » Miscellaneous
kreynen’s picture

Component: Miscellaneous » Policy
gisle’s picture

Assigned: joshuami » Unassigned

Josh signed up for this in #87 to liaison with the DA, but has since resigned as CTO of the DA. Setting it to "Unassigned".

For the record, I don't think we should provide for this. With support for composer.json, we have a superior way of managing distributions that combine PHP-based modules, so I would really like to close this now (Reason: Won't fix) - but I would like to hear the opinions of others before doing so.

The current distribution system is a rather clumsy, as distributions tend to be poorly maintained and will, as they age, contain an increasing number of outdated components with unfixed bugs and even security problems. Rather than adding features to the profiles/distributions, we should encourage those who want such things to use composer.json to combine PHP-based components from various sources (other types of libraries such as JS should use the Libraries API to manage libraries - as is already the recommended practice).

dsnopek’s picture

... as distributions tend to be poorly maintained and will, as they age, contain an increasing number of outdated components with unfixed bugs and even security problems.

I'm not sure I agree with that. :-)

Panopoly has committed to a policy of releasing the same day or day after a security release that affects us, and we've stuck to that policy for almost 2 years. We're further behind non-security releases, but we keep up where there are community members who care about a module.

Also, we depend on the distribution packager on Drupal.org as the way we get a fully built Panopoly to our users. If we had to host our built packages off Drupal.org, we'd get by, but we'd have to increase our efforts to have our own marketing site and try to build trust in downloading Drupal stuff off of somewhere that isn't Drupal.org. It's hard enough just staying on top of the effort to maintain Panopoly (which is done by volunteers, either in their own time or as part of client projects that include Panopoly).

So, I'd personally love to see the licensing policy and packager improved for the modern era!

gisle’s picture

@dsnopek,
my statement about distibutions being poorly maintained may have been too broad - please accept my apologies for that.

Just to make things clear, I am not trying to shut down the distribution packager on Drupal.org.

This thread is about a feature request ("Give installation profiles/distributions GPLv3+ license as option for packaged downloads"). Today, there are no options: GPLV2+ is the only license available.

Can you care to expand on why having GPLv3+ as an option is an improvement "for the modern era". Can you tell us how important the requested new feature is for Panopoly (for example on a scale from "nice to have" to "business-critical").

This issue is over four years old. Last real comment (except yours) was two years ago. It is not very likely that any refactoring of the distribution packager on Drupal.org will happen any time soon. So I would like to close it in the interest of having fewer loose ends in the LWG issue queue. But I am not going to close it if there are important community members (such as yourself) that really believe there is some merit in still keeping the issue open.

sylus’s picture

100% agree with @dsnopek and thanks for giving clarifications on distributions being maintained.

One thing I would really like the packager to do is to support different types of builds for an install profile such as:

panopoly.core
panopoly.full
panopoly.light
panopoly.experimental

However it might be more rational just to start encouraging packages that are built off of D.O. It is my hope that a proper and stable composer workflow and support with the packager could help to mitigate this.

dsnopek’s picture

@gisle: Thanks :-)

Can you care to expand on why having GPLv3+ as an option is an improvement "for the modern era". Can you tell us how important the requested new feature is for Panopoly (for example on a scale from "nice to have" to "business-critical").

So, as it stands, because we've chosen to double down on Drupal.org for packaging and distribution of our distribution, we simply won't consider GPLv3 or Apache licensed libraries for inclusion in Panopoly.

(The reasons we've chosen to distribute Panopoly on Drupal.org aren't directly relevant to this conversation, but for reference are primarily: (a) the Drupal community trusts things on Drupal.org and not really so much elsewhere, (b) support from the Drupal security team (c) less stuff we have to build for a resource-strapped volunteer team.)

However, there's been a trend in new libraries licensed under GPLv3 and Apache, and not really much new being released as GPLv2 (although, lots of stuff is still released as MIT which we can use). So, this limits our ability to "get off the island" and include the newest and coolest stuff.

So, I mean, it's not really "business critical", in the sense that Panopoly will continue to exist - it's just limiting what Panopoly could become. And the longer this goes on, and the more and more new libraries are GPLv3 and Apache, we may eventually hit an inflection point where we just have to leave Drupal.org and host our built packages elsewhere -- but I'd really rather not since being on Drupal.org has the advantages listed above.

gisle’s picture

Priority: Major » Normal
Issue summary: View changes

Removed examples that has been resolved from the summary (we manged to persuade Twitter Bootstrap to dual licensed under GPLv2+).

Setting priority to "Normal" (re: https://www.drupal.org/core/issue-priority ). It has remained unresolved for four years, opinions about its desirability differ, and workarounds exists (e.g. persuade the author of the library you want to use dual lisence under GPLv2+, or use composer to assemble the components).

gisle’s picture

Issue summary: View changes

Changed "or later" into "and later".
Historical note: A some point in time, the phrase "or later" (used in the the Git Repo Usage policy) was replaced by "and later". Both mean exactly the same thing, but the phrase "and later" is the "official" term.

Expanded the section "Potential problems". Added section "Workarounds".

gisle’s picture

Issue summary: View changes
gisle’s picture

Issue summary: View changes
gisle’s picture

dsnopek wrote:

However, there's been a trend in new libraries licensed under GPLv3 and Apache, and not really much new being released as GPLv2 (although, lots of stuff is still released as MIT which we can use). So, this limits our ability to "get off the island" and include the newest and coolest stuff.

Just to avoid any misunderstanding. If there was a GPLv3+ option, this would not allow you to include a single component licensed under GPLv3 or Apache 2.0 in it.

It is perfectly legal for downstream recipients to use such components in derivative works of Drupal, but Drupal.org cannot package them and distribute them under a GPLv3+ license.

All components in a GPLv3+ distribution must be GPLv3+ compatible. Being licensed under GPLv3 or Apache 2.0 only will not be sufficient (for the same reason that software made available under GPLv2 only cannot be included in our current distributions that uses the GPLv2+ license).

redndahead’s picture

#103 This is where @gisle and I disagree. It would be nice if the DA could get a lawyer involved that could make this evaluation.

gisle’s picture

@rednhead, can you elaborate? What in #103 is that you disagree with?

Is it the following statement:

If there was a GPLv3+ option, this would not allow you to include a single component licensed under GPLv3 or Apache 2.0 in it.

I am pretty sure that this is correct. We simply cannot take some component that is licensed under "GPL version 3" and relicense under "GPL version 3 and later". While "GPL version 4" does not exist today (and probably never will), such an act is not future-proof and that alone makes it impossible.

To distribute components licensed under GPLv3 or Apache 2.0, we need to allow each component that does not allow re-licensing to retain its original license. It is of course OK to re-license software licensed under GPLv2+ to GPLv3 or GPLv3+ (because of the "+" in the original license). But unfortunately, you cannot take software licensed under GPLv3 (without the "+") and re-license it under "GPLv3+".

So while mixing components with different downstream compatible flavours of the GPL and APL inside the same distribution is technically and legally possible, it is not possible by simply offering GPLv3+ as an option for distributions.

As for the other solutions (that allows mixing components with different downstream compatible flavours of the GPL and APL inside the same distribution) they are IMHO horribly complex and not something we should work on.

However, if you think that my evaluation of the GPLv3+ option lack of merit is wrong, and has to be corrected by having it evaluated by a lawyer, feel free to reach out to the DA and request that a lawyer takes a look at it. I shall of course respect the outcome of such an evaluation.

hestenet’s picture

Re: #104 we(the DA) are currently undertaking a legal review. It can be a somewhat protracted process - but we'll provide more information as soon as we have it.

chr.fritsch’s picture

Any updates on this?

hestenet’s picture

I wish I had a bigger update. The DA engineering team has jumped in to help out in the Packaging Whitelist queue for now - until we can sort this out. Turns out getting the right legal and leadership voices in the same room at the same time has proven very tricky. We're going to continue to try and resolve this. I hope my next update doesn't take as long.

webchick’s picture

The core Modernizing JavaScript initiative is starting to hit this as well.

The group is hoping to put together a prototype of a Calypso-like decoupled admin backend for Drupal, and wants to use https://github.com/mozilla-services/react-jsonschema-form for rendering forms in their new decoupled admin theme, but it’s licensed under Apache 2.0. Mozilla will not re-license (see https://www.mozilla.org/en-US/MPL/license-policy/) so we will need to go to GPL v3 in order to incorporate it (see https://github.com/drupal/drupal/blob/8.5.x/core/COPYRIGHT.txt#L6 and https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).

That library is cross-framework, popular, and well-maintained, so would be nice to use it versus a less-popular/well-maintained alternative with a friendlier license.

dsnopek’s picture

Doesn't look like anyone mentioned this here (at least based on a quick text search) but this issue also affects CiviCRM which is GPLv3. There's the main CiviCRM module which can't be hosted on D.o, but also some other contrib modules and we've got a Drupal 8 & CiviCRM distro. Being able to use the D.o composer endpoint with the main CiviCRM module would have helped a little with getting CiviCRM to work with Drupal 8 too.

kreynen’s picture

I haven't worked with CiviCRM for a few years, but I used to be an active contributor to that project and packaging it with Drupal as part of CiviCRM Starter Kit.

I wanted to clear up a few things...

  1. CiviCRM itself isn't a Drupal module. It leverages permissions and routing of the parent CMS. The same version of the CiviCRM code can work with WordPress and Joomla. CiviCRM itself is licensed as AGPL-3.0. CiviCRM includes several other libraries that are compatible with GPL-2.0 and GPL-3.0. I was the person who originally requested CiviCRM be whitelisted along with all of the libraries required to rebuild CiviCRM with .make packaging. It's only the CiviCRM Drupal modules that are considered derivate work and require the same licensing as Drupal. Those modules act as a bridge and can be hosted on Drupal.org.
  2. CiviCRM should never have been whitelisted and the CiviCRM Starter Kit should not be distributed from Drupal.org. Unfortunately in the rush to allow the packaging of 3rd party code with Drupal distributions, there was some confusion about what was actually allowed and no easy way to figure out which distribution used which whitelist entry to remove these mistakes. This was before the LWG. Along with the patent concerns that come with GPL-3.0, the risk of ending up with AGPL-3.0 code in a build should be very scary to anyone trying to build a business on Drupal.

Even if we allow GPL-3.0, I don't think we should allow AGPL-3.0.

I'm pushing to allow the GPL-3.0 option largely because of the compatibility issue with Apache-2.0. That is Google's license of choice and one 3 option GitHub pushes as part of https://choosealicense.com/. While GitHub recently changed their UI to make it easier to select licenses other than the top 3, but the fact is most projects are selecting from the promoted licenses; Apache-2.0, GPL-3.0, or MIT. Of those, only MIT is currently compatible with Drupal's GPL-2.0 and GPL-3.0 licensing.

Licensing options when creating a new project on GitHub highlight MIT, Apache-2.0 and GPL-3.0 licenses

dsnopek’s picture

Ah, sorry, you're right, it's AGPLv3 rather than GPLv3.

It's only the CiviCRM Drupal modules that are considered derivate work and require the same licensing as Drupal. Those modules act as a bridge and can be hosted on Drupal.org.

For whatever reason, the CiviCRM maintainers think that the CiviCRM Drupal module can't be hosted on Drupal.org - this came up when trying to figure out how to handle composer with CiviCRM & Drupal 8. They also list the license for the CiviCRM Drupal module to be GPLv3:

https://github.com/civicrm/civicrm-drupal/blob/8.x-master/LICENSE.txt

In any case, it sounds like there won't be the ability to include CiviCRM distros or modules on Drupal.org any time soon (or maybe ever).

kreynen’s picture

FileSize
227.77 KB
kreynen’s picture

You scared me for a minute. https://github.com/civicrm/civicrm-drupal/blob/8.x-master/LICENSE.txt is GPL-3.0, which is OK from GitHub. It's just not currently allowed from Drupal.org.

CiviCRM's licensing is a little difficult to understand from GitHub. They include https://github.com/civicrm/civicrm-core/blob/master/agpl-3.0.txt, but they also include https://github.com/civicrm/civicrm-core/blob/master/gpl.txt. https://github.com/civicrm/civicrm-core/blob/master/header-agpl.txt is really the most important files. There's a script to add that to header of all their core PHP like https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Action.php. This is somewhat similar to how a LICENSE.txt files in a Drupal project's git repo is overwritten when the release is packaged, but much better since the license is also included for anyone cloning the code from GitHub. Users cloning Drupal project have to do some detective work to figure out the project's license.

At one point, the CiviCRM module was available from https://www.drupal.org/project/civicrm. Back then install and updates were a 2 step process. I didn't think the reason for moving was licensing of the Drupal module, but ease of maintaining builds of CiviCRM for all the supported CMSes and ease of updates. By packaging and distributing CiviCRM inside the Drupal module, site owners only have to update code in one location.

This is just going to keep coming up, but the decision to distribute projects as GPL-3.0 or allow distribution of both GPL-2.0 and GPL-3.0 from Drupal.org isn't trivial.

I proposed a session to discuss licensing at DrupalCon. Since FOSS licensing discussions aren't nearly as interesting as javascript front ends or even support for pull requests on Drupal.org, I could use some help promoting https://events.drupal.org/nashville2018/sessions/playing-well-others-doe.... I think everyone who's participated in this discussion understands how important this topic is to the future of the Drupal project.

@dsnopek You'll get a kick out of this. Part of the session I did at CiviCON DC back in 2013 was about Drupal's licensing requirements for packaging distributions on Drupal.org. The last 10 minutes of that session were spent discussing the future of CiviCRM and Drupal 8 when both projects leveraged Symfony and what the CiviCRM Starter Kit might look like if it was built on a smaller, framework only version of Drupal :)

chr.fritsch’s picture

At the Thunder distribution we faced this issue a few times.
First time when we integrated Google AMP which is a must-have for a publishing distribution. We are using https://www.drupal.org/project/amp for that which depends on https://github.com/Lullabot/amp-library which is licensed under Apache 2. No chance to get Lullabot/amp-library whitelisted.
Currently, Thunder provides the drush make and composer installation method.
If you are using composer everything is fine. Lullabot/amp-library will be just downloaded. I am afraid what happens when d.o. will someday support composer builds.
If you are still using the drush make build process, we had to write additional documentation how to download Lullabot/amp-library afterwards.

At the moment we are integrating https://www.drupal.org/project/yoast_seo into Thunder. This module has a dependency on https://github.com/Yoast/YoastSEO.js, which is licensed under GLP-3. So same situation.

For us as a distribution, it would be much easier if the license rules would be a little less strict. That would also help a lot to provide a better UX on the installation process.

kreynen’s picture

a little less strict

Allowing "GPL friendly" non-code assets like FontAwesome of the CC-SA licensed image was the first real change the project has made to the Drupal.org licensing policies. I think that qualifies as being "a little less strict" and gets Drupal more in line with what WordPress allows.

While I think the change is inevitable, allowing GPL-3.0 in any form would be a HUGE change. Becuase of the difference in implicit patent rights in GPL-2.0 vs. explicit patent rights in GPL-3.0, there are large organizations that say they would stop contributing to (and potential stop using) anything distributed as GPL-3.0.

Drupal's current "everything committed has to be compatible with GPL-2.0 and GPL-3.0 while we distribute as GPL-2.0" has allowed us to walk a line that while legal, is very confusing to most developers.

I honestly don't know if organizations would really leave the project over GPL-3.0, but allowing distributions to be distributed that way would be a good way to judge any potential fall out before even considering this change for core.

Yes. Having a mix of GPL-2.0 and GPL-3.0 compatible code would be more confusing than being able to say "all of the PHP and javascript downloaded from Drupal.org is GPL-2.0", but trying to pressure Google, Mozilla, Apereo, etc into using a license that is GPL-2.0 compatible just isn't going to work.

aleksip’s picture

Becuase of the difference in implicit patent rights in GPL-2.0 vs. explicit patent rights in GPL-3.0, there are large organizations that say they would stop contributing to (and potential stop using) anything distributed as GPL-3.0.

@kreynen Interesting. Do you know more/can you make an educated guess about the reasons behind this? It can't be about the code they are contributing, as that already has to be compatible with GPL-3.0? So it is to do with license compatibility with other software they are using?

gisle’s picture

aleksip,
it is clearly about the requirement to grant a sub-licensable "patent license" to all downstream recipients that emerges from the (IMHO) very hard to understand section 11 of GPLv3.

kreynen’s picture

Right. There is also no/very little case law about this, so everyone is really just speculating about how this would play out in court.

Everything that was written about the Facebook/React/WordPress issue really highlighted how little anyone understands this.

https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-patent-... is probably the best summary of the issue I read. This is BSD + clauses vs. MIT, but a lot of it applies.

IANAL, but if I was a lawyer working for a large enterprise that was concerned about inadvertently granting people rights to a patentable idea, the safe play would be to avoid FOSS completely. If FOSS couldn't be avoided, recommend not allowing employees to contribute back or distribute work. If the organization really wanted to contribute and distribute, recommend avoiding licenses with explicit patent grants. When it comes to options of not sharing vs. exposing a company to a patent litigation, the safer bet is not sharing.

Again, I really want to share what the Licensing Working Group believes are common set of facts and some of the pros and cons of the options at DrupalCon Nashville. https://events.drupal.org/nashville2018/sessions/playing-well-others-doe...

Step 1. Create a group of people who understand open source licensing (as well as copyright and patents)
Step 2. Establish a framework of facts and expand the number of people who understand these issues
Step 3. ???

I took the LWG more than 2 years to get the Dries and the DA to make what we thought wouldn't be a controversial change regarding non-code assets.

Even though we've been debating this specific issue for 6 years, we spend a lot of time getting developers new to the issue up to speed on the complexity and potential fall out. The conversation with developers often starts with a request like "I was told I couldn't include project X in my code. Please change Drupal's license so I can do that." Developers often approach the blocker they've run into viewing the need for GPL-3.0 like any other dependency that should be updated.

Unlike other dependencies, we have no automated tests to confirm that a change to GPL-3.0 isn't going to break something critical in Drupal.