Licensing Requirements for Modules / FAQ #7
What is the basis for the claim of http://drupal.org/licensing/faq#q7 ?
Disclaimer: I am not a lawyer.
Primary fact: Whether or not something is a 'derivative work' is defined by copyright law, not by the license.
From my reading, it seems the question is far from settled in the United States in regards to software. It seems to me that the legal validity of the claim "Drupal modules and themes are a derivative work of Drupal" is suspect.
See, for a example, http://www.rosenlaw.com/lj19.htm for a lawyer's opinion which counters the claims of the Licensing FAQ.
What are other's opinions on this? I've seen many discussions centered around the GPL's FAQs, but what matters is the text of the GPL itself. The only text that speaks to derivative works is:
"a "work based on the Program" means either the Program or any derivative work under copyright law" . I defend my 'Primary fact' with this statement.
Since 'copyright law' is interpreted via court rulings, one question that might bring the issue to a point: Which court ruling can be identified to support the assertion that software modules are derivative works?
Note that I am a proponent of Free Software, and support the decision to require all code in the official repository to be GPL. But I also support individual freedom of developers to release their work under the license of their choice. I think the development of proprietary modules would be a benefit to Drupal, not a harm. I think most developers who do so now would continue to choose to release their work under an OSL. But I also think it would be beneficial to allow alternatives.
This has been discussed many times
See:
http://www.google.com/search?&q=gpl+requirements+site:drupal.org&btnG=Se...
http://www.google.com/search?&q=third+party+code+site:drupal.org&btnG=Se...
http://www.google.com/search?&q=cvs+license+policy+site:drupal.org&btnG=...
http://www.google.com/search?&q=theme+covered+gpl+site:drupal.org&btnG=S...
and, you should definitely read this: http://groups.drupal.org/node/6318
The issue gets raised periodically on the dev list -- I'd say at least twice a year for the last three or four years. I'd recommend re-reading those threads, as the majority of your questions are answered within them.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
I've seen many of these
I've seen many of these discussions. Still, it seems the "official" position, stated in various places is "modules & themes are derivative works." This position is never defended with reference to case law in the United States or anywhere.
Counter to that, this is quite interesting:
"The all-modules-must-be-GPL issue did come up at DrupalCon in Belgium. The majority of people pretty much agreed that whether or not it was "officially" stated, modules did NOT have to be GPL" (Boris Mann - http://drupal.org/node/25768#comment-333369 )
If Drupal is a product of the community, and the community disagrees with the explicit claim in the FAQ, then why is it still there?
What is the process for having the FAQ revised? It's the closest thing we have to an "official' statement.
To me, this is more important than the GPL / LGPL debate. If it could be definitively stated that "Modules and Themes containing only original code are NOT Derivative works," we'd be OK. This is what the CiviCRM project did.
Not a question of desire
What people may wish to be the case is not the point. The FAQ is the result of several weeks worth of work with a licensed attorney specialzing in copyright, specifically Open Source. The FAQ is not subject to revision without the involvement of lawyers, because that's how it was prepared.
Again, this is not "what we want to be the case". This is what the law says, according to the law firm the Drupal Association is working with for precisely that purpose.
Where does the law say this?
Where does the law say this? Lawyers are not judges. That's the core of my original question: show me the documentation.
The lawyer I linked to clearly disagrees with your lawyers. When lawyers disagree, the matter is settled in court.
To strengthen the point that
To strengthen the point that what is primary is not "what (some lawyer thinks) the law says", but rather, the intent of the copyright holder, see the case of CiviCRM:
http://drupal.org/node/48185#comment-92566
They explicitly stated that using the API does not constitute a derivative work. Drupal could do the same.
I also spoke with an SFLC legal assistant via IRC who said that whether or not a module is a "derivative work" would "depend on the details." (To be fair, he was very clear that he had no specific experience with Drupal.) I only bring this up to reinforce that it is NOT a settled question and we DO still need a clear, official resolution to the matter.
The lawyers chosen by the community to do not sit above the community. The community must decide what it wishes to do, and then the lawyers can consult on the best way to accomplish that wish.
I simply doubt that Boris
I simply doubt that Boris did a valid census at that DrupalCon. Also, all people who were there were non-lawyers, so there opinion doesn't really matter much. The license (and by extension its implications) were already chosen at that time by Dries. If the people would have disagreed with his choice they'd probably have written their own CMS under another license.
For me as a Drupal implementor it is very important to have a clear cut legal position on Drupal's licensing.
"For me as a Drupal
"For me as a Drupal implementor it is very important to have a clear cut legal position on Drupal's licensing."
I agree. That's the point of raising this question.
As to who's opinion matters, in truth, the copyright holder's matters most, regardless of whether or not they practice law.
Who does Dries plan to sue? There are several proprietary modules out there that I've found. I just created one in this thread...
Thanks for the clarification below...
Ok cool. I think I understand now what you're saying here.
As someone who holds copyright on a fairly substantial portion of Drupal's code, I completely disagree that our policy should be revised to state that modules and themes aren't derivative works, and agree 100% with the conclusion drawn in the FAQ. For a few reasons:
It's dead simple for a dummy non-lawyer like me. Because all modules and themes must be GPL-licensed, that means I can mix and match them and redistribute them to clients, to friends, and to fellow community members without worry that I'm accidentally doing something illegal.
Drupal modules and themes directly integrate with Drupal core. That's the entire point of hooks. This is a no-brainer, and to pretend otherwise is pretty silly, imo. The situations talked about at the rosenlaw article don't sway me in the least; this isn't the case of include 'adodb.inc' and calling its query functions in some program you've written, this is a case of providing metadata and execution code specifically so that it will modify the way that Drupal behaves, or outputs its data.
This isn't a CiviCRM situation where someone like Dries can decide on a whim that he wants to change the restrictions of the GPL. He needs the agreement of all the copyright holders that wrote Drupal -- which is several thousand people -- to add a clause to make this possible.
I'm an open source hippie, and a GPL purist. ;) The fact that Drupal uses the GPL was one of the reasons I chose to contribute code to it in the first place -- so my work would be protected as open source throughout eternity. If I had ideological problems with the GPL, I would've written my own CMS or used something BSD-licensed or whatever. And there are many other Drupal copyright holders like me out there.
There's no such thing as writing "original" code that implements Drupal hooks. The argument that you could write some PHP framework independently that just "happened" to have a "drupal_set_message" function that somehow accepted the same parameters and performed the same action doesn't hold any sort of water with me, and I'm quite sure wouldn't stand up in court either. Let's be serious here.
I see no reason to
I see no reason to encourage ignorance. And Dummy or not, I would rather be able to create and sell modules to clients, friends, and fellow community members as I see fit without fear that you might sue me. Remember, it's not a question of doing something 'accidentally illegal.' It's a question of doing something 'infringing.' The police aren't going to come and take me away for not licensing my module under GPL. You or another copyright holder will have to sue me if you want me to change my software license. And if I distribute a proprietary module, you will have to acknowledge that it is proprietary when you install it. No accidents possible.
I think you've got it backward. Drupal comes and asks for my hook. I'm not directly integrating with Core. I'm providing functions that Drupal can choose to use or not. A hook implementation is my API. it just so happens that all Drupal modules use a shared API structure. But the point of the Rosenlaw article is that the technical means of integration is not important.
Actually, CiviCRM also has distributed copyright. http://civicrm.org/licensing
I'm also very happy that Drupal uses GPL. I am not happy if Drupal contributors sue me because they think my code should be GPL too.
In order for a program that acted on a Drupal Module to be useful, if would not need to accept the same parameters and perform the same actions. I'm not necessarily talking about another CMS; but what's to stop someone from writing a bridge module that allowed some Drupal modules to work in Joomla, or an exisiting proprietary CMS, for example? Or imagine if I had written code-style.pl (I didn't) or a program like it. What if I created a stand-alone training program that provided tutorials for using various modules? I'm simply making the point that a Drupal module is valid PHP code in it's own right; it doesn't necessarily need Drupal to be valuable. To use the CiviCRM example again, it is a Drupal module, but it also works with Joomla, and now without any CMS at all.
So I'll ask you directly, webchick (with the utmost respect, and gratitude for your contributions): As a copyrightholder, Why do you feel the need to reserve the right to sue people who make proprietary modules? Why won't you, personally, disclaim this opportunity? Or perhaps we could start a 'manifesto of non-interference' among Drupal developers and you could be the first to sign it.
(PS - I have also contributed code to Drupal core, but my few contributions are so small that I don't think I'd qualify for a copyright stake. If I do, I promise not to sue anyone.)
As a copyrightholder, Why
I've actually had my GPLed code stolen and closed-source before. It was just a dorky little PHP text-to-binary script I wrote back in high school, and I never pursued any kind of legal action against the firm who did it. But no, I'm not real keen on giving up my right to pursue legal action if I should so choose, even if the probability of ever exercising such action is extremely remote.
From what I'm reading, the only compelling reason to do so is so that developers who don't want to "keep with the spirit of the open source development model," to use Acquia's wording, can make money off Drupal. I don't see why this is necessary. Lots of people in the Drupal ecosystem are making lots and lots of money, including myself, and are benefiting from the open source development model by participating within it, not by trying to work around it. This is a good and wonderful thing, and is indeed one of the main things that makes Drupal such a strong platform to build from.
Also, CiviCRM doesn't do distributed copyright in the same way that Drupal does. Note the clause:
In this way, CiviCRM holds the ultimate say in how the resulting code is licensed, and can add clauses such as the one you propose. The Drupal Association has no such clause to license peoples' copyright over their works to the Drupal Association. And to do so, we would need to get agreement from all of the thousands of copyright holders. So we're going with stock GPL, which states that programs that share the same memory space and can call each others' functions directly are "derived works." And personally, I'm quite comfortable with that interpretation.
But it sounds like it's worth proposing some follow-up questions for James, to further articulate why Drupal's situation is different from CiviCRM's situation, as well as whether or not we should go for the more "loose" wording in Joomla's legal FAQ.
I've actually had my GPLed
This is impossible. As long as you have a copy of your own code, no one can stop you from distributing it as open source, and no one can force you to use a difference license. (Ironically, this discussions is really about you trying to force me to use a particular license for my work.)
The whole point of the GPL is to protect user's freedom to do what they like with free software, as long as they keep it free. I want to keep Drupal free, and I want to keep Drupal module developers free to do what they wish. You violate the spirit of the GPL through your definition of 'derivative works' by insisting on your right to sue me. Please don't misunderstand: I don't want to create a non-free version of Drupal or any existing modules. I only want people to be able to create proprietary tools that work with Drupal. I want more Freedom, you want less.
Respectfully, you seem to be very confused about the difference between 'copyright' and 'licensing.' CiviCRM DOES have distributed copyright, because many people hold copyright over various portions of the project. Licensing a work does not necessarily transfer any copyright.
I think this is a good course of action. Thanks.
My terminology might be off...
Like I said, I'm a legal dummy. :)
When I refer to my code being "stolen," what they did was take a copy of my script that had /exactly/ the same output (and the same bugs ;)), put it on their website, and charged people money to get a copy of its source, distributed under a license that said they were the copyright holders and no one could modify the code. I asked that they make a copy of the source code available to me, as the original copyright holder, and in order to honour the terms of the GPL, and they refused. This felt like "stealing" to me, but there might be another word for it, like "license violation" or "being a complete jerk." ;)
And when I refer to CiviCRM copyright/licensing, what I'm meaning to say (please correct whatever terms) is that CiviCRM added a specific clause in their version of the GPL so that sub-modules weren't considered derivative works. The Drupal project cannot do the same thing without getting permission from all of the people who've contributed substantial parts of Drupal, so it needs to go with the default GPL interpretation which is that yes, they are.
And very true, GPL is well-known for being less "free" than other licenses such as BSD, which place absolutely no restrictions on what can be done with derivative works. The rationale behind the GPL's "viral" nature is that in order to ensure freedom, you need rules in place in order to protect it.
Drupal modules being considered derivative works isn't just my personal view on things, it's also the conclusion reached by the SFLC, and, apparently Acquia's lawyers as well. I just happen to agree with it.
the default GPL
I disagree that this is the 'default intepretation.' This happens to be how the Drupal Licensing FAQ has chosen to interpret it. Joomla says, "It usually means this, but we grant there may be exceptions, and we won't try to enforce it anyway."
Based on http://civicrm.org/licensing , it seems this is not true. CiviCRM is distributed under an unmodified version of of the AGPL v3. (Since the GPL licenses are (c) FSF, you're not actually allowed to modify them, as stated in the header copyright notice of each one.)
So CiviCRM has a similar, but lessor problem. Since any contributor of substantial code must license it to CiviCRM LLC under the Academic Free License, an individual contributor can not prevent me from distributing a derivative work under any license I choose. However, since CiviCRM then sub-licenses via GPL, CiviCRM LLC could make a claim on my derivative work. However, they state in their Licensing FAQ (also prepared by SFLC) that programs which interact with CiviCRM via API are NOT required to be GPL, thereby disclaiming, in my non-professional opinion, any right to 'Derivative Work' claims.
The full recipe is: Distributed Copyright + AFL contribution licensing + GPL Project licensing + Project 'Derivative Works' disclaimer = Freedom for Developers.
It seems that if the Drupal Module Hooks system can be considered an "API," then SFLC has no problem stating that a Module is not required to be GPL. The same could be said for the PHPTemplate engine, and database abstraction layer, etc. If they're all APIs, then modules are not derivative works, according to SFLC's opinion, as understood from the CiviCRM Licensing FAQ.
I began the manifesto because I suspected this might be the case. All contributors who wish to disclaim 'derivate work' rights may freely do so. If the statement above is indeed true, then we have identified the core problem that should be addressed with legal counsel.
I wouldn't be surprised if we could resolve this is the same way the class action lawsuits are done: a public notice that 'you have XX days to file your objection, otherwise, you are assumed to be a part of the class for which this decision will be binding.'
API?
Yes, hooks are an API. Which SFLC attorney have you spoken to that claims that an API that shares data structures in memory is exempted from the requirements of the GPL, despite the LGPL existing precisely to allow that sort of mixing because the GPL does not make any such exemption "because it's an API"?
This seems to be the opinion
This seems to be the opinion of whichever SFLC attorney prepared the CiviCRM Licensing FAQ, which states:
http://civicrm.org/node/166
...unless this is a difference between the GPL, and the AGPL. (I don't think it is, but I have not studied the AGPL really at all.)
Also, the SFLC legal assistant that I spoke to believed that whether or not a module constitutes a "Derivative Work" would depend on the individual case. We did not differentiate between "API" or any other kind of modular interaction.
SFLC
We went back and forth a few times with our attorney at the Software Freedom Law Center to be sure on that point. A Drupal module has no actual use outside of Drupal. And if you install a non-GPL-compatible Drupal module together with a GPLed Drupal and GPLed Drupal modules, you now have a Drupal that you're not allowed to distribute even if you wanted to. Whether it would be beneficial or not to allow proprietary modules is irrelevant; they're not allowed. Commercial development of modules, however, is allowed, encouraged, and quite profitable.
That said, I personally do not think it would be at all beneficial to encourage modules that cannot be mixed-and-matched ad infinitim. The very strength of Drupal is that you can mix and match and plug pieces together without worrying about the legality of inserting slot A into tab B. Balkanizing Drupal, and making parts of it pay-to-play, would be disastrous.
Module wrapper
"A Drupal module has no actual use outside of Drupal."
Aboslutely false, as has been discussed, for example: http://drupal.org/node/25768
In brief, I could easily write an app from scratch that implements functions with the same names as every function in Drupal Core (though, in a pinch, most of these would not be very useful functions.) My App could 'execute' my module, and Drupal can execute the module. It's use might be somewhat different, but you can't say that a module requires the presence of Drupal to be a 'work' in the legal sense.
"The very strength of Drupal is that you can mix and match and plug pieces together without worrying about the legality of inserting slot A into tab B."
Most people don't worry about it anyway, regardless of licensing. Remember, copyright law is only effective in so far as the copyright holder chooses to enforce it. In the case of PHP, anyone who wants to protect a proprietary module is going to have to encrypt the code somehow. So it's not like someone is going to be able to 'accidentally' install & run a proprietary module, as you seem to suggest.
It is a benefit to the marketplace to have both open source and proprietary products competing. Ubuntu probably wouldn't be nearly as good as it is if it hadn't learned from the work of Microsoft and Apple in Desktop OS design.
Boris argument that he could
Boris argument that he could create a system that would act like Drupal and not be Drupal is probably correct. However, it would gain him little since he couldn't use GPLed Drupal modules with this system. Unless of course he'd shoce also the GPL. In that case we are back at step 1.
"he couldn't use GPLed
"he couldn't use GPLed Drupal modules with this system"
I might be mistaken on this point, but my understanding is that he could. Isn't the point of the GPL that GPL'd code can be used by anyone anyway they want? The GPL only restricts how code can be distributed, not how it can be used.
Yes, that's ludicrous --
Yes, that's ludicrous -- systems under a more free license than the GPL can use and hook into GPL'd software. It's the other way around where things get screwy.
Linux is a GPL'd operating system. Yet commercial (proprietary) Linux applications exist -- applications that can do nothing without the operating system -- as do applications under more free licenses. Hopefully the parallels between Drupal and its modules are obvious on this point…
Different license...
From If I port my program to GNU/Linux, does that mean I have to release it as Free Software under the GPL or some other Free Software license?:
The following code is
The following code is protected under United States Copyright Law. All rights reserved. It may not be used, installed, modified, distributed, or printed on recycled paper without the express permission of the author. This Code is NOT licensed under the GPL or any Free or Open Source License.
proprietary.info
name = proprietaryproprietary.module
<?phpdrupal_set_message ("More modules would be great! I'd even pay for a really good one!");
?>
my_very_own_code.php
<?phpfunction drupal_set_message($s) {
print $s;
}
include('proprietary.module');
?>
Who's gonna sue me?
If you were in the EU and
If you were in the EU and your code would actually be copyrightable (it doesn't cross the threshold of originality), I'd stronly consider it.
Trolling
Well first of all I suspect the above code is too trivial to be copyrightable. Secondly, you're now just trolling, which is not at all beneficial to anyone.
The goal here is to ensure that the community is able to work together, both technically and legally. The terms of the legal agreement are the GPL, as they have been since day 1. There is nothing new here other than actually publicizing the implications of that, which most people are genuinely ignorant of (both open source developers and open source users). If someone's misconceptions don't match up with what the actual implications are, that is their loss. The goal of the FAQ is to help disspell those misconceptions.
As for the "show me the court case!" argument, that is old. Show me yours, where it's ruled by a court that code that comingles with GPLed code is unaffected by the GPL. I'll bet you can't. Until you can, we will operate under the advise of actual lawyers who specialize in this area.
Not trolling, only
Not trolling, only demonstrating the point previously made. (Though obviously a bit tongue-in-cheek)
"Until you can, we will operate under the advise of actual lawyers who specialize in this area."
http://groups.drupal.org/node/12624#comment-40517
shows that the lawyers are not even in agreement on this.
I believe the most relevant case law is:
Computer Associates Intl., Inc. v. Altai, Inc., 982 F.2d 693 (2nd Cir. 1992).
In this decision, the Second Circuit Court set out a method for identifying derivative works of software, which has been adopted also by the Fifth, Tenth, and Eleventh Circuits:
So, the next step is for this model to be applied to a Drupal module specifically by a court.
Hence, the question, which module developer will Dries sue first? I'd like to know if it will be inside my Circuit's jurisdiction. :-)
You can accuse me of being inflammatory, but 'trolling' is just unfair. :-) I really do want an answer to this question.
(PS - If Dries happens to read this, I think you're awesome. No harm intended. I'm not trying to paint a picture of wild lawsuits being unleashed on the community. I don't expect that. I'm using hyperbole to make a point. But please, jump in, your opinion matters!)
Could you ask a straight-up question, please?
matt2000, most of your replies in this thread seem to contain a lot of hyperbole, speculation, and deliberate wording of language intended to get a rise out of people. While that's fun and all, if you instead asked one or more specific questions, we could actually take them to our lawyer and see what he says, and then clarify the responses in the FAQ.
Help us out, here.
If I had to guess, it sounds like the "meat" of what you're asking is:
"Can I write a Drupal module and dual-license it under some proprietary license, as the copyright holder of the code?"
Is that it? Or something else?
The FAQ already answers that
The FAQ already answers that question.
The answer given is, "All Drupal Modules must be GPL."
My direct question is: "Why?"
Again, please be *specific*
James from SFLC is helping us out by providing the Drupal Association with legal advice on these matters, and he also helps out a bunch of other open source projects. So we need to be respectful of his time, and only bug him to ask him well-thought-out, to-the-point questions that are able to be answered promptly.
Can you please condense your concerns/research into some sort of paragraph, and then state the specific questions you want to know based on that? The more clear it is what exactly you're trying to suss out, the better the answers will be. "Why?" is already answered in the FAQ. Obviously it's not to your satisfaction. So please help us determine what specific aspects of the answer are missing, so that we can come to James with something he can act on.
I think the policy should
I think the policy should be:
"Developers may release themes and modules for Drupal under any license they may choose. Themes and Modules are NOT considered derivative works."
(However, themes and modules released via Drupal Community CVS must be GPL licensed. (Dual licensing is, of course, permitted.)
So I guess the question for the lawyer is:
"Can we have this policy and still license Drupal under the GPL ?"
(The answer is, Yes, but if you must ask the lawyer, go ahead.)
Thinking more, the question
Thinking more, the question is, can we ENFORCE this suggested policy. because Drupal has distributed copyright.
e.g., Dries may not consider Modules to be derivative works, but if John Doe comes along who wrote drupal_count_modules_backward(), can he claim that my module is a derivative work, and therefore sue me?
So the bigger need might be to abandon distributed copyright, and require contributors to assign their copyright to the Drupal Association.
So the question for the lawyer is:
"How do we make sure that contributors who may participate in the distributed copyright of Drupal do not claim that some module is a derivative work?"
Note that I am only talking about modules with 100% original code. Obviously if I copy & paste copyrightable code from another module, I am creating a derivative work.
This proposed policy of
This proposed policy of yours has been the policy of Mambo for years (and probably still is). After the split from Mambo the Joomla! guys finally saw the errors of their ways and introduced a policy that is similar to the one covered by the FAQ.
Joomla has two important
Joomla has two important differences.
http://civic.joomla.org/index.php?view=article&catid=42%3Alicenses&id=55...
This makes it clear that the matter of derivative works is NOT settled, and open to the interpretation of the courts in a given jurisdiction. This is more honest than the Drupal Licensing FAQ, in my opinion.
This means that the Joomla Community will not attempt to sue someone who differs with them on their stated opinion about derivative works.
So if you like the Joomla approach, I'll give my support to that.
I think Joomla!'s stance is
I think Joomla!'s stance is a bit problematic. It sort of encourages people to violate the license.
Also, your interpretation of
as
is wrong.
They are saying that they can't go after everyone but they don't rule out to go after individual license infringers. They need to, why would they havea license at all if not seeing suing someboy to adhere to it as a possibility?
My other question is: "Can
My other question is: "Can we please change the FAQ?"
This is not permitted,
This is not permitted [1], according to the FAQ. Is that really what the community wants? I think Khalid's approach is an excellent model. Too bad he risks being sued by SFLC for trying so hard to find a way to give at least some of his work back to the community. (Flame on!)
[1] http://drupal.org/node/25412
well..
Khalid's approach sounds a lot to me like:
http://drupal.org/licensing/faq#q8
Right?
Not the way I understand his method
Not the way I understand his method:
"This way, everyone wins: the community gets a base to build on, I get to sell it to others AND release a version under the GPL,"
I think this means that the version he sells to others is the enhanced version, and the GPL version is a different, limited version. Since selling is distribution, the enhanced version must also be GPL, if it is considered a derivative work.
If he only gives the original client the enhanced version, and the version he sells separately IS the GPL version, then he is OK, I believe. This alternate instance is better understood in GPLv3, where the term 'distribute' is clarified by the concepts of 'propagate' and 'convey.'
Somehow all your references
Somehow all your references o to old articles from 2005...
I'd check with Khalid if he still does his business in a similar way.
Also, what he does is not neccessariy against the license. It is covered by the license /if/ he distributes his work under the GPL to all people who receive a copy.
Of course, then these people might just distribute the code to third parties (also under GPL) but they may chose not to do so.
Newer discussions
My references are to the most relevant discussions I could find by searching or as referenced by Bill in the first response.
Can you point me to something more recent that would shed new light on the discussion?
Many existing discussion are not relevant to my concerns, because I do NOT object to Drupal being licensed as GPL or requiring CVS code to be licensed as GPL. I don't even care if Drupal moves to LGPL. My only objection is the assertion by the FAQ and some community members that all Drupal modules and themes are inherently and automatically and without exception considered 'derivative works' of Drupal.
In short, I object to anything that allows you to claim copyright on my work. Why should this be so controversial?
There have been several
There have been several similar discussions over the years. There was usually a thread starter who didn't agree that Drupal modules need to be GPLed. Then there would be people like me who said "they have to". Then there was support from various people for on or the other side. The discussion then petered out or turned into a flamewar. There isn't really much to be learned from them, here is one:
http://drupal.org/node/30708
Why we want Acquia to make proprietary modules
Acquia should be on my side of this, and everyone who sells Drupal services should want them to be.
Here's why:
Acquia claims to be a 'product' company, not a service company, so they will not compete with existing Drupal service consultants like myself.
If all of Acquia's products are GPL'd, then it will take about an hour for someone to release an unbranded copy of their distribution. Karbon, anyone? Think of CentOS and RedHat.
The difference is, RedHat is a service company. CentOS may have hurt them, but it certainly won't put them out of business.
If Acquia cannot protect it's product, it will be forced to become a service company too, and it's 7 million dollars of capital will be plenty to push smaller Drupal service providers out of the market.
I'm speculating here, of course. I'm sure somene at Acquia has thought through these things and discussed them with Dries. I'd love to hear their thoughts on the issue.
Drupal code will be freely licensed under the GPL license
http://acquia.com/about-us/newsroom/press-releases/acquia-unveils-roadma...
"In keeping with the spirit of the open source development model, all Acquia-developed Drupal code will be freely licensed under the GPL v2 license and the company will work continuously to merge new features and patches into the main line Drupal project through the established community process."
I've asked my colleagues, particularly Jay who is a lawyer to review this thread and see if we need to clarify.
Cheers,
Kieran
Drupal community adventure guide, Acquia Inc.
Drupal events, Drupal.org redesign
Hmm -- not going to render an "opinion" here
Dries and I have spoken at length about this, since he's been quite involved with the SFLC. And based on Dries' interactions with them, Acquia's position is as Kieran has stated above: We're treating Drupal modules - including those that we develop from scratch - as covered by GPLv2, and thus we (who are "distributing" Drupal, which triggers GPL) are treating them as open, GPLv2 things.
I have several other comments.
As it regards Drupal, I'm pretty confident that a module is a derivative work. However, case law would suggest that the following might not be a derivative work. Consider the case where a company wants to build an application for skyscraper building management to monitor, control, and manage all the power, plumbing, and telecommunications systems in a 150 story tall building. They start by taking Drupal core (only) in it's off-the-shelf form, ran it through the Zend optimizer to produce a "binary" Drupal (NB: I don't know if this is technically possible...). Then they develop so many custom modules that the code count for the custom work is 90% of the total lines of code. Assume also that they develop so many other ancillary web services that they provide over the internet that the completed application is basically non-functional without those services - e.g. the "Drupal parts" of the application are so constrained that you don't hardly even see them. (Such services might include North American power grid load monitoring, telecom least-cost-call-routing services, in-building sensor monitor inputs, etc.) Post-development, it barely looks or functions like a typical Drupal site.
Is this a derivative work, or a new work that included a binary copy of a (Drupal) library? This would be a fascinating case to adjudicate. Larry R. would probably assert it is not. Stallman would probably assert it is.
The point of this point is that we are all making assumptions about what constitutes a derivative work. The closer you are to "just adding a bit of functionality using a new module" to Drupal, the higher the likelihood that the module is derivative, and covered by GPLv2. If, at the other extreme, you create a separate binary which provides new functionality to Drupal through an HTTP interface (vs. RPC/IPC) - whether on the same host as the Drupal site or not - this would tend to suggest your binary is not a derivative work, especially if any application - Drupal or not - can use that interface (a'la how Mollom works with Drupal.) So if you care a lot, you might look into building generally-useful web services the way Dries has.
This has been the most
This has been the most useful analysis of the question so far. Thank you, Jay.
On a side note, how does Acquia plan to deal with "the CentOS strategy" ? If you end up selling support subscriptions, then aren't you a service company, not a product company? Or is your "technical assistance center" merely an automated system, i.e., video tutorials, and such? I suppose that might be a valuable product.
Covered in the FAQ.
Jay's description above in 2a is correct, according to our conversations with the SFLC. The PHP code of a theme is "code" that comingles with Drupal code, and therefore is subject to the terms of the GPL as a derivative work. The Images in the theme are "data" and therefore are not. That is all covered in the FAQ. (If the images are checked into CVS, however, then they too must be released under the GPL.)
Regarding 2b, as far as Drupal's PHP code is concerned, yes, Javascript is data and therefore not affected by the GPL on the PHP code. However, if it makes use of Drupal's Javascript (jquery.js, drupal.js, etc.) then it is comingling with GPLed code and therefore is subject to the GPL if distributed. (Note: "comingling" is not a legal term, I grant. The legal definition given in the GPL involves in-memory interaction and such.) For the really tricky edge cases there, you should seek your own attorney for your case (or just GPL anything you write since that's sure to be safe :-) ).
Regarding Jay's hypothetical power grid monitoring system, whether a GPLed work is source or binary is irrelevant to whether something constitutes a "combined work", AFAIK. Drupal being used as "just a library" would matter if it were under the LGPL, but it's not; it's under the GPL.
Web services are not affected by the GPL, so Mollom, Akismet, etc. are perfectly fine.
well thought out
Jay,
Thanks for taking the time to write up such a detailed post with good examples. For me, at least, the key take away from your post was that the law doesn't have full clarity in this area so we (members of OSS) have to proceed with caution, run with the best advice we have, as well as our gut feeling.
-Jacob Redding
Hello,
Hello, matt2000@drupal.org,
When I first saw (and responded) to your post, I made the assumption that you had not read the voluminous past discussions on this topic, which read remarkably like this one.
In reading this thread, it seems like your main objection is that you want a different model.
And this is fine, and you are free to want whatever you want, but your desire does not trump one basic, unavoidable, beautiful fact:
The current FAQ is the result of years of thought and effort by caring, talented, and motivated people. You can disagree with it, but your disagreement does not require any of us to agree with your interpretation. Yes, the FAQ can and should be a living document that changes as the situation warrants, but I have seen nothing particularly new in this thread that requires a change.
I apologize if I am overlooking something, but a specific question grounded in a specific, non-hypothetical situation would go a long way toward helping me understand your point of view.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
A half dozen non-hypotheticals
My reference to Khalid's post was intended to be a specific, non-hypothetical situation.
My references to US case law are specific, non-hypothetical situations in which a court used a documented process to determine if a piece of software was a derivative work. I would like to see someone with authority to change policy evaluate an original Drupal module (i.e., no non-Core dependencies, no copy & pasted functions) using this process.
My references to CiviCRM are specific and non-hypothetical. This represents a working, ideal solution.
The more recent references to Joomla are non-hypothetical. This represents a better, though non-ideal solution.
My recently posted manifesto is a specific, non-hypothetical, non-inflammatory, non-trolling, totally serious attempt to bring about a grassroots solution. If every developer signs it, the issue will be moot. http://groups.drupal.org/node/12631
Finally, a specific, non-hypothetical question:
Bill, why do you, personally, feel the need to reserve the right to sue a fellow Drupal developer for making use of your freely distributed contributions?
A bit much
Hello, Matt,
When I worked as a bartender, I never needed to sign a waiver/mainifesto stating that I wouldn't sue other bartenders.
When I worked as a teacher, I never needed to sign a waiver/mainifesto stating that I wouldn't sue other teachers.
When I worked as a tech director, I never needed to sign a waiver/mainifesto stating that I wouldn't sue other tech directors.
Now that I'm working as an open source developer, the same rules apply. The Drupal community is a great place to be. If you are worried about a lawsuit, my first piece of advice would be to examine the action that is triggering your concerns.
I'm not worried about a lawsuit. I don't share your immediate concerns -- sorry, but after working in this community for a while I don't share your conclusions or your worries.
RE your offer to integrate the module script, thank you. We'll look at the script, and go from there -- either by contacting you through your contact form, or responding directly on the thread. It looks like a useful piece of code.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
I think you are painting a
I think you are painting a picture more in line with Joomla's statements on the issue.
Bartenders don't create a work of IP in their activities (ok, maybe drink recipes?). Teachers & Tech Directors might do so, but I've never heard a teacher say 'if you create a poster to hang outside my classroom that might further educate my students, it is a Derivate Work of my efforts and I have copyright interest in it." (Not a perfect analogy, but you get the point.) The Drupal Licensing FAQ explicitly says this. That's the difference.
PS
PS - Bill, I studied your DrupalEd Distribution Profile when creating my scripts for Downloading modules during profile installation. Thank you for your contribution. If you'd like any help adding my script to you next release, please let me know. I'd be glad to participate.
cf: http://groups.drupal.org/distributions
Derivative work
I'd also like to know what in all details means "derivative work" about themes and how we are able to circumvent them on the end of the day. however some people don't like this thinking it could be the only way to be save from law side. Another question is how we can circumvent this licensing burden - for example by writing wrappers/interfaces to abstract other parts from Drupal dependencies.
I'm thinking about adding a wrapper file that includes own work and calls private functions if a hook is called. This way I would be able to distribute a wrapper script under GPL and the rest under a CC license. Additional it would allow me be add more wrappers for other CMS's like Joomla or my own CMS calling a PHP function that could be named in a drupal schema.
Questions:
1. Would a wrapper script solve the licensing issue?
2. Would a documentation that writes all the code down as "examples" - allows me to distribute a build-your-proprietary-module-per documentation snippets solve this derivative work licensing issue?
3. Why must a PHP function that is named in a specific way - a derivative work of Drupal? Maybe I'd like the drupal way and like to participate on logics and idea's but not on code.
4. Could I solve this issue by writing a "name" on my code and tell users "this module is compatible with Drupal, but will also work in other CMS that would implement the specific hooks" !?
You demonstrate the point exactly.
These things all point, in my opinion, to the absurdity of the claim "all modules are derivative works." There are so many ways to enhance/extend/improve/modify a Drupal-based system that get around the GPL. It's a waste of time to try to defend the idea that 'all modules must be GPL.'
Crell has also just answered your question with another way to circumvent:
So, you just never write a Drupal "module" again. Instead, you write a Drupal "web service." This is now very easy to do, thanks to Services module. You could probably even define a 'Raw PHP server' for Services that would have little or no significant impact on performance.
Do it like Dries: write a "service." (Preferably using RDF, per Drupalcon Boston.) Modules are for GPL hippies.
All in good fun (and serious inquiry), with respect to all hippies present. :-)
"Get around?"
Matt, I'm going to be as honest and polite as I can about this. If your entire goal is to "get around the GPL", then you're using the wrong CMS and the wrong license. This group is not here for the purpose of finding ways around the GPL, which was chosen as the license for Drupal for a reason. If you are not comfortable with the requirements of the GPL, then don't use/develop for GPLed projects. It's that simple.
To the grandparent, no, a wrapper module that operates still in PHP space does not "get around" the GPL. That was covered in the FAQ. It doesn't matter how many layers of indirection you add within the program. You would have to physically separate the two programs into completely different memory spaces (like on separate computers) and call between them using a wire format (which could include the Unix shell). However, at that point even if you are able to "get around" the letter of the GPL (which may or may not be the case; you'd need to consult an attorney for your specific architecture) you are still unquestionably violating the spirit of it.
Sorry to be unclear.The
Sorry to be unclear.
The previous commenter used the terminology of 'circumventing the GPL.' I was simply answering his question.
I do not wish to "get around the GPL" as it concerns Drupal, or any other project, for that matter. I want Drupal to be GPL, and if I release a modified version of Drupal it will be GPL.
If I want to "get around" anything, it is the FAQ's assertion that "all modules are derivative works", which actually has nothing to do with the GPL directly. "Derivative work" is a concept independent of any licensing. The GPL is simply one way for a person to be granted permission to create a Derivative Work. The GPL says explicitly that whether or not something is a Derivative Work is defined "under copyright law" which is, to restate the primary point of this discussion, jurisdictional and widely ambiguous.
Because of this fact, which has been confirmed by Jay, an attorney at Acquia, I believe it is wrong for the FAQ to state unequivocally that all modules and themes are "Derivative Works." This statement is an opinion that is extraneous to the GPL. (Remember my primary fact from the original post? "Whether or not something is a 'derivative work' is defined by copyright law, not by the license.")
The above paragraph is my thesis; nothing more, nothing less. Long live the GPL, peace be upon it, etc, etc.
unequivocally, is too far
The way that I read Jay's post is that the law isn't clear. Some activists, lawyers, judges might state that they are indeed derivative works while others would say that they are not. The only way to get full clarity on this is to take it to court and not just once but multiple, multiple times. Jay's example used two extremes and didn't come to a conclusion rather he stated what might be the conclusion of those on nearly opposing poles (i.e. Larry R, Richard Stallman).
I understand that you believe that it is wrong for the FAQ to state that all modules and themes are derivative works but the FAQ is a work of many people and has been consulted and vetted by lawyers that are familiar with the appropriate laws as well as relevant court cases. The Drupal community (through the Association) has done it best to choose the right licenses and framework that protects and fosters the Drupal community. If it does not fulfill that mission then it should be modified. In order for it to be modified, however, there would need to be consensus from the community that this clause is harmful as well as more lawyers reviewing this clause and they would probably have to be different lawyers as this FAQ is a result of a lawyers opinion.
Lastly let just be clean and fair here. Jay took the time to respond to the post with a non-legal opinion and adequately disclaimed that he is not providing legal advice. Please be respectful to him and his career in the future by referring to him as a person and not as a lawyer. Your post above could falsely give off the impression that Jay rendered legal advice when he in fact did not.
-Jacob Redding
Apology to Jay
I apologize to Jay if he felt that my referring to him as a 'lawyer' was in anyway harmful or misleading. I think he is a wonderful person, and I am very grateful for his unofficial, non-legal contribution to this discussion.
CC license
@Crell: It's not that I'm not respecting the GPL Drupal is licensed under.
My issue is - if I cannot provide a GPL license - as I don't have the rights to do so. For example my theme hardly depends on a CC license of someone else. So I cannot provide more rights I have. In this case I cannot integrate the great work of someone else who provides his work under a CC license.
This is why I need to find a way around this license! I don't understand well how it is possible to a PHP function named in a specific way must be derivative of Drupal. I could give my child a different name and write down that "it's compatible with Drupal". A drupal "hook" is nothing more than a PHP function, named in a Drupal way. Aside it doesn't contain the word Drupal... it's "mytheme_*" - how can this ever a derivative work of Drupal. This way your are able to tell every piece of software that implements a named function that sounds like a Drupal hook is derivative work of Drupal.
If the original author is
If the original author is not willing to let you use his code under GPL you can indeed not integrate it with Drupal (or IMO with any other GPLed project).
Also, the whole argument is based that all the PHP functions share a common memory space, so in order to have a work you can distribute under the GPL all your scripts need to be GPLed.
The functions only share a
The original author don't like to get his work cluttered... that's all as I know.
The functions only share a common memory space if the user who installs the module implement this... if I provide a CC licensed theme with PHP functions the user is able to use the theme in Drupal or any other software he likes. He must only find a way to call the PHP functions in the correct way that is based on a API documentation of Drupal.
Trying to circumvent the GPL
Trying to circumvent the GPL is a very bad idea especially, if you live in Germany where courts have already decided that the GPL is valid (although the concrete case has of course not been brought forward).
@Gerhard: Are you aware
@Gerhard: Are you aware about any "final action" regarding this example? (Example: A PHP function becomes a derivative work of Drupal)
"Coram iudice et in alto mari sumus in manu Dei." Römische Juristenweisheit; zu deutsch: "Vor Gericht und auf hoher See sind wir in Gottes Hand." not sure how to translate :-)
There are several examples
There are several examples for enforcing the GPL in Germany available on http://gpl-violations.org/
The most recent example isn't on the web page yet:
http://www.heise-online.co.uk/news/GPL-violation-by-Skype-re-affirmed-by...
None of the examles has yet dealt with what exactly a derived work in context of the GPL is, as far as I know.
different situations...
I'm also reading heise.de... but these are totally different situations. The companies haven't provided the source code back... was there really a final decision? I cannot remember if it wasn't only and arrangement on the end of the day...
Code offered under a CC license is a bit different... it's open - but not licensed under the GPL.
We could also think about a totally different way... Do you know http://www.sveasoft.com/? They have a very strange thinking about GPL... they block access to GPL source code and you can only get access - if you have payed a subscription. Additional they made their binaries hardware specific.
Something I cannot really do with a CC licensed theme... but it could be one way.
Another GPL example
The Mambo Open Source project is another example of a GPL'd CMS that does not believe that modular software are derivative works:
Note that Mambo does NOT have distributed copyright, so developers can be assured that they are not in danger of legal action from project contributors who disagree with this interpretation.
This also seems a good time to point out that a situation like the Mambo/Joomla split is my greatest fear for Drupal.
So the question becomes:
Should Drupal attempt to consolidate it's copyright under a Non-profit organization? Or will we see the same things happen to Drupal as Mambo if that is attempted?
A question along these lines was recently added to the wiki for this group. I lok forward to SFLC's response on that.
When I was looking for CMS
When I was looking for CMS to use back in 2001, I also looked at Mambo and their crooked interpretation of the GPL was a reason not to use it. It feels a bit like "Open Source, but we don't mean it".
I don't think Drupal needs to try to consolidate all copyright into the hands of one organization.
I selected Drupal for code quality
I selected Drupal for code quality, stability, modularity and extensibility. Nothing else and never thought much about license persnicketiness regarding one specific license detail.
I was researching CMSes for
I was researching CMSes for an organization, not for myself, so a solid legal footing also entered the equation. It wasn't the only reason of course.
Mambo/Joomla
Mambo/Joomla community module is not something that Drupal wants to follow exactly. They (Mambo/Joomla community) have done some really awesome things and they have also had bad things happen. Their community has been reviewed, researched, watched, and contacted to understand what triggers the various twists and turns in their community (both for the good outcomes and the bad outcomes). So simply stating that Mambo does it this way doesn't necessarily mean that its right for the Drupal community.
In reading this thread there is one thing that is clear to me; Your original argument seems more geared towards a discussion for law students, lawyers sitting around at lunch, or other legal types. It doesn't seem appropriate here.
One of the first questions/facts was
"Whether or not something is a 'derivative work' is defined by copyright law, not by the license."
This may very well be true (and I'm not implying that it is as ianal) but it doesn't stop the fact the community would prefer to have items released under the GPL if you utilize GPL code. If you listen to/read Richard Stallman he would most indeed disagree with your assertion but it doesn't mean that the law agrees with him.
This area of law is incredibly vague and simply there is not enough court evidence to provide utmost clarity. Furthermore law is simply the codification of a community/society ideas/thoughts (or better said, it changes often). The best we can do is work off the advice of lawyers and create a structure that the community believes best protects their interests.
I think you bring up excellent points just as those before you have brought up excellent points. I do think, however, that the community has thought about this and has come up with something they are comfortable with (rereading those old threads). That not only protect their works and rights but also fosters the community.
If you truly believe that this clause is causing irreparable harm to the community my best suggestion would be to talk with other developers with similar thoughts and ideas and create a case as to how changing this clause would benefit the community without causing harm. Although reviewing court cases and getting legal advice is necessary in the end it is what the community wants and what the community feels they need to do to protect their work.
The honest truth is that those that are going to violate the licenses really don't care what the licenses are anyhow.
-Jacob Redding
I fully support the current FAQ
I know case law exist, and that case law might rule otherwise. First, it seems unlikely given that we consulted some of the world's best experts already. Second, I don't know how case law translates to an international project. Does case law exist in, say, Spain? Let us be careful not to be too US-centric. Third, it has always been my intent and understanding that modules are 'derivative works' of Drupal.
I fully support the current FAQ. (I've been involved in its creation/writing).
That is not to say that we can't update or change the FAQ as we learn more. I expect this to be a living document. However, all changes will have to be researched rigorously and we should take the time to research matt2000's arguments. This is a non-trivial amount of work so don't expect us to make changes overnight. I'm not comfortable with that. We spent months working on the current FAQ and have been extremely rigorous about every sentence.
Thanks for the comment. It
Thanks for the comment. It certain adds significant weight to the discussion, particularly,
Care to elaborate on that? What makes Drupal modules different from, say Mambo Components? (Of course, you could say that you think the Mambo Project is wrong in it's opinion about it's own Components.)
As far as I can tell....
As far as I can tell, that's exactly what's going on. Drupal and Joomla! have each independently sought legal advice to clarify this question, and have come up with the same conclusion. Mambo has not sought concrete legal advice to clarify the answer to this question, likely because doing so would harm their commercial components ecosystem.
From Overview of Legal Matters:
Ignorance is bliss, I suppose...
Exactly.
Exactly.
Do the attorney's know themselves?
Do the attorney's from Joomla and Drupal know themselves, are friends, hear the same professors, read the same books or are they really independed from each other and found the same arguments on completely different ways?
And finally - is there any judge who already and finally judged (highest court) about "derivative work" in the discussed context of PHP functions with a Drupal like name?