Move drupal core and contrib to gpl v3 or later.

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
redndahead's picture

Short version

Move drupal core and contrib licensing to gpl v3 or later.

Long version

Currently drupal core and contrib are licensed as gpl v2 or later. While this works fine for core, themes and modules this poses some possible issues with installation profiles. Recently drupal.org started packaging 3rd party libraries in installation profiles. The requirement, at the moment is that any 3rd party library be compatible with gpl v2. This currently leaves us incompatible with a few important licenses. Here is a comparison of the licensing compatibility gains/losses if we move to gpl v3 taken from here. http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

Gains:

  • gpl v3 only
  • gpl v3+
  • lgpl v3
  • lgpl v3+
  • agpl v3
  • Apache V2
  • Educational Community License 2.0
  • xFree86 1.1

Losses:

  • gpl v2 only

Downsides for our users

By moving to gpl v3 we would restrict our users from distributing the code as gpl v2 only and gpl v2+. It would be nice to hear of places where this is taking place and provide reasons why this would be detrimental.

Resources

Changes in gpl v3: http://www.gnu.org/licenses/quick-guide-gplv3.html
List of licenses compatible with gpl v3 (exclude gpl v2): http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
Issue relating to moving to gpl v3 in installation profiles: http://drupal.org/node/1449452

Comments

Given that gpl v2 is the most

pwolanin's picture

Given that gpl v2 is the most popular license for open source projects, I think this is an unacceptable proposal at this point.

Is there a specific library you have in mind?

The Drupal Association also has no control over the licensing of the code, so this is the wrong group - adding "Legal".

Not quite

Crell's picture

GPLv2+ is the most common license. GPLv3 is still compatible with GPLv2+; the combined work simply has to be licensed under GPLv3. There's relatively little code that is GPLv2-only, or at least that's my understanding from my conversations with SFLC a few years back.

One v2 only example is

This is gpl v2+. Like drupal

redndahead's picture

This is gpl v2+. Like drupal unless specifically stated which version it's considered gpl. Including the license text is more of an example of which gpl license you can use. See the Linux kernels license text for an example of gpl v2 only code. http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob...

I don't think it is v2+. The

greggles's picture

I don't think it is v2+. The license clearly says "Version 2, June 1991". The only mention of later is the second paragraph of section 9 which is a clarification of how to interpret the phrase "later version" if that phrase is present, which it's not.

The Linux Kernel example is a clarification they've added because people misinterpreted and the wanted to be very clear, but I don't see why anyone should have to say "Version 2. No really, only Version 2."

SFLC

Crell's picture

The Software Freedom Law Center advised us the opposite when we were putting together the FAQ originally. That was a major concern of mine for exactly this reason. According to our contact there, GPLv2 is by default upward compatible.

Read on: If the Program does

mot's picture

Read on:

If the Program does not specify a version number of this License, you may
choose any version ever published by the Free Software Foundation.

The program does not specify a specific version number of the license . It only contains a license text which has a version number, namely the text-file says it is the version number two of the license text in that file (that is because there are multiple versions of a license called "GNU GENERAL PUBLIC LICENSE").

This is not the same as specifying a license version with the software. There is no copyright comment in the sourcecode that specifies a license version, nor are there interactive parts that output it on the screen or similar.

The original author might have missed to specify the GPL version with it's program, so it's normally better to first contact the author and clarify the version instead of assuming that any GPL version can be used.

V2 is definitely the most

redndahead's picture

V2 is definitely the most popular license and will continue to be until people have a reason to move to gpl v3+. The reason for this is because most projects are already gpl v2+ so they have very little reason to move. I think I stated a good reason for us to move. The problems that could arise is when people try to incorporate drupal into their projects they distribute. Any examples of this happening?

While this issue was the catalyst for this request I'm sure it will be the first of many. http://drupal.org/node/1445226

Larry had mentioned in this comment that he believed it was up to the DA to make this decision. http://drupal.org/node/1449452#comment-5635428

Edit: sorry to be redundant with what Larry posted above. Cross-posted

Well, ok - I guess the infra

pwolanin's picture

Well, ok - I guess the infra team could switch the license on the d.o git repo, but that would not fly. Any such decision requires a consensus of contributors and committers.

The decision to specify that it's GPL v2+ instead of just GPL (i.e. version 1+) was not one that had any practical effect, and so wasn't controversial.

http://osrc.blackducksoftware

pwolanin's picture

http://osrc.blackducksoftware.com/data/licenses/

not clear how many of the 42% listed as GPL v2 are actually v2+

According to this article in

redndahead's picture

According to this article in 2010 gpl v3 is over half of the licenses at google code. That said it still doesn't show how many of those were gpl v2+. http://www.internetnews.com/skerner/2010/07/gplv3-now-dominates-at-googl...

Cons

redndahead's picture

So I thought I would start a list of cons of moving to gpl v3. Please add more if you can think of some.

  • Difficult to implement. We would have to contact each developer that has contributed code either in core or contrib and ask for their permission.
  • Companies may not want to contribute if they have software patents.

Difficult to implement. We

Crell's picture

Difficult to implement. We would have to contact each developer that has contributed code either in core or contrib and ask for their permission.

Not true. Code distributed to Drupal.org is contributed under GPLv2+, which means Drupal.org is free to take it and redistribute under GPLv2, GPLv3, or GPLv2-and-3. We do the latter currently. That's what I mean above with the DA. We do not need to get every contributor's permission to switch to GPLv3. We already have it, legally speaking.

Companies may not want to contribute if they have software patents.

Whether that is a positive or a negative is, I suppose, a matter of opinion.

I am of the mind that it is a

redndahead's picture

I am of the mind that it is a positive. If we look at the software patent landscape it's riddled with unnecessary lawsuits. Just take a look at the Eolas/University of California patent [1] that tries to patent practically the internet. I think the additional protections the gpl v3 provide for patents can only help us in the long run.

Disclaimer: Although I work for the University of California these views are my own and, obviously, not that of my employer.

  1. http://news.cnet.com/8301-1023_3-57374394-93/jury-strikes-down-eolas-int...

Large companies, enterprises, and startups will not like this

rj's picture

One of the issues with GPLv3 is you cannot run GPLv3 as Software as a Service without releasing full source-code of changes and modifications, such as custom modules. With Drupal becoming more of a framework, I can see this as a dis-incentive for using Drupal if you're a startup. The attorneys I've spoken with strongly recommend against using GPLv3 for any custom software and applications for this same reason, so I could see this as a dis-incentive for large companies and enterprises adopting Drupal as well.

Note that IANAL.

--

R.J. Townsend

AGPL

stevepurkiss's picture

I believe that's the AGPL license, not the GPLv3:

http://www.gnu.org/licenses/agpl.html

Only true for agpl v3

redndahead's picture

This is not true for gpl v3. AGPL v3 closes the loophole but it still exists in gpl v3.

http://changingway.org/2007/06/29/gpl-v3-and-saas/

Ambiguity still exists around

rj's picture

Ambiguity still exists around GPL & SaaS, even though AGPL was written to address this issue. Keep in mind it's an attorney who would say this. :) GPLv2 is considered the "safer" of them all.

--

R.J. Townsend

Citation needed

Crell's picture

Everything I've heard from FSF or SFLC would imply that GPLv3 is still SaaS safe. AGPL exists specifically for that reason.

An attorney will argue for whatever his client pays him to argue for; Sorry, but "some lawyer somewhere may argue..." is FUD. Unless you can show where a judge in a court ruling, the authors of the GPL license, or an excerpt from the license say otherwise, we can safely continue on the assumption that GPLv3 == GPLv2 as far as SaaS implications.

Ambiguity only exists because

redndahead's picture

Ambiguity only exists because perpetually people say that it's ambiguous without any real examples. FUD about gpl v3 has been around since it's inception and when that's spread throughout the internet it's hard to convince people that it really is FUD. The SAAS issue was even debated during the draft period and the loophole was purposefully made less ambiguous in gpl v3 than it was in v2.

IANAL, but when I see discussions on this topic it is often said that a lawyers job is to protect the client and many times it's viewed as a risk/reward type of situation. To a lawyer the gpl v2 is safer because it has a longer history and if the software was already gpl v2 then nothing is changing. There is case history with gpl v2 that a lawyer can rely on. Moving to gpl v3 is viewed as riskier because change is involved, although I think after almost 5 years gpl v3 has been around long enough to have proven itself. I would ask any lawyer to try and specify which part of v3, in respect to SAAS, is more ambiguous than v2. My bet is they will be hard pressed to come up with an example in the license text.

An attorney would argue

rj's picture

An attorney would argue there's no definitive court rulings. My point is that moving to GPLv3 may be a turn off for enterprises and start ups. I am sad to see my comments voted down, this is definitely FUD but it's also the way many enterprises/startups think.

--

R.J. Townsend

Not what you said

Crell's picture

There's a huge difference between "GPLv3 closes the loophole" and "some businesses might be squeamish because they're overly cautious and aren't yet convinced that GPLv3 doesn't close the loophole." The first is FUD. The second is a sad but often true observation.

But what you said was: "One of the issues with GPLv3 is you cannot run GPLv3 as Software as a Service without releasing full source-code of changes and modifications, such as custom modules."

Which is not true. It's what some businesses who listen to FUD on the Internet may think, but that doesn't make it true. Pointing out that it's FUD that we'd have to combat if we wanted to make this move is a valid point to make, however.

Yet it is...

rj's picture

Agree, this is something to address in communications.

--

R.J. Townsend

An advantage besides patent issues.

micheas's picture

Imagemagick is as I understand it not GPL2 compatible but is GPL3 compatible.

http://www.imagemagick.org/script/license.php

There may be other libraries/programs that have similar licenses that would be useful.

Although it doesn't

redndahead's picture

Although it doesn't explicitly exclude gpl v2. In the case of imagemagick it's a system library and not really fit something we would distribute, you are right that there could be libraries that are gpl v3+ only that we would now be able to include.

GPL

cw's picture

I'm in the 2+ camp. To me it ain't broke so I don't see any reason to throw it away.

I would also normally be in

redndahead's picture

I would also normally be in the camp of if it ain't broke don't fix it. So beyond the flexibility of packaging installation profiles that I mentioned in the description, drupal would also benefit with better patent restrictions.

Let's say proprietary company A is an evildoer software patent license holder. Company A says to drupal company B "Let's agree to not sue each other's customers over the software patents we hold that we may believe applies to drupal." If drupal company B agrees to it it effectively creates a fear in customers and they may say "Patents may exist out there and I might get sued! I better get my drupal from Company B so I'm protected." There is a clause that says if you suspect that there are patent problems with this code and you enter into an agreement to protect yourself you must be able to provide the same protections to whomever you distribute the code to. By company B entering into an agreement with company A to protect their customers and not the company themselves they get around that clause. This loophole is closed in gplv3.

This may not have been the best summary of the patent clause, but you can read more about this at: http://www.oss-watch.ac.uk/resources/gpl3final.xml

I'm opposed to the effort and

pwolanin's picture

I'm opposed to the effort and confusion a license change would necessitate unless you have clear evidence that this is something other than a theoretical concern at this point.

If you look at the link I

redndahead's picture

If you look at the link I posted above Novell and Microsoft did the exact same thing with Linux. It certainly isn't theoretical.

Edit: Here is more of a direct link http://www.oss-watch.ac.uk/resources/gpl3final.xml#body.1_div.6

Apache 2 code

Crell's picture

GPLv2 and Apache 2 licensed code are not compatible. That's the issue that prompted this discussion:

http://drupal.org/node/1445226
https://github.com/twitter/bootstrap/issues/2054

There's a lot of quality Apache2 code out there. Probably more than there is GPLv2-only code that we would consider leveraging. (I have no data to back that up, mind, but Apache 2 seems anecdotally more popular than GPLv2-only in PHP circles from what I've seen.)

Is it possible to summarise

slef's picture

Is it possible to summarise the compatibility gains/losses with some numbers of extensions which people may want to include, rather than a potentially-infinite-but-irrelevant list of licenses?

Otherwise, this looks like a lot of pain for the small gain of Twitter Bootstrap, which one could use on sites anyway as long as there's nothing in drupal itself or the extensions actually used that is v2only rather than v2+. That is: either this is a solution looking for a problem, or I've not understood the issue with Twitter Bootstrap.

So there are too many

redndahead's picture

So there are too many projects to be able to list. I certainly can't go and show a list of every software project that exists in the world that have those licenses. ;)

Here is a couple more examples of projects that couldn't be included right now
http://code.google.com/webtoolkit - Apache 2
http://freemind.sourceforge.net/ - The full bundle is GPL V3+
Any http://apache.org projects

Pretty much anything you can find that is licensed under any one of the licenses I mentioned in the description could not be included.

The reason we worry about the license of other projects is because of installation profiles. If the licenses are not compatible with gpl v2+ then we aren't allowed to include them in the installation profile when someone goes to download it from d.o. The point of beginning to include them in the download was to improve the user experience when installing them. Also the fact that we couldn't package external libraries was one of the main reasons many distributions were/are not hosted on drupal.org

Additional Request for Apache 2 licensed code

redndahead's picture

Here is an additional request for an apache 2 licensed project.

http://drupal.org/node/1491516

+1 for distributing as GPLv3+

rickvug's picture

We gain a lot more than we loose by distributing distribution code as GPLv3+. Much work went into GPLv3 to solve license incompatibility and proliferation problems. Let's put the effort to good use! While I don't have statistics, I do come across Apache 2 licenses are very common (increasingly so?). AWS SDK PHP and Twitter Bootstrap are just two real world examples.

Here's another issue that is

cyberswat's picture

Here's another issue that is affected by this http://drupal.org/node/1923880 ... CAS is an apache 2.0 licensed project that provides single sign on capabilities for education focused organizations.

It seems like this issue has

cyberswat's picture

It seems like this issue has become stale. I'm curious what is needed to pick it back up and move it forward?

Summary

redndahead's picture

Sorry I haven't continued this on. A job change has kept me away. So I'll try to summarize what was discussed here.

The request is to move from GPL V2+ to GPL V3+. I stated 2 reasons for this.

  1. We have requests for inclusions of libraries in the packaging white list that are not compatible with the GPL v2+ license. The major license being Apache 2.
  2. What seems like a minor concern for us is the better patent protections.

People have brought up concerns with moving to GPL v3+

  • http://groups.drupal.org/node/211698#comment-696853

    We are not quite sure what is the correct path to take

    These are my suggestions on what path to take
    I'm aiming for the most transparency in this process. As the DA manages the hosting for the d.o. modules, I believe it would be up to them to decide the license in which the code is distributed. That said, I think the most transparency and feedback we get, the better off people will feel about any transition.

    1. We ask the DA if they would be willing to facilitate the process of changing to GPL v3
    2. A d.o. front page post is created calling for requests for feedback on a request for the license to change from GPL 2+ to GPL 3+
    3. The comments are distilled and if there seems to be good cause to make the change a proposal is created for how that is going to happen and is sent back out on a d.o. front page post for requests for feedback.
    4. Repeat as necessary
    5. Notice will be sent to all maintainers of modules on d.o.
    6. Sufficient time will be given for a response.
    7. DA will approve the go ahead.
    8. Infra team and whomever else needs to get involved will implement the necessary changes.

Are you proposing to change

pwolanin's picture

Are you proposing to change the license of Drupal itself, or the license under which things can be packaged as distros?

This thread is rather confused at this point.

The request to allow packaging things under GPL3 is possibly a question for the infra team and DA legal team in terms of implications for drupal.org.

To change the license of Drupal as a whole to me is not even in the scope of this discussion and I'm quite opposed since it would far reduce our options.

My proposal would be

redndahead's picture

My proposal would be everything. I don't see a reason to change install profiles and not drupal. Could you explain more on how moving drupal to gpl v3 would reduce our options?

We would clearly lose the

pwolanin's picture

We would clearly lose the option to integrate with a GPL v2 library in any distribution and would potentially lose contributors and users who are more confortable with GPL v2.

Devil's advocate: we might

greggles's picture

Devil's advocate: we might gain some contributors who prefer GPLv3 only.

Personally I'm fine with our status quo for the forseeable future.

By "lose the option to

redndahead's picture

By "lose the option to integrate with a GPL v2 library in any distribution" I'm assuming you mean we wouldn't be able to integrate with a GPL V2 only library. We would be fine with any gpl v2+ library.

I understand the potential of losing contributors. I think if we can be open to feedback and be ready to answer questions I think it will go over fine. I don't have any real data, but I also have the feeling that if people don't contribute because of a license it would be more gpl/non-gpl versus gpl v2/v3. The fact that we would be able to include libraries of other licenses may actually stimulate contributions even if they have to be hosted outside of d.o.

I agree with Greg - I don't

pwolanin's picture

I agree with Greg - I don't see a compelling reason to change our underlying license and I'm not going to spend more time discussing it.

If you specifically want to make a GPL3 distro on drupal.org, due to external libs, I think that's something that does bear discussion in terms of legal and technical implementation.

I don't have an installation

redndahead's picture

I don't have an installation profile that needs these libraries, I just follow the whitelist queue and I've seen many requests for libraries that are not gpl v2+ compatible, but are gpl v3+ compatible.

What frustrates me about this discussion is that it has seemed there is a growing focus on drupal as a platform and installation profiles as the future of what people use. To make this really happen we need installation profiles to be a download ->install->configure type of operation. There are libraries that we cannot include because of our current license. We are excluding the use of these libraries not because of a technical reason, but either because it doesn't concern us, some assumption that we'll lose developers/companies or some perceived difficulty in doing it.

I think there are ways to get information about these concerns, but where do we start? This conversation has been sitting in legal group since near the beginning so I'm not sure that this is the right place for it. I guess I can pose the question to the DA and see if they will have an idea of who would be the deciding body.

Of course Drupal.org can distribute such code

Acubed's picture

There are libraries that we cannot include because of our current license.

Says who? Can Drupal.org, as a software distributor, uphold the terms of the Apache Software License in addition to the GPL when it posts code on the website? Yes? Well great, then let's include ASL code in Drupal.

There's no reason one cannot include open-source code in their open-source project if they so choose. If Drupal.org can uphold all the terms of the Open Source Definition when distributing code, then by definition it can distribute code under any OSI-compliant license. This is what the Open Source Definition is for.

We currently distribute all

redndahead's picture

We currently distribute all code dual licensed gpl v2 and gpl v3. We cannot say that we can distribute under gpl v2 if there is apache licensed code in it. They are not compatible. So the only way we would be able to distribute apache 2 licensed code and say it's gpl code is if we only use the gpl v3+ license. Otherwise we would have to worry about each bit of code and what license it's under. I don't think anyone wants to take on that task.

"Not compatible" just means

Acubed's picture

"Not compatible" just means that the person distributing the code has to agree to the terms of two licenses, instead of merely one.

It does not impact their ability to distribute the code in question.

not true. When you

pwolanin's picture

not true. When you distribute a "combined work" you can only combine elements with GPL compatible licenses since the whole is considered to be GPL licensed.

when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License

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

The quoted section only

Acubed's picture

The quoted section only applies to derivative works. A copyright license can not, nor does the GPL claim the ability to, lawfully prevent you from merely distributing a library.

Distrubtion

Crell's picture

A distribution is a combined (derivative) work of core plus the libraries and modules it uses. A distribution like, say, OpenAtrium that includes GPLv2+ core, some GPLv2-only module, and an Apache 2 3rd party library is not legal to distribute. FSF has said so before.

FSF's solution to that problem is... GPLv3.

Ah, Crell beat me to it :)

cweagans's picture

Ah, Crell beat me to it :)

--
Cameron Eagans
http://cweagans.net

The FSF doesn't get to write

Acubed's picture

The FSF doesn't get to write copyright law...

And even if they could, and they made this illegal (aren't they going for coder freedom anyways? but I digress), what is Drupal going to do, sue itself? Oh, the horror.

If Drupal doesn't modify a library then it's not creating a derivative work. Even if they did modify the library, the license might insist that changes be made under the same terms, which is perfectly acceptable. Drupal.org can distribute this library however it likes, even alongside Drupal code: Open Source software, by definition, requires this. (This is not to be confused with forming a derivative work: Compiling a GPL'd library into a proprietary program is a no-go.)

as long as you don't include

redndahead's picture

as long as you don't include the gpl v2 only software. ;)

Preface: IANAL. When we

cweagans's picture

Preface: IANAL.

When we distribute code from Drupal.org, it is licensed as GPLv2 or later. We cannot include Apache licensed code within the code we distribute from Drupal.org because Apache licensed code cannot be relicensed as GPL2.

A copyright license can not, nor does the GPL claim the ability to, lawfully prevent you from merely distributing a library.

99% of copyright licenses that exist are designed to prevent the receiver of the work from doing things, such as duplication and distribution. It's the entire basis of copyright law. The GPL does not claim to restrict your ability to distribute a GPL licensed library: that would be irony at its finest. The Apache license, however, cannot be relicensed as GPL2, so we cannot distribute it from Drupal.org.

This policy has been developed with the assistance of the Drupal Association's legal counsel, as well as this reference page: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

The SFLC seems to agree as well: http://wordpress.org/news/2009/07/themes-are-gpl-too/

--
Cameron Eagans
http://cweagans.net

Well technically, All

Acubed's picture

Well technically, All licenses grant permission: the status quo is you get to do nothing. No license, no fair use? No permission to redistribute.

Wordpress is wrong, themes are only GPLd when the copyright holder releases them as such. As for the SFLC, they have no published opinion on the matter nor when I've contacted them. If they're suggesting this same opinion to Drupal I'd suggest to you that they're pandering: All of the case law on this, for three decades straight, strikes this notion down.

(No subject)

cweagans's picture

Only local images are allowed.

--
Cameron Eagans
http://cweagans.net

So I guess you heard it here.

Acubed's picture

So I guess you heard it here. Point out to an organization that they forgot to do simple legal research, to find out that operating in the same process does not, in fact, constitute a derivative work... and be called a troll.

But why was this even brought up? This has little to do with my point: No one can seem to point out who would get to sue who, if Drupal did ship non-GPL code, or that they would even remotely come close to being successful.

No one, apparently, would sue anyone.

This is a good thing. Stop complaining about it.

No, you are refusing to

cweagans's picture

No, you are refusing to acknowledge the research that is being provided specifically about the problem at hand (open source licensing issues), the fact that the DA has spent a lot of money on smart lawyers to create this policy, the fact that Crell was the legal liaison for the DA for a long time, and the FSF's official stance on what licenses can and can't be relicensed as GPL (also prepared by smart lawyers). THAT is what earns you the troll label.

If I author a library and distribute it under the apache license, and it's relicensed by somebody else as GPL2, I could have grounds to sue just the same as if I released something under a commercial license and somebody thought that it'd be a good idea to relicense as GPL2.

You cannot just arbitrarily change licenses. It's all open source, but there are rules that have to be followed.

--
Cameron Eagans
http://cweagans.net

What research? If there's

Acubed's picture

What research? If there's been legal research done, I'd like to see it. Neither Drupal nor the SFLC have any legal research to show for it. Literally, no research. No case law, no statute, not even a potential injured party that might have an inkling to file, never mind one with any weighty claim. Seriously, who is the injured party if Drupal decides it wants to distribute another FOSS library alongside it? That's literally the first part of filing a lawsuit and we can't even get that far.

I've done the only legal research here that I know of, and I say (1) Drupal.org is fine (2) Drupal needs to dump its "lawyers".

But if someone else wants to do the research I'm open to changing my opinion.

The FSF can try and say whatever it wants, but that doesn't mean they can get away with it under copyright law (not that they do, they're actually pretty good).

So again: I'm siding with Drupal.org here, use whatever FOSS libraries we feel like, and stop worrying.

who is the injured party if

cweagans's picture

who is the injured party if Drupal decides it wants to distribute another FOSS library alongside it?

As mentioned above, distribution is not the issue. It's the relicensing necessary to make that happen. We cannot arbitrarily relicense software however we see fit, as that could potentially constitute material injury to the author of the library.

We have to relicense included libraries as GPL2 because of the reasoning presented in the SFLC letter to Matt Mullenweg that I linked to above:

Specifically, the CSS files and material contained in the images directory of the “default” theme are works separate from the WordPress code. On the other hand, the PHP and HTML code that is intermingled with and operated on by PHP the code derives from the WordPress code.

[...]

The PHP elements, taken together, are clearly derivative of WordPress code. The template is loaded via the include() function. Its contents are combined with the WordPress code in memory to be processed by PHP along with (and completely indistinguishable from) the rest of WordPress. The PHP code consists largely of calls to WordPress functions and sparse, minimal logic to control which WordPress functions are accessed and how many times they will be called. They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call. As works of authorship, they are designed only to be combined with WordPress into a larger work.

The same applies to Drupal. The DAs lawyers agree. The SFLCs lawyers agree. The FSFs lawyers agree. In fact, everyone seems to agree except for you.

We're not going to change our policies because some armchair lawyer thinks he knows better than the many lawyers who have put together the FSF's and SFLC's responses and data sheets, as well as the the DA's lawyers who have spent a great amount of time reviewing the former to ensure that following them would adequately protect the community.

Our project is big enough that doing what we feel like and not worrying about it is not a valid option. We always have to worry, and for the large number of people that make their living off of Drupal-related services, there's good reason to.

--
Cameron Eagans
http://cweagans.net

Whew!

redndahead's picture

That was a fury of responses.

@acubed I think the gist is that the powers that be have determined that we will release any code from d.o. under one license. All the advice that we've been given says that is what's best. So that policy won't change. All we can possibly change is what license we release that code under.

So right now we are discussing the move to gpl v3+. It seems by your responses that you would be in the camp for not caring if we went gpl v2 or gpl v3.

Thank you for posting your insight.

@cweagens thanks for pointing out those resources for why we choose to distribute software on d.o. under one license. That will help others who may be confused.

Is it likely that the "SFLC

Acubed's picture

Is it likely that the "SFLC lawyers" dug up case law backing this position up, case law that I am unaware of?

Or did they just see that there's no injured party here, no possibility for a lawsuit, and just told Drupal what they wanted to hear to remain a customer?

That written research is one of the most unsubstantive documents of legal advice I've read. Lewis Galoob Toys, Inc. v. Nintendo of America, Inc. is one of the most important software copyright cases ever. You'd think that the SFLC knows about it, right?

"The SFLC advised me and the FSF agreed" is not a legal defense. If you believe that you can just hire lawyers to tell you what you want and all will be good, I have some snake oil to sell you.

In other words, the injured

slef's picture

In other words, the injured party would be the copyright holder (usually author, sometimes hirer of the author) of the library that we relicensed. If drupal infringed often enough, I suspect one of them might sue - and anyway, shouldn't we be good sharers and try to honour their expressed wishes, rather than say "sue us if you think you're hard enough"?

But e.g. the BSD license

Acubed's picture

But e.g. the BSD license permits being bundled with other software. The authors of that library cannot be an injured party, they've already granted their permission. The violation is supposedly a clause somewhere in GPL... so the injured party would have to be Drupal, being violated by Drupal.org... which makes no sense.

The BSD and similar licenses

pwolanin's picture

The BSD and similar licenses are regarded as GPL 2 compatible, and are not a problem. The main issue is probably the Apache license, the terms of which are incompatible with GPL 2.

http://www.gnu.org/licenses/license-list.html#apache2

see also:
http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean

That was an example,

Acubed's picture

That was an example, substitute "Apache" in for "BSD" then.

Tell me, how does me choosing a software license for my project prohibit me from distributing software from authors who grant permission to include it and want to see it included?

Well in the case of apache 2

redndahead's picture

Well in the case of apache 2 they want me to include with some patent restrictions. By distributing it as gpl v2 I am not including those patent restrictions and they are now sad pandas.

What is the situation here?

slef's picture

What is the situation here? Taking this latest situation: something under the Apache2 licence released improperly with a derived work under the GPL by Drupal - the injured party would be Drupal, who could sue any downstream distributor or modifier for violating the GPL by adding the additional restrictions of the Apache2 licence not present in the GPL - which the GPL forbids.

In other words, no downstream distributor or modifier would have a satisfiable copyright licence from Drupal. I think this would make Drupal pretty toxic and some major distributors would not want to touch it with a bargepole.

What's with the suing?

Crell's picture

There is no "Drupal" to sue anyone. Individual developers retain copyright, so there are hundreds of people with substantial copyright claims against Drupal core. And whoever holds the copyright for the Apache2 license

Let me be clear: Anyone saying that "it would be silly to bother enforcing the GPL or Apache license in this case, so let's not worry about whether or not it would be a violation" is someone I don't want contributing code to Drupal. The law doesn't work that way. Quite simply, if your attitude is that lackadaisical then I don't trust your code to be legal for me to use in the first place.

Harsh maybe, but when it gets right down to it Free Software is built on respecting the copyright of the authors. "Whatever we can get away with without getting sued" is the wrong standard to be applying. "Is this right based on both the letter and spirit of the license" is the standard to apply.

The Drupal Association's position here, as stated in the FAQ and repeated by several people here, was developed on the advise of attorneys at the SFLC. We didn't pay them for the answer we wanted to hear; they gave us the answer they believe is legally correct, as pro bono consultation for a Free Software project. I spent several weeks going back and forth with an attorney there to make sure they were confident in that position.

Drupal.org views and will continue to view a distribution that contains both GPLv2 code and Apache2 code as a violation of one or the other license. The only way to mix GPL code and Apache2 code is by using GPLv3, which was developed specifically with that sort of mixing in mind.

The question at hand is whether or not to move to GPLv3 for that advantage (and various others), not whether or not that advantage exists. That point is not up for debate; please stop dragging that out yet again.

Literally, no research. No

greggles's picture

Literally, no research. No case law, no statute, not even a potential injured party that might have an inkling to file, never mind one with any weighty claim.

That's because there isn't any case law history nor statutes that specifically look at these licenses. It's possible to do research without doing those things.

I've done the only legal research here that I know of, and I say (1) Drupal.org is fine (2) Drupal needs to dump its "lawyers".

So you know it's illegal to give specific legal advice without being a lawyer, right (advice like "it's legally OK to do this style of packaging")? Are you a lawyer? In what state(s) have you passed the bar? Are you willing to give this statement on your own letterhead as a lawyer and sign it and get that signature notarized?

I don't understand your position. You claim the "FSF is...actually pretty good." but then you also claim that their advice to the Drupal Association, after months of meetings, research, and discussions, is flawed to the point of being useless.

Well, a legal opinion is

Acubed's picture

Well, a legal opinion is formed from the existing statute first and existing case law elsewhere, you apply similar parts from similar cases to your cases. Software is treated as nonfiction literary work in copyright law, and as such courts will even cite cases about literary works in their opinions. I have briefly here demonstrated why Wordpress is wrong, that themes are not (necessarily) GPL (the notion that merely invoking another program creates a derivative work is one dangerous to Free Software, and Lewis Galoob Toys specifically strikes this notion down). Admittedly I am aware of no case law that rules on a case where something like a GPLd work may ship with it another FOSS-licensed work, so long as license terms are complied with (and with most FOSS licenses this is extremely easy to satisfy, there's no reason a BSD library would have a problem shipping with Drupal). If anything this supports my position, because a lack of injured parties implies a lack of civil damages -- that is to say, if we can prove a lack of injured parties, we can prove a lack of civil damages.

This is legal research. This is not your research.

I don't have any record that the FSF has advised specific software projects. I don't even have any such record that the SFLC has offered such advice to Drupal projects, Drupal folks have not published the nature of their discussions, all I have is hearsay.

I misspoke when I said the

greggles's picture

I misspoke when I said the FSF had given advice to the Drupal Association. It was the SFLC as mentioned here.

@Acubed - please answer these simple questions:

So you know it's illegal to give specific legal advice without being a lawyer, right (advice like "it's legally OK to do this style of packaging")? Are you a lawyer? In what state(s) have you passed the bar? Are you willing to give this statement on your own letterhead as a lawyer and sign it and get that signature notarized?

"illegal to give specific legal advice"

slef's picture

I think it's only illegal to give specific legal advice for citizens of some particularly stupid countries. As I understand it, there are 1000 legal and advice agencies including Citizens Advice and the Law Centres Federation in England dispensing free or subsidised legal advice. Not all of that is done by lawyers.

So please, don't argue by appeal to authority. It's not convincing.

If you are asking about a

pwolanin's picture

If you are asking about a policy of packaging and hosting distributions on Drupal.org, the infra team and the DA would be the deciding authority I think. It sounds like this is all you actually are concerned about?

For the underlying license for Drupal itself, the deciding authority is (roughly) Dries +/- the contributors to core. Larry's statement above that it could be made somewhat unilaterally is true legally, but I would consider that to be serious poison in the water.

BTW, added a poll

greggles's picture

BTW, added a poll http://groups.drupal.org/node/285098 just to get a sense of what people think.

Thank you for doing this.

redndahead's picture

Thank you for doing this.

+1 for Drupal core goes GPLv3

hswong3i's picture

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

Apache V 2 compatibility is one-way

BCaron's picture

I emailed a member of the Apache Foundation board about gpl V3 and Apache V2. He pointed me to this website:
http://www.apache.org/licenses/GPL-compatibility.html

Bruce Caron is Executive Director of New Media Studio, Inc. and the New Media Research Institute in Santa Barbara: 501(c)3 public charities building informatics for education

Losses

gisle's picture

By going for GPL-3.0-or-later, we cannot distribute the following from Drupal.org:

  • GPL-2.0-only
  • GPL-3.0-only
  • Apache-2.0-only

Some people seems to think that it is OK to distribute GPL-3.0-only as GPL-3.0-or-later. Unfortunately, that is not how strong copyleft works.

Our current license (GPL-2.0-or-later) also puts on some restrictions. We cannot distribute the following from Drupal.org:

  • GPL-2.0-only
  • GPL-3.0-only
  • GPL-3.0-or-later
  • Apache-2.0-only
  • Apache-2.0-and-later

So we gain something in terms of being able to distribute GPL-3.0 and Apache 2.0 licensed code, but lose something in terms of being able to distribute GPL-2.0 licensed code.

However, there is a difference in what the license allows downstream recipients to do:

By going for GPL-3.0-or-later, downstream recipients can use code licensed under:

  • GPL-2.0-or-later
  • GPL-3.0-only
  • GPL-3.0-or-later
  • Apache-2.0-only
  • Apache-2.0-and-later

I.e. they too lose the ability to use code licensed under GPL-2.0-only.

By going for GPL-2.0-or-later, downstream recipients can use code licensed under:

  • GPL-2.0-only
  • GPL-2.0-or-later
  • GPL-3.0-only
  • GPL-3.0-or-later
  • Apache-2.0-only
  • Apache-2.0-and-later

Personally, I want to keep GPL-2.0-only as one of the options.

Legal

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: