Should Drupal core and contrib be distributed exclusively under a GPLv3 license

Posted by greggles on February 26, 2013 at 5:13pm

I don't care as long as its GPL

19% (6 votes)

No, stick with GPLv2 and GPLv3

26% (8 votes)

Yes, please

55% (17 votes)

Total votes: 31

Comments

For context, please read

Posted by greggles on February 26, 2013 at 5:14pm

For context, please read http://groups.drupal.org/node/211698

This poll isn't going to be binding by any means but is just to get a sense of how people feel.

knaddison blog | Morris Animal Foundation

I'll add if you say no or yes

Posted by redndahead on February 26, 2013 at 10:55pm

I'll add if you say no or yes it would be great if you could leave a comment on why you feel one way or the other.

+1 for GPLv3+

Posted by Matthew Davidson on February 27, 2013 at 4:13am

The above title is a bit misleading: Please note the proposal at http://groups.drupal.org/node/211698 is GPLv3-or-later, not "exclusively" GPLv3.

Why I'm for GPLv3+:

Now we've gotten over NIH, broader free software license compatibility FTW.
Closing the Microsoft-Novell and Tivoization loopholes is a Good Thing. Nobody wants a distro they can't legally modify or redistribute, or to buy a device with Drupal pre-installed only to brick it by modifying/upgrading it. That's taking "don't hack core" to an unnecessary extreme.
GPLv3 FUD will always be with us (at least as long as Linus Torvalds has strength to draw breath), but so will general copyleft FUD, and AFAIK nobody's proposing switching to a non-copyleft license because of it. The best thing we can do to combat FUD is to show we're a big GPL project and we're not afraid.
Also, I have a beard. Although I think my previous three points are compelling enough to persuade the non-bearded.

Can't modify distro?

Posted by DamienMcKenna on March 5, 2013 at 1:24am

Why would you think that someone couldn't modify a GPL2-licensed distro?

Caught me out there

Posted by Matthew Davidson on March 5, 2013 at 2:16am

Caught me out there: What I should have said is "modify and redistribute", or just "redistribute", for that matter. i.e. in a case where you have some patented algorithm added to a distro and a Microsoft-Novell-style covenant not to sue which applies to one or more distributors, but not downstream recipients.

Some people, notably Bradly Kuhn, argue that GPLv2 is enough to prevent the initial distribution of patent-encumbered code, but certainly GPLv3 is more explicit about this, and particularly prohibits the Microsoft-Novell trick.

Unhappy with GPLv3

Posted by slef on February 27, 2013 at 9:54am

I'm unhappy with the GPLv3 drafting process. I believe significant bugs were identified during the drafting which were left unaddressed, partly because of that defective process. We should wait for a new community-driven GPL (v4?) and allow people to choose GPLv2 if they prefer to choose the risk of Novell and Tivo over the risks from the new and rewritten clauses.

Interesting...

Posted by Matthew Davidson on February 27, 2013 at 1:49pm

You must forgive me, as I was quite young in at the time. What, specifically, was done right with the drafting process in 1991 that was messed up in 2007?

How was GPLv2 more "community-driven"? The Web interface for contributing to the GPLv3 drafting process (http://en.wikipedia.org/wiki/Stet_%28software%29), which was open to anybody, may not have been faultless, but on the other hand there was no World Wide Web when GPLv2 was drafted. As far as I know, the GPLv2 drafting process was RMS.

Can you name one or more bugs not present in GPLv2 that are in GPLv3? Just out of curiosity, because in any case, it's academic. As Drupal is currently GPLv2 or later, the "risks from the new and rewritten clauses" already apply, so you can only be saying that there's something desirable present in GPLv2 that's missing from GPLv3. What is it?

This is actually slightly

Posted by slef on March 4, 2013 at 8:37am

This is actually slightly before my time, but I was told that the GPLv2 was the result of a few iterations of a fairly fast release cycle with ad-hoc public licences 1985-1989, then the GPLv1 in 1989 and GPLv2 in 1991, and there was open discussion going on on some GNU mailing lists, where people felt their concerns were addressed.

The Stet web interface was not "open to anybody". It had serious bugs, many of which made it unusuable by assisted-access machines. It was based on RT (which I use at work and have extended), which is an OK project, but the Stet software release was undocumented spaghetti code that FSF refused to help others bugfix.

It's no surprise to me that stet has died a death.

What are the bugs that you

Posted by redndahead on February 27, 2013 at 5:24pm

What are the bugs that you feel were left unaddressed? These specifics are what we need to make a good informed decision.

Foolishly, I didn't keep a

Posted by slef on March 4, 2013 at 8:27am

Foolishly, I didn't keep a list of the bugs I reported. Most of them got onto http://gplv3.fsf.org one way or another (one of the bugs with the process was that the web app running that process was often broken) but that site has been removed now. Many bugs (sorry, "issues") were dismissed abruptly, which you can see in messages like http://lists.debian.org/debian-legal/2006/02/msg00333.html

I remember some of them and have gathered others from my messages to the debian project around that time.

http://lists.debian.org/debian-legal/2007/06/msg00276.html reminds me that the biggest bug is the addition of a conversion clause that weakens the copyleft and allows later developers to switch to the even-more-questionable AGPL. I discuss a bit of why that's a problem in messages like http://lists.debian.org/debian-legal/2009/03/msg00114.html and I've developed some exceptions with my colleagues which we use when we meet AGPL projects. Most importantly, Developers need publish their modifications only (not the whole application source code with all unusual libraries) as long as they link back to our source code repository; and the running application need not check if the source code is currently on-line (so long as it is usually and can be requested).

If anyone is willing to hire the co-op to do some web archaeology, I can probably recover more of the specific issues, but it may be better if drupal's organisation hires a good lawyer to identify the vague/dubious bits in the GPLv3.

Oh the site's back up this

Posted by slef on March 4, 2013 at 8:50am

Oh the site's back up this morning. I'll see if I can get more of the issues out of it.

Update: http://gplv3.fsf.org/comments/rt/readsay.html?Query=%20%27CF.NoteUrl%27%... is the link to browse them. Look for ones without "This Comment is resolved by:". The comments search still doesn't seem to be working.

All I see there is

Posted by redndahead on March 4, 2013 at 5:33pm

All I see there is punctuation issues.

The one thing you had mentioned is agpl. From what I've read in the agpl license this is what is allowed. If you have gpl v3 code and you include agpl v3 code you must provide a way for people to download the agpl v3 code if it's used on a website. You don't have to provide a way for people to download the gpl v3 code though. Here is an example.

Drupal - gpl v3
libraryx - agpl v3

whitehouse.com built their website with drupal and libraryx. Some person can come up to them and say, "Hey Obama, give me the code to libraryx, foo'!" and they would have to provide it. They could say, "Hey Obama, give me the code for your entire website, foo'!" But Obama could say, "I'm sorry we can't give that code for national security reasons. How do we know you aren't going to give it to the enemy? I'll give you the code to libraryx, but that's it. Now don't make me drone you bro'."

If we would go with gpl v3 I think we would specifically exclude the usage of agpl v3 because it requires too much responsibility on the site owners that they may not be aware of when they download the software.

Keep digging and you should

Posted by slef on March 5, 2013 at 4:19pm

Keep digging and you should get to some substantive issues. If I had spare time/money, I'd do it for you.

Can you exclude the usage of agpl v3? Isn't that an additional restriction to the gpl v3, so not ordinarily possible?

"Can you exclude the usage of

Posted by redndahead on March 5, 2013 at 4:53pm

"Can you exclude the usage of agpl v3? Isn't that an additional restriction to the gpl v3, so not ordinarily possible?"

I'm not sure I understand this question. What I meant was that when we add libraries that are allowed to be downloaded in our white list we wouldn't allow agpl v3 licensed software even though it's technically compatible with gpl v3.

+1 for GPL v3 Being able to

Posted by ParisLiakos on March 4, 2013 at 6:11pm

+1 for GPL v3
Being able to package apache2 code together is a great plus imo..
see this for example
https://github.com/twitter/bootstrap/issues/2054

Additional +1 for GPL v3 for

Posted by acouch on March 5, 2013 at 8:23pm

Additional +1 for GPL v3 for reasons described here: http://groups.drupal.org/node/211698

me: http://aaroncouch.info
my work: http://nuams.co

+1 for Drupal core goes GPLv3

Posted by hswong3i on March 10, 2013 at 3:35am

Some more follow up information from http://www.gnu.org/licenses/quick-guide-gplv3.html, see this graphic:

Only local images are allowed.

Edison Wong
CEO, Co-founder
PantaRei Design Limited

@hswong3i, that graphic

Posted by kreynen on March 18, 2013 at 11:22pm

@hswong3i, that graphic doesn't include AGPL which is discussed later on that page...

if someone uses AGPLed source in an application without a network interface, they'll only have to provide source in the same sort of way the GPL has always required. By making these two licenses compatible, developers of network-interactive software will be able to strengthen their copyleft while still building on top of the mature body of GPLed code available to them.

I'm not a lawyer, but my understanding is moving core and contrib modules hosted on Drupal.org to GPLv3 wouldn't close the Software as Service Loophole, but would allow developers the option of creating AGPL licensed modules hosted on GitHub or some other repo that could then be packaged within a distribution... assuming Drupal.org allowed this. I'd hope we would since GPLv3 and AGPLv3 were designed to be compatible while achieving different goals.

http://en.wikipedia.org/wiki/Affero_General_Public_License#Compatibility...

GPLv3 and AGPLv3 each include clauses (in section 13 of each license) that together achieve a form of mutual compatibility for the two licenses. These clauses explicitly allow the "conveying" of a work formed by linking code licensed under the one license against code licensed under the other license, despite the licenses otherwise not allowing relicensing under the terms of each other. In this way, the copyleft of each license is relaxed to allow distribution of such combinations.

Moving code contributed to Drupal.org to GPLv3 would give developers who are more interested in maintaining Stallman's goal of never being prevented from modifying the software they use and/or who don't want to see modified versions of their work running on SaaS service by companies that have no legal obligation to share changes/improvements the option of licensing their work as AGPL.

Not allowing AGPL in Drupal.org's git repo would protect companies who invest in Drupal while developing their own SaaS solutions. They could safely use any module or theme on Drupal.org without being forced to release their source. They would only need to research the licensing requirements of code in distributions... but it really seems unlikely that a company with the resources to develop a SaaS solution would be using a distribution other than core as the starting point.

In general I believe the SaaS Loophole has been a good thing for open source, but as we continue to see a shift the ratio of users/contributors and enterprise level Drupal, we need to do more to protect the openness of the source. Over the years I've called out a few shops that actually distribute code, but refuse to share it. They aren't even hiding behind the SaaS loophole. They literally sell code they keep in a private repo along with other contrib modules. Most of the SaaS provider's I'm familiar with are generally good contributors who give a lot back, but w/ only a GPLv2 option, beyond bad karma there is little stopping someone from taking the community's contributions and giving nothing back.

The Opa project changed their licensing last year and is a great example of a mixed license distribution that uses different licenses to achieve different goals for different parts of what is downloaded as a single package.

Just a note here, I've been

Posted by cweagans on March 27, 2013 at 1:35am

Just a note here, I've been pulling some weight on getting Twitter Bootstrap relicensed as MIT so that we can use it in Drupal distros (https://github.com/twitter/bootstrap/issues/2054#issuecomment-15421838). While APL->MIT is a good move, IMO, we wouldn't have had to deal with it if Drupal were GPL3.

--
Cameron Eagans
http://cweagans.net

Stick with the current license: GPL-2.0-or-later

Posted by gisle on August 30, 2019 at 11:01am

Looks like the vote is closed. My vote goes for sticking with GPL-2.0-or-later. Being unable to use GPL-2.0 licensed code in a project is a big loss.