Posted by drupalnut-gdo on June 23, 2008 at 2:12am
http://drupal.org/project/wysiwygpro
Is something like that allowed:
A) on drupal's CVS
B) at all?
What about a module that talks to a third party non GPL software
http://drupal.org/project/wysiwygpro
Is something like that allowed:
A) on drupal's CVS
B) at all?
Comments
Please search the issue queue before posting
http://drupal.org/node/220497
Edit -- added after original post If you read the issue, the questions in this specific case arose because of how the integration was executed. Projects like TinyMCE/FCKEditor/Audio all integrate non-GPL code, and have for years.
FunnyMonkey
Tools for Teachers
FunnyMonkey
tinymce/fckeditor/audio
Tinymce: http://wiki.moxiecode.com/index.php/TinyMCE:License (LGPL)
FCKEditor: http://www.fckeditor.net/license - GPL, LGPL and MPL
id3 library (I assume that's what you mean): GPL: http://sourceforge.net/projects/getid3/
So, they are GPL or "GPL compatible." The reason they aren't in drupal.org contrib is because they are readily available elsewhere (see http://drupal.org/node/66113 for details).
That said, I agree, yes that the way it is integrated makes a problem where there could be none (since it is largely javascript/images which are "data" from PHP's perspective).
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation
yeah
I realized I was imprecise shortly after hitting submit --
And I actually thought the getid3 libs were AGPL, but didn't check.
But given the signal/noise ratio in the group recently, I figured it was a relatively small thing ;)
FunnyMonkey
Tools for Teachers
FunnyMonkey
A) It is allowed as long as
A) It is allowed as long as the non-GPL component is excluded. I.e., the user has to go out and download the component separately.
B) Definitely. You can create any module you like; it doesn't even have to be GPL'd -- however, the Licensing FAQ claims that if you distribute it to anyone outside your own organization (this may or may not include a client?), then it must be GPL'd. I obviously disagree with this claim.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Wrong
Please read the FAQ, which says quite explicitly that modules that bridge within PHP code to GPL-incompatible code are not permissable. Please do not continue to spread FUD just because you disagree with the license.
You must be referring to #10
You must be referring to #10 of the FAQ. I don't think the example here of wysiwygpro is what #10 is addressing. Please correct me if I'm wrong , and if so, how is it different from, say FCKeditor, or TinyMCE?
No need for FUD slinging. I was very clear that my disagreement with FAQ #7 is a personal opinion.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Google* modules
None of the Google code (like Analytics) we are linking to - is GPL as I know... this is going to be a strange discussion... i expect every 5-10' module will be in troubles.
Web services
googleanalytics.module is under the GPL. Google Analytics the web service sends its own self-contained Javascript to the client. What's on the other end of that web service on Google's servers is irrelevant, and is not subject to the GPL on Drupal. So Google Analytics, Mollom, Flickr, Akismet, etc. are all fine.
NON-GPL javascript linked into Drupal
googleanalytics.module downloads NON-GPL Javascript on local disc and link this local javascript file "ga.js" into Drupal. This cannot be allowed if all linked javascript needs to be GPL. GA themself is not GPL... it's nitpicking, but it's like nitpicking of linking a PHP function to a drupal function and the FAQ states linked JS code must be GPL.
Interacting
With Javascript, you can have JS running in the same browser window that does not interact with Drupal's Javascript. That is unaffected by the GPL on it, as the FAQ already says. The GA code does not call into Drupal's jQuery code.
That is unaffected by the
This is missing in the FAQ! The FAQ states every JS code in a module or theme must be GPL. This is wrong as you say here, too.
Only JS code that integrate or link with Drupal JS functions like
Drupal.attachBehaviors()orDrupal.t()must be licensed under the GPL. Therefore the FAQ must be corrected and explain that only drupal linked JS code must be licensed under GPL.Other JS code could be proprietary or any other license and is also data like CSS and images are. However I'm really missing what is data per definition. I'm going to get an idea for myself after all this discussions, but it's not clear at all.
Excerpt from question #7
(emphasis added)
Javascript is (almost) always data from the perspective of PHP. From the perspective of other Javascript, it is code. 3rd party downloaded code from Google that you are not in fact distributing any further (remember the GPL kicks in on distribution) is fine. If you're distributing Drupal with some other Javascript library that only "kinda sorta" interacts with Drupal, you'll want to consult a lawyer on your specific case.
Yes, this kind of
Yes, this kind of integration is indeed not allowed and I had to remove the project from drupal.org. Thanks for pointing it out.
Ah, I did not realize that
Ah, I did not realize that this project had been removed from d.o....
Looks like this is recent, as the page was cached by Google on Jun 17, 2008 21:47:11 GMT.
The discussion in the issues queue suggests the concern was pending a decision from the Drupal Association. Is there a record of the association member's votes on this case? I.e., who voted for removal, who voted against?
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
We don't vote on the removal
We don't vote on the removal of individual projects. I am the infrastructure manager of the association and feel that it is within the capacity of my office to do that without a vote on a specific project.
NB: We also didn't vote on the items of the FAQ since they were prepard by a lawyer. Had we thought that we have enough legal experience ourselves, we obviously wouldn't have bothered to ask for legal advice...
Could you please collaborate
Could you please collaborate on situation with SimplePie module?
SimplePie library is under BSD license.
Is that situation permissible for Drupal?
Dr.Upal
http://www.gnu.org/philosophy
http://www.gnu.org/philosophy/bsd.html
Since not all PHP extensions
Since not all PHP extensions and PEAR packages distributed under GPL compatible licenses, I would like to find out what is Drupal position on using those PHP extensions and PEAR packages?
It is could be very important for some developers and companies to make right business decisions.
So, please respond to this straight question.
Dr.Upal
Particularly, when PEAR
Particularly, when PEAR packages are just PHP libraries, i.e. PHP code and NOT compiled *.lib.so
What then?
Dr.Upal
A compiled binary object is
A compiled binary object is as much source as a PHP plain text file. It doesn't matter when it comes to distribution. The copyleft nature of GPL covers distribution of a program regardless of its content. Incompatible libraries and GPL can be used together privately without consequence. However you cannot distribute the result.
I would like to combine
I would like to combine together my last two messages with some clarification.
Could be this info http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs applicable in this case or not?
What is Drupal official position on that?
It is could be very important for some developers and companies to make right business decisions.
So, please respond to this straight question.
Dr.Upal
Re: GPL Incompatible Libraries
Simple answer is: Cannot be added to Drupal contrib modules.
If a license butts heads with GPL then you can use the libraries for personal use only. You cannot redistribute the result.
How about GPL "special exception"?
I have put link to http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs for reason.
Read it please.
"What legal issues come up if I use GPL-incompatible libraries with GPL software?
Both versions of the GPL have an exception to their copyleft, commonly
called the system library exception. If the GPL-incompatible libraries
you want to use meet the criteria for a system library, then you don't
have to do anything special to use them; the requirement to distribute
source code for the whole program does not include those libraries, even
if you distribute a linked executable containing them.
The criteria for what counts as a "system library" vary
between different versions of the GPL. GPLv3 explicitly defines
"System Libraries" in section 1, to exclude it from the
definition of "Corresponding Source." GPLv2 says the following,
near the end of section 3:
If you want your program to link against a library not covered by the
system library exception, you need to provide permission to do that.
Below are two example license notices that you can use to do that; one
for GPLv3, and the other for GPLv2. In either case, you should put this
text in each file to which you are granting this permission.
..."
go to the link and read it further - http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
Dr.Upal
Depends on the license
PEAR is annoyingly weird in that it allows different modules to be licensed differently. Most are under the PHP license. A few are under the LGPL. I think there are some that are under the revised BSD, but I'm not certain of that. There are a lot of PEAR packages. :-)
The PHP license is, unfortunately, not compatible with the GPL. Bridging those packages to Drupal, which must by nature be done in all PHP code, is not permitted. (Or rather, distributing code that does so.)
The LGPL license is completely compatible with the GPL, so bridging to those packages is perfectly fine.
It really does depend on the individual package in question.
Regarding a "FOSS exception", we can't do that. There's nothing wrong with the concept per se, and I know a number of (non-Drupal) developers include such exceptions in their code. However, that is a change in the license that would have to be agreed to by everyone who holds copyright on code in Drupal or contrib. That's... a whole heck of a lot of people. (Well over 1000, many of whom we don't have contact with anymore.) It's simply not practical to do that. Making such an exception on a per-module basis isn't feasible either, since if module A gives you an exception that says "but PHP license is OK, too" but module B doesn't, then the combined work (it is all one big piece) is still not valid as it contains non-excepted GPL code and PHP licensed code.
Okay, finally we are
Okay, finally we are talking.
If developers will include "special exception" notice in module copyright holder header about GPL-incompatible libraries only in this module, then by GPL rules it does not have to apply on entire product, since in this case we have a legal way to create module as a not derivative work of Drupal.
And as far as I can see it is completely GPL legal.
Dr.Upal
Er, no
It doesn't work if just one module provides an exception. Imagine, say, a module that wraps a PEAR library under the PHP license. That module author could, potentially, license his module under "GPL, but linking to PHP license is OK too". However, another module, say, Views, is not. So if you now install this hypothetical module, Drupal, a PEAR library, and Views all together, then you have a site with mixed code that you cannot legally distribute even if you wanted to, because Drupal core and Views do not have that same exception. See where the problem is?
Now, if the PEAR module had a license of "PHP license, but GPL is OK too", then that is, um, doesn't actually make sense. :-) At that point it is effectively dual-licensed under both the PHP license and the GPL. That's perfectly fine as far as Drupal is concerned as then it's just using GPLed code, no problem. However, that would violate PEAR's repository rules, I imagine. (I don't actually know there, as I'm not a PEAR developer.)
Licensing games
Special exception clauses can only be applied to an original work and never a derivative. As has been sited already modules are considered by FSF and by Drupal as a derivative work and can therefore never add a special exception clause to remove affects of licenses set forth. No, this isn't acceptable. The purpose of the GPL is to force closed source to become open and it usually has the more restrictive license forcing others who use GPL libraries to need to use the GPL for its source. Bridging is not an acceptable means of overcoming this restriction. Neither is playing games with special clauses.
BTW, PEAR also include
BTW, PEAR also include Apache license for some packages - http://pear.php.net/manual/en/group.licenses.php
Dr.Upal
You can't expeect us to have
You can't expeect us to have an official opinion on each fringe case of PHP usage. If you want such an opinion you should consult with a lawyer.
Of cause, I'm not expecting
Of cause, I'm not expecting you to have official opinion on each "fringe" case of PHP usage.
But particularly this one is very important since according to your FAQ it is unclear what can be done in this case.
I just thought if somebody in Drupal will consult with your lawyers that will help us - simple Drupal developers around the world.
In fact we are members of this community and it is logical for us to seek a legal advise here on Drupal Legal group.
Don't you think?
Dr.Upal
Yes, responsible answers
Yes, responsible answers should be given in the group named Legal toward legal questions. So, yes, someone with legal authority for Drupal should be able to answer any question with regard to legal use of Drupal if it is posed in this group.
Could somebody point out for
Could somebody point out for me how from legal point of view CiviCRM under AGPL v3 distribution allowed, even if it is using Drupal under GPL v2?
AGPL v3 is not GPL v2 compatible - see http://www.gnu.org/philosophy/license-list.html under "GNU Affero General Public License (AGPL) version 3"
May be somebody can post some links to previous discussion about that?
But I'm looking here for answer not a discussion.
Dr.Upal
Via GPLv3
GPLv2 and the AGPL are not compatible, that is true. However, Drupal is under GPLv2 "or any later version" (as is the majority of GPLv2 software), which means distributing Drupal under GPLv3 is permissible. GPLv3 and AGPLv3 are compatible, as they were written specifically to allow the use of AGPLv3 and GPLv3 code together.
So if you wanted to combine Drupal and CiviCRM and ship the whole thing, you can do that provided that the Drupal bits are licensed under GPLv3, not GPLv2.
So, AGPLv3/GPLv3 it is. Now
So, AGPLv3/GPLv3 it is. Now if developer will do the same thing what CiviCRM does and create HIS program in the way as CiviCRM does, then, according to http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs, developer can in the license notice for HIS program include "special exception" notice.
Is that would be a correct assumption?
Dr.Upal
No.
Drupal would be the one to give the special exception; not the user of Drupal.
Oh, Really? Then you have
Oh, Really? Then you have to sue CiviCRM.
Dr.Upal
My opinion is that CiviCRM
My opinion is that CiviCRM doesn't understand the issue and some legal representatives should take a look.
from http://civicrm.org/node/166 we have
This is not correct according to the GPL FAQ and that FAQ trumps the CiviCRM FAQ.
There are a lot of
There are a lot of misunderstandings around here about the nature of these FAQs.
None of them are licenses. They can't make legal demands on licensees, because they are not incorporated into the license. They merely explain someone's interpretation of the license.
I can ignore the GPL FAQ all day long without fear of reprucussion, as long as I am following the GPL itself. Usually the two are in agreement, but often, the FAQ goes beyond the legal requirements of the GPL itself.
Now, it's true that the licensor's intent is one of many factors to be considered in interpreting a license. Clearly the FSF intends for all software to become free & open. Good for them. But there are other factors also.
I could write a license that is identical to the GPL with one extra provision: "Anyone who uses my software shall become my life-long indentured servant and must immediately report to my plantation for work."
My intent in this provision, is irrelevant, because slavery is illegal in my country. The provision is not enforceable.
Furthermore, the FSF might wish for my intention to be upheld or not, but they have no say in the matter, because they didn't license my software, I did. I just happened to substantially use language they freely provided me.
It has been falsely stated that "Drupal modules are derivative works because the GPL says so." This is an incorrect conclusion, because the GPL does not define what a "derivative work" is. This term is generally defined by the US Copyright Act, and specifically defined by courts when a copyright violation is being contested. (I have no idea if or how the term is defined in other jurisdictions.)
Whether or not a module is a "derivative work" is a legal fact entirely independent of the terms of the GPL.
If a module is not a derivative work of a GPL work, then the GPL can not make any claims on it.
It is my opinion that CiviCRM is not derivative of Drupal (primary evidence being that it can run independently of Drupal), and if that is so, the CiviCRM developers are free to license it however they choose.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
I'm tired of your game.
Please take your assumptions to the FSF and ask them directly. Then report your findings here.