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.
Comments
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
FunnyMonkey
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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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...
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.)
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.'
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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…
The Boise Drupal Guy!
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?
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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!)
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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?"
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.)
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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?"
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
well..
Khalid's approach sounds a lot to me like:
http://drupal.org/licensing/faq#q8
Right?
knaddison blog | Morris Animal Foundation
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.'
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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?
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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
-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
FunnyMonkey
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?
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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
FunnyMonkey
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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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. :-)
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
"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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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
-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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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
-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.)
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
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?
No, I am not aware of any
No, I am not aware of any high court decision specifically regarding the definition of Derivative Works as applied to programs written in PHP making use of Open APIs. It will likely be a long time before we see any such decision.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
This is a problem
The "derivative work" hasn't been highly contested in court. In fact the GPL has rarely gone to court (in the grand scheme of things) so the law is still very, very grey on matters such as this. This discussion is over a very grey area and the FAQ represents a long process of using the community supplemented with lawyers to determine the best course of action.
Its possible that the Joomla and Drupal attorney's know each or read the same books (highly likely) or went to the same University. This would be why the community (via the Association) didn't speak to just a single lawyer but rather a few as well as legal assistants. Additionally anyone in the community is more than welcome to hire a lawyer, have this reviewed and have a legal rendered and presented back to the community and Association for future revisions to the FAQ and licensing policies.
If this turns out to be the wrong way it can be changed but that change needs to come from the community (i.e. we need more voices saying I don't like this I want something different) and then confirmed by a lawyer. I really like this discussion but I would love to hear from more people rather than just a single person. This is not meant to be offensive to Matt but change requires people.
-Jacob Redding
-Jacob Redding
Mambo has not sought
I don't need to seek legal advice to decide whether or not I will sue someone who makes a program that uses an API I provide. (Or in the case of Drupal hooks, the reverse: someone who is kind enough to make a program with an API that I can use with my program.) I can simply decide, as Mambo has, to disclaim any interest in anyone else's modular code.
Drupal could very easily say, "whether or not a court says a module is a derivative work, we have decided not to treat them as such." You don't need a lawyer for that. You can always freely choose to NOT exercise your right to sue someone. Then we don't have to wait for the courts to battle it out over dozens of only loosely applicable cases. We can just decide to BE NICE and support TRUE FREEDOM for module developers.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
you're right...
Drupal could easily say that but the community, Drupal's hired lawyers and the founder of the project have decided that this will cause harm, and not good, to the community and the project.
I understand that you disagree with this but continuing to point examples and shout louder will not change that fact. The best way to change this policy is to get the developers and the people making up this project to understand your side of things. At it stands, at the very least in this thread, you're the loud minority (Which sounds harsh and I apologize).
Also I understand that you believe the ability to choose your own license is TRUE FREEDOM but, as a developer, I have to say that I don't agree with you and I believe that have that sort of "freedom" would lead the project down the wrong path. As a developer I work in OSS for a reason. If someone writes code that utilizes my code I want to see what they did and why they did it that way. I really don't want to see someone take/interact/implement/blah my code then close their code and put it under a restrictive license. So the FAQ, for me, works and I don't agree with your assertion about true freedom (insert freedom isn't free, there is no true freedoom, true freedom is anarchy clause here).
Moreover with "BE NICE" I would have to say that the community is being incredibly nice and very open. This FAQ was compiled after many months of debate that spawned from years of talks and conversation about it. It was then put in front of more than one lawyer and true legal advice was sought. This isn't just simply thrown together by a random person over a few beers. Additionally this conversation is going on and hasn't been censored. You fully disagree with this clause and people that have been directly involved in the writing of the FAQ, indirectly involved, as well as community members have come together to discuss it with you. Additionally its been previously discussed and recorded for all to read/learn. So people are being extremely nice and open.
Just because you disagree with it and your opinions are otherwise doesn't mean that the other "side" is being an evil, dictator monster, so relax (i.e. stop writing in caps as it conveys a shout message). I really, really don't want to see this thread go down the "7 million reasons" path.
Finally, the FAQ simply talks about derivative works and no where does it say "we'll sue if you don't do this" so please stop stating this we'll sue as if it a direct threat. FAQs are part of guidance, this isn't cease and desist letter sent out to all project contributers.
You have made a very good point and I honestly thank you for bringing up the topic. At this point, however, you're being more antagonistic than productive.
-Jacob Redding
-Jacob Redding
"Be Nice" was not directed
"Be Nice" was not directed towards the participants of this conversation. Everyone involved has been nice, civil, mature, and very gracious to participate with their time.
I simply meant to express the opinion that it is 'nicer' to share in a way that does not restrict the recipients usage. It would be pretty lame for me to give you a car for your birthday and insist that you only use it to drive to my house. That's not really giving.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
I understood your point
I fully understand your point with the "Be Nice" but that's your interpretation and one that I, and others, don't agree with. And just because there are people that don't agree with you doesn't mean that they are mean or those that put together the FAQ, spent months/years fleshing it out and countless hours going back and forth with lawyers are evil, horrible beings that want to keep others down.
This is a difference of opinion and it should be treated as that. This is not a black and white issue, its extremely, extremely gray. The FAQ leans one way and you lean the other. Lets all stick to facts and try to leave any name calling or any drawing hard lines out of it. At least try to see it from the other angle.
I really do understand your point but I simply don't agree, so I'd like to see a convincing argument. As of yet I haven't.
-Jacob Redding
-Jacob Redding
No body ever said anybody
No body ever said anybody was evil, but if you're just throwing my hyperbole back at me, well played. :-)
I wouldn't say the FAQ 'leans.' It makes a very explicit statement that themes and module ARE derivative works.
I would rather FAQ #7 said something like: "This is largely an unsettled question with answers that may vary depending on the circumstance and jurisdiction. You are safest if you license your work under the GPL. You should seek your own legal advice if you wish to use a different license. It is the opinion of the Drupal Association that modules and themes ARE derivative works, and (or but) the Drupal Association would (or would not) endorse legal action against a developer of a non-GPL'd work."
You could also add "Our own lawyers can't agree on this, because they told the CiviCRM project the opposite of what they told us." :-)
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Add Plone to the list of projects...
...that agrees with the conclusion on derivative works reached by Drupal and Joomla.
From http://plone.org/about/copyrights/license-faq/:
This is still better than
This is still better than Drupal's balnket statement that "everything is derivative." Plone makes it very clear how one could write an add-on that would NOT be derivative. So, for those keeping score:
Mambo > Plone > Joomla > Drupal
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Maybe its the breadth of the stroke
FAQ #7 also caught my eye. After thinking about it, perhaps what seems incorrect is the expansive breadth of statement, effectively that any and all modules/themes are derivative works and if distributed, must be done so under the GPL.
As a normative matter, I appreciate the reasoning behind wanting all modules to share the same license. But as a matter of pure positive analysis, it seems doubtful to me there aren't cases on the margins where the module is either not a derivative work, or is otherwise not required to carry the GPL forward on distribution.
As an example of the later, say there is large proprietary PHP code base, proprietary.php. The authors of the proprietary.php also release a trivial drupal module, which in its in its entirety serves to include() proprietary.php and dump results from a single function call within into a block. In this case, there's probably no copyright at all in the module itself, but my understanding is the prevailing view is that the co-mingled PHP execution of proprietary.php and drupal is itself impermissible as the end program is a derivative work. Assuming for the moment that this level of interaction rises to being a derivative work, this seems to me a like a fair-use derivative work. A prerequisite for GPL derivative work requirements to apply is that the derivative work would be infringing if not for the GPL; one could well have fair-use scenarios where fair use serves as a defense to the underlying infringement, rendering a license to the copyrighted work unnecessary, and the GPL inapplicable in the situation.
I don't expect Drupal to
I don't expect Drupal to suddenly pick up a different license, or to change the terms of the FAQ, or change its mind on the whole modules-must-be-GPL thing (as questionable as it is).
However, I do hope that we all, as developers interested in open-source software, are learning something from all this back-and-forth and confusion.
Namely; the GPL, and other "copyleft" licenses, do more harm than good. In the GPL's attempts to "ensure" software freedom, it actually artificially restricts it. How dare you do whatever you want with the code you have written! It's already pre-determined, as soon as you hit Command-S (or Escape Shift-Semicolon W Return or whatever) in your text editor, that that code must follow all these certain rules that someone you've never met who lives an ocean away (or further) decided on a half decade ago (or longer). No more. No less. Hooray for software freedom!
It's too late for Drupal to avoid the siren call of the GPL. It is GPL software, and barring calamity, it will remain GPL software for all of its existence. So I reluctantly release my modules under the GPL, when I'd rather just have them be public domain. (Some big company comes along and uses my module to make millions of dollars? That's awesome! And, as mentioned before, it doesn't stop my previously-released code from still being free.)
However, now that everyone in this thread has (hopefully) learned this lesson, should you ever move on to start your own open-source project that other developers are eventually going to work with, please do the right thing and steer clear of dangerous copyleft licenses.
matt2000, you are a hero for making your concerns heard, no matter how much you may be annoying the GPLerati.
The Boise Drupal Guy!
More harm than good..?
Drupal wouldn't be where it is today without the GPL. I see at least 3 high-profile developers in this thread alone who've stated that the GPL (and the larger Drupal community's interpretation of it) is one of the primary reasons they chose to contribute their many thousands of collective hours of development to the project.
Again, many thousands of people right now, as we speak, are happily making money building Drupal sites, offering Drupal services, providing custom development, and more. These people are making money while participating within the spirit of the open source nature that the GPL offers, not by trying to get around it. Each new GPL module that is released serves to strengthen the code base, and opens the doors for even more advanced functionality and more types sites that can be made with Drupal. That translates to more money that can be made, because new clients can be approached, for whom Drupal is now a suitable solution. It's win-win.
So remember that every time you make a dime off of Drupal's code, you are doing so, to a large extent, because of the GPL. Terms like "the GPLerati" are derisive and serve only to lower the quality of this discussion which has, for the most part, remained civil and respectful. Let's keep it that way, hm?
You seem to imply that both
You seem to imply that both Drupal's large user/contributor base and its profit potential are a direct cause of it being licensed under the GPL instead of a more liberal license. I don't think it's fair to make that assumption, and I would argue that the GPL may have actually hindered in that regard. It's quite common for people to say "I legally can't/don't want to work with this code because its license is too restrictive," which will be the case of some individuals and entities when the GPL is thrust upon them. But few would say "I can't/don't want to work with this code because its license is too free," and I'd argue those who would say such a thing are the ones who are contrary to the spirit of open-source software.
It's not hard to see projects that have been successful at both making money for people and being technologically awesome under non-copyleft licenses. See: SQLite, the most popular database system in use today (public domain), the BSD Unices, Apache, LightTPD, PHP itself…
Yes, "GPLerati" was snide, but the people who think that all the world should be covered by the GPL -- that it's immoral to both sell software for a profit and give it away with as few restrictions as possible -- bug me with their fanaticism.
The Boise Drupal Guy!
?
I didn't say that GPL was the only way to have a successful project with a healthy ecosystem. I said that, for the Drupal project specifically, use of the GPL has demonstrably led to the attraction and retention of developers who have together put hundreds of thousands of lines of code in core and contrib. And that's just between myself, Jacob, Larry, Gerhard and "the man" Dries himself, all of whom are in support of the SFLC's interpretation of the GPL. So yes, it is one direct cause, although it is definitely not the only one.
Has Drupal's GPL license at the same time probably turned away potential developers who could have contributed hundreds of thousands of lines of code, but didn't because of their moral, ethical or other concerns with the GPL? I'm quite sure that it has. But those lines of code are theoretical. The actual code we're getting from contributors who are in support of the GPL is enough to support a thriving ecosystem, and the SFLC's interpretation of the GPL will ensure that this ecosystem continues to live on.
And remember, you're using code written by those "fanatics" every time you install or interact with a Drupal site. A little respect would go a long way, here.
I suppose neither of us will
I suppose neither of us will win by arguing theoreticals, but I still maintain that there'd be more Drupal developers in the world if there were fewer restrictions stopping them.
I'd prefer to believe that the majority of Drupal developers are normal people who understand that software licensing does not have to be an all-or-one proposition; that there's a place for commercial software, free software, and software in between. I'm not calling out the average Linux nerd so much as I am the OSS snobs who look down their noses at us mundanes who are actually willing to purchase software (and then use it without spending fifteen hours configuring it first).
The Boise Drupal Guy!
Debates between GPL, BSD,
Debates between GPL, BSD, and other licenses have already played out on thousands of threads around the web.. Sorry but it seems like a real waste to relive those debates again here when the license was already chosen years ago. Developers or users who don't like GPL can find some MIT-licensed project or whatever floats their boat.
Most of us are happily using software with GPL, Apache, PHP and whatever other licenses in our sites/servers, and have no interest in rehashing these old flame wars. But if someone wants to exhaustively prove the pros or cons of some license, fine with me, they can start a blog or write a dissertation and post a link here when it's finished.
Off topic
Really, the "more free" debate has no place here. Seriously. Drupal is under the GPL. That cannot and will not change. If that bothers you that much, don't use GPLed code.
The GPL is designed to protect the freedom of end-users to do what they want with the code, even if they are far down-stream from the original author, possibly at the expense of the immediate-next developer. If you would rather emphasize the flexibility of the immediate-next developer downstream, even at the expense of the freedom of end-users further downstream, then BSD-esque would be more appropriate. You pick the balance you want to strike; Drupal chose its balance long ago.
It has its place insofar as
It has its place insofar as it's a perfect example that developers ought to think long and hard about the implications of the licenses they choose (if they're allowed to choose one…) when they release their software. If you really care about allowing as many people being able to use your great software as possible in whatever manner they might find it useful, the GPL -- which seems to be the "default" OSS license nowadays -- is not a good choice. Furthermore, I feel that perhaps many people do not truly understand the extent of the "viral" nature of it, if they are aware of its existence at all; hence this thread.
I fully understand that Drupal is GPL'd, and am not asking that to change; I think such a change, if done properly, would be a tremendous waste of time and effort at this point.
The Boise Drupal Guy!
Again, many thousands of
That may be correct, but is not correct at all for others who don't work full time on Drupal development. In this case they have for e.g. limited time to build a theme or module and don't have the time to work as full time drupal developers to earn money from big customer projects. They wish to earn a very few money for their valuable, but limited spare time and they wouldn't receive any cent - if they only develop their stuff and all others only use their code. This new way they are made to no more develop for other people and very important work get's lost or is only available on payed request as public distribution is not allowed. This will stop innovation on stuff that is not available somewhere else and others won't waste their time for free in such complex parts, too.
In such a case it would be much more benefit for all who like to accept this for themself to have for example a CC license with a very small amount to pay and bring the project forward. People like to pay if they understand how many hundreds of hours they save. This is a personal decision to pay or reinvent the wheel again in a much more bad way.
Businss model
Marc, you're arguing that you want the license to support a particular business model, that of charge-per-unit. That business model is very difficult if not impossible to implement using GPLed code. That is by design. If you want that sort of business model, then you want to be writing proprietary software, not open source. Do remember that your erstwhile themer is making money off of all that code that I wrote, as did thousands of others who work on Drupal, and he's not paying me a cent for it. The only thing the GPL requires in return is that he can't prevent his clients from sharing his work. If you want to prevent your clients from sharing your work, then don't use GPLed software. It's as simple as that.
That said, there is no requirement that your hypothetical themer provide any code to anyone except his client. If he distributes it to someone, including his client, he must do so under the GPL, but he is under no obligation to distribute it to anyone else. He just can't stop his client from doing so, and as gdemet and killes explained above most clients, in practice, don't care enough to do so. They just want a site that works and doesn't cost a fortune. The vast majority of sites have at least some code that is released to the client under the GPL but never goes any farther, and in fact wouldn't be of any use if it did so.
Most of the code written for Drupal these days is written by people who get paid to work with Drupal.
Only to give one example.
Only to give one example. See why localizer passes away... http://drupal.org/node/222865#comment-836154 - unpaid work. Unbelievable bad - as it was 1000 times better then i18n.
Huh?
The comment you link to says:
The primary reason he's not choosing to continue that module is that there is no need to anymore. He mentions that it's too much unpaid work to keep up with a second localization system as well, which is fine and has nothing to do with the GPL. The GPL does not say you can't get paid for your work; as mentioned elsewhere in this thread, lots of work gets done for bounties, or by people whose day job is to work on Drupal or build sites with Drupal or both.
So your post is an off-topic red herring.
Please get lost. Quick.
Please get lost. Quick.
Two different issues?
It's certainly clear that there are open questions about the interpretation of GPL. Jay's personal remarks on the subject seem to express that eloquently enough for me.
However, the issue at hand is what is permissible in the drupal.org repositories, yes? And in that instance, there are other concerns beside what various people would like to be true or universally accepted. And one is protection of the Drupal community from potential risks of a policy based on a GPL interpretation that could open up potential liabilities for the community and Drupal Association via the website.
What is decided to be allowed to be hosted on Drupal.org may seem conservative to some in that only very clearly GPL-licensed code is accepted, but in the end this is a decision based on these interests.
Laura
pingVision, LLC (we're hiring)
...and member of the Drupal Association General Assembly.
PINGV | Strategy • Design • Drupal Development
No, The question here has
No, The question here has nothing to with what exisit in the repositories, though there is a discussion crossing that tangent here:
http://groups.drupal.org/node/12646
My question is about proprietary works, distributed elsewhere.
I am in favor of requiring Drupl.org repository works to be GPL.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
My question is about
That's one of the most important questions! If I offer a piece of software that have PHP function names in the source code that look like Drupal hooks, but must not depend on Drupal only - who will tell me that this is written only for Drupal and it must be GPL!? I think nobody can make me to release under a GPL license if my PHP function names looks like a Drupal hook. Nobody have a patent on a naming scheme!
Nobody speaks about a change on d.o repository... it's ok to have a GPL only requirement here.
Another Perspective
Hello Everyone,
I'm the author of the Gallerix module, and the Gallerix Widget Engine, so I take some interest in this thread. About a year ago I decided to write a photo management gallery for Drupal since none of the solutions available were right for me. What was to be a small project turned into a pretty big part of my programming hours. Naturally, I released it under the GPL on Drupal.org, as a way to give back to the Drupal community. For my own personal reasons, I also wrote a small extension that hooks unto Gallerix (so transitively to Drupal) and adds a variety of AJAX features, known as the Gallerix Widget Engine. I "sell" licenses to use this extension on my website, and view it as a fair compromise. Everyone gets 90% of the functionality under the GPL and those who want the last 10% can contact me.
According to the FAQ published on Drupal, this is not legal, since the extension to the module is also a derivative of Drupal. The only way it "uses" Drupal is by being shown in the admin/build/modules so users can enable it, but nevertheless, I'm not trying to argue whether or not this is useless without Drupal or not. I have sought out legal advice (simply out of curiosity) here in the US, and I've been told this is not in fact against the GPL, since it's not a derivative work, but rather one that works alongside Drupal. However, to me the integrity of the community as a whole is much more important than a mere side business, so I'm just playing the devil's advocate. Some other modules also operate under this "business plan", mainly Node Voting and Userpoints.
One more thing to consider: why aren't applications used under Linux forced to be GPL as well? After all, Linux is GPLed, and applications "hook" unto an operating system in a very similar manner to Drupal's module system.
Silvio
Linux as an OS
My understanding is that the Linux kernel is under GPL, but programs that run on it don't have to be because they are not considered derivative works. programs that run on Linux and interact with it through system calls are considered to be using the Linux kernel, not a derivative of it. In essence, the Linux kernel (not to be confused with an "Operating System"), is a platform that things may use without having to be derived from it.
Is Drupal a platform? Or is Drupal merely a program/application (a "system" ?) itself that other "modules" use?
Linux is different
Actually no, the way applications on Linux interact with Linux is different than the way Drupal modules work.
In a typical GNU/Linux system, or any other operating system, the operating system runs in its own protected memory space. Other applications each run in their own protected memory spaces. If there is any communication between them, it is through established inter-process communication mechanisms. Essentially it's the same concept as web services, but all on the same computer; the programs are talking to each other as separate entities rather than sharing data in memory.
In Drupal, a Drupal module is incorporated into Drupal itself via hooks. It shares a memory space, it calls internal APIs, it passes raw data structures back and forth. It becomes part of Drupal, which is why it is subject to the GPL.
The same issue actually arises in Linux development as well. The legality of non-GPL-compatible kernel modules (which are a rough analogy to Drupal modules because they get integrated into the kernel's memory space) is questionable at best, as are "bridge" kernel modules such as what nVidia uses for its video drivers.
That sort of loophole is, as stated above, "questionable at best". The Drupal community and Drupal Association don't want to deal with "questionable at best" situations, which is why the FAQ doesn't make wiggle-room for it. A specific case will require a lawyer (and maybe judge, but one hopes to always avoid that) to sort out the nitty gritty of each instance, but as an FAQ-level policy "modules are GPL, and the code they bridge to must be GPL-compatible, have a nice day" is a solid guideline to work from, and the one that is in force for Drupal's CVS repository.
as an FAQ-level policy
But you own words demonstrate that it is a dishonest statement. If something is questionable, then the most honest statement is that it is questionable, hence why I believe the Plone & Joomla FAQ's are superior, even though I still disagree.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
legal opinion
I don't know why you keep missing this but the FAQ is a work of many months of work as well as the expert legal opinions of several lawyers.
This is the opinion of what lawyers have said. Nobody is acting dishonestly here. The statement from the FAQ doesn't say its a hard-and-fast rule but a solid guideline to work from.
It wouldn't be fair to write a FAQ that says something like
"Well maybe.. if you went to court you might kinda, like.. possibly win or possibly lose. We don't really know. I mean lawyers have told us stuff but then... their just lawyers and lawyers aren't judges.. so.. um.. ya.. it might be OK or it might not be".
Lawyers gave advice that advice was put into an FAQ. If the advice turns out to be wrong OR if the community would like to turn against all of this work well then that can certainly happen.
-Jacob Redding
-Jacob Redding
Re: Linux is different
Crell,
I didn't mean to oversimplify the situation; I understand the differences between a kernel and a PHP script. But like you said, things like kernel modules lie in a gray area. But unlike most Drupal modules (short of core ones) they are usually a necessary evil; such is the case with restricted video drivers.
I think one of the greatest aspects of the GPL is that it ensures people who get the product (whether it was from a free source or they paid for it), can hack away at it to improve it, add features, etc. I think threats to this aspect of Drupal are the most dangerous ones, and against the community's best interest. To the best of my knowledge, all "commercial" versions of Drupal modules out there still come with readable code.
One more thing; it'd be interesting to see how the FAQ mutates to accommodate pluggable system handlers, just like you mentioned in your (very interesting) article. This would make some modules more like drivers and certainly more than useful without Drupal around.
Silvio
Why does it matter?
Generally speaking, the only reason you would need to license something under a non-GPL-compatible license is if you or your client was looking to commoditize that software. The only real restrictions that the GPL puts on you is that you have to provide your source code along with the software, and you have to allow the person to whom you provide the software to modify it or redistribute it along with source code if he or she chooses to do.
If you have a client who wants to create a module for Drupal that has some kind of proprietary logic, there's nothing preventing you from doing so, and charging that client for your work. As long as you don't upload it to Drupal.org, it's up to you and your client whether or not what's in that module gets shared with anyone else.
I've been in this business for a while, and I learned long ago that most clients are far less interested in buying exclusive rights to use a particular piece of code than they are in hiring someone who can develop software that helps solve their business problems. Drupal is a great piece of software for doing so because it has available a large number of modules that can be easily adapted to solve a large number of problems.
Our clients who use Drupal understand that they're benefiting because we don't have to reinvent the wheel or license some expensive piece of software to solve their business problem; we can leverage what's already out there instead. What we're being paid to do is essentially customize and configure Drupal to their unique situation, which may include writing new modules. If we think those modules might help others as well, we make them available to the community, which in turn makes Drupal even better.
Yeah, I'm fully aware that the GPL allows anyone else to make money off of code we've written, or use it for purposes I may not agree with, but at a certain point, you need to either be okay with that, or only develop software under licenses that give you the power to decide who does and doesn't get access to your code and the terms under which they get to use it. The GPL is not one of those licenses.
If you're looking to create a custom module or theme that you can commoditize, Drupal's probably not the best CMS for you, and you should consider looking at other tools that allow you to do so. For better or worse, Drupal's success is largely due to the fact that the folks who write modules for it are willing to share and share alike, and to try to do otherwise misses the point in a big way.
Thanks for summing this up
Thanks for summing this up so nicely. Your client experiences are very similar to mine. The GPL is in my opinion a great license to do business with. The only people who don't benefit are the ones who want to charge multiple times for the same code being written. I can sure live with that.
Have you ever thought about
Have you ever thought about projects that cannot receive all money at once as nobody will/can pay this at once and therefore only a few hours of the required hours get payed and they must charge multiple times to get the invested time payed?
many bounties for projects
There have been many bounties for projects over the years. A quick search yields many results: http://www.google.com/search?q=site%3Adrupal.org%20bounty
knaddison blog | Morris Animal Foundation
This is a key point,
This is a key point, especially in the Civic / Non-Profit world where I do much of my business. One organization can't pay enough for a "luxury" like their website, to cover my bills, when they'd rather put every dollar possible into serving their constituents. But if I can sell a module for less money, over and over, everybody wins.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Why it matters now that Drupal is mainstream
Where are the 2bits, PingVisions, CiviActions, Lullabots, etc of Red Hat ? (It's an honest question; I am relatively ignorant of this market. Maybe they exist.)
For me as a consumer of Linux products, if I want Professional services for my RPM-based Linux Distro, I go to Red Hat. If there are other professional service companies, I don't know about them, because Red Hat dominates the market.
Counter this to the world of Linux video & 3d animation tools, where Open & Proprietary Products co-exist well, without detracting from small business who provide video production services.
What will stop Acquia, as a service driven business, from doing the same as RedHat? A support subscription is a service, not a product, no matter what they say. Acquia has no choice but to compete with us, the community, in the same space, because we won't let them do something they might be able to do better: make & support proprietary modules.
This is Jay Batson in a recent Wired Magazine interview describing many of the things that I do. You can also read job descriptions on Acquia's website; they are hiring people to do things I would do for my clients. In order for Acquia to succeed, it must try to take away from me my existing & potential customers. And it has a lot more resources that I do to reach it's goal. (BTW, I fully support Acquia's right to be in competition with me; but I see no reason to encourage it. )
If Acquia could create proprietary modules, it could be a successful company without competing with me. And in creating more high quality, business class modules, it would grow the user base, which is good for all. Many of those new users would create or sponsor new GPL'd enhancements, precisely because, as gdemet has said, most businesses are far less interested in having exclusive rights to use a particular piece of code than they are in solving their business problems.
Also, proprietary modules are NOT a dead end for continued development. A good closed product will still have an Open API. See Google technologies for a prime example. If I develop a proprietary module, I would LOVE for you to enhance it with GPL'd components, and will encourage you to do so. The only thing I don't want you to do is give away the code that I may have invested much time & money in developing. Free market principles drive innovation, they don't hinder it.
This is why proprietary modules are good for the Drupal Community, particular as we continue to grow into this relatively new stage of worldwide recognition and corporate adoption. It's one thing when a project's growth is driven by individual coders, who do the work of improving the product themselves. It's a different game when a project begins to intersect with venture capitalists, who pay others to improve a product, and who expect a financial return on their investment.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Huh?
I don't even follow what you're saying here.
The Red Hat analogy for Acquia is nice marketing, but it is imperfect. Red Hat created their own distribution very early on, and have managed it since. Drupal is to date much more akin to the wider Linux community, or possibly to Debian if you wanted to pick a specific distro. There are lots and lots of small to medium Linux consulting shops, doing quite well. Red Hat has competition in the "big distro" market as well from SuSE, Canonical (Ubuntu), Mandriva, etc.
What that has to do with open source licensing, though, I have no idea. Proprietary modules are good because then Acquia can go proprietary and not compete with you? That doesn't even make sense. Acquia doing everything under the GPL helps you, because you get to make use of their contributions just as they make use of yours. It prevents them from "taking their ball and going home". That encourages free market competition rather than locking up code that can't be shared.
If you want to compete with Acquia in the long-term-commercial-support-services market, then good luck to you. Seriously. I fully support there being more than one player in that space and look forward to Acquia having competition. But that has nothing to do with the GPL.
As for VC money paying people to improve a product, you are aware of the amount of code that Sony funds that is all GPLed, and that Acquia's backers signed on knowing that they were going to be all open source, and all the code written by NowPublic developers (who had even more VC than Acquia), and the code written by full time developers at hundreds of professional Drupal consultancies... all of it under the GPL. Drupal went commercial a long time ago with the GPL and is doing just fine. :-)
wow...
you clearly don't know your OSS world. I'm sorry but there are 1,000s of Linux based companies doing quite well off of setting up, installing, configuring, designing and supporting Linux infrastructures. DELL and IBM both offer Linux support contracts as well Penguin computing. UBUNTU has professional support also and..... in short you can get professional services for Linux at the drop of a hat. Your example was well off.
We're detracting here and beginning to spiral downward.
-Jacob Redding
-Jacob Redding
Ubuntu won't support my RRR
Ubuntu won't support my RRR HHH or CentOS or whatever distribution. I don't know about they others, but that's exactly the point. I don't know about them because Red Hat dominates the market. Pick a 100 random people on the street and ask them to name a Linux company. 9 of the 10 who don't stare blankly at you will list Red Hat in their top three. (50 of them will probably say 'Mozilla' or 'Firefox', if you explain to them that Linux is Free software...) Also, IBM and Dell are bigger than RH. I am worried about the smaller shops, like those I listed, who can't compete with Acquia.
But you're right, we losing the point, so I will not respond to this particular train of replies, even if you insult my mother or give a really good refutation in your next reply. :-)
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Clarification on Acquia
This is a bit late; this thread seems to have run its course. But I thought I'd share a couple of things in clarification to Matt's comments as they relate to what we do.
1) Acquia believes Drupal modules to be covered by the GPL. We do not expect to develop "proprietary Drupal modules." All Drupal modules that we develop and contribute back to the project are - as everyone's - covered by the GPL. (As with anybody, when our developers sign up for their CVS accounts to check in code, they must agree to check that code in as GPL.) Acquia could end up developing some modules for which there is no reason to check in to drupal.org CVS. An example might be a module that works only with a network-based service that we might offer subscribers; without the service, the module is useless. In this case, we might not check the module in. (On the other hand, we might anyway.) Regardless if whether we check it in, though, we still believe those would be subject to the GPL.
1a) Acquia may incorporate code outside of Drupal, and supply it with our distribution, and that code would be subject to whatever licensing applies to that code. For instance, if one version of our "distribution" included the remainder of the *AMP stack, the Apache included therein would be subject to the Apache license, MySQL subject to ... etc. This might also apply to code that lives outside Drupal but which isn't part of the stack. E.g. if we licensed some closed source commercial application we felt compelling, and it communicated with Drupal via interprocess communication, that application would be subject to _its_ license. (And not subject to GPL for the same reason that different, separate, non-kernel applications on Linux can run with different licenses than Linux itself.) (Note: This isn't to suggest that we're currently out shopping for commercial stuff to put with Drupal; but it's worth pointing out in this discussion since it's relevant in case we ever do.)
2) Acquia does not want to take away from Drupal professional services companies (like Matt's). First and foremost, our business is to sell subscription support for Drupal, much the same way MySQL, JBoss, and others did. The most likely people / companies to help promote and sell our subscriptions are website development shops - much like those Matt suggests he is (or is part of). We, therefore, consider it important to make them good partners - and avoid competing directly with them when possible. To claim that all major Linux professional services development is done by Red Hat is not accurate. Red Hat is a public company; go look at their quarterly reports. Roughly < 20% of their revenue is from professional services, and most of that is training and certification; only a limited amount is direct customer engagements. 80%+ of the revenue is subscription revenue.
Note that companies like them - and us - do generally engage in some amount of direct professional services consulting. It has several benefits: (a) keeps us in touch with real customer utilization and requirements, so that we can invest directly in Drupal software development to meet those customers' needs (and contribute that code back to the open source project); and (b) there is a class of customer that just won't work with small Drupal development shops, and wants a well-capitalized company as the primary contract point. In this latter case, we very much want to partner with smaller shops, and have them do a bunch of the delivery of software, with us acting like a "General contractor" / project oversight manager, etc., passing much of the revenue on the project through to these partners. Bottom line: In most cases, we hope to be a good partner to companies like Matt's, not compete.
Matt brings up the Wired interview. "Support" for Drupal should be viewed as maturing, too. Developers need to figure out where they add the most value, and concentrate there, and let other things get handled "at scale." For instance, do you the developer really need to be charging by the hour to help a customer - for whom you finished a job 3 months ago - learn how to establish a new Role to enable restricted access to a new content type? No; you probably (a) don't charge for such advice, so (b) it's actually a cost to your business - not a profit engine - because it takes you off of revenue-generating work. This is the type of support that can be done by an Acquia "at scale," using an on-call staff of people who can handle a lot of these questions in a day for a fixed subscription cost per year and be profitable at it.
Another part of this "support" relates to automating things. Acquia should always be looking at automating a things that are appropriate - even if small shops charge money to do them "by hand" now. Though this might be viewed as competing, it is healthy. Drupal, and the service companies around it, should be always advancing the ball relative to where developer effort is focused. Dries has stated publicly that his vision for Drupal is to continually reduce the amount of developer effort required to build a compelling website. He later clarified this to say that developers shouldn't go away; they should just be thinking about problems at a different level. This is the key point. Web development shops shouldn't plan on making their money by hand-working a bunch of stuff over and over that can be automated; expect that we'll automate what's reasonable to automate. This is what I was referring to in the Wired interview. Focus on novel development and get paid for brilliance, not for being a robot. If so, you'll never see us as a competitor.
who pays for novelty and brilliance?
Hi Jay,
Thanks for the input. I hope you don't think I'm antagonistic to Acquia (I'm very excited about what Acquia may offer my business) and you've made the case well that Acquia does not intend to be antagonistic to me. :-)
I will respond to your final comment to say, with perhaps a bit of pessimism, that the state of the world is such that people will not pay (in advance) for novel development and brilliance. (Though they may flock to it once proven.) If I can be paid well enough for 'robot work' (which I may very well have automated via a proprietary tool or business process), then it frees me to spend unpaid time working on potential innovation and brilliance, without having to worry about making the mortgage.
But hey, I'm always willing to talk to someone who wants to pay me to sit at my code editor and think of great ideas.
All the Best,
Matt
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Proposed Improvements to the FAQ as resources become available
Ideology aside the main problem is the blanket statement in question 7. That needs to be addressed - AS has been stated over and over again in this thread - it will require legal council.
Blanket statements are always wrong. Always! [sic]
andre
progress...
Wow, this a bit more in depth than I even imagined going, but it is an improvement on the current state.
One key claification:
This is not a meaningful statement. The issues at hand is not about interpreting the GPL; it's about interpreting copyright law. The GPL says nothing about whether something is or is not a derivative work; Only that Derivative Works are 'works based upon' and therefore must be distributed under GPL.
This would be a meaningful, true, and honest statement:
It's unfortunate that it must be so obtuse to be meaningful. :-(
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Don't miss to answer...
Don't miss to answer - how a themer could circumvent this.
I'm not sure if I must provide the PHP templates under GPL (what could be acceptable) in one download package (mytheme_php.tar.gz) and the CSS and Image stuff licensed under a different license in another package (mytheme_css.tar.gz) or if i'm able to package them together with a clear statement what is GPL and what not.
Circumvent?
If your goal is to circumvent the GPL, then neither the Drupal Association nor this working group is going to provide you with any advice or assistance in the matter whatsoever except telling you not to.
Maybe "circumvent" is the
Maybe "circumvent" is the wrong word... not sure. I have CSS that is not GPL licensed and the new FAQ states I should GPL'ize the PHP parts. Ok, no problem - BUT how can I distribute this to be save??? The FAQ says I can do this, but don't say how and what is required to be save. For sure this will not a 100% GPL theme, but this is allowed as the FAQ says...
Back to the main question - what should I care about if I have mixed licences on PHP and CSS/Images?
I think the easiest and
I think the easiest and safest wy is to distribute two sets of downloads, one with the php files and one with the css/images.
Yep...
See the Gutenberg theme, which is a GPLed theme that manipulates Drupal's output to match that of Movable Type, and allows you to separately download Movable Type themes (which might be under any number of licenses) and use them with Drupal.
Wow, with such an 'easy'
Wow, with such an 'easy' solution, no wonder Open Source software & Drupal have such a good reputation of user-friendliness.
Imagine if when you bought a book, you had to go to a different store to get the cover, and a different store to have page numbers printed. Even if the book, the cover, and the printing were free, most of the time I'll pay the $10 or $20 dollars for the all-in-one book. How many of us bought a Drupal book containing mostly information contained on api.drupal.org and in the handbooks? I did.
Speaking of... My "Pro Drupal Development" book contains the complete code for various modules, making it an alleged derivative work. But it's not licensed under the GPL. The copyright page says 'All Rights Reserved.' Why is this allowed?
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
My non-professional opinion,
My non-professional opinion, after participating in these discussions, is that you should ignore FAQ #7. It sounds to me that your situation has nothing to do with 'circumventing' the GPL, if you are not using actual GPL'd code.
If your theme contains only original code & code form other licenses, go ahead and distribute under whatever license is required by those other licenses, if any. If you don't have any GPL code, you don't have to distribute under the GPL.
Here are my reasons for believing this:
Crell has stated that the Drupal hooks system is an API.
Another group member has stated that there is a history of failed legal attempts to restrict usage of APIs. I have not researched this myself, but I have reason to believe it is true.
The advice of the SFLC is unreliable, because they gave the opposite answer to the CiviCRM project. They will tell the client what the client wants to hear.
Go forth and distribute. Enrich the Drupal Community by giving or selling your own code, under the license of your choice. (I am not a lawyer.)
If the polls are any indication, roughly half this group will tell you I am giving you dangerous advice. It's up to you to study the issue for yourself and make your own decision.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Larry Rosen != SFLC
http://groups.drupal.org/node/12662#comment-41010
GPL has successfully been defended in court before -- http://www.gpl-violations.org/news/20061110-dlink-judgement_frankfurt_en... -- so #2 is just someone's opinion, as far as I can tell.
Again, the FAQ is the Drupal Association's legal understanding of the GPL and its implications, based on consultation with our attorney. It's a surer bet to go with that, than someone's personal opinion. :)
The CiviCRM website includes
The CiviCRM website includes information prepared with the assitance of both Larry Rosen, and other information prepared with assistance from the SFLC. The CiviCRM Licensing FAQ states very clearly that it was prepared with the help of the SFLC.
You're still missing the point. No one is talking about legally defending the GPL. The question is not "do I have to follow the GPL?" (Yes!) The question is, "Is my module/theme a derivative work?" (???) this GPL does not answer this question, no matter how much you wish it did.
Actually, the FAQ published by the Drupal Association is equal to my personal opinion (legally speaking). Otherwise, the Drupal Association is possibly practicing law without a license...
The FAQ states: "The Drupal Association has provided this FAQ...." (Thanks to SFLC for their help.) It does not say: "The SFLC has provided this legal opinion...."
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Inaccurate
RE:
See http://civicrm.org/licensing, or the Licensing FAQ -- this page states: "The following guidelines cover project guidelines for licensing and copyright for patches and code contributions to be accepted into the core codebase. They were developed for us by Lawrence Rosen – our project attorney – who specializes in Open Source Software licensing."
The AGPL licensing FAQ page, at http://civicrm.org/node/166, says: "This FAQ has been prepared by our legal counsel, the Software Freedom Law Center, to clarify the implications of the AGPL license."
BTW, this response is largely cut and pasted from here, where you didn't mention the reference to Rosen's contribution, as in that context it appeared that not mentioning Rosen's contribution made your argument appear stronger.
Matt -- I understand that you have a strongly held opinion here. Please -- all I ask -- consider what it is you are trying to gain from these conversations. Is this method of discourse really helping you achieve a larger goal?
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
Except for those places
Except for those places where I have obviously stated something with intended (attempted?) humor, sarcasm, or hyperbole (and usually noted it), I don't think most people will doubt my sincerity about this issue. Why is it my responsibility to quote or link to every last bit of information. I was not trying to cast a false light on anything.
Please review what is meant on http://civicrm.org/licensing by "the following guidelines." I don't believe it refers to the FAQ, but I could wrong. I'm going on the best information available to me, same as what everyone else has. If the FAQ page is wrong, that's certainly not my fault, and I would hope it will be updated soon. I know folks from CiviCRM are watching this discussion.
We were doing so well, but this will certainly turn to rubbish if we start with the "you're hiding information; no you're hiding information." To not state something is not dishonest. It's just not stating it. You're free to add whatever information you have to the discussion. Questioning my integrity does not support your point any better. But I'm not surprised that it's getting personal now that I've clearly stated my conclusion on the matter.
By the way, my very first post linked to an article by Rosen. I have never denied his involvement.
I just don't know how anyone can say "The SFLC didn't say say that" when the document says "this was prepared by the SFLC." It couldn't be more obvious.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
RE
RE: "I was not trying to cast a false light on anything."
Okay.
RE: "Why is it my responsibility to quote or link to every last bit of information." -- it's not your responsibility, or an obligation. It provides (to me, anyways) an increased level of credibility.
RE: "We were doing so well, but this will certainly turn to rubbish"
IMO, having read all of this thread as it unfolded, I think the future tense is optimistic :) -- As I said in my initial reponse on this thread these issues have been covered repeatedly in the past. Every time they arise, I attempt to steer clear, as this specific issue has been the subject of years of focused research and discussion, and the resulting FAQ is a solid document that represents the legal advice of experts and the overall will of the community.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
If the FAQ were a solid
If the FAQ were a solid document, this thread would have never happened.
But I sense that we are probably at (or well past) the point of, "We'll have to agree to disagree" and shake hands.
I just wish I could get one single person to agree not to sue me over this. (Yes, I realize the legal credibility of the linked manifesto is questionable. It's mostly symbolic, but I'm willing to be legally bound by it.)
Kind Regards,
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Not past that point at all
Matt --
We disagree on this. For me, the FAQ, in its current form, works perfectly well. I get the sense that we don't share that opinion.
WRT the manifesto, it strikes me as very unnecessary. In my earlier posts, I had questions about the logic and support you employed in making your argument -- from your response, it sounds like you took that as something personal -- definitely not my intent, and to the extent that it was interpreted in that way, my apologies.
So, personally, I'm fine agreeing to disagree. I will admit to being at a loss as to what you are trying to accomplish with this thread -- and please don't take that as any type of personal statement. I just don't understand it -- nothing more, nothing less.
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
Accomplishments
If the Drupal Association is really going to revisit the FAQ, with or without their current lawyers, then I have accomplished my primary goal.
I think I've also accomplished:
1. Drawing awareness to the problems with FAQ #7s interpretation of copyright law,
2. Encouraging some developers to be bold & creative in their business planning to the benefit of Drupal.
3. Laying out a case for the value that proprietary add-ons provide to an open-source project. (albeit controversial)
4. Participating in a variously stimulating and amusing conversation.
5. Got at least one person to call me their hero. I'm a sucker for ego plays (ask my wife), so I could do this all day. (and I have, for several days....)
Back to work....
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
If the FAQ were a solid
We actually very much expected such a discussion to occur.
Regarless how well you prepare a document, you'll always find somebody
who'll object to one or two parts of it. And be it for the sake of it.
The question is, "Is my
This is really the main question.
@webchick: this dlink
@webchick: this dlink example is NOT comparable at all. Gerhard have mentioned this example earlier and I answered that this is not a case of "derivative work". Dlink has been sued to provide the source code of iptables or linux in source code version for download. The source code of a theme and module is public if you distribute it...
Shared memory
I hate to ask a question that might have an obvious answer, but why exactly does shared memory = derivative work?
It's important to note that
It's important to note that that claim is only the opinion of the FSF. It's not contained in the GPL itself, and it has not been established universally by any case law or legislation that I am aware of. (IANAL) It is only one of many factors that a judge might consider in determining if a particular program is indeed a derivative work.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
GPL
In the GPL FAQ you can find info on the shared memory space issue: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation and here: http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins.
The second discusses the the crux of this thread from the opposite direction. This faq describes what happens if you write a calling program that uses or loads a pre-existing GPL "plug-in" (as opposed to writing a "plug-in" for a GPL'ed central program). Interesting to note that forking is given as a counter example.
A good analysis
One of the saner analyses missed this thread completely:
http://groups.drupal.org/node/12648#comment-40850
Of course, missing this thread completely might be evidence of sanity in itself, but I digress...
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Who you calling sane ?
Thank you. I didn't miss the thread entirely. The arguments are so winding and detailed that it took some time to wade through it. I still don't completely understand some of the comments.
I tend to look at licensing issues from the perspective of an application developer. I am more of a downstream customizer rather than a core developer of GPL products. Commercial clients ( and non-profits for that matter ) are primarily concerned with 1) quality software and 2) the right not to distribute code containing business logic. It's unique to the application and not re-usable anyway.
In fact, I agree with you in part about the wording of FAQ 7. There is good example of why the "derivative work via API" argument does not work.
Without getting too detailed about it, consider the example of Mono and Microsoft ( http://en.wikipedia.org/wiki/Mono_(software) ). Essentially, Mono duplicates the Dot Net runtime using the Microsoft interface. Microsoft has created a strange alliance with Novell that somehow gives them rights to Mono and they have put everyone else one notice that they are in violation etc etc.
Now, Microsoft huffs and puffs but it has not gone to court ( granted it might do so eventually ). Certainly, it has shown little enthusiasm for asserting its API rights, despite a fairly obvious smoking gun pointed at Dot Net. Why ? They know that the legal proceedings could go on for 10 years and they would probably lose in the end. Maybe good FUD, but definitely bad business.
What I am saying is: it is my strong impression that a piece of software invoking a runtime API does not necessarily make it derivative. It is the incorporation of source code, use of proprietary algorithms or compiled modules that makes it derivative - there are probably other reasons that I have missed.
This is my understanding of it as a user of open source software licenses. Almost every line of code I have written in the last 10 years is derivative in some way. It keeps clients happy because it gets me off the clock and out the door faster. Using open source also makes it less like the idiosyncratic work of a single individual and more like a community effort - it is code with a history. It is also code with a future, in the form of fixes/updates/extentions over the course of maybe 3-5 years.
Thank for the complement about being sane ... I don't often hear it. Despite many assertions to the contrary, "I am but mad north-northwest", on a good day.
Bill Breitmayer
Non-distribution
The GPL does not require distribution. It only requires that distribution, when it happens, happens under the GPL. If you write a module and give it to your client, then you have distributed it to your client under the GPL. There is no obligation on you or your client to distribute that module to anyone else beyond the two of you. The only requirement is that if you do so, you do so under the GPL.
A great deal of customized code for a specific client is of little if any use on any other site anyway, and the parts that are useful elsewhere are, rather by definition, generic rather than proprietary (otherwise they wouldn't be useful elsewhere).
This is a fascinating thread
This is a fascinating thread and I'm glad I discovered it although it is over 2 years aged. This thread for me answered a question that is asked often about Drupal "why are there not more ready-for-use commercial class modules complete with interfaces and layouts?" The answer is now obvious to me - because Drupal will play Robin Hood, stealing away the work under the guise of GPL and passing it around for all to enjoy.
I suspect as a result of this GPL licensing requirement that the very best Drupal modules probably sit under lock and key on private servers - too valuable to be given away, but not eligible for commercial distribution either.
I would certainly pay for commercial modules as long as they saved me money compared to building a site with free modules. I've built about a dozen sites with Drupal so far and I've used some decent contributed modules, but I've also spent anywhere from $500 all the way up to $2,000 theming and customizing each module used. In most cases that cost could be entirely eliminated or cut in half if we had access to commercial grade modules that took presentation and usability into account, and were truly ready-for-use, not merely functional snippets of code.
I agree with the argument that API use alone should not and probably does not constitute a derived work under GPL license. However clearly based on the lack of commercial modules available today the uncertaintly over this issue has so far proven enough to thwart any serious module development. Who wants to be the first to risk 200K building a commercial class module only to be sued by Drupal or find its commercial license unenforceable?
I think this whole issue is a shame, because what could be more of a slap in the face the idea of Open Source than a larger firm like Drupal Acquai using GPL as an excuse to enforce its licensing terms against relatively small individual developers and firms? When did we lose our appreciation of the distinction between someone voluntarily sharing their lunch with us - as opposed to beating someone else up in order to steal their lunch?
Well, time for lunch here! I wonder how many of you are still around from 2008 to reply? Isn't the web great? You can consider something done and done - and then years later it rises up to be a thorn in your side again.
By the way, any official legal change or updates to the status of "commercial module/theme" development or other related topics in the past 2 years?
You could sell commercial modules under the GPL
Actually, you absolutely could sell commercial modules. Layouts, themes, CSS, image and other things that you describe could be copyrighted. The code, however, would all still be GPL.
See my recent commentary on this around some WordPress issues: http://bmannconsulting.com/2891/drupal/themes-and-modules-are-derivative...
Specifically, my friends at BraveNewCode are selling commercial WP plugin with this very model -- they own the name of it, but the code itself is GPL.
Thanks Boris, would that be
Thanks Boris, would that be the WPTouchPro 2.0 you mentioned at BraveNewCode? I read their section about GPL and also found their legal terms at http://www.bravenewcode.com/general/terms/. That is really useful as a potential model to follow. I had heard of this option before but it didn't really make sense until I saw it in practice on a real product. Their wording about the GPL, and how they are charging for support and upgrades was all very helpful. I did wonder what an "upgrade" is in this context, is it just more GPL code?
Perhaps another idea might also be to bundle a "Guidebook" or "Training Manual" or other extended documentation with the module which could all be copyrighted.
Regarding your first statement about copyrighting other part of the theme or module such as CSS, images, layouts, that was also insightful because I had previously thought of the GPL license was something applied to the product as a whole. The stance provided by some of the earlier comments in this thread seemed to suggest that if you make a custom Theme, the entire theme including your images, CSS and XHTML are all collectively considered "derived works".
Given the information you provided I'm surprised there are not more commercial modules available already, because these conditions do not sound like to big a problem. Most software is stolen and distributed on the black market anyway, so what difference does it make if the GPL code in your product is being distributed or used freely? As long as you have a solid marketing plan you should be able to continue making sales so long as the product is actually offering a real advantage over completely unrestricted free modules.
Correct
Yes, I was referring to BraveNewCode.
Correct. Except most people that are good at code are bad at marketing (and vice versa).
Re: images, etc., this is exactly how premium themes are sold. The images, CSS, and so on are copyright and limited and so can't be distributed, but all PHP files are GPL.
However (personal opinion), I actually don't think that Drupal modules are a good fit for this module. Drupal install profiles are a whole other ball of wax, and are an area where I would look to make some money if you want to go down this route.
I notice you're in Kelowna. I'd be happy to chat further if you are planning on coming to the Pac NW Drupal Summit - http://pnwdrupalsummit.org/
Thanks Boris, I've actually
Thanks Boris, I've actually relocated to Surrey BC now. So if I'm in the city around that time I'll definitely attend that PNW Summit and I look forward to meeting you there.
I suspect as a result of this
I guess it depends on how you define "value." Do you mean code which would be incredibly useful for a wide range of people? Or code which helps people earn money? There's examples for both in the GPL codebase. No, I think that most of the Drupal code locked away on servers are custom modules and themes for that particular Drupal installation, which may be incredibly useful or profitable for the sites they serve, but of little value or utility to anyone else, at least not without a lot of polish to clean up and "generalize" the code for wider use. Such is my opinion from personal experience.
Make no mistake, I despise the GPL and wish Drupal hadn't had chosen it as its license. But I don't think it causes developers to write commercial-quality code and then just sit on it. Either they'll write good code and give it away, or they'll just write good enough code for their own use case and not distribute it.
The Boise Drupal Guy!
You make some good points. In
You make some good points. In my comment there I was referring to the situation where developers write what their paying clients want in a private project. Sometimes it includes a module that would be useful to at least a few others. In that case the work belongs to the client, and so its up to the client to decide to share or sell that system if they choose. Turning private systems into commercial applications happens very often in both other CMS systems and even with entire custom web applications. Lots of commercial modules/components and Web 2.0 apps have their roots as privately retained work. If something works very well for one type of company, say a realtor or car dealer, then it may work well for others in their business. Earlier this year one of our clients from Malaysia contracted us to add a new module to their real estate management system developed in CakePHP. It had started out as a private application for one of their country's largest realties, but since then had become a commercial application sold to realties throughout the country. The original realty involved still owned much of the shares, and they partnered with the developers in selling the system to other realties and continuing development.
Using another example, I would imagine over the years that quite a few car dealers have hired Drupal developers to create vehicle management systems. Surely out of the hundreds or even thousands of attempts at that type of module at least 1 of them would be at or near to commercial quality? With the right incentive and some additional development, the car dealership that owns such a system would probably be glad to see it turned into a commercial module. If I saw a module like that being sold for $50 or even $200 dollars I would probably think there is something that might be worthwhile if I ever work with a dealership.
Not always true
Not necessarily. That depends entirely on your contract. Many firms, my own included, retain copyright on code we write for a client specifically so that we can reuse it on other projects and, if appropriate, release it to the community. Most clients don't care; they're just happy to have a good web site. Those that do care more often than not encourage release because it helps the code they depend on grow. We are working with a client right now where writing the code to be community-releasable was a project requirement from the get-go. We like those clients. :-)
You're also making the flawed assumption in the second paragraph that if it costs money then it is "commercial quality" and therefore better than something that is just given away. It's a very common assumption, but it's been shown definitively over the past 30 years to be quite false. It just takes time for businesses to adjust to the realization that money paid and quality do not really have any sort of correlation.
By that logic, there are no good popular web servers; Both Apache and IIS (which together have nearly the entire market) are available for no-cost. Therefore if someone started charging for a new web server it would have to be better than either of them, right? Of course not. I'd put Drupal (free and Free) up against any for-money closed-source CMS anyday. See also: Linux, Firefox, WordPress, CakePHP, any Linux distribution, etc.
To be sure, some no-cost software is utter crap (both open source and closed, see: IE 6), but the same can be said for for-pay software. Whether or not it costs something implies really nothing about its quality.
You're also mistaking a solution for a module. That was common in Drupal's early days, but in modern Drupal architecture you'd be a fool to build a cardealership.module. You assemble a car dealership site using Views, CCK, Panels, possible some remote data handling, etc. and, maybe, bundle it as a feature. Those modules are all first-rate, production-ready, runs-on-million-node-sites-and-the-frickin'-Whitehouse good. :-) And they're all GPL and no-charge.
The useful-to-others examples you use are actually one of the best arguments FOR the GPL and widespread freely distributed code, because it allows for collaboration by people in the same field on what is not their business focus. A car dealership should be selling cars, not PHP code. They're much better at selling cars, believe me.
That is fine for basic functionality
"You assemble a car dealership site using Views, CCK, Panels, possible some remote data handling, etc. and, maybe, bundle it as a feature."
Last year in November we were approached by a Polaris and Victory motors dealership looking to build a new site. They had received bids ranging from $5,000 up to $50,000 for a wide variety of custom solutions from many different firms using different frameworks. However using Systems2000, a dealership system that is installed by thousands of Polaris dealers throughout North America remained an option also. That system would cost a lot less to setup, but they would never own it and would always be required to pay fees for support and maintenance, something that in the long run would make the system quite costly.
Systems2000 has a lot of features that work together in an integrated way such as handling the dealers insurance requirements, parts inventory tracking, automation of supply ordering, and a CRM for managing customers which in turn feeds into the systems accounting system which is also tied into an ecommerce store for filling parts sales. Many other features exist for handling service calls, managing government required forms, handling recalls, its a robust system designed to handle all the dealers needs for software and ecommerce in an integrated way.
When I viewed this system I thought "I could build something better than this in Drupal", because as a developer I always see some opportunity to improve any system, especially an out-of-the-box system. However when I started estimating the cost to recreate just a few key components of that system that the dealership really wanted, I realized delivering even a fraction of the functionality for a comparable cost would not be possible. Long term over 10 years, perhaps the cost of a custom system would have been a worthwhile investment.
So in that case I recommended that dealer choose the Systems2000 which they did, and it works fine for them so far. If there were modules available for Drupal that provided a base for such a system, or a configurable alternative, then that would have been something I'd have considered for this project.
In response to your point that anyone who embarks on solving larger problems than what Views or Panels can handle must be a fool, well yes I realize that a basic car listing system could be put together in a couple of hours using Views and Panels. However is that the only feature you can think of for a car dealership? Doesn't that say more about your creativity than my level of savvy? Suggesting that my firm and companies like Polaris are foolish just because we see the benefits of solving more complex requirements was uncalled for. Views and Panels are both tools, and like a hammer or chisel they have practical limitations and are not always the right choice for every job. Sometimes instead of building a whole new house with hammers all you need to do is buy a house and paint it.
Within the context of Drupal
I'm specifically talking about within the context of Drupal. Certainly there are cases where Drupal is not the right solution and you're better off with another platform or entirely custom. The math for that has to be decided by each customer for their situation. If you are going to use Drupal, though, you will 98% of the time be better served writing a few new Views plugins and Views data integration for your inventory management system than just writing a free-standing module. (I speak from experience, having done both multiple times in Drupal 5 and Drupal 6.)
And, to get back to the point of this thread, if you distribute those plugins they have to be under the GPL. If they're generally useful rather than only applicable to one site, it's in your interest to release them because then you get the community karma, bug testing, patches from others, security team reviews, etc. that come with that. If they're essentially useless outside of that one use case, then it doesn't matter in practice anyway. :-)
And to get back to the point I was making originally about "commercial" software, whether or not you charge a per-install license fee for them has absolutely nothing to do with how good of a module they are.
digression ahead: security team doesn't do reviews
Hi,
The security team does not review every contrib. We facilitate a process where many people (including sometimes team members) find vulnerabilities and report them to us.
knaddison blog | Morris Animal Foundation
Derivative vs. Inspiration?
Hi, I've written some Bash shell scripts to automate work with Drupal infrastructure, and someday I might re-implement this stuff as Drush components. This work is intended for general publication and distribution. Before reading this discussion, I considered these copyright terms for my code:
# 1. This software code is copyrighted by (me) under the same GPL / Creative Commons# conditions as Drupal itself, as described here:
# - http://drupal.org/licensing/faq
# - http://creativecommons.org/licenses/by-sa/3.0
# 2. This code should not be considered a "derivative work" of Drupal or other software.
# 3. New software inspired by this code, but not copied directly,
# shall not be considered a "derivative work" of this code.
After reading this discussion, I now conclude:
BTW, has the topic arisen yet, whether Drush add-ons and Bash scripts controlling Drupal are more like "FAQ #7 / api / shared memory space / modules / themes ", or "FAQ #10 / bridge modules / inter-process communication" ?
Bash != PHP
Bash scripts are not PHP scripts and are not operating in the same memory space, so that should fine. They would not be a derivative work of Drupal.
Were you to rewrite them as Drush extensions, the GPL license on Drush would apply the same as it would for Drupal's license applying to a Drupal module.
That said, saying that the code is governed by "these two licenses" is asking for trouble. :-) While GPLv2 and CC by-sa 3 are similar in spirit I do not believe they are technically compatible licenses. (I'm not sure if anyone has investigated that question, to be honest, although the attribution requirement of that CC variant could be problematic.) I'd suggest picking one and sticking with it. Drupal doesn't use CC for any code, only for non-code documentation in the handbooks.
As for point 3, "inspired by" is a legally shaky term since I don't think it has any firm legal definition. If your intent is "these scripts are GPL, but if you write add-ons then I don't consider them subject to the GPL by me" then I would suggest either using the LGPL or GPL with a specific exemption that says that more specifically. That is completely legal, and the GPL allows for such specific exemptions; most GPLed Java VMs, for instance, include a "classpath exception" to make it clear that the standard Java libraries that ship with the JVM don't apply the GPL to Java code you write that runs on that JVM. If you are the sole copyright holder on these Bash scripts and they are not a derivative work of something, you can absolutely use that sort of license-with-exception if you want.
If you were to distribute them via Drupal.org you'd have to use the same stock GPL as everything else on Drupal.org, but if you distribute them from your own site then you're fine.
I think it's time to let this thread die, too. It's way too long. :-) New questions should be asked in new threads.
"Operating in the same memory
"Operating in the same memory space" is not legal grounds for calling something a derivative work. http://scholar.google.com/scholar_case?case=10867856245078964488
OK, but...
Sorry, but this thread is only too long for those who've been present from the beginning in 2008. That's not me, nor others who encounter this thread in late 2010 and have newer questions still relevant to the topic at hand. And I'm sure there will be newcomers in the future who haven't yet had their chance to pipe in. Legal issues never die, when they ultimately boil down to opinions and perspectives?
Nevertheless I want to take your advice in this case, but since I'm less of a lawyer than you, could you propose a concise phrasing for a copyright blurb at the top of these Bash scripts - expressing the summarized intentions in a Drupal-compatible manner? Of course there may be exceptions, but if you want to close the case, how about providing tangible working examples - one for Bash mode, and one for drush-embedded php - maybe five to ten lines.
IANAL
I am not a lawyer either, I just get to talk to them. :-) If you want real legalese, you should find a Free Software-savvy lawyer in your area. If you just want to roll something quickly, have a look at the license for GNU Classpath, which I mentioned earlier:
http://www.gnu.org/software/classpath/license.html