Posted by matt2000 on June 23, 2008 at 5:31am
Yes, every last one.
39% (31 votes)
Some are, some aren't.
29% (23 votes)
No, only when code is definitely copied.
22% (17 votes)
No, never.
1% (1 vote)
I don't understand the question.
8% (6 votes)
These are not meaningful legal terms in my country / jursidiction.
1% (1 vote)
Total votes: 79
Comments
Depending on intonation, the
Depending on intonation, the question may be phrased as a yes-or-no question, but I would prefer not to; they are works based upon Drupal, but not derivative works of Drupal. But IANAL.
The Boise Drupal Guy!
Pleaswe rephrase the question or the answers . . .
You've got an either/or question with yes/no answers. Except for the last two, the answers don't directly answer the question. For example, does "Yes, every last one." refer to "Derivative Works" or "Works based upon"?
it's not an either/or
it's not an either/or question. The GPL uses the two terms synonymously, because the legal terms vary by jurisdiction.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Irrelevant thread
I have no idea what "work based upon" even means. To a lawyer, I suspect it doesn't mean anything. That makes this question moot.
This poll is also pointless as it is irrelevant. A poll of random people on the Interweb has no legal standing whatsoever. The Association spent weeks working with an attorney to work out the details of where the edge cases were. A web poll (which is horribly easy to fake, remember) is not going to change the prevailing legal position.
[sarcasm]No, I demand that
[sarcasm]No, I demand that you bow to the whims of this web poll.[/sarcasm]
Just gathering informal, unscientific information. No need to get defensive.
"Work based upon" is the phrase used in the GPLv2, for which "derivative works" are the only given example outside the program itself.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
I don't like to assume the
I don't like to assume the following, but if I engage a lawyer to find out how I could protect my rights... what would you expect as result? Personally - I wouldn't expect an open minded result that also tells us there is a hole or the way's around will be concealed as this is something you don't like to hear and tell someone else.
Last time I engaged a lawyer - I learned very quick that lawyers like to earn money with every instance or hour they work for you... nevertheless you loose or not and they are correct or not. This is something a court need to decide and their contract makes them free of sue against them self if they are wrong and they earn their money of they are wrong or not - it doesn't matter if everything they say is totally wrong.
PS: Could someone turn off this suxxx auto preview/save feature that makes my browser hanging every ~10 seconds, PLEASE?
someone with right should
someone with right should add, it does not matter, it is what it is.
IANAL, but if I was asked to
IANAL, but if I was asked to distinguish the two phrases, 'work based on' would include work that depends on the APIs of the work and thus include drupal modules and themes, even though the modules and themes are not 'derivative works'
Thus the different licenses GPL and LGPL.
Lesser GPL (LGPL)
Note, the only difference is a right to use a compiled binary as a library without the use of the library infecting the product using the library with GPL. It doesn't cover interpreted source code such as PHP and the distribution of a LGPL binary library is the same as GPL. In fact libstdc++ uses GPL with another exception of use statement to allow you to include the header files of libstdc++ without infection. I.E.: Do not think that LGPL is different from GPL because it isn't other than an exception statement.
Eschew Licensing Obfuscation
I'm not a lawyer or a GPL expert, but I've flirted with open source for as long as it been around, so I've been embroiled in many discussions of this sort.
First, a detailed discussion of GNU licenses at the Free Software Foundation.
http://www.fsf.org/licensing/licenses/gpl-faq.html
The term "derivative work" has legal definitions outside of the GPL, so it is far more complicated than a intuitive notion of "works based upon".
http://en.wikipedia.org/wiki/Derivative_work
So long as developers give attribution to their sources, pretty anything is acceptable, including selling it as a commercial product ... the catch is that it must be under GPL - attempting to break out of GPL would definitely involve seeking expert legal advise.
If you are developing non-GPL software using an API to a GPL product , you are also OK. There are schools of thought on this ( there's a lot on money behind it ), but generally APIs can not be restricted or copyrighted with any degree of assurance. Cases to restrict access to APIs have been thrown out of court many times in the past 30 years - IBM, Apple, Microsoft, all the Biggies have gotten smacked down on API restrictions again and again.
In general, a developer creating a non-GPL commercial product for use with an GPL product like Drupal should feel no threat of legal consequences from using the API. Sometimes, I think people spread fear-uncertainty-doubt about developing commercially for open source APIs because they just don't like the idea of open source ...
On the other hand, if you are using open source code from the Drupal repository, it should probably be under GPL, even if it's being sold as a commercial product. This is particularly true for one-shot applications sold for big bucks to a fat-cat client company ( one hopes ). Since odds are no one but the client will ever know the thing exists, why not GPL. In principle, it is distributable, but you aren't required to actually distribute it if it's not intended. It is a common misconception that one is required to distribute GPL-base software, but it's not true.
Whether of not the lawyers get after you, the original developers will be after you for not giving them credit for all their hard work. Morally crushing potentially.
Again, take all this as meremly my own view, not an expert opinion. Once one gets into it, GPL is a fascinating subject and I would like to hear other people's opinions on the above.
Bill Breitmayer
it cuts both ways
Or just as often, from the other side, because they don't like the idea of anyone developing anything commercially.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
How big is my slice ?
It seems like everyone I know who opposes commerical development is under the age of 30. Maybe we should have a poll about that ! :-)
Some folks have visions of muli-billion dollar corporations running 9,000 Drupal sites, but most commerical Drupal is for non-profits - many of them in the "Under $1,000,000 Club":, some of them under $100,000 ... in other words, necessarily non-profit.
There may be a whole world of small, ultra-lite businesses that could get better value from Drupal and better support from a semi-commerical Drupal community than from a commerical developer. I hope that many small business will follow the Open Source leaders in the next few years.
I think these discussions about GPL are important to have now, it will be easier to convince small business that GPL will protect their software investment. I've been doing some volunteer work for non-profits and they often require open source GPL, so the subject is coming up more often.
Semi-commercial?
The GPL does not prevent commercial development, just metered-per-copy development. I work for a for-profit Drupal shop; we're all about making money and are always looking for ways to make more of it. Using Drupal and embracing the GPL has made it much easier for us to do so. In exchange for not being able to charge a premium fee for permission to use the software, we get to use and leverage Form API, Views, Panels, CCK, and a hundred other modules that lets us build the site faster and better. We get a happy paying client, the client gets a great site, and we can move on to another paying client sooner. That's as commercial as you get. :-)
Semi-Coherent ?
You are right, of course. I meant to say mixed commercial and non-commercial.
In addition to licensing, there is an emerging issue of how to blend commercial and non-commercial interests, particularly since developing end-user application with Drupal does not usually produce reusable or sharable code.
It seems to me that most of the big, nitty-gritty issues arise from the need to achieve a balance between the benefits received by Drupal producers and Drupal consumers, maybe call it "equity". I think the equity issue runs parallel to the debate about GPL licensing. It will be interesting to see how the community works this out in the next few years - if handled correctly, it might become a model for other collaborative development projects.
Bill Breitmayer
At a minimum, the 8 other
At a minimum, the 8 other people who voted "No" should sign this:
http://groups.drupal.org/node/12631
Discuss here:
http://groups.drupal.org/node/12722
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
How about this one?
How would you like that? ;-P
Dr.Upal
GPL everybody
Not only Drupal, also Joomla, WordPress, Typo3, etc., are licensed under the GPL.
I think PHP's license is less restrictive than GPL. So, it seems that PHP cannot derivate from GPL software, but GPL software (such as Drupal, etc.) can derivate from PHP.
It doesn't matter, because
It doesn't matter, because no one at the PHP project is attempting to claim intellectual property rights over software that uses it's "API", contra Drupal, which does.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Please don't make misleading statements.
The term "Derivative work" has a specific legal definition in this situation (and is defined independently of the GPL).
As I understand it, Drupal is NOT a derivative work of PHP.
Here is a detailed interpretation of the derivative work question:
http://www.linuxjournal.com/article/6366
kind regards,
D
And that article emphasizes
And that article emphasizes the point that a module that doesn't modify Drupal doesn't create a derivative work. The module simply uses Drupal's provided API. A module that replaces an already provided API with different code does create a derivative work.
Nope
False. As far as the C code that is the PHP engine is concerned, Drupal is just data. The license has no effect on the data.
In the same vein, the GCC compiler used to compile the PHP engine considers PHP itself just data. Therefore the license of GCC has no effect on PHP.
Similarly, the data in your database is, as far as Drupal is concerned, just data. The GPL license on Drupal has no effect on the data you enter into it.
So the basic premise is flawed.
You mention further below that you were joking when you posted this comment. Please don't joke about such licensing matters. It only confuses people needlessly and makes my job harder, since I then have to answer these sorts of questions. :-)
If you wanna joking around
If you wanna joking around on this matter a little longer, then touch this:
1. C is nothing to do with that statement. PHP itself as a language provided under PHP license.
2. Drupal written in PHP.
3. By the same logic you have here enforcing on "Derivative Work" term, Drupal is derivative work of PHP since it is written in PHP and communicate with PHP engine over PHP code.
What other argument against this logic you can propose?
(I'm just curious how long it will take for you or somebody else to find correct exit from this logical loop? ;-P )
Dr.Upal
I think the correct
I think the correct question, if one accepts the FSF's premise, is, do PHP programs run in the same memory address space as the PHP engine? Someone more familiar with these tech issues than me will have to answer this one.
Crell has made a correct observation that the PHP engine essentially treats PHP as data, so you are somewhat inaccurate when you say that Drupal communicates with the PHP engine via PHP "code." It simply sends the PHP engine some PHP "data" to process.
Yes, the distinction is particularly archaic, and may not be legally relevant, but I agree that it is an amusing question to consider.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal communicate with PHP
Drupal communicate with PHP engine by using PHP language and making PHP functions calls.
We are not looking here on PHP from PHP engine prospective. We are looking here on how Drupal use PHP. And answer is clear - Drupal use PHP language.
Dr.Upal
No, I don't
I really have no desire to joke around on the logic even more, actually, nor do I have time to play irrelevant logic games that only serve to confuse people about the how and why of Drupal's licensing. Please, this is not the place for such games.
Here where you are wrong.
Here where you are wrong. This is not irrelevant logic at all.
Any discussions and discoveries in the area of licensing issues are logical games and puzzles.
Answer to this logic puzzle is very simple - PHP license is not enforcing anything on product that could be created with PHP.
PHP is not enforcing its own license on any derivate work.
GPL license v2 have specifically state in the [TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION, 2.c, 2nd paragraph]:
And that is why I was trying to tied together this two issues - "derivate work" and appropriate licensing for Drupal module with "special exception". Read this http://www.law.washington.edu/lct/swp/Law/derivative.html
So, as long as people here will be so stubborn to allow distribution of GPL modules with "special exception" for working with non-GPL libraries, it is not helping Drupal to become a framework that can be chosen for development in the business model.
In fact it will only increase number of cases when Drupal will be silently used for business without distribution of modules that can help another people.
But you right about one thing - if people are not ready to hear what you have to say, then it is time wasting to continue convince them otherwise.
Ciao!
Dr.Upal
FAQ
For questions about modules, etc.:
Drupal Licensing FAQ
Okay, here we go
Okay, here we go.
When I was posting here previously at http://groups.drupal.org/node/12648#comment-52109, I was joking around.
But now I'm going to be serious.
So, #6 is describing the way to create web application in your way.
Okay, I'm tired now.
Dr.Upal
A theme?
A theme is often an implementation of copyrighted artwork. How would that work?
I will have to think about
I will have to think about it.
Dr.Upal
No need
We already spent a great deal of time thinking about that with our lawyer. This question is answered in the FAQ. In short: GPL applies to the code, not to the "look and feel". The code can be GPLed but the look and feel not.
That can be a bit odd to think about, but welcome to copyright law. :-)
The same as any other GPL
The same as any other GPL work. GPL gives a person a license to use, modify, distribute and sell any such covered work within the bounds of the provisos given.
Living with the GPL...
Actually this has little to do with the interpretation of "derivative work". While there may be some gray areas regarding API's that are specific to an application in general it has been upheld that a library or plugin in themselves are not derivative works.
There is only an issue when the plugin is used in conjunction with the other program. At that point the question becomes weather it either violates the license when combined or run in that configuration. When an API is exposed this becomes murky regardless of the license involved.
Regardless the writers of the GPL specifically state that they consider plugins to be covered under the GPL ( http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins ). Unless you want to test this in court for all of us (I would appreciate it) then I wouldn't suggest going this path.
If you do want to combine a proprietary module with a GPL's program there are ways to do that. The most obvious being to communicate with the proprietary program through IPC as separate processes. Beyond that there are a few other loopholes.
For a more complete explanation you may want to check out my thoughts at ( http://martysmind.com/2008/02/10/sleeping-with-the-gpl/ )
-Marty
What we really need...
Regardless of our interpretation of the GPL there is a simple way out of this problem. The solution is simple and quite legal.
Dries Buytaert simply states what he believes. It is completely in his right (and I would say responsibility) to explicitly state whether he considers Themes and Modules to violate the GPL. He can even add these as specific exclusions to the license.
So can we have a little help here Dries?
-Marty
Already did
Dries along with the other members of the Drupal Association, most of whom have written significant bodies of code for Drupal as well, read, vetted, and accepted the Legal FAQ that was prepared in cooperation with our attorney. Dries has stated what he believes by accepting and supporting the standing policy. He also happens to have said the same elsewhere, too.
Remember, though, that Dries currently holds the copyright to a minority of the code in Drupal. There were over 700 people who contributed code to Drupal 6 alone, and Dries was not even in the top ten. Dries personal opinion does not win out over everything as a point of law, because there are many other copyright holders involved.
To expand on Crell's point,
To expand on Crell's point, the fact that there are so many different copyright holders is precisely why the licensing FAQ was developed: to provide definitive answers to these questions that are informed by the months of research done into the matter by the Drupal Association in conjunction with its legal counsel.
If you disagree with those answers, fine, but they're not subject to individual interpretation. If every individual was allowed to interpret Drupal's licensing terms in their own way, there would be massive confusion over how the software could be used and distributed, which would drive many people away from Drupal. There needs to be a clear and consistent understanding for how Drupal can and can't be used and/or distributed, and that's what the FAQ is for.
Thank you, that clears it up...
As Crell stated, this has already been explicitly stated in the FAQ ( http://drupal.org/licensing/faq#q7 ) to agree with GPL's own interpretation ( http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins ). This simplifies the disposition of your Modules and Themes, they are subject to the GPL ... if you distribute them.
You do not have to distribute your proprietary code if you DO NOT distribute/sell your code. Simply put if you keep the code inside the company then it is yours. If you sell, license or give your proprietary code to another entity, then you must also distribute your proprietary code.
It is of course a bit more complicated, so please reference my notes at ( http://martysmind.com/2008/02/10/sleeping-with-the-gpl/ ) for a more complete business analysis of how this works.
Thanks Crell!!
The GPL FAQ is not a
The GPL FAQ is not a license, and it's not law.
I do not believe that the claim of
http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
...has been substantiated either; but if I missed something in my reading of the GPL v2, I would be very grateful if someone could point me to it.
If I understand his position correctly, Attorney Larry Rosen has stated that the means by which a plugin interacts with it's host is irrelevant, essentially refuting the claim of gpl-faq.html#GPLAndPlugins and Drupal FAQ #7. I've linked to his article elsewhere in this group.
I've also previously noted that other open-source projects, including some which integrate with Drupal, do not blindly follow the GPL FAQ on this point either.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Marty, I just read your
Marty,
I just read your article and it is one of the better resources I've found.
It seems your thesis is that the greatest weight should be given to the intent of the author of the license, in the case of GPL, it is the FSF. I might adjust that slightly to suggest that perhaps it is the intent of the licensor who adopts the license that matters most. What do you think?
Also, what do you think about when the author does not take a clear position. For example, much of my position is based on this statement from the GPL FAQ:
http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
This is the core sentiment I have continually echoed throughout this group.
Thoughts?
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Go ahead
Matt, it is quite clear that you will not accept any answer other than "Judge X said so in Foo vs. Bar". Such an answer doesn't exist yet, as no one has been foolish enough to challenge the GPL all the way to a judicial ruling. They always settle before that, which should tell you something.
If you would like to begin a legal proceeding and carry it through to a judicial ruling, you are welcome to do so. We have provided an FAQ based on our best understanding of the law with the advise of an attorney skilled in the subject, but in the end we cannot control your actions nor are we going to bother trying.
I have already answered all of your questions and challenges, twice. I am not going to bother with a third time.
That's a fair answer at
Crell,
Although my questions were directed at Marty, that's a fair answer at least. Thanks.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Here's a ruling last month
Here's a ruling last month in the US Court of Appeals for the Federal Circuit that upheld an open-source license: http://jmri.sourceforge.net/k/docket/232.pdf I wouldn't say it's directly related to the gray areas of derivative works discussed in this thread but it does show that a US federal court will recognize an open-source license violation, with the help of amicus curiæ briefs filed by advocacy groups like Creative Commons.
Crell wrote: Matt, it is
Crell wrote:
Could you please clarify what the attorney's advice was based on? If there is no judicial basis for the "contagious license" principle, there must be at least some arguments for it that an attorney (or judge) could consider persuasive. Can anyone provide citations?
Oh, I understand it very
Oh, I understand it very well.
I just point out in my messages (including this one http://groups.drupal.org/node/12646#comment-52427 and this one http://groups.drupal.org/node/12646#comment-52452) in order to benefit for all of us that there is a GPL legal way to use some of the libraries/PEAR packages that are not GPL compatible by using "special exception" notice in the module copyright holder header.
From what I see in http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs is nothing GPL illegal in that.
Unless you wanna come up with your own interpretation of GPL license that will be differ from GNU.
I'm not pushing anybody here. But it is nothing wrong in learning something new about GPL licensing process.
I'm just concern that if we will not correctly recognize GPL license on this subject, then we will outcast a very big portion of open source libraries available for developers under another GPL incompatible licenses.
And another point is that if some another development community recognize it before us, then they will have advantage over us on this matter. I just wanna prevent it from happening. Because I like Drupal. Otherwise, I can drop this discussion long ago.
Everybody can do that on it own and benefit from it without contributing it back to community. But point is that we have chance to acknowledge this for benefit of all community, unless somebody have some hidden agenda.
Dr.Upal
Lets not confuse folks...
Hi Levsha,
Regardless of gray area of the GPL, unless someone wants to fight it in court the GPL FAQ and Drupal's FAQ both state unequivocally that they believe that all modules and themes are derivative work. Therefore if anyone wants to debate the legal gray areas they should probably do so in a forum that is set up for that.
As far as Drupal is concerned there is no question. As far as the law is concerned there may be, but that should not concern most developers till it has been cleared up in a federal court.
There are very specific ways that have been spelled out to combine proprietary code with GPL'd programs that I outlined above and on my blog. If you follow that guidance you can have your cake and eat it too, otherwise we are just playing legal hide and go seek and waiting to be tagged.
If folks do not want to play by the rules of the GPL... those folks should not use Drupal.
-Marty
Yeah, let's not confuse
Yeah, let's not confuse anyone with honesty and truth about what the law does and does not say....
Anyone who wants to can agree with the DA and say all day long and say that ALL modules are derivative works. That doesn't make it necessarily true, but it is the easiest and simplest position to take.
Honestly, we don't know if it's true or not, so instead of taking a dishonest position, we should encourage developers to seek their own legal counsel, but also followed the preferred practice of releasing as much as possible under GPL, so they don't have to worry about it.
That's kind of the point of licenses like GPL and creative commons. You don't have to worry about it, if you follow along. That's why it's generally a good policy for the Drupal.org repository to be only GPL.
But if developers do have specific desire keep their own work proprietary, it's only fair to admit that it is an open question.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Blocks.
There have been points made that "data" isn't covered by the GPL, but blocks are sometimes not just data, but code. If I create a piece of PHP code that simply access the Database directly and lists all the users, but never invokes (directly) a Drupal function is that considered code that must be GPL'd
--
John K. Lewis | aim: neoliminal
--
John Kipling Lewis
Sort of...
It must be GPL's if it is distributed outside of your company. A company is considered and entity under the law and under GPL and entity does not have to distribute code under the GPL as long as they do not distribute it outside of the Entity.
In other words any company can extend, mash-up, "create derivative works", combine with proprietary code and not have to distribute anything as long as they keep it on their own servers.
-Marty
I do understand that part,
I do understand that part, but if I publish the code on a website as an example or in a book, is it then GPL? It was data. I could theoretically be divorced entirely from Drupal and run simply as PHP on any PHP/DB page. But I put it in a block... so now it's code in Drupal?
--
John K. Lewis | aim: neoliminal
--
John Kipling Lewis
This is another great
This is another great example of not derivative work.
But I'm almost positive that you will not get confirmation on this here from Drupal "official" developers and representative, since they are entirely satisfied and poisoned by lawyer how's looks like have no expedience as a PHP developer at all, which is kind of normal for lawyers ;)
So, we are doomed here until Drupal "core" people will check this again and again with another lawyers.
Dr.Upal
Have you read the FAQ?
It states in the first paragraph that the Drupal Association developed it with the assistance of the Software Freedom Law Center (SFLC), which is an organization that provides legal advice dedicated to protecting and advancing free and open source software.
My understanding is also that the particular lawyer who the Association worked with has personally contributed code to a number of different open source projects.
So your assertion that their lawyer has "no expedience [sic] as a PHP developer at all" would not appear to be supported by the facts. In fact, I suspect there are few lawyers out there who have as much direct experience with these matters as the folks from SFLC.
I don't think there's such a
I don't think there's such a thing as 'Drupal "official" developer' ?
And as someone who tends to agree with you, levsha, I think 'poisoned' is an unnecessarily strong and derisive term. Obviously there are competing ideologies here, but that doesn't have to break up the community, and it doesn't call for insults.
I'm sure the SFLC are good people. They just have vested interest in a certain point of view, that's all.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Blocks need to be address in the FAQ.
The instance of code in the Database which is then rendered by Drupal, particularly in Blocks, needs to be addressed in the FAQ. Currently my reading of the FAQ shows no mention of Blocks or code in the database. See my previous comments for background.
--
John K. Lewis | aim: neoliminal
--
John Kipling Lewis
Important distinction
I have a distinct scenario that I am able to describe clearly as it is based on my current situation.
I have a simple stand alone php based web application. It leverages a basic session management library that is released under a bsd licence. But any session management system could be used.
So most of the application is my own copyright and it does not inherit any licencing restrictions for the purposes of this discussion.
I have for some time been planning to release the application as a module for drupal. This would involve refactoring the code to implement the Drupal api for sessions and user management and store its data in additional database fields. The only reason I have not done so is my time pressures and project priorities.
So far, according to my understanding, I could do this but not distribute it - that way I retain full control over the work.
I could release the code via the Drupal community website as a freely available module under the GPL.
But I could not release the code under any other kind of licence. i.e. While I am the copyright holder for the work I would only be able to control the licencing of my my work for that which is not released as a Drupal module.
However, if I refactored my own work to operate as a stand alone application with its own api, I could create a module for Drupal that implements my api and makes my application available as a plugin for Drupal. I could licence my application any way I like and distribute it any way I like as long as the Drupal module that implements the api is released under GPL.
...This model seems to be used already to implement some commercial and alternatively licenced applications as plugins to Drupal.
Does anyone care to comment on interpretation of the situation?
respectfully,
D
This is very close to what I
This is very close to what I have describe above http://groups.drupal.org/node/12648#comment-52295
And I agree it should work fine.
Dr.Upal
This is not true. The
This is not true. The developer of the WysiwygPro app, who sponsored a GPL'd Drupal module exactly as you described, was threated by a member of the DA council as being in violation of GPL. The bridge module was removed from D.O, and the developer was forced to remove the module from his own website.
That situation is largely what drives my passion about this issue. I don't think the Drupal community should tell business to go f&*% off like that, when they are seeking to provide valuable resources to Drupal users. God knows we need a decent wysiwig.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Wrong
Matt, as a member of the DA Board (there is no "Council") I can tell you there was no "threat". There was a clear statement of the legal problem we believed to be present upon the advise of our attorney, and the Infrastructure team removed the module from CVS (as it has every right to do for any module at any time, as it controls the servers). There was never any "go f&*% off" stated or implied, and it is disingenuous and quite frankly insulting for you to claim such.
There are a half dozen other WYSIWYG modules that do not have legal issues you can pick from. Even if not, that has nothing to do with the legality of the situation.
Forgive me if my
Forgive me if my characterization was imbued with too much passion, but that is essentially what the action implies. "If you won't abide by our personal interpretation of this issue, we don't want your contributions."
I see no problem with proprietary software developers offering GPL'd bridge modules to interface with their software. I don't think the objections are legally based.
Thank you for correction my terminology. It can be assumed wherever I've referred the "council," I intended the "board." I was simply trying to make a distinction between the decision makers whoever they are, and the DA at large, of which my company is a proud member.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Almost
You are essentially correct with one caveat. The license of your 3rd party system would have to be GPL-compatible, although it needn't be the GPL itself. GPL, LGPL, revised BSD, all would work. Apache license and AGPLv3 would be somewhat problematic as then the resulting combined work would have to be GPLv3 (which is OK, as Drupal is GPLv2+), but is doable.
You cannot use that method to bridge to a non-GPL-compatible library, such as the PHP license or various proprietary licenses, because the resulting combined work is then undistributable. Some proprietary software vendors have tried to do so, but we have had to tell them that it doesn't work and removed the bridge modules from CVS.
Correct
The bridge would have to take on both GPL and GPL-incompatible licenses and therefore the bridge itself doesn't have a legal leg to stand on because the two licenses clash with each other.
please explain further
Really? Couldn't the copyright holder on the proprietary side simply extend an special exception to the bridge module to interact with the third-party software as needed?
I see no problem if the bridge is only interacting with the third-party app via API, in the same way that it interacts with Drupal; i.e., no modifications to the 'host' system's code.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
It so happened that I have a
It so happened that I have a copy of this module you are talking about almost right before it was removed from repository. And author's problem is that he is not create his GPL copyright holder header correctly. Therefore, his entire module was license in the wrong way.
That why I'm as well talking about importance of creating copyright holder header correctly (http://groups.drupal.org/node/12646#comment-52452, http://groups.drupal.org/node/12646#comment-52507).
Dr.Upal
I think I am more confused now!
For the avoidance of doubt, I am not looking for ways to avoid releasing my work under GPL.
But there are clearly pitfalls as outlined above.
I notice that there are modules that implement the flickr api for example.
So if I provide a web based service for free (such as flickr or facebook) and provide an api that is freely available / distributable under a GPL compliant licence, it can be implemented via a Drupal module. But if I were to choose to distribute my application under a non-gpl compliant licence in addition to offering it as a free service to end users it would make the Drupal module somehow undistributable - despite the fact that the api continues to be available under a GPL compliant licence.
...or am I wrong?
I read in the GPL FAQ that CMS templates would not be considered to inherit GPL unless they made particular calls to large amounts of Javascript in order to render. I wonder why the Drupal FAQ chooses to adopt a more dogmatic approach to drupal themes. I would have thought there were advantages in allowing theme authors more flexibility in how to licence and distribute their themes.
Perhaps Drupal should go all the way and ask all contributors to assign copyright to the DA for all materials that are to be distributed through drupal.org.
best,
D
See the FAQ. :-)
See question #10, which directly addresses the bridge module question. The GPL does not apply across a web service, so while the Flickr Drupal module is GPLed that has no bearing on the code running on Flickr's servers either way.
Drupal's CMS templates are an unusual case because, using the PHPTemplate engine, they are, in fact, executable code. A Smarty template or PHPTal template is used as data, whereas a PHPTemplate template the template files are executed as code. Anything in template.php is also executed as code, so the GPL applies to that as well.
That does not apply to the non-code parts of the theme, such as CSS or images. (Unless of course the theme is placed in Drupal's CVS repository, for which the GPL applies to everything for consistency.)
On Reflection...
The FAQ is pretty clear.
It is the nit-picking that seems to be causing more confusion - I think the expectation that contributors and developers accept the terms as explained in the FAQ is reasonable. There is always the choice to use another framework, write a new system from scratch or simply not distribute code as an alternative.
As a developer, I know what I can and cannot do. I can advise my clients accordingly. Business hates uncertainty more than anything else, and if the rule is "it must be GPL in every case" - that is a more certain position than "it must be GPL unless we make an exception".
Here is EBEN MOGLEN on the status of kernel modules in linux:
"If the kernel is pure GPL, then I think we would all agree that non-GPL, non-free loadable kernel modules represent GPL violations. Nonetheless, we all know that there are a large number of such modules and their existence is tolerated or even to some degree encouraged by the kernel maintainers, and I take that to mean that as an indication that there is some exception for those modules.
The kernel also maintains a technical mechanism, namely the GPL-only symbols and tainting structure, which seems to suggest an API for the connection of non-GPL'ed code to the kernel, which also seems to me a strong indication of the presence of an exception. The difficulty as a lawyer, even a lawyer that is reasonably knowledgeable about these matters, is that I don't understand what the terms of that exception are."
Full interview here: http://lwn.net/Articles/147070/
If the Drupal community can only avoid a situation that can cause such confusion through rigid dogma, then so be it.
kind regards,
D
I prefer full disclosure
I prefer full disclosure over dogma.
Why is it so hard to say this?:
"We don't know if your module can be non-GPL and still comply with Drupal's licensing. You should ask your lawyer. However, we do know that you are safe if you make it GPL, so that's the easiest solution for you. Your module definitely has to be GPL if it directly copies or modifies other Drupal code."
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Because that goes against
Because that goes against the GPL itself. GPL is used to force you to GPL your code if you use API from a GPL source. Your choice is not use Drupal or accept the GPL as the license for your product.
By my recollection, the GPL
By my recollection, the GPL itself makes no mention of APIs.
My reading has uncovered various cases where it was held that licensing restrictions could NOT be made on an independent product which makes use of a third party API.
If the GPL is trying to do this, it is my personal belief that the GPL is trying to do something that is not legally enforceable.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
GPL compliance and why it is a good thing - without exception
It appears that the clear message of the FAQ is not getting through to some people.
While there are other FOSS projects where the GPL is applied so loosely there are numerous exceptions that become impossible to audit, it is the considered view of the Software Freedom Law Center that GPL compliance should be enforced without exception in GPL'ed projects - especially those with a modular architecture. (see Eben Moglen interview http://lwn.net/Articles/147070/)
The reason for this approach is to ensure a free software project (such as Drupal) that chooses to distribute under the GPL does not become an easy target for the next predatory legal attack. The best foundation for an attack is to argue that a software (such as Drupal) breaks the terms of the GPL because of X, Y and Z exceptions and the GPL ceases to protect any of the work.
This is not simply at the whim of the Drupal Association, it is the considered advice of the the Software Freedom Law Center - an organisation that is dedicated to keeping open source software open.
I would urge those who are struggling to understand or accept the assertions in the Drupal Licencing FAQ to refer to the SFLC guide to GPL compliance:
http://www.softwarefreedom.org/resources/2008/compliance-guide.html
It is unlikely that it contains advice that is incompatible with the DA's position.
Lastly.
I think levsha's remarkable thinking on software inheriting the licence of the language in which it is written could upset the entire global software industry in addition to the open source community. Levsha - you should call a press conference at once, you will make the front page on every news stand with your shock revelations. ;-)
best,
D
Predatory Legal Attacks
Who is it that sues people for supposed GPL violations?
Try googling "GPL lawsuit".
That should make it very clear whether or not the DA selected an objective and impartial law firm capable of giving valid advice.
When you sleep with the predator, expect to become his lunch.
Who would be sued anyway? Someone is going to try and sue thousands of unnamed developers? The Drupal Project itself is in no danger if individual developers choose to license their own code under the license of their choice.
Who's spreading FUD now?
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Absolutely
You are absolutely correct. And here's where I'm going to give the suggestion that I've been giving in a number of situations where there has been a lot of talk: just do it.
You are absolutely free to release Drupal modules under whatever license you see fit ... you just won't be able to host them on Drupal.org CVS without being under the GPL.
Edit: and I forgot to add the part about seeking legal counsel of your own if you are going to "just do it", since in all likelihood violates the GPL to do so, which is exactly why we have the FAQ. No one can stop you from putting a different license on it, just as no one can stop you from doing other illegal acts :P
Thank you
Thank you, Boris. This is my position exactly.
Throughout this group, I have continually supported the GPL-only policy of the d.o repository. It makes things easier for end users and developers who come here to get resources.
I also believe that proprietary modules, developed and hosted elsewhere, can improve Drupal for end users.
That's my ultimate desire.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Update with an edit
Sorry, I crossed that bridge a long time ago. I made an edit above, since what I meant and what I wrote were confusing.
Drupal modules must be GPL if they are distributed. I crossed that bridge a long time ago, when we originally developed Hostmaster as Python + PostgreSQL and non open source. You can manipulate Drupal outside of Drupal with proprietary software. If you're specifically talking modules, they are legally required to be distributed as GPL.
No, it doesn't violate the
No, it doesn't violate the GPL to release a module for a GPL program, as long as your module is not a 'derivative work.'
The FSF & SFLC can not define what a 'derivative work' is, no matter how much they want to. Only the law can do that.
Refer back to the Larry Rosen article and the University of Washington study, or your own lawyer, if there any confusion about how courts in the US have ruled on this.
FACT: The Drupal Association's lawyers, the SFLC, work for the FSF, authors of the GPL, and can not be considered an independent consultant on the issue.
FACT: The only public legal action ever taken by the SFLC to date is to file aggressive lawsuits against software developers. (This was acknowledged to me in a private conversation with a SFLC staff person. To be fair, they also engage in private settlements which are not publicly known.) They've never publicly defended an open source project against lawsuits.
FACT: US Courts have rules that a derivative work "must incorporate a protected work in some concrete or permanent 'form'." Lewis Galoob Toys, Inc. v. Nintendo of America, Inc. , 964 F.2d 967 (9th Cir. 1992).
FACT: Drupal modules do not require modification to Drupal, and do not require a developer to incorporate any protectable work to be functional.
FACT: Drupal modules are not a market substitute for Drupal itself.
FACT: The Drupal 'concepts' that modules implement are primarily functional.
FACT: Applying the FSF/SFLC procedures for identifying Derivative works results in many logical absurdities, as pointed out in http://www.law.washington.edu/lct/swp/Law/derivative.html
FACT: The GPL can not impose anything on a work that is not derivative of a GPL work.
CONCLUSION: The SFLC's advice is not trustworthy, it only reflects the vested interest of their primary client, the FSF.
CONCLUSION: The implementation of Drupal hooks are unlikely to be copyrightable expressions under the 'fair use limitation.'
CONCLUSION: The Drupal Licensing FAQ is based on one-sided opinions, and does not present a truthful analysis of the legal realities of the GPL.
CONCLUSION: There is good reason to believe that some kinds of modules can be legally defended as independent works, not derivative of Drupal. The developer of such a module is free to license and distribute that module at will. (Just not on the Drupal CVS, for policy reasons, not legal reasons.)
I'm not lawyer, but after studying this issue in depth for a couple months now, this is the bridge I have crossed. I don't have anything more to say on the issue at this time.
When the time comes that I wish to build a business around a proprietary Drupal module, I will consult with a real lawyer, not an activist.
I will continue to work hard to convince business to adopt Drupal and support the development of new enhancements, (even under the GPL, when possible) no matter how hard some people want to make it to do so.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
I think you're missing the point here
You've argued throughout that the licensing FAQ's position on proprietary modules is "open to debate". Even if that was true (and I'm not saying it is), it would still mean that there's a very distinct possibility that the FAQ's position on this issue is the correct one, and if so, any Drupal module must be distributed under a GPL-compatible license.
This means that if you distributed a proprietary Drupal module and it was later determined in a court of law that Drupal modules were derivative works under the GPL, the judge might then order you to release that module and its source code under the terms of the GPL, whether you wanted to or not.
The point of the licensing FAQ is to provide advice that will prevent module developers and others writing code for Drupal from making mistakes that could cause them to run afoul of the terms of the GPL, potentially costing them a lot of time, money, and heartache. If people wrote modules for Drupal under assumptions that later turned out to be false, the result would be chaos and calamity in the development community, and rejection of the software by most businesses. You can argue all you want that there's more than one position on this issue, but you cannot deny the position taken by the FAQ is the safest advice for anyone looking to create Drupal modules.
No one is going to get in trouble for writing GPL-compatible modules, but there's a good chance they will get in trouble if they write proprietary ones. Even if you're on the winning side, fighting a case in federal court is an incredibly expensive and time-consuming process and is something that most people seek to avoid.
You've also argued that the Software Freedom Law Center is biased because they work for the Free Software Foundation, the authors of the GPL, and that the FSF's definition of "derivative work" is flawed. Even if, again, we were to accept that assertion, that definition is clearly the intent of those who wrote the license, and you yourself have argued that author's intent should be considered when interpreting software licenses.
I am glad to hear that you are planning to seek the advice of an attorney before deciding whether or not you want to start a business built around a piece of proprietary software that you've written. If that time ever comes, I hope you will point that person toward the licensing FAQ as well as the other articles that have been written on both sides of this issue. If your attorney is a good one, then I'm sure he or she will advise you to proceed along the path that's least likely to get you in trouble with the terms of the GPL.
Facts
1) If a library, web service or whatever is providing an API and that API is covered by the GPL without any special provisions and you use that API in your program, module or whatever it must also be covered by the GPL. This is a direct result of the viral nature that RMS coined copyleft and is the intended affect of the GPL covered API.
2) Statements posed in a FAQ or other documentation to clarify the intent of the license are subject to be considered as part of the license itself because it helps clarify meaning in the court of laws.
3) These facts are not Drupal specific. They refer to any API that are covered by the GPL.
4) Both the GPL FAQ and the Drupal FAQ state that modules are a "derivative work" so therefore it is.
5) Any other interpretation of the GPL is meaningless. If you want to debate these facts then please do so with RMS.
Why is this in the Contributed Modules Status group?
I have just reread the group description, and I'm not sure how it includes "engage in debate on the licensing of contributed modules." The 6.x status page includes no information on licenses.
The debate seems to consist of people spitting in each other's soup, creating a circular argument that won't end until all realize its irrelevance and cease to be concerned with having the last word. If this could happen sooner, my inbox and I would be grateful.