Weekly Edition
Return to the Press page
| |||||||||||||
GPL compliance issues are tearing Joomla! apart (Linux.com)
Here's a Linux.com story on the debate over proprietary extension modules in the GPL-licensed Joomla project. "[Project leader Louis] Landry wants developers to understand that the reason Joomla! wants to move closer to the GPL is to protect the project. "If we are condoning violations, we're weaker in a legal sense. If someone challenged our license down the road, if we've systematically been condoning violations, they could say, 'What's different now?'""
(Log in to post comments)
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 20, 2007 19:55 UTC (Wed) by mrshiny (subscriber, #4266) [Link] What I find disturbing is that one of the authors of a proprietary Joomla! extension is considering forking Joomla! and releasing a version of Joomla! that is "tolerant" of proprietary extensions. Somehow I don't think this is legal. Nevermind that this person has no understanding of open-source or its community:Knafo is vehemently against the idea of re-licensing her extensions. "We will never release our software as GPL, never!" She says the core team doesn't understand what it is asking of the third-party developers. "The Joomla! core developers are very young. They don't have a lot of real life experience. They don't understand how things work in the real world. If you don't compensate people in the real world, they're not going to do it."However I'm sure the Joomla! people could make proprietary extensions legal if they relicense as LGPL or adopt a "boundary" across which the license is not deemed to cross, such as the Linux Kernel's kernel/user boundary.
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 20, 2007 20:08 UTC (Wed) by ballombe (subscriber, #9523) [Link] I think the issue is that Joomla! includes code from Mambo CMS which is under the GNU GPL, so they cannot relicense their codebase. This would also imply that proprietary extensions break Mambo copyright even if Joomla! developers were "tolerant".
This show lots of carelessness from the part of the proprietary extensions authors. They should be grateful of Joomla! attempts at fixing the resulting
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 20, 2007 20:39 UTC (Wed) by JohnNilsson (guest, #41242) [Link] According to http://mambo-foundation.org/content/view/2/1/
The copyright is controlled by the Mambo Foundation. But:
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 20, 2007 20:58 UTC (Wed) by vmole (guest, #111) [Link] It also shows a lot of carelessness on the part of the core developers; tolerating proprietary extensions for so long is going to make it hard to enforce the GPL in court, if it comes to that. Even if it doesn't, the bad will generated by the change in attitude is going to be hard on the project. What a mess.
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 20, 2007 20:11 UTC (Wed) by sp.at (subscriber, #36249) [Link] I have read some statements of both sides here and what I believe is sad about the whole issue is that the FUD that has been spread regarding the GPL seems to be believed by a lot of people.
It seems to me that most of those developers think that a.) they cannot sell GPL'ed code, which is plain wrong and b.) have to make their code available to the public as soon as they license is under the GPL, which also is plain wrong.
About forking and then changing the license: This is legally not possible. The copyright holder, and only the copyright holder, may change the license.
Another thing that has been suggested elsewhere, being the removal of copyright headers from the file, is not a solution either. In order for the GPL to work there needs to be a valid copyright header in the file. People seem to either not know or forget that, in case the GPL is violated, copyright law protects the work.
As for relicensing under the LGPL: An option, but why should that be done? Also, it would require permission from every copyright holder to do the relicensing.
I doubt a boundary is possible there. The "boundary" between user and kernel space is not one that has been introduced but that is given through the technical nature userspace applications communicate with the kernel(space). You do not need link a program against the kernel but rather use an interface (like interrupts for example) to communicate with it.
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 21, 2007 21:21 UTC (Thu) by zlynx (subscriber, #2285) [Link] There is no legal difference between calling code through INT, JMP, CALL, BR, or whatever.
With fast system calls implemented through a VDSO, there's no technical difference between a library call and a system call either.
The GPL is all about if it's a derived work, not about the technical details of how the code is invoked.
If someone wrote a BSD-licensed plugin test harness, and published complete documentation of the plugin interface, so that a plugin can be written without ever viewing GPL code, no-one could claim the resulting plugin was derived.
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jul 2, 2007 15:57 UTC (Mon) by gwg (guest, #20811) [Link] > The GPL is all about if it's a derived work, not about the technical> details of how the code is invoked.
Right
> If someone wrote a BSD-licensed plugin test harness, and published
Not exactly. The plugin isn't derived from the GPL code, but the combination of the plugin and the GPL application it plugs into is a derived work, and can only be distributed together if the plugin complies with the GPL licence.
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jul 2, 2007 17:37 UTC (Mon) by zlynx (subscriber, #2285) [Link] Opinions vary.
I could write a proprietary XML parser that reads and writes standard input and output. However, just because it can "plug in" to a Unix command pipeline does not mean it would need a GPL license to be included in a Linux distro.
Change that read/write of text strings to a stream into function calls passing string pointers, and the plugged-in-ness and derived-ness do not really change.
there are others, as usual Posted Jun 28, 2007 17:38 UTC (Thu) by gvy (guest, #11981) [Link] >> The Joomla! core developers are very young. They don't have a lot of real>> life experience. They don't understand how things work in the real world That seems true to some extent but then a person who didn't do the homework on licensing has no say on the topic.
Should I (as a happy user) advertise TYPO3 as a *mature*, professional, and GPL all the way through CMS/CMF which is just so much better both as a project and as a product? :)
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 20, 2007 20:31 UTC (Wed) by colinleroy (guest, #40525) [Link] We added the equivalent of MODULE_LICENSE() in our project to avoid such plugin issues before they could arise.
Quoting Eben Moglen's reply on the subject when I asked him for confirmation:
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 20, 2007 22:54 UTC (Wed) by i3839 (guest, #31386) [Link] I think it matters a lot on how intertwined the plugin is with the main program.
If the main program provides some hooks where plugins can do their own thing, independent of the main program (but at pre defined moments notified by the main program), then it doesn't really seem like the plugin is derived from the main program, but independent software which just works together with the main program.
If, on the other hand, the main program also provides a lot of library/help functions used by the plugin, then the plugin isn't independent any more and should be GPL compatible.
They can always do the Nvidia trick (if it doesn't rely on main program specific functionality), providing a closed plugin with a BSD/MIT wrapper for the plugin stuff, and distribute that seperately.
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 21, 2007 7:37 UTC (Thu) by colinleroy (guest, #40525) [Link] Yes, probably. Our plugins are in the second case; they wouldn't be able to do much without using a lot of Claws' functions.
Also, I have no idea whether the nVidia trick can be considered legal or not, it probably is, but I've got to say I'd hate if someone used that to write a Claws plugin; it shows a clear will to not play along.
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 21, 2007 7:44 UTC (Thu) by sp.at (subscriber, #36249) [Link] From my understanding the 'nVidia trick' is nowhere near being legal.
If you combine a program which is licensed under the GPL and, for example, a library licensed under the 3-clause BSD license the GPL, as the least permissive license, applies.
Thus it is not possible to link a proprietary library to the 3-clause BSD library which in turn is linked against a GPL'ed program legally.
For the record, I am not a lawyer and that's my understanding of licensing and copyright issues.
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 21, 2007 11:48 UTC (Thu) by i3839 (guest, #31386) [Link] The "trick" part is that Nvidia doesn't distribute any GPL code at all, so it's not bound by it. End users do the combining, and that's allowed by the GPL. You're right they (probably) can't distribute the whole, but that's the users' and distro's problem, not Nvidia's.
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 21, 2007 11:54 UTC (Thu) by cate (subscriber, #1359) [Link] But Nvidia "bridge" modules is derived from kernel (and GPL code), so implicity should be GPL or GPL compatible. They don't add license to the mid-module, to have more freedom in legal case, but anyway should be GPL compatible.
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 21, 2007 12:16 UTC (Thu) by tialaramex (subscriber, #21167) [Link] Are you sure that the bridge module source code is derived (in the legal sense) from kernel code that's only available under the GNU GPL?
There would be a hole in your argument if e.g.
(a) actually nVidia wrote all of this code by merely observing how the Linux kernel works
I suspect that (a) is true
The binary bridge module built from this source is almost certainly a derived work in the legal sense, but as far as I know nVidia deliberately do not distribute that, although many unofficial packages do.
GPL compliance issues are tearing Joomla! apart (Linux.com) Posted Jun 21, 2007 15:52 UTC (Thu) by i3839 (guest, #31386) [Link] The impression I get when reading unreadable legal copyright stuff is that the term "derived" isn't something mentioned much, let alone made clear, and that merely using other software by the interface provided by that software isn't enough to become derived work. But it's all shady and uncertain, so I won't bet on anything both ways.
Derivation Posted Jun 22, 2007 14:36 UTC (Fri) by hummassa (subscriber, #307) [Link] It is a common misconception spread thru linux mailinglists and forums that "derivative" is an unclear term.In copyright law, a "derivative work" is "the work of intellect that is novel in itself but results of the transformation of another (original) work". The classic example of a derivative work is the translation of a book (e.g. from English to French). The translator is making a new, novel work, but this work is the result of the transformation of the original work. Other examples are the creation of an abridged version of a book (Moby Dick for kids) or the creation of a screenplay based on a book (Lord of the Rings, ...). Mashups are derivative works, but in some cases and in some jurisdictions, they take small bits and pieces of each original work, falling under local "fair use"-like provisions. The USofA caselaw has lots of cases of derivation, and has a test that is used by USofAn courts to establish derivations: the "filtration, abstraction and comparison" test. Look at wp:Computer Associates Int. Inc. v. Altai Inc.
Derivation Posted Jun 22, 2007 16:45 UTC (Fri) by i3839 (guest, #31386) [Link] Interesting link, thanks.
I believe that the fogginess of the whole thing is because it's unclear what the abstraction level is applied. If you see e.g. libraries as external components, then the GPL allows non-GPL programs to use GPL libraries (which would make the LGPL redundant). But clearly many think that isn't the case and that the GPL somehow prohibits this, though I don't see how, as no GPL code is copied anywhere.
I agree that it's all clear and simple if when not copying any GPL code the work isn't bound by the GPL, which to me seems to be the case. Merely interacting with and relying on other code doesn't seem to be enough to be derivative work.
Derivation Posted Jul 2, 2007 16:08 UTC (Mon) by gwg (guest, #20811) [Link] You left out the other type of derived work, a compilation. You can create a derived work by compiling (in the literary sense) other works with attention to the selection and arrangement of the other works (think poems). So any work that includes a GPL component (unless it is "mere aggregation" - a GPL exception), is a derived work.
A plugin and the application it plugs into is a derived work, irrespective of whether the plugin itself is derived from the application. The fact that the plugin plugs into the application proves that it is not mere aggregation.
|
|||||||||||||