Modules that integrate non-GPL PHP apps violate the GPL.
For quite some time, it has been commonly understood in the Drupal community that non-GPL software (like a third-party PHP message board system) can be integrated into Drupal legally by using an intermediary 'bridge' module. After some in-depth emails with the Free Software foundation's license gurus, it's become clear that this is NOT the case. Before going any further, I want to make clear that I'm not expressing approval or disapproval of this: I'm just relaying the conclusions that were reached after several days of discussion and questioning with the FSF. Why do these modules violate the GPL? 1) Under the FSF's accepted interpretation of the GPL, if a module is integrating Drupal and another PHP script, by calling one's APIs when triggered by the other for example, its purpose is to make a single unit of software out of those parts. 2) If multiple programs are operating together and functioning as one unit, all the pieces must be GPL'd. There are a lot of angles to approach the question from, but that's what it boils down to. From a developer's perspective, if debug_backtrace() can ever include functions from both Drupal and an external program, you've turned them into a single program. There are some potential solutions, though none of them are ideal. 1) Add a notice to Drupal's license that clarifies that writing such modules IS explicitly allowed. This is problematic, however, because that would make Drupal non-GPL'd itself, a GPL variant, and we would require explicit relicensing permission by the authors of any GPL code we wish to include. 2) Remove modules that integrate with third-party non-GPL code from the CVS repository, even if they do not *include* the aforementioned non-GPL code. 3) Continue on as we are, and don't try to police these issues as there are NOT likely to be any real complaints. (No one that I know of is trying to SELL modules that integrate with non-GPL resources, for example.) This is an important question for us, and other GPL'd projects, to work through. Many GPL CMS's rely on integration components for critical functionality (message boards and mass mailing are two common examples). I can provide some detailed snippets from the correspondence to those who want them, but I'm not sure it would be useful for me to spend any more time corresponding. I exhausted my list of questions, and I'm just summarizing what I found out. --Jeff
For quite some time, it has been commonly understood in the Drupal community that non-GPL software (like a third-party PHP message board system)
If a license is GPL-Compatible http://www.gnu.org/philosophy/license-list.html is that enough? Or we need genuine GPL?
Jeff Eaton wrote:
1) Add a notice to Drupal's license that clarifies that writing such modules IS explicitly allowed. This is problematic, however, because that would make Drupal non-GPL'd itself, a GPL variant, and we would require explicit relicensing permission by the authors of any GPL code we wish to include.
Direct GPL variants are only allowed with approval of the FSF.
2) Remove modules that integrate with third-party non-GPL code from the CVS repository, even if they do not *include* the aforementioned non-GPL code.
I'm not sure that's a problem. The GPL only affects redistribution, not what a person does on his or her own computer. Just ensure the forbidden integration isn't distributed. (If I'm wrong here, I'd like to know.)
3) Continue on as we are, and don't try to police these issues as there are NOT likely to be any real complaints. (No one that I know of is trying to SELL modules that integrate with non-GPL resources, for example.)
As long as Drupal core is GPL-clean, I think this is acceptable. I don't think anyone but a lawyer would be qualified to do the policing, anyway.
David Strauss wrote:
I'm not sure that's a problem. The GPL only affects redistribution, not what a person does on his or her own computer. Just ensure the forbidden integration isn't distributed. (If I'm wrong here, I'd like to know.)
The reason I think this is the case is because the GPL code is not distributed with the non-GPL code. It's OK to distribute a C++ program that uses STL, even though there are proprietary STL implementations. It's also OK for me to compile GPL code against a proprietary STL implementation, as long as I don't redistribute the binary. The only distinction left is that some Drupal modules can *only* link to non-GPL code, but that seems to be a dubious place to draw the line. If we draw the line there, applications using Cocoa break the GPL. Applications using parts of the Windows API absent from Wine break the GPL.
David Strauss wrote:
David Strauss wrote:
I'm not sure that's a problem. The GPL only affects redistribution, not what a person does on his or her own computer. Just ensure the forbidden integration isn't distributed. (If I'm wrong here, I'd like to know.)
The reason I think this is the case is because the GPL code is not distributed with the non-GPL code.
It's OK to distribute a C++ program that uses STL, even though there are proprietary STL implementations. It's also OK for me to compile GPL code against a proprietary STL implementation, as long as I don't redistribute the binary.
The only distinction left is that some Drupal modules can *only* link to non-GPL code, but that seems to be a dubious place to draw the line. If we draw the line there, applications using Cocoa break the GPL. Applications using parts of the Windows API absent from Wine break the GPL.
Applications depending on Cocoa or Windows API *do not* violate GPL. Paragraph 3 in GPL v2 (which is used by Drupal) clearly and loudly states:
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
RTFL ;-) Regards, Thomas
David Strauss skrev:
Jeff Eaton wrote:
1) Add a notice to Drupal's license that clarifies that writing such modules IS explicitly allowed. This is problematic, however, because that would make Drupal non-GPL'd itself, a GPL variant, and we would require explicit relicensing permission by the authors of any GPL code we wish to include.
Direct GPL variants are only allowed with approval of the FSF.
Wrong. You are allowed to add ny terms and condition you which as long as long as you don't impose any further restrictions on the recipients' exercise of the rights granted in GPL. See paragraph 6 of GPL v2 (which is used by Drupal). In fact, FSF/GNU tells you to add such notice to allow use of non-GPL libraryies. Read the FAQ: * http://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense * http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs * http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface MySQL is an example of this: * http://www.mysql.com/company/legal/licensing/foss-exception.html In fact, if MySQL didn't add that notice, Drupal had not been able to use MySQL, since the PHP licence isn't compatible with GPL v2.
2) Remove modules that integrate with third-party non-GPL code from the CVS repository, even if they do not *include* the aforementioned non-GPL code.
I'm not sure that's a problem. The GPL only affects redistribution, not what a person does on his or her own computer. Just ensure the forbidden integration isn't distributed. (If I'm wrong here, I'd like to know.)
Wrong. If a module depends on a software with a license not compatible with GPL, then that module can't be distributed under GPL. Read the FAQ: * http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins * http://www.gnu.org/licenses/gpl-faq.html#MoneyGuzzlerInc
3) Continue on as we are, and don't try to police these issues as there are NOT likely to be any real complaints. (No one that I know of is trying to SELL modules that integrate with non-GPL resources, for example.)
As long as Drupal core is GPL-clean, I think this is acceptable. I don't think anyone but a lawyer would be qualified to do the policing, anyway
Isn't that to live by double standard? Why is it okay to violate the GPL when it comes to modules, but not when it comes to the core itself? The solution, IMHO, is to add a FLOSS exception to Drupal. Regards, Thomas
Thomas Barregren wrote:
Wrong. You are allowed to add ny terms and condition you which as long as long as you don't impose any further restrictions on the recipients' exercise of the rights granted in GPL. See paragraph 6 of GPL v2 (which is used by Drupal). In fact, FSF/GNU tells you to add such notice to allow use of non-GPL libraryies. Read the FAQ:
The license itself says, "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." Paragraph 6 says nothing about producing a modified version of the GPL. MySQL's exception is rendered as a separate exception document, not a modification of the GPL. This distinction is important because people redistributing the code aren't obligated to allow the exceptions granted by the original licensor. So, I stand by my statement that, "Direct GPL variants are only allowed with approval of the FSF." See the AGPL for an example of an approved variant.
I'm not sure that's a problem. The GPL only affects redistribution, not what a person does on his or her own computer. Just ensure the forbidden integration isn't distributed. (If I'm wrong here, I'd like to know.)
Wrong. If a module depends on a software with a license not compatible with GPL, then that module can't be distributed under GPL.
If you're going to call someone "wrong," you had better be right: http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs That FAQ item gives instructions for releasing something under the GPL that links to non-free libraries. I said, "The GPL only affects redistribution" because the original distributor has the right to include any exceptions in a supplement to the license. Re-distributors cannot add such an exception. However, I also said, "Just ensure the forbidden integration isn't distributed" because even the owner of the GPL software doesn't have the right to redistribute software without permission.
As long as Drupal core is GPL-clean, I think this is acceptable. I don't think anyone but a lawyer would be qualified to do the policing, anyway
Isn't that to live by double standard? Why is it okay to violate the GPL when it comes to modules, but not when it comes to the core itself?
I didn't say it was OK. I said it wasn't worth policing contributed modules.
On Aug 31, 2007, at 11:40 AM, David Strauss wrote:
The license itself says, "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." Paragraph 6 says nothing about producing a modified version of the GPL. MySQL's exception is rendered as a separate exception document, not a modification of the GPL. This distinction is important because people redistributing the code aren't obligated to allow the exceptions granted by the original licensor.
So, I stand by my statement that, "Direct GPL variants are only allowed with approval of the FSF." See the AGPL for an example of an approved variant.
The 'exception document' is an interesting idea, and I'd like to explore this concept further with some advice from the FSF. We don't want to create an altered version of the GPL (obviously), but I wonder if the exception document would make sense to include in Drupal's default download, clarifying some things like the status of theme template files, 'intermediate' integration modules, etc. As noted by the FSF, however, it's difficult to open the door to integration modules 'officially' without opening the door to closed- source modules. It becomes easy for someone to simply build their functionality as a closed source module, and wrap it in a 'compatibility layer' rather than engaging with the community and participating in the sharing of code and resources that has made the Drupal world thrive. --Jeff
David Strauss skrev:
Thomas Barregren wrote:
Wrong. You are allowed to add ny terms and condition you which as long as long as you don't impose any further restrictions on the recipients' exercise of the rights granted in GPL. See paragraph 6 of GPL v2 (which is used by Drupal). In fact, FSF/GNU tells you to add such notice to allow use of non-GPL libraryies. Read the FAQ:
The license itself says, "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." Paragraph 6 says nothing about producing a modified version of the GPL. MySQL's exception is rendered as a separate exception document, not a modification of the GPL. This distinction is important because people redistributing the code aren't obligated to allow the exceptions granted by the original licensor.
So, I stand by my statement that, "Direct GPL variants are only allowed with approval of the FSF." See the AGPL for an example of an approved variant.
It is true that the GPL itself cannot be modified without permission from FSF. But you are entitled to add a notice to allow for instance linking against non-GPLed libraries.
I'm not sure that's a problem. The GPL only affects redistribution, not what a person does on his or her own computer. Just ensure the forbidden integration isn't distributed. (If I'm wrong here, I'd like to know.)
Wrong. If a module depends on a software with a license not compatible with GPL, then that module can't be distributed under GPL.
If you're going to call someone "wrong," you had better be right:
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
That FAQ item gives instructions for releasing something under the GPL that links to non-free libraries.
Yes, but that is not what I claimed to be wrong. The problem lies in the fact that Drupal.org distributes modules which depends on non-GPLed code. That is not permitted, since Drupal.org doesn't have the proviso described in the FAQ. (I would certain endorse a such proviso.) Regards, Thomas
On Thursday, 30. August 2007, Jeff Eaton wrote:
For quite some time, it has been commonly understood in the Drupal community that non-GPL software (like a third-party PHP message board system) can be integrated into Drupal legally by using an intermediary 'bridge' module. After some in-depth emails with the Free Software foundation's license gurus, it's become clear that this is NOT the case.
Before going any further, I want to make clear that I'm not expressing approval or disapproval of this: I'm just relaying the conclusions that were reached after several days of discussion and questioning with the FSF.
Why do these modules violate the GPL?
1) Under the FSF's accepted interpretation of the GPL, if a module is integrating Drupal and another PHP script, by calling one's APIs when triggered by the other for example, its purpose is to make a single unit of software out of those parts.
My understanding was that non-GPL software may not be a derivative work of GPL code, but that it can go the other way round. As David Strauss mentioned, it is indeed possible to write GPL software by using the Win32 or Cocoa API. Following this reasoning, it would mean the following for Drupal modules: - Drupal modules are based on Drupal, so they are GPL in any case. - Thus, modules may not incorporate code that make the integrated software derive (call functions) from Drupal or the module itself. - Whereas it should be possible to call functions from the integrated software from the module. For example, that would mean no authentication in the integrated software that is based on Drupal users and passwords. Or displaying any information that comes from Drupal. But it should be possible to manage and display stuff from the integrated software from Drupal. Like is done with Apache, for example (which uses the GPLv2 incompatible Apache license). I'm sure there are lots of other good examples. Would this make sense?
2) If multiple programs are operating together and functioning as one unit, all the pieces must be GPL'd.
There are a lot of angles to approach the question from, but that's what it boils down to. From a developer's perspective, if debug_backtrace() can ever include functions from both Drupal and an external program, you've turned them into a single program.
David's argument that the GPL only covers distribution, not usage, is a good counter argument to this point of view. Of course, this is somewhat of a difficult issue, quite comparable to the kernel module blobs for the ATI and nVidia graphics card drivers which are widely considered a legal gray area. Also, you could extend the issue not only to PHP code but also to XML-RPC calls, where you do not even know if the software that you communicate with is GPL or not. That is, I'm a big fan of the FSF and their views, but I think their opinion on this specific issue is a tad too radical, and not legally binding as well. Regards, Jakob
On Aug 30, 2007, at 7:02 AM, Jakob Petsovits wrote:
My understanding was that non-GPL software may not be a derivative work of GPL code, but that it can go the other way round. As David Strauss mentioned, it is indeed possible to write GPL software by using the Win32 or Cocoa API.
Following this reasoning, it would mean the following for Drupal modules: - Drupal modules are based on Drupal, so they are GPL in any case. - Thus, modules may not incorporate code that make the integrated software derive (call functions) from Drupal or the module itself. - Whereas it should be possible to call functions from the integrated software from the module.
This was my understanding for a while, but the FSF's position is that the use of the thre components together creates a single piece of software, at least when implemented in the way that bridge modules generally do. GPL software *may not derive from non-GPL components* unless the copyright holders make them GPL'd as well. This is, according to the GPL, to protect the GPL license from being abused by companies that write proprietary software with a thing GPL'd "wrapper" that is useless when not used with the pricey software.
For example, that would mean no authentication in the integrated software that is based on Drupal users and passwords. Or displaying any information that comes from Drupal. But it should be possible to manage and display stuff from the integrated software from Drupal. Like is done with Apache, for example (which uses the GPLv2 incompatible Apache license). I'm sure there are lots of other good examples.
Would this make sense?
That's similar to a question I asked. The issue ultimately lies in HOW the software is integrated. 'loosely coupled' mechanisms like REST, most XMLRPC stuff, direct manipulation of databases without calling APIs, etc., are generally OK because they are 'standard mechanisms that separate porgrams use to communicate with each other.' No matter what we call it, most bridge modules ultimately work out to: "Program 2 is sucked into the execution chain of some Drupal code, via a bridge module." I'll quote Brett Smith, the helpful GPL guy who spent a couple days hashing this out with me. ---- Perhaps you meant some kind of web services API, like a REST interface. That's a little more borderline. There could also be other ways to construct the bridge that even more clearly avoid making a derivative work. For example, if the bridge didn't call functions from either program, and instead just read from or wrote to their underlying databases directly, that probably wouldn't create a derivative work. If there were command-line tools available that the bridge could call to help with its work, using system() or similar functionality, that probably wouldn't make a derivative work either. I should also point out that if CMS developers want to make this sort of bridge development unambiguously okay, they could do so by providing some sort of licensing exception as described at <http://www.fsf.org/licensing/licenses/gpl- faq.html#LinkingOverControlledInterface>. This requires the assent of all the copyright holders, so I realize it may not be a feasible option for every free CMS, but it is out there. ----
David's argument that the GPL only covers distribution, not usage, is a good counter argument to this point of view. Of course, this is somewhat of a difficult issue, quite comparable to the kernel module blobs for the ATI and nVidia graphics card drivers which are widely considered a legal gray area.
Also, you could extend the issue not only to PHP code but also to XML-RPC calls, where you do not even know if the software that you communicate with is GPL or not.
Regarding graphics cards and so on, I asked the same question: ---- "So, for example, we believe that programs that merely run on top of a given kernel are not derivative works of that kernel, even if they make basic system calls that the kernel provides. Because of this, the license of the kernel doesn't matter to a GPLed application. "The second thing that comes into play is called the System Library exception. This isn't the technical definition, but in short, the GPL also doesn't worry about the licenses of libraries that are essential to the operating system. This is also in the fifth paragraph of section 2." ---- While the GPL only covers distribution, they consider it a GPL violation to *distribute software that is intended to be used in violation of the GPL*. In other words, distributing a proprietary commercial piece of software that relies on GPL libraries, and telling people, 'We can't put X into our program, but you can to make it work...' is creating a GPL-derived program just as much as rolling the GPL'd libraries in and then distributing. So, while no one is going to root around your server seeing if you've called include() on something non-GPL, distributing that middle component is, in the FSF's eyes, an attempt to circumvent the GPL. I'll quote again: ---- "The developers of the bridge are just looking to accomplish a particular task and find a license that doesn't get them in trouble. Unlike my scenario, nobody's obviously scheming to thwart the GPL. But when you just look at the structure of all the code when all's said and done, the two cases look very similar. And the structure of the code is overwhelmingly what concerns copyright law. It would be very hard to distinguish between these cases in a legally secure way in the license." ---- Again, I want to make clear that I'm not saying that I agree or disagree, just that I went through the work of asking and clarifying the FSF's position on a lot of these edge case questions, and hope to clarify. More than anything, I want to make sure that the advice we give to other developers when we're asked, "Hey! Can I do X?" is accurate. I should also clarify that in our discussions it was obvious that things like images, CSS, HTML, etc was NOT in fact covered. So, for example, it would be perfectly legal to create a Drupal theme that consists of nothing but images and CSS files (using drupal 6's new .info file format) and release it under a non-GPL license. Obviously, it couldn't be checked into Drupal's CVS repository in that case. --Jeff
Hrm. So, a few applied examples: Suppose for a moment that TinyMCE was non-GPL. Someone other than the TinyMCE authors writes our TinyMCE module, which is a wrapper with value-add around TinyMCE to make it work in Drupal. The TinyMCE module is distributed GPL, and end-users are expected to download TinyMCE themselves and put them together. There is no distribution of the combined code. Legal or illegal? I was always under the impression that was legal, since there was no distribution of non-GPLed code and GPLed code together. nVidia is, too, since that's how the nvidia drivers for Linux work. :-) (non-Free driver and GPLed wrapper that goes into the kernel.) Scenario 2: A theme engine that is designed to consume non-PHPTemplate template files produced by a non-Free system, such as Dreamweaver or a design-time CMS. Legal or illegal? I was also under the impression this was legal, since the engine is GPLed and the files generated by the non-Free system are technically output of it (which is explicitly not affected by the GPL) rather than the code itself. (A linked work, according to the FSF's GPL FAQ (wow that's a lot of TLAs), means sharing the same memory space or data structures in memory. PHP certainly does that, as each server process has only one memory space and code can access any data structure it wants.) --Larry Garfield On Thu, 30 Aug 2007 09:32:56 -0500, Jeff Eaton <jeff@viapositiva.net> wrote:
On Aug 30, 2007, at 7:02 AM, Jakob Petsovits wrote:
My understanding was that non-GPL software may not be a derivative work of GPL code, but that it can go the other way round. As David Strauss mentioned, it is indeed possible to write GPL software by using the Win32 or Cocoa API.
Following this reasoning, it would mean the following for Drupal modules: - Drupal modules are based on Drupal, so they are GPL in any case. - Thus, modules may not incorporate code that make the integrated software derive (call functions) from Drupal or the module itself. - Whereas it should be possible to call functions from the integrated software from the module.
This was my understanding for a while, but the FSF's position is that the use of the thre components together creates a single piece of software, at least when implemented in the way that bridge modules generally do. GPL software *may not derive from non-GPL components* unless the copyright holders make them GPL'd as well. This is, according to the GPL, to protect the GPL license from being abused by companies that write proprietary software with a thing GPL'd "wrapper" that is useless when not used with the pricey software.
For example, that would mean no authentication in the integrated software that is based on Drupal users and passwords. Or displaying any information that comes from Drupal. But it should be possible to manage and display stuff from the integrated software from Drupal. Like is done with Apache, for example (which uses the GPLv2 incompatible Apache license). I'm sure there are lots of other good examples.
Would this make sense?
That's similar to a question I asked. The issue ultimately lies in HOW the software is integrated. 'loosely coupled' mechanisms like REST, most XMLRPC stuff, direct manipulation of databases without calling APIs, etc., are generally OK because they are 'standard mechanisms that separate porgrams use to communicate with each other.' No matter what we call it, most bridge modules ultimately work out to: "Program 2 is sucked into the execution chain of some Drupal code, via a bridge module."
I'll quote Brett Smith, the helpful GPL guy who spent a couple days hashing this out with me.
---- Perhaps you meant some kind of web services API, like a REST interface. That's a little more borderline.
There could also be other ways to construct the bridge that even more clearly avoid making a derivative work. For example, if the bridge didn't call functions from either program, and instead just read from or wrote to their underlying databases directly, that probably wouldn't create a derivative work. If there were command-line tools available that the bridge could call to help with its work, using system() or similar functionality, that probably wouldn't make a derivative work either.
I should also point out that if CMS developers want to make this sort of bridge development unambiguously okay, they could do so by providing some sort of licensing exception as described at <http://www.fsf.org/licensing/licenses/gpl- faq.html#LinkingOverControlledInterface>. This requires the assent of all the copyright holders, so I realize it may not be a feasible option for every free CMS, but it is out there. ----
David's argument that the GPL only covers distribution, not usage, is a good counter argument to this point of view. Of course, this is somewhat of a difficult issue, quite comparable to the kernel module blobs for the ATI and nVidia graphics card drivers which are widely considered a legal gray area.
Also, you could extend the issue not only to PHP code but also to XML-RPC calls, where you do not even know if the software that you communicate with is GPL or not.
Regarding graphics cards and so on, I asked the same question:
---- "So, for example, we believe that programs that merely run on top of a given kernel are not derivative works of that kernel, even if they make basic system calls that the kernel provides. Because of this, the license of the kernel doesn't matter to a GPLed application.
"The second thing that comes into play is called the System Library exception. This isn't the technical definition, but in short, the GPL also doesn't worry about the licenses of libraries that are essential to the operating system. This is also in the fifth paragraph of section 2." ----
While the GPL only covers distribution, they consider it a GPL violation to *distribute software that is intended to be used in violation of the GPL*. In other words, distributing a proprietary commercial piece of software that relies on GPL libraries, and telling people, 'We can't put X into our program, but you can to make it work...' is creating a GPL-derived program just as much as rolling the GPL'd libraries in and then distributing.
So, while no one is going to root around your server seeing if you've called include() on something non-GPL, distributing that middle component is, in the FSF's eyes, an attempt to circumvent the GPL. I'll quote again:
---- "The developers of the bridge are just looking to accomplish a particular task and find a license that doesn't get them in trouble. Unlike my scenario, nobody's obviously scheming to thwart the GPL. But when you just look at the structure of all the code when all's said and done, the two cases look very similar. And the structure of the code is overwhelmingly what concerns copyright law. It would be very hard to distinguish between these cases in a legally secure way in the license." ----
Again, I want to make clear that I'm not saying that I agree or disagree, just that I went through the work of asking and clarifying the FSF's position on a lot of these edge case questions, and hope to clarify.
More than anything, I want to make sure that the advice we give to other developers when we're asked, "Hey! Can I do X?" is accurate.
I should also clarify that in our discussions it was obvious that things like images, CSS, HTML, etc was NOT in fact covered. So, for example, it would be perfectly legal to create a Drupal theme that consists of nothing but images and CSS files (using drupal 6's new .info file format) and release it under a non-GPL license. Obviously, it couldn't be checked into Drupal's CVS repository in that case.
--Jeff
Larry Garfield skrev:
Hrm. So, a few applied examples:
Suppose for a moment that TinyMCE was non-GPL. Someone other than the TinyMCE authors writes our TinyMCE module, which is a wrapper with value-add around TinyMCE to make it work in Drupal. The TinyMCE module is distributed GPL, and end-users are expected to download TinyMCE themselves and put them together. There is no distribution of the combined code. Legal or illegal?
Illegal. See * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MoneyGuzzlerInc. However, if both Drupal and the module makes an exception, it is legal. There are two common exceptions made: The FLOSS Exception and the Controlled Interface Exception. See * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLib... * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingOverControl...
I was always under the impression that was legal, since there was no distribution of non-GPLed code and GPLed code together. nVidia is, too, since that's how the nvidia drivers for Linux work. :-) (non-Free driver and GPLed wrapper that goes into the kernel.)
Scenario 2: A theme engine that is designed to consume non-PHPTemplate template files produced by a non-Free system, such as Dreamweaver or a design-time CMS. Legal or illegal?
Legal. The output of Drupal is not a derivative work based on Drupal. Hence GPL don't apply. Furthermore, the template is just data to Drupal. There are several related answers in the GPL FAQ. Here are a few: * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#CanIUseGPLToolsFor... * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLOutput * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#WMS Best regards, Thomas
First, mandatory disclaimer: IANAL, so this is only an interpretation in general terms, not advice to anyone, for which they'd have to consult a lawyer. This being said... The last "obviously" is not so obvious: since committers have had to agree to only submitting code to be distributed by d.o. under GPLv2, everything they commit will be distributed by d.o. under that license. But it does not prevent *additional* licenses to be available for the same code, as long as they are compatible with the GPLv2. Case in point: my own modules are originally created and distributed under the CeCILL 2.0, because the GPL has various issues under french law. According to both the FSF and the CeCILL authors, both licenses are compatible with each other, so no incompatibility arises. Details at: http://www.fsf.org/licensing/licenses#CeCILL http://www.cecill.info/licences.en.html Now, since I commit this code to d.o., I have to make it available from d.o. under the GPLv2 (actually: licensing it to d.o. under the GPLv2), because this is a prerequisite to be allowed to commit there. As a consequence, any user obtaining the code from d.o. obtains it under both licenses, at his choice: the GPLv2, available for everything downloaded from d.o. due the requirement on committers, or CeCILLv2, because an *additional* compatible license to GPLv2 has been specified in the module files. This is only possible because the license are compatible, otherwise this would be a violation of the GPL and possibly of the other license, but any user will probably want to use the product under the CeCILL because it is better for them. There's a rather good explanation on wikipedia, even better than on the very site of the CeCILL: http://en.wikipedia.org/wiki/CeCILL#CeCILL_version_2 The same dual (or even multiple) licensing mechanism would work with any GPL-compatible license. Not there are that many available, actually... So code released under a non-GPL license can be checked into Drupal's CVS repository, as long as: - it is also released under the GPL - the other license does not prevent it. FGM ----- Original Message ----- From: "Jeff Eaton" <jeff@viapositiva.net> To: <development@drupal.org> Sent: Thursday, August 30, 2007 4:32 PM Subject: Re: [development] Modules that integrate non-GPL PHP apps violatethe GPL. [...]
So, for example, it would be perfectly legal to create a Drupal theme that consists of nothing but images and CSS files (using drupal 6's new .info file format) and release it under a non-GPL license. Obviously, it couldn't be checked into Drupal's CVS repository in that case.
--Jeff
On Aug 30, 2007, at 1:06 PM, FGM wrote:
So code released under a non-GPL license can be checked into Drupal's CVS repository, as long as: - it is also released under the GPL - the other license does not prevent it.
FGM, that's correct. Sorry I was unclear when I said that. :) The only caveat mentioned by the FSF was that such dual-licensing would NOT be an acceptable workaround to the 'bridge code' problem. In other words, "Drupal is GPL, my module is GPL AND LGPL, so the piece that connects to my module isn't affected by the GPL" is invalid due to the fact that anything sharing address space with Drupal (ie, included PHP files) has to be compatible with ITS license, not just the module's license. --Jeff
Indeed. Which brings back the web services loophole. I reread about it, and it appears it wasn't eventually closed in GPLv3: they created the Affero GPL for that specific purpose. http://gplv3.fsf.org/agplv3-dd1-guide.html I suppose this improves the likelihood of more code being moved over to GPLv3. The AGPL provisions should only appeal to a limited crowd. ----- Original Message ----- From: "Jeff Eaton" <jeff@viapositiva.net> To: <development@drupal.org> Sent: Thursday, August 30, 2007 8:19 PM Subject: Re: [development] Modules that integrate non-GPL PHP appsviolatethe GPL.
On Aug 30, 2007, at 1:06 PM, FGM wrote:
So code released under a non-GPL license can be checked into Drupal's CVS repository, as long as: - it is also released under the GPL - the other license does not prevent it.
FGM, that's correct. Sorry I was unclear when I said that. :)
The only caveat mentioned by the FSF was that such dual-licensing would NOT be an acceptable workaround to the 'bridge code' problem. In other words, "Drupal is GPL, my module is GPL AND LGPL, so the piece that connects to my module isn't affected by the GPL" is invalid due to the fact that anything sharing address space with Drupal (ie, included PHP files) has to be compatible with ITS license, not just the module's license.
--Jeff
On Aug 30, 2007, at 8:32 AM, Jeff Eaton wrote:
GPL software *may not derive from non-GPL components* unless the copyright holders make them GPL'd as well. This is, according to the GPL, to protect the GPL license from being abused by companies that write proprietary software with a thing GPL'd "wrapper" that is useless when not used with the pricey software.
I'm all behind this reasoning. However....
I'll quote Brett Smith, the helpful GPL guy who spent a couple days hashing this out with me.
---- Perhaps you meant some kind of web services API, like a REST interface. That's a little more borderline.
There could also be other ways to construct the bridge that even more clearly avoid making a derivative work. For example, if the bridge didn't call functions from either program, and instead just read from or wrote to their underlying databases directly, that probably wouldn't create a derivative work. If there were command-line tools available that the bridge could call to help with its work, using system() or similar functionality, that probably wouldn't make a derivative work either.
I should also point out that if CMS developers want to make this sort of bridge development unambiguously okay, they could do so by providing some sort of licensing exception as described at <http://www.fsf.org/licensing/licenses/gpl- faq.html#LinkingOverControlledInterface>. This requires the assent of all the copyright holders, so I realize it may not be a feasible option for every free CMS, but it is out there.
This reasoning seems to employ arguments made by the RIAA and MPAA, except to opposite effect. I write this as a GPL advocate and a big believer in open source. GPL open source software is greatly advantaged to dominate the software world eventually, but trying to force that through legal ownership assertions strikes me as a great way to undermine the whole movement. For example, this API argument: by prohibiting use of APIs to bridge differently-licensed applications (and aren't APIs developed *precisely* to bridge two different applications?) we're forcing a "dumbing down" of work (and sundry other potential problems and risks) by legally requiring the bypassing of established application methodologies (such as security protocols) to write direct queries to databases. How are we going to build an integrated world when GPL starts claiming rights to all that touch it? We're going from the freedom that comes from building a commons to the restriction that comes from making that commons a fenced-in zoo. Maybe I'm wrong and going off in high spirits for no reason. The net result, I fear, is the creation of a GPL ghetto where anybody with one foot in the proprietary -- i.e., real -- world is given reason to hesitate coming within a country mile of GPL, just when GPL apps are poised (and have already started) to transform the mainstream business world. Vivek Purl wrote:
Just for background this issue has come up because Joomla have decided to "fully" comply with GPL. This raised a few question for SMF team and they discussed it with FSF. The final result of that discussion is if php ( or any other scripting language ) which is distributed in source form is bridged to a non GPL software also distributed in source form then it violates the GPL.
The immediate effect for drupal is that VB and SMF bridges are violating GPL. It doesn't matter if its being distributed via d.o. or not.
So GPL apps are prohibited from touching non-GPL apps. I'll be snarky and say this is the kind of thing that happens when lawyers get involved. Time to stop developing software and start developing new licenses and lawsuits! Laura (who's still wondering what was wrong with GPLv2)
At 23.04 30/08/2007, you wrote: <delurking>
For example, this API argument: by prohibiting use of APIs to bridge differently-licensed applications (and aren't APIs developed *precisely* to bridge two different applications?) we're forcing a "dumbing down" of work (and sundry other potential problems and risks) by legally requiring the bypassing of established application methodologies (such as security protocols) to write direct queries to databases.
If GPL programs do exist in windows (and mac) environments it is fairly obvious that use API of differently-licensed applications... or they write pixels directly in the graphic card and sectors directly in the hard disk? Sorry to be rude but this had to be said this way... if I'm wrong I apologize, but I think I'm not. </delurking> Ciao! --8<-----------------------------------fnord----- Piermaria Maraziti piermaria@maraziti.it KALLISTI ICQ744473 MSN:kallisti@hotmail.it +3934735GILDA www.gilda.it www.eridia.it www.hovistocose.it
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Piermaria Maraziti schrieb:
At 23.04 30/08/2007, you wrote:
<delurking>
For example, this API argument: by prohibiting use of APIs to bridge differently-licensed applications (and aren't APIs developed *precisely* to bridge two different applications?) we're forcing a "dumbing down" of work (and sundry other potential problems and risks) by legally requiring the bypassing of established application methodologies (such as security protocols) to write direct queries to databases.
If GPL programs do exist in windows (and mac) environments it is fairly obvious that use API of differently-licensed applications... or they write pixels directly in the graphic card and sectors directly in the hard disk?
Sorry to be rude but this had to be said this way... if I'm wrong I apologize, but I think I'm not.
You are completely wrong and you had better stayed in some dark corner. The "problem" we are facing is due to the nature of how PHP and probably other scripting languages work. The situation isn't comparable to a compiled programms. One could argue that one shouldn't place PHP programms under the GPL license. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG10/Ifg6TFvELooQRAjQwAJ9Gd/Fa1wyyzBdOCoUoU/X1R9p4EACgpj9m yAQXsDpzuHapE0cB3hf10OA= =f12K -----END PGP SIGNATURE-----
Is there a similar situation with javascript executing in the browser environment? It's common to integrate various javascript libraries which may have different licenses (and pull in js from other sites via <script> tags) --mark On 8/30/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Piermaria Maraziti schrieb:
At 23.04 30/08/2007, you wrote:
<delurking>
For example, this API argument: by prohibiting use of APIs to bridge differently-licensed applications (and aren't APIs developed *precisely* to bridge two different applications?) we're forcing a "dumbing down" of work (and sundry other potential problems and risks) by legally requiring the bypassing of established application methodologies (such as security protocols) to write direct queries to databases.
If GPL programs do exist in windows (and mac) environments it is fairly obvious that use API of differently-licensed applications... or they write pixels directly in the graphic card and sectors directly in the hard disk?
Sorry to be rude but this had to be said this way... if I'm wrong I apologize, but I think I'm not.
You are completely wrong and you had better stayed in some dark corner.
The "problem" we are facing is due to the nature of how PHP and probably other scripting languages work. The situation isn't comparable to a compiled programms.
One could argue that one shouldn't place PHP programms under the GPL license.
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG10/Ifg6TFvELooQRAjQwAJ9Gd/Fa1wyyzBdOCoUoU/X1R9p4EACgpj9m yAQXsDpzuHapE0cB3hf10OA= =f12K -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 mark burdett schrieb:
Is there a similar situation with javascript executing in the browser environment? It's common to integrate various javascript libraries which may have different licenses (and pull in js from other sites via <script> tags)
That's a very interesting question. I guess the FSF guy would happily discuss this with you. Let us know what he says. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG11awfg6TFvELooQRAmgcAKCL98oncaRTzxEEpc5oAgBjwWZ6pgCgt5nd Vl24O60+MBYR3cFNUp1LVWE= =sPhT -----END PGP SIGNATURE-----
--- mark burdett <mfburdett@gmail.com> wrote:
Is there a similar situation with javascript executing in the browser environment? It's common to integrate various javascript libraries which may have different licenses (and pull in js from other sites via <script> tags)
You have a valid point but as I see most prominent javascript libraries are distributed either under BSD, LGPL or MIT licenses. And these licenses are somewhat liberal in this sense. Again you are free to mix and match as long as you dont distribute. If you start distributing GPL software with other's the other license must be GPL compatible. ____________________________________________________________________________________ Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/
mark burdett skrev:
Is there a similar situation with javascript executing in the browser environment? It's common to integrate various javascript libraries which may have different licenses (and pull in js from other sites via <script> tags)
Please read http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#WMS Best regards, Thomas
Gerhard Killesreiter skrev:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Piermaria Maraziti schrieb:
At 23.04 30/08/2007, you wrote:
<delurking>
For example, this API argument: by prohibiting use of APIs to bridge differently-licensed applications (and aren't APIs developed *precisely* to bridge two different applications?) we're forcing a "dumbing down" of work (and sundry other potential problems and risks) by legally requiring the bypassing of established application methodologies (such as security protocols) to write direct queries to databases.
If GPL programs do exist in windows (and mac) environments it is fairly obvious that use API of differently-licensed applications... or they write pixels directly in the graphic card and sectors directly in the hard disk?
Sorry to be rude but this had to be said this way... if I'm wrong I apologize, but I think I'm not.
You are completely wrong and you had better stayed in some dark corner.
The "problem" we are facing is due to the nature of how PHP and probably other scripting languages work. The situation isn't comparable to a compiled programms.
One could argue that one shouldn't place PHP programms under the GPL license.
I wonder if you have misunderstood the subject of the discussion. The issue original brought up by Jeff Eaton was about the fact that it is not permissible to write modules that bridge software with a license not compatible with GPL. But I cannot refrain from asking what problem you see with "the nature of how PHP and probably other scripting languages work."? If it is the meaning of "linking" you are troubled by, please read: * http://www.gnu.org/licenses/lgpl-java.html If it is the fact that program in a scripting language is linked with its interpreter, please read: * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#InterpreterIncompa.... * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL Best regards, Thomas
If GPL programs do exist in windows (and mac) environments it is fairly obvious that use API of differently-licensed applications... or they write pixels directly in the graphic card and sectors directly in the hard disk?
The difference here could be that these are compiled programs and DLLs... could be different legalese than a script lang like PHP.
At 01.50 31/08/2007, you wrote:
The difference here could be that these are compiled programs and DLLs... could be different legalese than a script lang like PHP.
It is a fairly small difference to me. An API is an API and the fact that it is compiled in a DLL or scripted, apart from the visibility of code has no real philosophical or legalese difference. #include in a scripting language or dll loading instructions in C/C++/Delphi are, semantically, equivalent and the difference that in the first case PHP will parse & tokenize the non-GPL'ed script on the fly while the DLL was compiled away and given as-is is a minor one. Please, if you tell me I'm "completely wrong" at least have the kindness of saying me why. Thanks. :-) Added: I just read from Thomas about the "Paragraph 3 in GPL v2". This is a completely different thing obviously. However, I saw Delphi programs distributed under GPL and they probably include Delphi (redistributable) libraries. Are, perhaps, the authors of those programs interpreting in a wrong way the GPL? If so I retire in good order ;-) Ciao! --8<-----------------------------------fnord----- Piermaria Maraziti piermaria@maraziti.it KALLISTI ICQ744473 MSN:kallisti@hotmail.it +3934735GILDA www.gilda.it www.eridia.it www.hovistocose.it
On Aug 31, 2007, at 3:45 AM, Piermaria Maraziti wrote:
At 01.50 31/08/2007, you wrote:
The difference here could be that these are compiled programs and DLLs... could be different legalese than a script lang like PHP.
It is a fairly small difference to me. An API is an API and the fact that it is compiled in a DLL or scripted, apart from the visibility of code has no real philosophical or legalese difference.
Actually, according to the terms of the GPL, and the FSF's interpretation of it and the public FAQs they have posted, *only DLLs that are part of the OS would be allowed to the included in such a way*. --Jeff
On Friday 31 August 2007, Piermaria Maraziti wrote:
At 01.50 31/08/2007, you wrote:
The difference here could be that these are compiled programs and DLLs... could be different legalese than a script lang like PHP.
It is a fairly small difference to me. An API is an API and the fact that it is compiled in a DLL or scripted, apart from the visibility of code has no real philosophical or legalese difference. #include in a scripting language or dll loading instructions in C/C++/Delphi are, semantically, equivalent and the difference that in the first case PHP will parse & tokenize the non-GPL'ed script on the fly while the DLL was compiled away and given as-is is a minor one.
Please, if you tell me I'm "completely wrong" at least have the kindness of saying me why. Thanks. :-)
Actually there is a legal difference between "statically linked" and "dynamically linked" (DLL) code. That's why the GPL and LGPL exist as two separate licenses. Of course, that predates the concept of powerful interpreted languages (PHP), "everything is dynamic by design" languages (Java), etc. I don't know off hand if that distinction has been tested in court yet in interpreted languages (but lots of LGPLed code exists for in PHP, like Smarty, so it seems the common wisdom is that it's OK, rightly or wrongly.) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Larry Garfield skrev:
On Friday 31 August 2007, Piermaria Maraziti wrote:
At 01.50 31/08/2007, you wrote:
The difference here could be that these are compiled programs and DLLs... could be different legalese than a script lang like PHP.
It is a fairly small difference to me. An API is an API and the fact that it is compiled in a DLL or scripted, apart from the visibility of code has no real philosophical or legalese difference. #include in a scripting language or dll loading instructions in C/C++/Delphi are, semantically, equivalent and the difference that in the first case PHP will parse & tokenize the non-GPL'ed script on the fly while the DLL was compiled away and given as-is is a minor one.
Please, if you tell me I'm "completely wrong" at least have the kindness of saying me why. Thanks. :-)
Actually there is a legal difference between "statically linked" and "dynamically linked" (DLL) code. That's why the GPL and LGPL exist as two separate licenses.
Could you please explain this "legal difference". Regards, Thomas
Quoting Thomas Barregren <thomas@webbredaktoren.se>:
Could you please explain this "legal difference".
LGPL libraries allows for use of the binary version of that library by other binaries without infecting the using binary with the GPL while GPL libraries (static or dynamic linked) force the GPL on the binaries using the library. There is no difference for distribution of the LGPL binary or source. Note, the libstdc++ library adds other statements of use so that you can include its header files in your proprietary source with infecting that source or binary with the GPL. I find it amusing that a discussion of "non-GPL *PHP* apps" is ensuing because PHP itself isn't L/GPL. I would almost label this thread as an example of oxymoron. But, however, my use of the Drupal API (a CMS library covered by a version of the GPL license) requires that my source also be GPL. If my code can be used without the Drupal library then that requirement doesn't fit and I am free to license as I please. If my source requires another library that isn't GPL but still requires Drupal (a GPL licensed library) then I am still forced to cover my source with GPL. My use of the non-GPL licensed library does not force Drupal to the license of the other library. My use of the non-GPL licensed library along with Drupal doesn't force my code to be covered by the other library either unless it is ``copyleft'' as well in which case I'm screwed. All-in-all, I can use Drupal along with all of the other programs I use. Drupal CVS can store contributed modules even if it includes non-GPL modules without affecting Drupal since the contribution isn't required to execute Drupal. No one can force me to not use GPL alongside non-GPL or force me to not use GPL on Windows or any other proprietary system. Earnie
Earnie Boyd skrev:
Quoting Thomas Barregren <thomas@webbredaktoren.se>:
Could you please explain this "legal difference".
LGPL libraries allows for use of the binary version of that library by other binaries without infecting the using binary with the GPL while GPL libraries (static or dynamic linked) force the GPL on the binaries using the library.
True. But there is no need to make a distinction between static and dynamic linked libraries.
...
I find it amusing that a discussion of "non-GPL *PHP* apps" is ensuing because PHP itself isn't L/GPL. I would almost label this thread as an example of oxymoron.
:-)
But, however, my use of the Drupal API (a CMS library covered by a version of the GPL license) requires that my source also be GPL.
No, you are free to *use* the Drupal API without your source being GPLed. But you are not allowed to *distribute* your source under another license than GPL if it make use of the Drupal API. It is important to keep this distinction clear, since much of the confusion in this thread comes from people erroneous believing that they cannot use Drupal with non-GPLed program, or help other (e.g. on consultant basis) to do that, when GPL in fact gives this right.
If my code can be used without the Drupal library then that requirement doesn't fit and I am free to license as I please.
True, *if* your code make no use whatsoever of Drupal or another GPLed software. But, if your code make reference to objects, functions, arrays or other internals of the Drupal API (or another GPLed software), then it must be distributed under GPL even if it works without Drupal present.
If my source requires another library that isn't GPL but still requires Drupal (a GPL licensed library) then I am still forced to cover my source with GPL.
True *if* your code make reference to objects, functions, arrays or other internals of the Drupal API. But, if your code don't make use of objects, functions, arrays or other internals of the Drupal API, but just requires Drupal to provide HTML or XML or JSON or similar over HTTP, your code can legally be distributed under another license other than GPL. (Although it might be against the spirit of GPL.)
My use of the non-GPL licensed library does not force Drupal to the license of the other library.
Of course not, since nobody than the collective owners of Drupal's Intellectual Property Rights can distribute Drupal under another license than GPL.
My use of the non-GPL licensed library along with Drupal doesn't force my code to be covered by the other library either unless it is ``copyleft'' as well in which case I'm screwed.
You are only "screwed" if you want to distribute a work derived from a GPLed software and another software which is under a license not compatible with GPL.
All-in-all, I can use Drupal along with all of the other programs I use.
True.
Drupal CVS can store contributed modules even if it includes non-GPL modules without affecting Drupal since the contribution isn't required to execute Drupal.
Completely wrong! For a a contributed module to be meaningful, it must implement at least one hook, and probably also call some function or use some data-structure provided by Drupal. Thus, the module is a derived work of Drupal. Since Drupal is provided under GPL, it follows that the module cannot be distributed under any other license than GPL. Now, if the module is stored in Drupal's CVS, anyone can check it out, and thereby making Drupal.org a distributor of the module. Consequently, the Drupal CVS should not store contributed modules which can't be distributed under GPL. Please, notice the wording in the last sentence. If an identifiable section of the module is not derived from Drupal (or another GPLed software), and obviously is a separate work, e.g. a library, then that part doesn't need to be under GPL to begin with. But, when that section is distributed as part of a module, GPL applies to it as well. That is the reason why third-party libraries and similar must be under a license compatible with GPL. Thus, from a legal perspective, it is okay for a module to contain non-GPLed parts, e.g. libraries, as long as (i) they have nothing to do with Drupal (or another GPLed software) and (ii) they are under a GPL compatible license, e.g. BSD, MIT or LGPL. However, Drupal.org doesn't allow this.
No one can force me to not use GPL alongside non-GPL or force me to not use GPL on Windows or any other proprietary system.
No one can force you to use GPL, but... "However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it." See § 5 of GPL v2 Regards, Thomas
Earnie, You said that "...there is a legal difference between 'statically linked' and 'dynamically linked' (DLL) code." And "[t]hat's why the GPL and LGPL exist as two separate licenses." Since I am not aware of a *legal difference* I wondered if I might have missed some subtlety. After all, I am not a lawyer. So that is why I asked you to "explain this 'legal difference'." Unfortunately, I didn't find the answer in your otherwise very interesting, but partly wrong, reply. I claim that there is no legal difference between statically and dynamically linked code. Let us assume you have developed a program P which depends on objects or functions in a library L. Also assume that you have obtained L under GPL. Now, it doesn't matter whether P links to L at compile time (static linking) or at runtime (dynamic linking). You are in both cases obliged to use GPL when distributing P. In fact, the preamble of LGPL v2 explicit states that there is no difference between statically linked and dynamically linked (a.k.a. shared) libraries: "When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library." As a corollary, I claim there is another motivation of LGPL. Quoting LGPL v2 again: For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Regards, Thomas
Quoting Thomas Barregren <thomas@webbredaktoren.se>:
Earnie,
You said that "...there is a legal difference between 'statically linked' and 'dynamically linked' (DLL) code." And "[t]hat's why the GPL and LGPL exist as two separate licenses."
I don't think that was me. I did respond to the query to explain.
Since I am not aware of a *legal difference* I wondered if I might have missed some subtlety. After all, I am not a lawyer. So that is why I asked you to "explain this 'legal difference'." Unfortunately, I didn't find the answer in your otherwise very interesting, but partly wrong, reply.
LGPL provides an exception to the use of the library API.
I claim that there is no legal difference between statically and dynamically linked code. Let us assume you have developed a program P which depends on objects or functions in a library L. Also assume that you have obtained L under GPL. Now, it doesn't matter whether P links to L at compile time (static linking) or at runtime (dynamic linking). You are in both cases obliged to use GPL when distributing P.
In fact, the preamble of LGPL v2 explicit states that there is no difference between statically linked and dynamically linked (a.k.a. shared) libraries:
"When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library."
As a corollary, I claim there is another motivation of LGPL. Quoting LGPL v2 again:
For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License.
In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system.
All I can say is that I agree. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Earnie Boyd skrev:
Quoting Thomas Barregren <thomas@webbredaktoren.se>:
Earnie,
You said that "...there is a legal difference between 'statically linked' and 'dynamically linked' (DLL) code." And "[t]hat's why the GPL and LGPL exist as two separate licenses."
I don't think that was me. I did respond to the query to explain.
You are right. I am sorry. It was Larry Garfield who said that. Best regards, Thomas
I write this as a GPL advocate and a big believer in open source.
ahem whats the point of advocating something which you don't understand ?
How are we going to build an integrated world when GPL starts claiming rights to all that touch it?
That has always been the case, don't you know GPL is also called viral license for a reason ;)
So GPL apps are prohibited from touching non-GPL apps. I'll be snarky and say this is the kind of thing that happens when lawyers get involved. Time to stop developing software and start developing new licenses and lawsuits!
Unfortunately like many you misunderstood GPL to be free as in beer. This issue is not new interpretation its has always been like that. People started building bridges between GPl & proprietary licensed software without fully understanding GPL ( this is all relevant to software distributed in source form)
Laura (who's still wondering what was wrong with GPLv2)
This issue is relevant to GPLv2 we are not even discussing impact of GPLv3
____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
Laura Scott wrote:
On Aug 30, 2007, at 8:32 AM, Jeff Eaton wrote:
GPL software *may not derive from non-GPL components* unless the copyright holders make them GPL'd as well. This is, according to the GPL, to protect the GPL license from being abused by companies that write proprietary software with a thing GPL'd "wrapper" that is useless when not used with the pricey software.
I'm all behind this reasoning. However....
I'll quote Brett Smith, the helpful GPL guy who spent a couple days hashing this out with me.
---- Perhaps you meant some kind of web services API, like a REST interface. That's a little more borderline.
There could also be other ways to construct the bridge that even more clearly avoid making a derivative work. For example, if the bridge didn't call functions from either program, and instead just read from or wrote to their underlying databases directly, that probably wouldn't create a derivative work. If there were command-line tools available that the bridge could call to help with its work, using system() or similar functionality, that probably wouldn't make a derivative work either.
I should also point out that if CMS developers want to make this sort of bridge development unambiguously okay, they could do so by providing some sort of licensing exception as described at <http://www.fsf.org/licensing/licenses/gpl-faq.html#LinkingOverControlledInterface>.
This requires the assent of all the copyright holders, so I realize it may not be a feasible option for every free CMS, but it is out there.
This reasoning seems to employ arguments made by the RIAA and MPAA, except to opposite effect.
That might be due to the fact that both FSF/GNU and RIAA/MPAA use the same copyright law. :-)
I write this as a GPL advocate and a big believer in open source. GPL open source software is greatly advantaged to dominate the software world eventually, but trying to force that through legal ownership assertions strikes me as a great way to undermine the whole movement.
The beauty of GPL is that is doesn't fight the copyright laws. Quite the opposite! GPL leverage on the copyright laws to protect your freedom to * to run the program for any purpose. * to study and modify the program. * to copy the program so you can help your neighbor. * to improve the program, and release your improvements to the public, so that the whole community benefits. Or, as Dr. Debora Halbert put it: "Essentially, Stallman has codified sharing in order to prevent profiteers from stealing from the public domain. The GPL cleverly uses the power of copyright law (which allows the author of the product to control its use and distribution) to provide software for free.[56] In this way he transformed the rules of the game and redefined copyright (what he calls copyleft) into a tool the supports the creator and users of software." See § 46 in http://www.murdoch.edu.au/elaw/issues/v10n4/halbert104_text.html#GNU/GPL%20L....
For example, this API argument: by prohibiting use of APIs to bridge differently-licensed applications (and aren't APIs developed *precisely* to bridge two different applications?) we're forcing a "dumbing down" of work (and sundry other potential problems and risks) by legally requiring the bypassing of established application methodologies (such as security protocols) to write direct queries to databases.
How are we going to build an integrated world when GPL starts claiming rights to all that touch it? We're going from the freedom that comes from building a commons to the restriction that comes from making that commons a fenced-in zoo.
Maybe I'm wrong and going off in high spirits for no reason. The net result, I fear, is the creation of a GPL ghetto where anybody with one foot in the proprietary -- i.e., real -- world is given reason to hesitate coming within a country mile of GPL, just when GPL apps are poised (and have already started) to transform the mainstream business world.
GPL allows you to use both GPL:ed and non-GPL:ed API:s to bridge different applications. GPL also allows you to distribute the derivative work which emerges thereby. But to make sure that *you* don't deny the receiver the same rights as you got, GPL requires you to distributed the derivative work under GPL. Therefore I think this reciprocity of GPL (a.k.a. "copyleft") is something very good. The reciprocity prevents *distribution* of works derived partly from a third-party software with a license which is not compatible with GPL. Normally, this is also something good. As is said on the GPL FAQ: "If we permitted company A to make a proprietary file, and company B to distribute GPL-covered software linked with that file, the effect would be to make a hole in the GPL big enough to drive a truck through. This would be carte blanche for withholding the source code for all sorts of modifications and extensions to GPL-covered software." See http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#TOCMoneyGuzzlerInc But, as this discussion is about, this can also pose a hindrance for situations where it can seem reasonable to include software with license not compatible with GPL. For an example, imagine someone who has put in a lot of effort to write code that integrates a popular but proprietary software with Drupal. So far it is okay under GPL. But now he wants to share his effort with the community. Since the integration code calls functions and share data structures with both the proprietary software and Drupal, it is not allowed. Fortunately, there is a solution. As long as you don't revoke any rights granted by GPL, you can add your own terms and conditions. This can be used to allow integration with software under a license incompatible with GPL. Two examples on this: * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLib... * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingOverControl... So, to solve the problem that the licensing of Drupal currently force us to "dumbing down" or "bypassing of established application methodologies", I suggest that the Drupal licensing is supplemented with an exception for module developers linking through hooks.
Vivek Purl wrote:
Just for background this issue has come up because Joomla have decided to "fully" comply with GPL. This raised a few question for SMF team and they discussed it with FSF. The final result of that discussion is if php ( or any other scripting language ) which is distributed in source form is bridged to a non GPL software also distributed in source form then it violates the GPL.
The immediate effect for drupal is that VB and SMF bridges are violating GPL. It doesn't matter if its being distributed via d.o. or not.
So GPL apps are prohibited from touching non-GPL apps. I'll be snarky and say this is the kind of thing that happens when lawyers get involved. Time to stop developing software and start developing new licenses and lawsuits!
Laura (who's still wondering what was wrong with GPLv2)
Pardon??? All what had been said applies to GPL v2 as well as v3. So you concerns must consequently also apply to GPL v2 which is used by Drupal. Correct? Best regards, Thomas
On Aug 31, 2007, at 6:05 AM, Thomas Barregren wrote:
The issue original brought up by Jeff Eaton was about the fact that it is not permissible to write modules that bridge software with a license not compatible with GPL.
This interpretation is tragic for GPL applications, imho. It makes GPL toxic to other non-GPL applications out there. IANAL. I speak only to my perception of how such reasoning can effect the adoption of GPL throughout the world.
This reasoning seems to employ arguments made by the RIAA and MPAA, except to opposite effect.
That might be due to the fact that both FSF/GNU and RIAA/MPAA use the same copyright law. :-)
Law is open to interpretation, and the legal tactics of the RIAA and MPAA are hardly universally viewed as being consistent with copyright law. Not to mention how they are attacking their own customers in the process and undermining their own markets. I believe the cliche is "to cut off ones nose to spite ones face."
I write this as a GPL advocate and a big believer in open source. GPL open source software is greatly advantaged to dominate the software world eventually, but trying to force that through legal ownership assertions strikes me as a great way to undermine the whole movement.
The beauty of GPL is that is doesn't fight the copyright laws. Quite the opposite! GPL leverage on the copyright laws to protect your freedom to
* to run the program for any purpose.
--except to integrate with any non-GPL application.
* to study and modify the program.
--unless, of course, you want to bridge it with a non-GPL application, apparently.
* to copy the program so you can help your neighbor.
--unless, of course, you want to help your neighbor integrate a GPL application into his non-GPL universe.
* to improve the program, and release your improvements to the public, so that the whole community benefits.
--unless, of course, you software doesn't, in effect, ignore the non- GPL world. Suddenly there are caveats in there.
GPL allows you to use both GPL:ed and non-GPL:ed API:s to bridge different applications. GPL also allows you to distribute the derivative work which emerges thereby. But to make sure that *you* don't deny the receiver the same rights as you got, GPL requires you to distributed the derivative work under GPL. Therefore I think this reciprocity of GPL (a.k.a. "copyleft") is something very good.
The reciprocity prevents *distribution* of works derived partly from a third-party software with a license which is not compatible with GPL. Normally, this is also something good. As is said on the GPL FAQ:
"If we permitted company A to make a proprietary file, and company B to distribute GPL-covered software linked with that file, the effect would be to make a hole in the GPL big enough to drive a truck through. This would be carte blanche for withholding the source code for all sorts of modifications and extensions to GPL-covered software."
See http://www.gnu.org/licenses/old-licenses/gpl-2.0- faq.html#TOCMoneyGuzzlerInc
But, as this discussion is about, this can also pose a hindrance for situations where it can seem reasonable to include software with license not compatible with GPL.
For an example, imagine someone who has put in a lot of effort to write code that integrates a popular but proprietary software with Drupal. So far it is okay under GPL. But now he wants to share his effort with the community. Since the integration code calls functions and share data structures with both the proprietary software and Drupal, it is not allowed.
That's the problem, isn't it? Suddenly "free" does not mean what it means. That also seems to mean that proprietary systems need not try to integrate with Drupal, even if they want to offer such integration to the community under GPL. According to the reasoning at the top of this thread, GPL prevents them from doing that. That is a shame because it could seriously hinder or prevent the adoption of Drupal and other GPL software throughout the business world (where I argue it could do a lot of good).
Fortunately, there is a solution. As long as you don't revoke any rights granted by GPL, you can add your own terms and conditions. This can be used to allow integration with software under a license incompatible with GPL. Two examples on this:
* http://www.gnu.org/licenses/old-licenses/gpl-2.0- faq.html#GPLIncompatibleLibs * http://www.gnu.org/licenses/old-licenses/gpl-2.0- faq.html#LinkingOverControlledInterface
So, to solve the problem that the licensing of Drupal currently force us to "dumbing down" or "bypassing of established application methodologies", I suggest that the Drupal licensing is supplemented with an exception for module developers linking through hooks.
All we need to do is track down everyone who has contributed code to the Drupal project and get their okay, right?
Laura (who's still wondering what was wrong with GPLv2)
Pardon???
All what had been said applies to GPL v2 as well as v3. So you concerns must consequently also apply to GPL v2 which is used by Drupal. Correct?
That signoff followed "Time to stop developing software and start developing new licenses and lawsuits!" It was deliberately snarky, and as such perhaps confusing to some. My apologies. Laura
Laura Scott skrev:
On Aug 31, 2007, at 6:05 AM, Thomas Barregren wrote:
The issue original brought up by Jeff Eaton was about the fact that it is not permissible to write modules that bridge software with a license not compatible with GPL.
This interpretation is tragic for GPL applications, imho. It makes GPL toxic to other non-GPL applications out there. IANAL. I speak only to my perception of how such reasoning can effect the adoption of GPL throughout the world.
You surprise me. GPL has been around for *18 years* and this reciprocity (a.k.a. "copyleft") is the very heart of the license. I don't think the reciprocity has any negative effect on the adoption of GPL. Look at GNU/Linux, MySQL, Java and many more high profile projects. They don't look hampered to me. On the contrary! I believe GPL actually foster new generations of Free and Open Source Software (FOSS) contributors. As support for this opinion I plead the fact that GPL is the most used FOSS license. "As of August 2007, the GPL accounted for nearly 65% of the 43,442 free software projects listed on Freshmeat, and as of January 2006, about 68% of the projects listed on SourceForge.net," says Wikipedia. The numbers talk for them self.
I write this as a GPL advocate and a big believer in open source. GPL open source software is greatly advantaged to dominate the software world eventually, but trying to force that through legal ownership assertions strikes me as a great way to undermine the whole movement.
The beauty of GPL is that is doesn't fight the copyright laws. Quite the opposite! GPL leverage on the copyright laws to protect your freedom to
* to run the program for any purpose.
--except to integrate with any non-GPL application.
Wrong. You are allowed to integrate GPL-application with any non-GPL application.
* to study and modify the program.
--unless, of course, you want to bridge it with a non-GPL application, apparently.
Wrong. You are allowed to study and modify the program for any reason, including for the purpose of bridging it with non-GPL application.
* to copy the program so you can help your neighbor.
--unless, of course, you want to help your neighbor integrate a GPL application into his non-GPL universe.
Wrong. You are allowed to give your neighbor a opy of the GPLed program, and you are allowed to help him to integrate it into his non-GPL universe.
* to improve the program, and release your improvements to the public, so that the whole community benefits.
--unless, of course, you software doesn't, in effect, ignore the non-GPL world.
If you modify the GPLed program it becomes a derived work. You are free to distribute it under the same license as you obtained it in the first place. Do you consider it unfair?
Suddenly there are caveats in there.
Yes, there are caveats in GPL v2. For an example Tivoization <http://en.wikipedia.org/wiki/Tivoization>. But I assume it is not that kind of caveats you allude to. :-)
GPL allows you to use both GPL:ed and non-GPL:ed API:s to bridge different applications. GPL also allows you to distribute the derivative work which emerges thereby. But to make sure that *you* don't deny the receiver the same rights as you got, GPL requires you to distributed the derivative work under GPL. Therefore I think this reciprocity of GPL (a.k.a. "copyleft") is something very good.
The reciprocity prevents *distribution* of works derived partly from a third-party software with a license which is not compatible with GPL. Normally, this is also something good. As is said on the GPL FAQ:
"If we permitted company A to make a proprietary file, and company B to distribute GPL-covered software linked with that file, the effect would be to make a hole in the GPL big enough to drive a truck through. This would be carte blanche for withholding the source code for all sorts of modifications and extensions to GPL-covered software."
See
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#TOCMoneyGuzzlerInc
But, as this discussion is about, this can also pose a hindrance for situations where it can seem reasonable to include software with license not compatible with GPL.
For an example, imagine someone who has put in a lot of effort to write code that integrates a popular but proprietary software with Drupal. So far it is okay under GPL. But now he wants to share his effort with the community. Since the integration code calls functions and share data structures with both the proprietary software and Drupal, it is not allowed.
That's the problem, isn't it? Suddenly "free" does not mean what it means.
Free in the "Free Software" sense can be compared to Free Speech. You are free to do/say what you want as long as you don't do/say something that threatens the very same freedom.
That also seems to mean that proprietary systems need not try to integrate with Drupal, even if they want to offer such integration to the community under GPL. According to the reasoning at the top of this thread, GPL prevents them from doing that. That is a shame because it could seriously hinder or prevent the adoption of Drupal and other GPL software throughout the business world (where I argue it could do a lot of good).
In my experience, as a software developer and entrepreneur, GPL is very business friendly compared to many of the proprietary software licenses I have encountered. Obviously, I am not alone of thinking so. Consider all companies doing business with help of GPL, e.g. Red Hat, MySQL, SpikeSource and many more. And both your and my companies are good examples on companies that prosper thanks to GPL. Being President of pingVision, a company that obviously makes money on a GPL software, you are surprising ignorant of the license under which your company are operating.
Fortunately, there is a solution. As long as you don't revoke any rights granted by GPL, you can add your own terms and conditions. This can be used to allow integration with software under a license incompatible with GPL. Two examples on this:
* http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLib...
* http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingOverControl...
So, to solve the problem that the licensing of Drupal currently force us to "dumbing down" or "bypassing of established application methodologies", I suggest that the Drupal licensing is supplemented with an exception for module developers linking through hooks.
All we need to do is track down everyone who has contributed code to the Drupal project and get their okay, right?
Yes, that is how the copyright law works. But I am sure that it should not an insurmountable difficulty. Best regards, Thomas
On 31.08-17:52, Thomas Barregren wrote: [ ... ]
The issue original brought up by Jeff Eaton was about the fact that it is not permissible to write modules that bridge software with a license not compatible with GPL. [ ... ] You surprise me. GPL has been around for *18 years* and this reciprocity (a.k.a. "copyleft") is the very heart of the license. [ ... ] Wrong. You are allowed to integrate GPL-application with any non-GPL application.
i believe you contradict yourself. the issue is the extension of GPL to include interfacing software, as below [ ... ]
* to study and modify the program.
--unless, of course, you want to bridge it with a non-GPL application, apparently.
Wrong. You are allowed to study and modify the program for any reason, including for the purpose of bridging it with non-GPL application. [ ... ]
So, to solve the problem that the licensing of Drupal currently force us to "dumbing down" or "bypassing of established application methodologies", I suggest that the Drupal licensing is supplemented with an exception for module developers linking through hooks.
if you are allowed to study and modify the program for the purpose of bridging it with non-GPL code then there is no cross pollination of the licenses. this has traditionally been done (i.e. the use of GPL'd header files in compilation) but often brought under question by more aggressive GPL proponents. i think the original author is confused about the exact status of GPL, especially, in relation to something like hooks where, it would appear to me, there is no issue. essentially, i see no reason you could not interface an application using hooks and keep that application propiertory. i am still unclear as to how this may be effected by GPLv3.
On Aug 31, 2007, at 11:43 AM, ttw+drupal@cobbled.net wrote:
i think the original author is confused about the exact status of GPL, especially, in relation to something like hooks where, it would appear to me, there is no issue. essentially, i see no reason you could not interface an application using hooks and keep that application propiertory.
If I'm the original author being referred to, it's important to remember that I'm summarizing the position articulated to me by the FSF after three days of communication, including detailed descriptions of how Drupal's hook system operates and how dynamic script languages like PHP handle bridging projects. Please read earlier messages. The FSF's position is that, if two projects are calling each others' functions or sharing in-memory data structures and so on (even if they do it via an intermediary plugin), they are operating as a single unit. There is a LOT of technical wrangling in the details of that, but it comes back to the rule of thumb: *** If you can, at any point, call debug_backtrace() and see BOTH drupal functions AND functions from a non-GPL-compatible piece of software, the terms of the GPL are being violated. *** I say this not because I am a torch-waving opponent of proprietary software, nor because I am a critic of the GPL. I just think that there is a great deal of confusion in the OSS CMS community, and I hope to help achieve some clarity. If you have an issue, or a point you feel needs to be clarified, ** DO WHAT I DID. CONTACT THE FREE SOFTWARE FOUNDATION. ** They're great folks to talk to, and even if you don't like the results of your questions, they're very patient and willing to help work through the thorny technical details. --Jeff
On 8/31/07, Jeff Eaton <jeff@viapositiva.net> wrote:
*** If you can, at any point, call debug_backtrace() and see BOTH drupal functions AND functions from a non-GPL-compatible piece of software, the terms of the GPL are being violated. ***
Let me amend / extend this -- They are being violated, if and only if, you distribute the code. -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
On Aug 31, 2007, at 3:33 PM, Boris Mann wrote:
On 8/31/07, Jeff Eaton <jeff@viapositiva.net> wrote:
*** If you can, at any point, call debug_backtrace() and see BOTH drupal functions AND functions from a non-GPL-compatible piece of software, the terms of the GPL are being violated. ***
Let me amend / extend this -- They are being violated, if and only if, you distribute the code.
This is very true. It's also important to keep in mind that the FSF gets annoyed when people distribute code that "Is GPL Compliant, Wink Wink Nudge Nudge" but doesn't actually do anything until you put it in the presence of non-GPL code. So, while the GPL wouldn't prevent someone from whipping up a compatibility module themselves or a one-off module like that for a client, the FSF would consider it a violation of the GPL if that person distributed the resulting module with a see-no-evil "Well, it's just some code I wrote, people might install X and Y together, but how am I to know?" excuse. --Jeff
Jeff Eaton wrote:
This is very true. It's also important to keep in mind that the FSF gets annoyed when people distribute code that "Is GPL Compliant, Wink Wink Nudge Nudge" but doesn't actually do anything until you put it in the presence of non-GPL code.
So, while the GPL wouldn't prevent someone from whipping up a compatibility module themselves or a one-off module like that for a client, the FSF would consider it a violation of the GPL if that person distributed the resulting module with a see-no-evil "Well, it's just some code I wrote, people might install X and Y together, but how am I to know?" excuse.
To avoid this sort of GPL Hell, we have very specific terms on which we work with clients: (1) The client owns the work we do specifically for them. (2) The client licenses .module files and their dependencies back to us under the GPL, version 2, and all future versions as published by the FSF. The terms of (2) mean their internal staff can contribute to the project, but the final working modules are licensed back to us in a GPL-clean way that allows us to return the work to the community.
On Aug 31, 2007, at 2:56 PM, David Strauss wrote:
Jeff Eaton wrote:
This is very true. It's also important to keep in mind that the FSF gets annoyed when people distribute code that "Is GPL Compliant, Wink Wink Nudge Nudge" but doesn't actually do anything until you put it in the presence of non-GPL code.
The no-distribution loophole seems to contradict what was quoted earlier, but if true that's very reassuring. Thanks. The not- permitted- even-if-not-distributed thing was what sounded so alarming. It's a darned shame though that a GPL module that enhances a free- standing GPL system (e.g., a module that bridges Drupal with an outside system) is lumped together with a "GPL" widget that is wholly dependent upon a proprietary system. The former is what I would consider a powerful enhancement of another existing GPL system, while the latter is clearly a licensing gimmick to get away with something. And yet legally they should be considered the same? Ouch! Hypothetical: Could one argue that the GPL bridging module that bridges, say, Drupal and ASP.NET does not depend upon the proprietary system in order to be there and available for Drupal? I mean, if I can, for example, see the module active and available in the Drupal admin area, even if the ASP site is not connected, would not that module be considered as not requiring a proprietary system to run?
To avoid this sort of GPL Hell, we have very specific terms on which we work with clients:
(1) The client owns the work we do specifically for them.
(2) The client licenses .module files and their dependencies back to us under the GPL, version 2, and all future versions as published by the FSF.
The terms of (2) mean their internal staff can contribute to the project, but the final working modules are licensed back to us in a GPL-clean way that allows us to return the work to the community.
That's a very interesting contractual approach. Thanks for sharing that! Laura
On Aug 31, 2007, at 4:31 PM, Laura Scott wrote:
Hypothetical: Could one argue that the GPL bridging module that bridges, say, Drupal and ASP.NET does not depend upon the proprietary system in order to be there and available for Drupal? I mean, if I can, for example, see the module active and available in the Drupal admin area, even if the ASP site is not connected, would not that module be considered as not requiring a proprietary system to run?
Well, since ASP.NET isn't running as PHP code, it's almost certain that it would involve some sort of clean XMLRPC gateway or RESTful interface. Or do you mean, Drupal running on ASP.NET? The latter would, I believe, fall under the OS/system libraries clauses that Thomas Barregren has linked to a number of times. Carefully exploring that clarified a couple of the "Wait, but, does that mean..." kinds of questions I was posing to the FSF folks. --Jeff
Laura Scott wrote:
On Aug 31, 2007, at 2:56 PM, David Strauss wrote:
Jeff Eaton wrote:
This is very true. It's also important to keep in mind that the FSF gets annoyed when people distribute code that "Is GPL Compliant, Wink Wink Nudge Nudge" but doesn't actually do anything until you put it in the presence of non-GPL code.
The no-distribution loophole seems to contradict what was quoted earlier, but if true that's very reassuring. Thanks. The not-permitted- even-if-not-distributed thing was what sounded so alarming.
You must have misunderstood this part. You are permitted to do what ever you want with a GPLed code as long as yo don't distribute it. But, if you distribute the code, with or without modifications, you must do that under GPL. It is as simple as that.
It's a darned shame though that a GPL module that enhances a free-standing GPL system (e.g., a module that bridges Drupal with an outside system) is lumped together with a "GPL" widget that is wholly dependent upon a proprietary system. The former is what I would consider a powerful enhancement of another existing GPL system, while the latter is clearly a licensing gimmick to get away with something. And yet legally they should be considered the same? Ouch!
Hypothetical: Could one argue that the GPL bridging module that bridges, say, Drupal and ASP.NET does not depend upon the proprietary system in order to be there and available for Drupal? I mean, if I can, for example, see the module active and available in the Drupal admin area, even if the ASP site is not connected, would not that module be considered as not requiring a proprietary system to run?
Suppose you have a GPLed program A and another program B. The fact that A depends on B (or vice versa) is not enough to trigger the requirement that B also is GPLed. For an example it is perfect legal to let B be non GPLed if A use fork and exec and similar mechanisms to call B. A special case of this proviso is the "web service loophole". It is only if A uses a function, an object or some other internals of B, or vice versa, that B is required to be GPLed. Thus, for any construction where A and B can collaborate without knowing or assuming anything about each others internals, it is acceptable that B isn't GPLed. So, if you want to build a module that can be used to integrate a software with a license incompatible with GPL, I *believe* that a solution is to build a GPLed Service Provider Interface (SPI) which makes no assumption about the internals of the service providers. Regards, Thomas
On Friday 31 August 2007, Thomas Barregren wrote:
Suppose you have a GPLed program A and another program B. The fact that A depends on B (or vice versa) is not enough to trigger the requirement that B also is GPLed. For an example it is perfect legal to let B be non GPLed if A use fork and exec and similar mechanisms to call B. A special case of this proviso is the "web service loophole". It is only if A uses a function, an object or some other internals of B, or vice versa, that B is required to be GPLed. Thus, for any construction where A and B can collaborate without knowing or assuming anything about each others internals, it is acceptable that B isn't GPLed.
So, if you want to build a module that can be used to integrate a software with a license incompatible with GPL, I *believe* that a solution is to build a GPLed Service Provider Interface (SPI) which makes no assumption about the internals of the service providers.
Regards, Thomas
So you are claiming, then, that a Drupal wrapper module for a non-GPLed system that communicated only via REST calls (or similar) but still had no actual function of its own without that non-GPLed system, is legal? Just for the record, how many of the people in this thread actually *are* lawyers? :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
The FSF folks, when I asked about this, basically said that it was probably violating the spirit of the GPL but not the letter. The number of permutations involved is why it's best to ask them -- or a lawyer. ;) --Jeff On Aug 31, 2007, at 7:31 PM, Larry Garfield wrote:
So you are claiming, then, that a Drupal wrapper module for a non- GPLed system that communicated only via REST calls (or similar) but still had no actual function of its own without that non-GPLed system, is legal?
Jeff- Two questions, mercifully brief, for all: 1) Should we escalate this to the Drupal Association to pull in some lawyerly resources? I presume the answer is "no" here, as I hear killes in my head saying "Drupal follows GPL; end of discussion." 2) How does this affect Edison Wong's (and many others') work on Oracle / DB2 integration for Drupal core? Can GPL software invoke data directly from a non-GPL storage system? - Ken
On Friday 31 August 2007, Ken Rickard wrote:
Jeff-
Two questions, mercifully brief, for all:
1) Should we escalate this to the Drupal Association to pull in some lawyerly resources?
I presume the answer is "no" here, as I hear killes in my head saying "Drupal follows GPL; end of discussion."
That depends what is being asked of the lawyers. "How can we tweak our licensing policy" is probably not going to get very far at all, lawyers or not. "Would we be breaking the law to host in CVS a module that does X" would be a question best asked of a lawyer, and I agree that the DA would probably be the correct party to ask. (FSF has lawyers who will give us answers, as Jeff has found, but they are not exactly an unbiased source. And I say that as a card-carrying FSF Associate Member.)
2) How does this affect Edison Wong's (and many others') work on Oracle / DB2 integration for Drupal core? Can GPL software invoke data directly from a non-GPL storage system?
- Ken
IANAL etc., but since the communication with the server is all via SQL, which is a (nominal) standard, I'd think it would be no more problematic than Aggregator, which pulls RSS feeds from both GPLed blogs and proprietary newspaper sites. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
I have always found that when dealing with lawyers the best approach is to tell them what you are going to do and ask for possible changes that will get you into the least trouble. Without that approach the answer is always NO. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Larry Garfield Sent: Saturday, September 01, 2007 2:54 AM To: development@drupal.org Subject: Re: [development] Modules that integrate non-GPL PHP apps violate the GPL. On Friday 31 August 2007, Ken Rickard wrote:
Jeff-
Two questions, mercifully brief, for all:
1) Should we escalate this to the Drupal Association to pull in some lawyerly resources?
I presume the answer is "no" here, as I hear killes in my head saying "Drupal follows GPL; end of discussion."
That depends what is being asked of the lawyers. "How can we tweak our licensing policy" is probably not going to get very far at all, lawyers or not. "Would we be breaking the law to host in CVS a module that does X" would be a question best asked of a lawyer, and I agree that the DA would probably be the correct party to ask. (FSF has lawyers who will give us answers, as Jeff has found, but they are not exactly an unbiased source. And I say that as a card-carrying FSF Associate Member.)
2) How does this affect Edison Wong's (and many others') work on Oracle / DB2 integration for Drupal core? Can GPL software invoke data directly from a non-GPL storage system?
- Ken
IANAL etc., but since the communication with the server is all via SQL, which is a (nominal) standard, I'd think it would be no more problematic than Aggregator, which pulls RSS feeds from both GPLed blogs and proprietary newspaper sites. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.13.1/981 - Release Date: 8/31/2007 6:13 AM
Ken Rickard wrote:
1) Should we escalate this to the Drupal Association to pull in some lawyerly resources?
I will see if my company can devote some of its legal resources to answering this question.
Ken Rickard skrev:
Jeff-
Two questions, mercifully brief, for all:
1) Should we escalate this to the Drupal Association to pull in some lawyerly resources?
I presume the answer is "no" here, as I hear killes in my head saying "Drupal follows GPL; end of discussion."
Since Drupal.org distributes the possible offending modules, it is not enough to just say that "Drupal follows GPL; end of discussion." I think there is three issues worth further consideration: 1. Would Drupal benefit from having some sort of FOSS License Exception? Especially considering the problem with libraries under the PHP license. 2. Is it advisable for Drupal.org to distribute modules that depends on software under a GPL-incompatible license? 3. Could a Linking Over Controlled Interface Exception, for hooks and some other unctions (e.g. t() and l()), be a a feasible solution to allow distribution of modules that depends on software under a GPL-incompatible license?
2) How does this affect Edison Wong's (and many others') work on Oracle / DB2 integration for Drupal core? Can GPL software invoke data directly from a non-GPL storage system?
It depends. If the access can be done without knowing the internals of the non-GPLed storage system, for example through SQL, it is not a problem. But if the access requires a non-GPLed driver, then we have a problem. I haven't followed the work by Wong et al so I can't speak for that particular case. Best regards, Thomas
I'm not a lawyer, either. But in my day job, I'm the last guy who reviews things before calling one. :-) - Ken On 9/1/07, Thomas Barregren <thomas@webbredaktoren.se> wrote:
Ken Rickard skrev:
Jeff-
Two questions, mercifully brief, for all:
1) Should we escalate this to the Drupal Association to pull in some lawyerly resources?
I presume the answer is "no" here, as I hear killes in my head saying "Drupal follows GPL; end of discussion."
Since Drupal.org distributes the possible offending modules, it is not enough to just say that "Drupal follows GPL; end of discussion."
I think there is three issues worth further consideration:
1. Would Drupal benefit from having some sort of FOSS License Exception? Especially considering the problem with libraries under the PHP license. 2. Is it advisable for Drupal.org to distribute modules that depends on software under a GPL-incompatible license? 3. Could a Linking Over Controlled Interface Exception, for hooks and some other unctions (e.g. t() and l()), be a a feasible solution to allow distribution of modules that depends on software under a GPL-incompatible license?
2) How does this affect Edison Wong's (and many others') work on Oracle / DB2 integration for Drupal core? Can GPL software invoke data directly from a non-GPL storage system?
It depends. If the access can be done without knowing the internals of the non-GPLed storage system, for example through SQL, it is not a problem. But if the access requires a non-GPLed driver, then we have a problem. I haven't followed the work by Wong et al so I can't speak for that particular case.
Best regards, Thomas
This seems like pretty safe ground to me. Of course what constitutes a "derived work" is and will always be subject to legal interpretation, And I do think what you "distribute" and how you distribute it will make a big difference. But something that communicates over an internet protocol with another service, can hardly be considered part of the product you've distributed. Particularly if the spec for the web service is not proprietary. The service your consuming hasn't necessarily been distributed (and often isn't). This is probably the crux of the static vs, .dll difference in some peoples (lawyers or not) interpretation. Just how stand- alone does a library need to be in order to be considered an independent work vs. a derived work? Would a reasonable person believe that some other individual could write a replacement "library"? Would they be able to distribute it as a standalone product? I'd be interested to see how an interpretive api that was written so that anyone can register a callback and therefor inerface with the module would measure up in this interpretation, but as Larry hints at... that's probably best left to a real lawyer. I once attended a talk by a copyright lawyer on the subject, and in the states at least, most software licensing is considered contract law, and not copyright law, so the interface gets muddy in a hurry, particularly around commercial software. From a legal perspective you don't own your copy of MS word in the states. You've just purchased (read rented) the rights to use it. The real question in all this isn't which interpretation is right or wrong, but rather what level of risk is drupal.org willing to accept. That interpretation ought to be somewhat conservative IMHO. But I think web services are safe, if the spec is open. Enough of this, I'm going to write some more code :) Dave On Aug 31, 2007, at 5:31 PM, Larry Garfield wrote:
On Friday 31 August 2007, Thomas Barregren wrote:
So, if you want to build a module that can be used to integrate a software with a license incompatible with GPL, I *believe* that a solution is to build a GPLed Service Provider Interface (SPI) which makes no assumption about the internals of the service providers.
Regards, Thomas
So you are claiming, then, that a Drupal wrapper module for a non- GPLed system that communicated only via REST calls (or similar) but still had no actual function of its own without that non-GPLed system, is legal?
Just for the record, how many of the people in this thread actually *are* lawyers? :-)
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Larry Garfield skrev:
On Friday 31 August 2007, Thomas Barregren wrote:
Suppose you have a GPLed program A and another program B. The fact that A depends on B (or vice versa) is not enough to trigger the requirement that B also is GPLed. For an example it is perfect legal to let B be non GPLed if A use fork and exec and similar mechanisms to call B. A special case of this proviso is the "web service loophole". It is only if A uses a function, an object or some other internals of B, or vice versa, that B is required to be GPLed. Thus, for any construction where A and B can collaborate without knowing or assuming anything about each others internals, it is acceptable that B isn't GPLed.
So, if you want to build a module that can be used to integrate a software with a license incompatible with GPL, I *believe* that a solution is to build a GPLed Service Provider Interface (SPI) which makes no assumption about the internals of the service providers.
Regards, Thomas
So you are claiming, then, that a Drupal wrapper module for a non-GPLed system that communicated only via REST calls (or similar) but still had no actual function of its own without that non-GPLed system, is legal?
Yes, I think so.
Just for the record, how many of the people in this thread actually *are* lawyers? :-)
Probably none. I am for sure not a lawyer. But for what it is worth, I have more than ten years of professional experience of reading and writing contracts and licenses. I am not an expert. But I have learned a lot, and think of myself as quite well versed in these issues. Especially when it comes to Free and Open Source Software (FOSS) licensing, which I have taken a great interest in for several years. For those who are interesting to learn more in this interesting field, I can recommend following books (available free on-line): * http://www.rosenlaw.com/oslbook.htm * http://www.oreilly.com/catalog/osfreesoft/book/ Best regards, Thomas
Thomas Barregren wrote:
For those who are interesting to learn more in this interesting field, I can recommend following books (available free on-line):
* http://www.rosenlaw.com/oslbook.htm * http://www.oreilly.com/catalog/osfreesoft/book/
Larry Rosen, the author of the book in the first link, is one of the lawyers my company consults with.
Larry Rosen, the author of the book in the first link, is one of the lawyers my company consults with.
So the question that the list should debate: what are the questions that a lawyer should answer for us? Larry Rosen looks like a good candidate. (Or maybe two lawyers? One in the EU, one in the USA)
I think this discussion should happen on a new thread. - Ken On 9/2/07, Karoly Negyesi <karoly@negyesi.net> wrote:
Larry Rosen, the author of the book in the first link, is one of the lawyers my company consults with.
So the question that the list should debate: what are the questions that a lawyer should answer for us? Larry Rosen looks like a good candidate. (Or maybe two lawyers? One in the EU, one in the USA)
So far this whole discussion seems to be a case of ask the wrong question, get the wrong answer. I have seen no evidence to suggest that one cannot write some code that depends on non-free software, release it under the GPL, and have the GPL apply to that code. What would be against the spirit of the GPL would be to write code that depends on GPL software and to release only a compatibility layer under the GPL, keeping the main functionality non-free. Since 1) the third-party apps that are being integrated do not depend on Drupal and 2) the module authors do not own the rights to the code in the third-party apps, this issue is irrelevant to the situation under discussion.
Quoting Darren Oh <darrenoh@sidepotsinternational.com>:
So far this whole discussion seems to be a case of ask the wrong question, get the wrong answer. I have seen no evidence to suggest that one cannot write some code that depends on non-free software, release it under the GPL, and have the GPL apply to that code. What would be against the spirit of the GPL would be to write code that depends on GPL software and to release only a compatibility layer under the GPL, keeping the main functionality non-free. Since 1) the third-party apps that are being integrated do not depend on Drupal and 2) the module authors do not own the rights to the code in the third-party apps, this issue is irrelevant to the situation under discussion.
That is how I see the issue. I have two different components one GPL licensed one some other license. I need to write software to communicate between the two. I have the right to license it as I see fit. Since I wish to use the Drupal methods of distribution I need to use GPL. I also have the right as the copyright owner to license this new work under some other license. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Quoting Earnie Boyd <earnie@users.sourceforge.net>:
That is how I see the issue. I have two different components one GPL licensed one some other license. I need to write software to communicate between the two. I have the right to license it as I see fit. Since I wish to use the Drupal methods of distribution I need to use GPL. I also have the right as the copyright owner to license this new work under some other license.
Correction. If I use a library API that is GPL licensed I must license as GPL. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Sep 2, 2007, at 9:43 AM, Darren Oh wrote:
So far this whole discussion seems to be a case of ask the wrong question, get the wrong answer. I have seen no evidence to suggest that one cannot write some code that depends on non-free software, release it under the GPL, and have the GPL apply to that code. What would be against the spirit of the GPL would be to write code that depends on GPL software and to release only a compatibility layer under the GPL, keeping the main functionality non-free. Since 1) the third-party apps that are being integrated do not depend on Drupal and 2) the module authors do not own the rights to the code in the third-party apps, this issue is irrelevant to the situation under discussion.
I used to take this position as well, but it's apparent after quite a bit of research that this is based on loose use of the phrase "depends on" to define the terms of the discussion. The GPL doesn't use those words. It doesn't recognize a difference between a piece of software that *uses* a library, and the library that *is used by* another program. It simply sees those two programs being combined to form a single work if they interoperate in certain ways. As such, if they do not share compatible licenses, they can't be distributed together. And if one component is clearly designed to work *only in the presence of the other component* it is an implicit violation of the GPL. (According to the FSF). That's their official interpretation. --Jeff
On a practical note, SugarCRM is being released under GPL 3.0: http://www.sugarforge.org/content/faq/gplv3.php and CiviCRM is AGPL (compat with GPL 3.0, but not 2.0): http://wiki.civicrm.org/confluence/display/CRMDOC/AGPL+vs.+GNU While these are FOSS licenses, they represent technical violations (I think) if an integration module is offered on d.o or by that project, right? -Peter On 9/2/07, Jeff Eaton <jeff@viapositiva.net> wrote:
On Sep 2, 2007, at 9:43 AM, Darren Oh wrote:
So far this whole discussion seems to be a case of ask the wrong question, get the wrong answer. I have seen no evidence to suggest that one cannot write some code that depends on non-free software, release it under the GPL, and have the GPL apply to that code. What would be against the spirit of the GPL would be to write code that depends on GPL software and to release only a compatibility layer under the GPL, keeping the main functionality non-free. Since 1) the third-party apps that are being integrated do not depend on Drupal and 2) the module authors do not own the rights to the code in the third-party apps, this issue is irrelevant to the situation under discussion.
I used to take this position as well, but it's apparent after quite a bit of research that this is based on loose use of the phrase "depends on" to define the terms of the discussion. The GPL doesn't use those words. It doesn't recognize a difference between a piece of software that *uses* a library, and the library that *is used by* another program. It simply sees those two programs being combined to form a single work if they interoperate in certain ways.
As such, if they do not share compatible licenses, they can't be distributed together. And if one component is clearly designed to work *only in the presence of the other component* it is an implicit violation of the GPL. (According to the FSF).
That's their official interpretation.
--Jeff
On 02.09-15:47, Jeff Eaton wrote: [ ... ]
As such, if they do not share compatible licenses, they can't be distributed together. And if one component is clearly designed to work *only in the presence of the other component* it is an implicit violation of the GPL. (According to the FSF).
thank you for finally putting this clearly. i am not a lawyer but i concur. what still confuses me, however, is that i recall a law suit with one of the larger software companies about 10 years ago where they sued a smaller company for reverse engineering their code to write compatible software. the case was lost (as i recall) on the basis that once you had purchased something you were entitled to use it to access your data (which you still had ownership over) in whatever manner you chose (including reverse engineering and interfacing with those components to better access your information). my understanding of the gpl is that it was created precisely in response to this sort of corporate behaviour. thus it appears to me contradictory to suggest that i cannot interface with free software (which is based upon shared ownership) unless i also make my software free. this appears to be the goal of some GPL proponents. and i don't believe possible under law (at least the majority of EU law). hence my earlier assersion that using drupal hooks in any software is not illegal or problematic, nor is distributing that software (unless you also distribute drupal). i re-iterate that i agree about the distribution of free software and libraries as a reasonable incentive toward free software and as a reasonable barrier to wholesale consumption of free software into commercial products. i disagree that we can prevent someone from communicating with free software on the basis of copyright and think this directly contradictory to the notion of freedom that we wish to preserve and propogate.
One thing you need to keep in mind is the explicit allowance of reverse engineering by law within the EU member states, transposing an EU directive, which AFAIK does not an equivalent in the USA, where reverse engineering can land you in deep trouble. The case you mention could fall under this legal situation. ----- Original Message ----- From: <ttw+drupal@cobbled.net> To: <development@drupal.org> Sent: Monday, September 03, 2007 1:05 PM Subject: Re: [development] Modules that integrate non-GPL PHP apps violatethe GPL.
On 02.09-15:47, Jeff Eaton wrote: [ ... ] what still confuses me, however, is that i recall a law suit with one of the larger software companies about 10 years ago where they sued a smaller company for reverse engineering their code to write compatible software. the case was lost (as i recall) on the basis that once you had purchased something you were entitled to use it to access your data (which you still had ownership over) in whatever manner you chose (including reverse engineering and interfacing with those components to better access your information). [...]
US copyright law does not ignore the need for reverse engineering in these circumstances (i.e., for compatibility purposes)... Title 17, Section 1201 of the US code says, in part .. *(f) Reverse Engineering. ... a person who has lawfully obtained the right to use a copy of a computer program may circumvent a technological measure that effectively controls access to a particular portion of that program for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs, and that have not previously been readily available to the person engaging in the circumvention, to the extent any such acts of identification and analysis do not constitute infringement under this title. * ... Heavy on legalese, but you get the idea. On 9/3/07, FGM <fgm@osinet.fr> wrote:
One thing you need to keep in mind is the explicit allowance of reverse engineering by law within the EU member states, transposing an EU directive, which AFAIK does not an equivalent in the USA, where reverse engineering can land you in deep trouble.
The case you mention could fall under this legal situation.
----- Original Message ----- From: <ttw+drupal@cobbled.net> To: <development@drupal.org> Sent: Monday, September 03, 2007 1:05 PM Subject: Re: [development] Modules that integrate non-GPL PHP apps violatethe GPL.
On 02.09-15:47, Jeff Eaton wrote: [ ... ] what still confuses me, however, is that i recall a law suit with one of the larger software companies about 10 years ago where they sued a smaller company for reverse engineering their code to write compatible software. the case was lost (as i recall) on the basis that once you had purchased something you were entitled to use it to access your data (which you still had ownership over) in whatever manner you chose (including reverse engineering and interfacing with those components to better access your information). [...]
That's a nice improvement over the previous situation, then. I'd read it was under discussion years ago, but didn't think it would make it. Looks like it did :-) ----- Original Message ----- From: "Hunter C" <hunterc@gmail.com> To: <development@drupal.org> Sent: Monday, September 03, 2007 8:33 PM Subject: Re: [development] Modules that integrate non-GPL PHP appsviolatethe GPL.
US copyright law does not ignore the need for reverse engineering in these circumstances (i.e., for compatibility purposes)...
Title 17, Section 1201 of the US code says, in part ..
*(f) Reverse Engineering. ... a person who has lawfully obtained the right to use a copy of a computer program may circumvent a technological measure that effectively controls access to a particular portion of that program for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs, and that have not previously been readily available to the person engaging in the circumvention, to the extent any such acts of identification and analysis do not constitute infringement under this title. * ...
Heavy on legalese, but you get the idea. [...]
On 03.09-18:53, FGM wrote:
[ ... ] what still confuses me, however, is that i recall a law suit with one of the larger software companies about 10 years ago where they sued a smaller company for reverse engineering their code to write compatible software. the case was lost (as i recall) on the basis that once you had purchased something you were entitled to use it to access your data (which you still had ownership over) in whatever manner you chose (including reverse engineering and interfacing with those components to better access your information). [...]
One thing you need to keep in mind is the explicit allowance of reverse engineering by law within the EU member states, transposing an EU directive, which AFAIK does not an equivalent in the USA, where reverse engineering can land you in deep trouble.
The case you mention could fall under this legal situation.
i believe you are correct here but the bigger question is what is right and what is wrong. i believe that trying to use copyright to prevent someone doing anything except copying your code is not only legally untenable (at least within the EU) but wrong. using the notion of freedom to impose freedom may be an appealing notion but what is the value of imposed freedom? rings of certain, current, foreign policies.
Sometimes my first attempt to express my thoughts confuses people. For those who are still confused, I hope this is clearer: The viral nature of the GPL means that an app that uses Drupal is automatically licensed under the GPL, whether or not the developer of the app says so. That's exactly what we want, and it's the reason Drupal is distributed under the GPL. This discussion has established the illegality of attempting to circumvent the GPL. It would be against the spirit of the GPL for a developer to write an app designed to work only in the presence of Drupal, integrate it using a module, and claim that the GPL applies only to the module. I see no reason why we would want to enable developers to do this. Based on the evidence presented in this discussion, it would not be against either the spirit or the letter of the GPL for a developer to distribute a module that integrates an existing third-party app that does not use Drupal and to which the developer does not own the rights. (Of course, the app can't be distributed with Drupal, but we already prohibit third-party apps from being included in Drupal's repository.) Therefore, it is incorrect to say that "if debug_backtrace() can ever include functions from both Drupal and an external program," the external program must be distributed under the GPL. That test is applicable only if the developer also owns the external program. And remember, if the external program uses Drupal, it is already under the GPL. I repeat, this discussion has been a case of right answer, wrong question. Module developers can stop worrying and go back to making Drupal better. On Sep 3, 2007, at 4:47 AM, Jeff Eaton wrote:
On Sep 2, 2007, at 9:43 AM, Darren Oh wrote:
So far this whole discussion seems to be a case of ask the wrong question, get the wrong answer. I have seen no evidence to suggest that one cannot write some code that depends on non-free software, release it under the GPL, and have the GPL apply to that code. What would be against the spirit of the GPL would be to write code that depends on GPL software and to release only a compatibility layer under the GPL, keeping the main functionality non-free. Since 1) the third-party apps that are being integrated do not depend on Drupal and 2) the module authors do not own the rights to the code in the third-party apps, this issue is irrelevant to the situation under discussion.
I used to take this position as well, but it's apparent after quite a bit of research that this is based on loose use of the phrase "depends on" to define the terms of the discussion. The GPL doesn't use those words. It doesn't recognize a difference between a piece of software that *uses* a library, and the library that *is used by* another program. It simply sees those two programs being combined to form a single work if they interoperate in certain ways.
As such, if they do not share compatible licenses, they can't be distributed together. And if one component is clearly designed to work *only in the presence of the other component* it is an implicit violation of the GPL. (According to the FSF).
That's their official interpretation.
On Sep 3, 2007, at 10:04 AM, Darren Oh wrote:
Based on the evidence presented in this discussion, it would not be against either the spirit or the letter of the GPL for a developer to distribute a module that integrates an existing third-party app that does not use Drupal and to which the developer does not own the rights.
This is exactly the opposite of what the FSF said when I asked them that question directly. --Jeff
Jeff Eaton wrote:
On Sep 3, 2007, at 10:04 AM, Darren Oh wrote:
Based on the evidence presented in this discussion, it would not be against either the spirit or the letter of the GPL for a developer to distribute a module that integrates an existing third-party app that does not use Drupal and to which the developer does not own the rights.
This is exactly the opposite of what the FSF said when I asked them that question directly.
--Jeff Hey folks, I'm not much of a developer but I'm a pretty good observer. A few months ago Joomla! when through this very same issue, check out: http://www.joomla.org/content/view/3510/1/ . I think a lot of time can be wasted in a discussion in reinterpreting FSF's own interpretation of what the GPL license says and doesn't say. I think for the sake of discussion, it's best to assume Jeff's original post ( http://lists.drupal.org/pipermail/development/2007-August/026130.html ) is correct, because I think most GPL projects are starting to acknowledge they have a problem with bridges that connect GPL and non-GPL work.
Joomla's response was to provide no exceptions or compromise to their extensions (equivalent to Drupal's contributed modules). However, is there not room for compromise with a combination of Jeff's first two potential solutions? 1) Add a notice to Drupal's license that clarifies that writing such modules IS explicitly allowed. This is problematic, however, because that would make Drupal non-GPL'd itself, a GPL variant, and we would require explicit relicensing permission by the authors of any GPL code we wish to include. 2) Remove modules that integrate with third-party non-GPL code from the CVS repository, even if they do not *include* the aforementioned non-GPL code. Could we not provide a notice to Drupal's license (yes a variant of the GPL) that does allow an exception for contributed modules that bridge GPL with non-GPL software? At the same time require modules included in the Drupal core and supported at Drupal.org to remain fully GPL compliant? Of course those contributed modules that are not complaint to the GPL would need to be and could be hosted off-site elsewhere. In some way it's sad that a strict GPL license that helps us keep "free code" free prevents us from freely sharing the code we use to connect with non-GPL software. The reality is such a variant in the GPL license would reflect the "real world" realities that Laura Scott discussed in an earlier post ( http://lists.drupal.org/pipermail/development/2007-August/026167.html ) and really how Drupal's own open source culture has evolved. I of course only presented a suggestion, as in the past months I have yet to come up with real answers on my own ( http://cmsreport.com/node/1091 ). Bryan Ruby
Why don't we just allow contributed projects to check a box that adds an EXCEPTION.txt to their packaged modules/themes that allows "linking" to non-GPL code? We can even make the exception as narrow as possible: (x) My module does not require any non-GPL libraries. ( ) My module requires a non-GPL but FLOSS library. ( ) My module requires a proprietary library named [ ].
On Monday, 3. September 2007, Bryan Ruby wrote:
In some way it's sad that a strict GPL license that helps us keep "free code" free prevents us from freely sharing the code we use to connect with non-GPL software. The reality is such a variant in the GPL license would reflect the "real world" realities that Laura Scott discussed in an earlier post ( http://lists.drupal.org/pipermail/development/2007-August/026167.html ) and really how Drupal's own open source culture has evolved.
That may be true, but if that is the case then the GPL is simply the wrong license for Drupal. My impression is that all the people requesting "more freedom" (which is a wrong statement in itself because there's obviously various opinions on "what software freedom actually is") would rather have an LGPL Drupal than a GPL one. Also (I believe this has been mentioned before), you can't add such a license exception without tracking down *all* the copyright holders of Drupal code and getting their approval for this license change. (It's really a change, yes.) I find it tiresome to read about license amendments when we haven't even got a list of copyright holders. Could we please defer the "license exception" discussion until there's proper copyright headers in the source files? It's impossible to change the license until we've got those. Thanks, Jakob
On 04.09-14:05, Jakob Petsovits wrote: [ ... ]
I find it tiresome to read about license amendments when we haven't even got a list of copyright holders. Could we please defer the "license exception" discussion until there's proper copyright headers in the source files? It's impossible to change the license until we've got those.
this seems like a very sensible note on which to terminate this discussion.
If I write some code, any code, it is my writing and I can say "the copy, the distribution and the modification of this code is covered by GPL" -- GPL is only about these. Now that if this code, Drupal and some third party app together makes an application which can not be distributed/modified under the GPL because said third party has a nonGPL compatible licence -- tough luck, I do not care, we do not care. drupal.org does not host such applications, so what's the big deal...? To put in another way, this means that depending on what routines a script calls it might not licenceable under GPL...?
--- Karoly Negyesi <karoly@negyesi.net> wrote:
drupal.org does not host such applications, so what's the big deal...?
You cant be more wrong ;) take a look at http://drupal.org/project/smfforum , this is in violation of GPL as per this latest discussion. And its hosted on drupal. The module make direct calls do SMF API ( a non-GPL compliant ) product. ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/
On 9/6/07, Vivek Puri <crystalcube@yahoo.com> wrote:
--- Karoly Negyesi <karoly@negyesi.net> wrote:
drupal.org does not host such applications, so what's the big deal...?
You cant be more wrong ;) take a look at http://drupal.org/project/smfforum , this is in violation of GPL as per this latest discussion. And its hosted on drupal. The module make direct calls do SMF API ( a non-GPL compliant ) product.
At last! Now we are talking. Wouldn't someone have to challenge the conformance or the module with a particular article of its attached license to claim such a thing? As a side-issue, there is also the question of "legitimate interest" of the one who does challenge it. Doesn't the requirement of legitimate interest exist in most countries? (IANAL either).
--- Cog Rusty <cog.rusty@gmail.com> wrote:
You cant be more wrong ;) take a look at http://drupal.org/project/smfforum , this is in violation of GPL as per this latest discussion. And its hosted on drupal. The module make direct calls do SMF API ( a non-GPL compliant ) product.
At last! Now we are talking. Wouldn't someone have to challenge the conformance or the module with a particular article of its attached license to claim such a thing?
As a side-issue, there is also the question of "legitimate interest" of the one who does challenge it. Doesn't the requirement of legitimate interest exist in most countries? (IANAL either).
Its not so much as question of challenging it. The fact is that module clearly is in violation of GPL and still hosted on Drupal. So question is whats Drupal's policy ? Still continue to say that d.o. is fully compliant or d.o. doesn't care ? If we go by your logic then everyone will just use GPL software and release their own modules as proprietary license under the concept of "legitimate interest". After all everyone has "legitimate interest" to not release their own contributions as GPL ;) ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vivek Puri schrieb:
--- Cog Rusty <cog.rusty@gmail.com> wrote:
You cant be more wrong ;) take a look at
I am sure that Karoly knows that there are such modules on drupal.org.
http://drupal.org/project/smfforum , this is in violation of GPL as per this latest discussion. And its hosted on drupal. The module make direct calls do SMF API ( a non-GPL compliant ) product. At last! Now we are talking. Wouldn't someone have to challenge the conformance or the module with a particular article of its attached license to claim such a thing?
As a side-issue, there is also the question of "legitimate interest" of the one who does challenge it. Doesn't the requirement of legitimate interest exist in most countries? (IANAL either).
Its not so much as question of challenging it. The fact is that module clearly is in violation of GPL and
It violates the GPL if one accepts the interpetation of the GPL communicated to us by Jeff. Given that this interpretation is from the people who distribute the GPL is makes a lot of sense to me to stick by that interpretation. Of course, their interpretation won't be unbiased. But by chosing the GPL as our license we are already party anyway.
still hosted on Drupal. So question is whats Drupal's policy ?
Indeed.
Still continue to say that d.o. is fully compliant or d.o. doesn't care ?
As the CVS maintainer I care very much. However, I don't want to act rashly.
If we go by your logic then everyone will just use GPL software and release their own modules as proprietary license under the concept of "legitimate interest". After all everyone has "legitimate interest" to not release their own contributions as GPL ;)
I've never heard of a legal concept "legitimate interest" before... Here's a Stallman quote which elucidates some points of this threat: The GNU GPL is not Mr. Nice Guy. It says »no« to some of the things that people sometimes want to do. There are users who say that this is a bad thing that the GPL »excludes« some proprietary software developers who »need to be brought into the free software community.« But we are not excluding them from our community; they are choosing not to enter. Their decision to make software proprietary is a decision to stay out of our community. Being in our community means joining in cooperation with us; we cannot »bring them into our community« if they don't want to join. Richard Stallman I've found it in a commented version of the GPLv2 which can be downloaded from: http://www.ifross.de/ifross_html/Druckfassung/Die_GPL_kommentiert_und_erklae... It is probably interesting to people participating in this thread. You need to learn German first, though. :p The whole PDF has 192 pages so it becomes clear that this is not exactly an easygoing license. ;) Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG4ACKfg6TFvELooQRAi2lAJ4tpMl39j7VBuh9VCNmLIKvz7SDAwCfT4eX /xKuBH884Y4OWnu9vIS0BnM= =EKQd -----END PGP SIGNATURE-----
On 9/6/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote: ...snip...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vivek Puri schrieb:
--- Cog Rusty <cog.rusty@gmail.com> wrote:
You cant be more wrong ;) take a look at
I am sure that Karoly knows that there are such modules on drupal.org.
http://drupal.org/project/smfforum , this is in violation of GPL as per this latest discussion. And its hosted on drupal. The module make direct calls do SMF API ( a non-GPL compliant ) product. At last! Now we are talking. Wouldn't someone have to challenge the conformance or the module with a particular article of its attached license to claim such a thing?
As a side-issue, there is also the question of "legitimate interest" of the one who does challenge it. Doesn't the requirement of legitimate interest exist in most countries? (IANAL either).
Its not so much as question of challenging it. The fact is that module clearly is in violation of GPL and
It violates the GPL if one accepts the interpetation of the GPL communicated to us by Jeff.
Given that this interpretation is from the people who distribute the GPL is makes a lot of sense to me to stick by that interpretation.
Could Jeff or someone ask them how (an whether) they would go about challenging the legitimacy of the smf module's challenge legally? I mean, to which point of its attached license they would try to apply their interpretation? And then see how reasonable that sounds if presented in a court? I am not claiming that is a "no-go". I am claiming that it would make it clearer to ourselves what we are talking about.
Of course, their interpretation won't be unbiased. But by chosing the GPL as our license we are already party anyway.
We are also party to what the license text says. It is supposed to give us not only obligations but some protection under the law as well.
still hosted on Drupal. So question is whats Drupal's policy ?
Indeed.
Still continue to say that d.o. is fully compliant or d.o. doesn't care ?
As the CVS maintainer I care very much. However, I don't want to act rashly.
If we go by your logic then everyone will just use GPL software and release their own modules as proprietary license under the concept of "legitimate interest". After all everyone has "legitimate interest" to not release their own contributions as GPL ;)
I've never heard of a legal concept "legitimate interest" before...
In short, it means that you can't sue someone for causing damage to your neighbor's car, only your neighbor can.
Here's a Stallman quote which elucidates some points of this threat:
The GNU GPL is not Mr. Nice Guy. It says »no« to some of the things that people sometimes want to do. There are users who say that this is a bad thing that the GPL »excludes« some proprietary software developers who »need to be brought into the free software community.« But we are not excluding them from our community; they are choosing not to enter. Their decision to make software proprietary is a decision to stay out of our community. Being in our community means joining in cooperation with us; we cannot »bring them into our community« if they don't want to join.
Richard Stallman
I've found it in a commented version of the GPLv2 which can be downloaded from:
http://www.ifross.de/ifross_html/Druckfassung/Die_GPL_kommentiert_und_erklae...
It is probably interesting to people participating in this thread. You need to learn German first, though. :p The whole PDF has 192 pages so it becomes clear that this is not exactly an easygoing license. ;)
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG4ACKfg6TFvELooQRAi2lAJ4tpMl39j7VBuh9VCNmLIKvz7SDAwCfT4eX /xKuBH884Y4OWnu9vIS0BnM= =EKQd -----END PGP SIGNATURE-----
FYi - the SMF bridge to Joomla! is no longer available because Joomla! is interpreting the GPL in exactly the way Jeff communicated. I've forgotten now, but this may be one reason why he went to the FSF in the first place? http://www.simplemachines.org/community/index.php?topic=184558.0 -Peter On 9/6/07, Cog Rusty <cog.rusty@gmail.com> wrote:
On 9/6/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote: ...snip...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vivek Puri schrieb:
--- Cog Rusty <cog.rusty@gmail.com> wrote:
You cant be more wrong ;) take a look at
I am sure that Karoly knows that there are such modules on drupal.org.
http://drupal.org/project/smfforum , this is in violation of GPL as per this latest discussion. And its hosted on drupal. The module make direct calls do SMF API ( a non-GPL compliant ) product. At last! Now we are talking. Wouldn't someone have to challenge the conformance or the module with a particular article of its attached license to claim such a thing?
As a side-issue, there is also the question of "legitimate interest" of the one who does challenge it. Doesn't the requirement of legitimate interest exist in most countries? (IANAL either).
Its not so much as question of challenging it. The fact is that module clearly is in violation of GPL and
It violates the GPL if one accepts the interpetation of the GPL communicated to us by Jeff.
Given that this interpretation is from the people who distribute the GPL is makes a lot of sense to me to stick by that interpretation.
Could Jeff or someone ask them how (an whether) they would go about challenging the legitimacy of the smf module's challenge legally? I mean, to which point of its attached license they would try to apply their interpretation? And then see how reasonable that sounds if presented in a court? I am not claiming that is a "no-go". I am claiming that it would make it clearer to ourselves what we are talking about.
Of course, their interpretation won't be unbiased. But by chosing the GPL as our license we are already party anyway.
We are also party to what the license text says. It is supposed to give us not only obligations but some protection under the law as well.
still hosted on Drupal. So question is whats Drupal's policy ?
Indeed.
Still continue to say that d.o. is fully compliant or d.o. doesn't care ?
As the CVS maintainer I care very much. However, I don't want to act rashly.
If we go by your logic then everyone will just use GPL software and release their own modules as proprietary license under the concept of "legitimate interest". After all everyone has "legitimate interest" to not release their own contributions as GPL ;)
I've never heard of a legal concept "legitimate interest" before...
In short, it means that you can't sue someone for causing damage to your neighbor's car, only your neighbor can.
Here's a Stallman quote which elucidates some points of this threat:
The GNU GPL is not Mr. Nice Guy. It says »no« to some of the things that people sometimes want to do. There are users who say that this is a bad thing that the GPL »excludes« some proprietary software developers who »need to be brought into the free software community.« But we are not excluding them from our community; they are choosing not to enter. Their decision to make software proprietary is a decision to stay out of our community. Being in our community means joining in cooperation with us; we cannot »bring them into our community« if they don't want to join.
Richard Stallman
I've found it in a commented version of the GPLv2 which can be downloaded from:
http://www.ifross.de/ifross_html/Druckfassung/Die_GPL_kommentiert_und_erklae...
It is probably interesting to people participating in this thread. You need to learn German first, though. :p The whole PDF has 192 pages so it becomes clear that this is not exactly an easygoing license. ;)
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG4ACKfg6TFvELooQRAi2lAJ4tpMl39j7VBuh9VCNmLIKvz7SDAwCfT4eX /xKuBH884Y4OWnu9vIS0BnM= =EKQd -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Wolanin schrieb:
FYi - the SMF bridge to Joomla! is no longer available because Joomla! is interpreting the GPL in exactly the way Jeff communicated. I've forgotten now, but this may be one reason why he went to the FSF in the first place?
http://www.simplemachines.org/community/index.php?topic=184558.0
The situation is slightly different. In that case the bridge module itself wasn't under GPL, something we always said wasn't ok. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG4BYtfg6TFvELooQRAvR1AJ9+F3hXN2X2dwRV0nEDU+bB8/kycQCghM8K 1xvP64khoB8HSy4IFULEfgk= =FmZt -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gerhard Killesreiter schrieb:
Peter Wolanin schrieb:
FYi - the SMF bridge to Joomla! is no longer available because Joomla! is interpreting the GPL in exactly the way Jeff communicated. I've forgotten now, but this may be one reason why he went to the FSF in the first place?
http://www.simplemachines.org/community/index.php?topic=184558.0
The situation is slightly different. In that case the bridge module itself wasn't under GPL, something we always said wasn't ok.
However, the exchange the SMF guys had with the FSF is also applicable to our situation: http://www.simplemachines.org/community/index.php?topic=184557 Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG4Bhdfg6TFvELooQRAhp8AKCQ+ppdrLOufC0Ep2+wyalN5w5fOQCdHuvS 76vhk68iKN9JglVyjaQzQ/E= =q09O -----END PGP SIGNATURE-----
On 9/6/07, Peter Wolanin <pwolanin@gmail.com> wrote:
FYi - the SMF bridge to Joomla! is no longer available because Joomla! is interpreting the GPL in exactly the way Jeff communicated. I've forgotten now, but this may be one reason why he went to the FSF in the first place?
http://www.simplemachines.org/community/index.php?topic=184558.0
-Peter
Was the Joomla SMF bridge licensed under GPL in the first place? Reading the announcement it seems it was not.
--- Cog Rusty <cog.rusty@gmail.com> wrote:
Was the Joomla SMF bridge licensed under GPL in the first place? Reading the announcement it seems it was not.
What will licensing bridge under GPL achieve. Wouldn't that pass the buck to bridge ? If bridge is licensed under GPL then connecting bridge (GPL) with SMF ( non-GPL) is same situation whats the difference ? in any case another thread also highlights the discussion between SMF and FSF http://www.simplemachines.org/community/index.php?topic=184557.0 this very questioned has been asked and answered by FSF from that thread
If the glue does have to be GPL (or LGPL), could
the second script be
then legally licensed under a non-compatible license?
No.
____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/
On 9/6/07, Vivek Puri <crystalcube@yahoo.com> wrote:
--- Cog Rusty <cog.rusty@gmail.com> wrote:
Was the Joomla SMF bridge licensed under GPL in the first place? Reading the announcement it seems it was not.
What will licensing bridge under GPL achieve. Wouldn't that pass the buck to bridge ? If bridge is licensed under GPL then connecting bridge (GPL) with SMF ( non-GPL) is same situation whats the difference ?
No difference at all if we find that the GPL license text attached to a bridge module invalidates itself. But does it, and according to which point of the license text? That is my question. Of course it is always up to d.o. to interpret the license and kick out some module, which module then might be distributed somewhere else with the attached GPL license again. In that case, d.o. might have an interest to go to court (because it is a drupal module), but then d.o. would have to point out something in the license text, and possibly argue using the "system" interpretation.
in any case another thread also highlights the discussion between SMF and FSF http://www.simplemachines.org/community/index.php?topic=184557.0
this very questioned has been asked and answered by FSF
from that thread
If the glue does have to be GPL (or LGPL), could
the second script be
then legally licensed under a non-compatible license?
No.
____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/
Quoting Cog Rusty <cog.rusty@gmail.com>:
No difference at all if we find that the GPL license text attached to a bridge module invalidates itself. But does it, and according to which point of the license text? That is my question.
The point which is exampled by the original BSD[1] is the one that the smf module violates because of restrictions the Simple Machines license places [1],[2] and the fact that the module becomes a combined work since it includes source code from both for you to use the differing API. [1] http://www.fsf.org/licensing/licenses/gpl-faq.html#OrigBSD [2] http://www.simplemachines.org/about/license.php [3] http://www.simplemachines.org/about/opensource.php Earnie P.S. I am neither for or against the GPL but when I create something new I do not choose it because its viral nature removes a freedom I do not wish to remove. However, I do abide by it if others have chosen it for their works and will at that time promote it.
Well it's not even as nice as the rms quote, since we also have barriers to integrate with non-proprietary FLOSS, from AGPL to GPL 3. And then there's all the PEAR libraries which use PHP license. --mark On 9/6/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vivek Puri schrieb:
--- Cog Rusty <cog.rusty@gmail.com> wrote:
You cant be more wrong ;) take a look at
I am sure that Karoly knows that there are such modules on drupal.org.
http://drupal.org/project/smfforum , this is in violation of GPL as per this latest discussion. And its hosted on drupal. The module make direct calls do SMF API ( a non-GPL compliant ) product. At last! Now we are talking. Wouldn't someone have to challenge the conformance or the module with a particular article of its attached license to claim such a thing?
As a side-issue, there is also the question of "legitimate interest" of the one who does challenge it. Doesn't the requirement of legitimate interest exist in most countries? (IANAL either).
Its not so much as question of challenging it. The fact is that module clearly is in violation of GPL and
It violates the GPL if one accepts the interpetation of the GPL communicated to us by Jeff.
Given that this interpretation is from the people who distribute the GPL is makes a lot of sense to me to stick by that interpretation.
Of course, their interpretation won't be unbiased. But by chosing the GPL as our license we are already party anyway.
still hosted on Drupal. So question is whats Drupal's policy ?
Indeed.
Still continue to say that d.o. is fully compliant or d.o. doesn't care ?
As the CVS maintainer I care very much. However, I don't want to act rashly.
If we go by your logic then everyone will just use GPL software and release their own modules as proprietary license under the concept of "legitimate interest". After all everyone has "legitimate interest" to not release their own contributions as GPL ;)
I've never heard of a legal concept "legitimate interest" before...
Here's a Stallman quote which elucidates some points of this threat:
The GNU GPL is not Mr. Nice Guy. It says »no« to some of the things that people sometimes want to do. There are users who say that this is a bad thing that the GPL »excludes« some proprietary software developers who »need to be brought into the free software community.« But we are not excluding them from our community; they are choosing not to enter. Their decision to make software proprietary is a decision to stay out of our community. Being in our community means joining in cooperation with us; we cannot »bring them into our community« if they don't want to join.
Richard Stallman
I've found it in a commented version of the GPLv2 which can be downloaded from:
http://www.ifross.de/ifross_html/Druckfassung/Die_GPL_kommentiert_und_erklae...
It is probably interesting to people participating in this thread. You need to learn German first, though. :p The whole PDF has 192 pages so it becomes clear that this is not exactly an easygoing license. ;)
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG4ACKfg6TFvELooQRAi2lAJ4tpMl39j7VBuh9VCNmLIKvz7SDAwCfT4eX /xKuBH884Y4OWnu9vIS0BnM= =EKQd -----END PGP SIGNATURE-----
Quoting mark burdett <mfburdett@gmail.com>:
Well it's not even as nice as the rms quote, since we also have barriers to integrate with non-proprietary FLOSS, from AGPL to GPL 3. And then there's all the PEAR libraries which use PHP license.
My read of the PHP license leads me to believe it is compatible with GPL so the PEAR and PECL libraries shouldn't be a problem. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Well I was just regurgitating http://www.gnu.org/philosophy/license-list.html which describes PHP License as incompatible with GPL. I do have my own "readings" of the various licenses, IP law, etc. but won't waste the list's time ;) --mark On 9/7/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting mark burdett <mfburdett@gmail.com>:
Well it's not even as nice as the rms quote, since we also have barriers to integrate with non-proprietary FLOSS, from AGPL to GPL 3. And then there's all the PEAR libraries which use PHP license.
My read of the PHP license leads me to believe it is compatible with GPL so the PEAR and PECL libraries shouldn't be a problem.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Quoting mark burdett <mfburdett@gmail.com>:
Well I was just regurgitating http://www.gnu.org/philosophy/license-list.html which describes PHP License as incompatible with GPL. I do have my own "readings" of the various licenses, IP law, etc. but won't waste the list's time ;)
I suppose because of this <blockquote> 6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes PHP software, freely available from <http://www.php.net/software/>". </blockquote> Which is in direct conflict with this <blockquote> 3. The name "PHP" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact group@php.net. </blockquote> because you cannot do 6 without it being considered an endorsement and you would need permission from PHP. Earnie P.S.: How is it a waste of developers time to understand the legalities of what they agree to license their copyright with?
On 9/6/07, Vivek Puri <crystalcube@yahoo.com> wrote:
--- Cog Rusty <cog.rusty@gmail.com> wrote:
You cant be more wrong ;) take a look at http://drupal.org/project/smfforum , this is in violation of GPL as per this latest discussion. And its hosted on drupal. The module make direct calls do SMF API ( a non-GPL compliant ) product.
At last! Now we are talking. Wouldn't someone have to challenge the conformance or the module with a particular article of its attached license to claim such a thing?
As a side-issue, there is also the question of "legitimate interest" of the one who does challenge it. Doesn't the requirement of legitimate interest exist in most countries? (IANAL either).
Its not so much as question of challenging it. The fact is that module clearly is in violation of GPL and still hosted on Drupal. So question is whats Drupal's policy ? Still continue to say that d.o. is fully compliant or d.o. doesn't care ?
Isn't that begging the question? How is it in violation of GPL if it is not show to violate some term(s) of its attached license text? By popular vote? By an interpretation which was written and posted after the event? I said "now we are talking" believing that this was a chance to see how those interpretations can be applied in practice, but not by using more sweeping statements.
If we go by your logic then everyone will just use GPL software and release their own modules as proprietary license under the concept of "legitimate interest". After all everyone has "legitimate interest" to not release their own contributions as GPL ;)
By "legitimate interest" I was referring to something different: Under law usually, when you see a thief robbing someone, you can report it to the police but you can't sue the robber. Only the victim can (or the authorities if it is a penal offence and not just a civil one).You don't need legitimate interest to do something. You need it to challenge something. Also notice that to make a point you (we) always automatically refer to a case of stealing GPL'ed code and using it in proprietary software, and assume it self-evident that this is the case under discussion.
On 06.09-17:11, Cog Rusty wrote: [ ... ]
By "legitimate interest" I was referring to something different: Under law usually, when you see a thief robbing someone, you can report it to the police but you can't sue the robber. Only the victim can (or the authorities if it is a penal offence and not just a civil one).You don't need legitimate interest to do something. You need it to challenge something.
the GPL essestially transfers ownership to you and the therefore i would understand that anyone who uses GPL code has a legitimate interest. a legal case will be weakened in the absence of a copyright holder (and certainaly alterations to licensing are extremely complicated in their absence) but it is not required.
On Friday, 7. September 2007, ttw+drupal@cobbled.net wrote:
On 06.09-17:11, Cog Rusty wrote: [ ... ]
By "legitimate interest" I was referring to something different: Under law usually, when you see a thief robbing someone, you can report it to the police but you can't sue the robber. Only the victim can (or the authorities if it is a penal offence and not just a civil one).You don't need legitimate interest to do something. You need it to challenge something.
the GPL essestially transfers ownership to you and the therefore i would understand that anyone who uses GPL code has a legitimate interest. a legal case will be weakened in the absence of a copyright holder (and certainaly alterations to licensing are extremely complicated in their absence) but it is not required.
No, it doesn't transfer ownership. It grants you a license to use, modify and redistribute the code, but it doesn't transfer ownership. You'll most likely need a copyright holder to sue violators.
On 07.09-15:15, Jakob Petsovits wrote: [ ... ]
No, it doesn't transfer ownership. It grants you a license to use, modify and redistribute the code, but it doesn't transfer ownership. You'll most likely need a copyright holder to sue violators.
ownership was a badly chosen term, apologies, it transfers equal rights of use to all parties. does than mean in the death or absence of a copyright holder that the GPL may be, essentiall, ignored? this seems problematic. in the case of copyright i understand rights transfer to the next of kin but with free software it seems there is little incentive for next of kin to pursue issues of copyright. furthermore, in the absence of *all* copright holders the right to challange may also be brought into question. is anyone aware of a case in point?
On Friday, 7. September 2007, ttw+drupal@cobbled.net wrote:
On 07.09-15:15, Jakob Petsovits wrote: [ ... ]
No, it doesn't transfer ownership. It grants you a license to use, modify and redistribute the code, but it doesn't transfer ownership. You'll most likely need a copyright holder to sue violators.
ownership was a badly chosen term, apologies, it transfers equal rights of use to all parties.
does than mean in the death or absence of a copyright holder that the GPL may be, essentiall, ignored? this seems problematic. in the case of copyright i understand rights transfer to the next of kin but with free software it seems there is little incentive for next of kin to pursue issues of copyright. furthermore, in the absence of *all* copright holders the right to challange may also be brought into question.
That's exactly what I wanted to say, thanks for the to-the-point explanation. Since I don't want to be known for insisting on copyright headers, I won't mention them here (...hehe), but you get the point.
is anyone aware of a case in point?
I'm not.
Hi, I'm starting a project where I need to make a larger database that I'm used to make. I can use a little advise on this project. Each record in the database will include 1 to 3 photo and some other information, in total aproximately 100k of memory per record. I expect a total of maximum 500 records per category (1000 categories). So 500 x 1000 x 100K = 50G. It is possible to store all data in one table. This database will be used between a larger database and the clients. My question is: is one table feasable for this amount of data? Or would it be recommended to store the data in different tables. The key factor here is speed. If the client wants to see some information (always with at least 1 photo), the time to get the information from the database to the screen should be minimal. thanks, Glenn _________________________________________________________________ Ontwerp je eigen Space op het net en deel wat je lief is met je vrienden! http://spaces.live.com
Glenn, I think that all the standard ways of storing images in Drupal is to store the file location in the database but to keep the photo itself in the server's /files directory. Are you doing something different? Shai On 9/7/07, Glenn Wybo <glennwybo@hotmail.com> wrote:
Hi,
I'm starting a project where I need to make a larger database that I'm used to make. I can use a little advise on this project. Each record in the database will include 1 to 3 photo and some other information, in total aproximately 100k of memory per record. I expect a total of maximum 500 records per category (1000 categories). So 500 x 1000 x 100K = 50G. It is possible to store all data in one table. This database will be used between a larger database and the clients. My question is: is one table feasable for this amount of data? Or would it be recommended to store the data in different tables. The key factor here is speed. If the client wants to see some information (always with at least 1 photo), the time to get the information from the database to the screen should be minimal.
thanks,
Glenn _________________________________________________________________ Ontwerp je eigen Space op het net en deel wat je lief is met je vrienden! http://spaces.live.com
Glen Regarding
I'm starting a project where I need to make a larger database that I'm used to make. I can use a little advise on this project. Each record in the database will include 1 to 3 photo and some other information, in total aproximately 100k of memory per record. I expect a total of maximum 500 records per category (1000 categories). So 500 x 1000 x 100K = 50G. It >> is possible to store all data in one table. This database will be used between a larger database and the clients. My question is: is one table feasable for this amount of data? Or would it be recommended to store the data in different tables. The key factor here is speed. If the client wants to see some information (always with at least 1 photo), >> the time to get the information from the database to the screen should be minimal.
Are you really planning on storing the photo's in the table. It is generally more useful to store the image on the file system and just the path in the database (you just need the image path and not the image for the browser). If you are not planning on placing the images in the database 100K is a lot of data, more than make sense to display on a single screen. As for speed, one of the factors is a unique key for each record another though is how you plan to look stuff up. Just the potential number of records is large (500,000) and almost twice as many comments a drupal.org has. The "obvious" way to break up the table would be to use 1000 a smaller tables, but too many tables can also cause a problem. The bottom line is it will take some tweeking to get things "right" and that will depend on the details of the data and how the data is accesed. Steve
On Fri, 7 Sep 2007 09:51:00 -0600, "Steve Ringwood" <nevets@mailbag.com> wrote:
Are you really planning on storing the photo's in the table. It is generally more useful to store the image on the file system and just the path in the database (you just need the image path and not the image for the browser). If you are not planning on placing the images in the database 100K is a lot of data, more than make sense to display on a single screen.
As for speed, one of the factors is a unique key for each record another though is how you plan to look stuff up. Just the potential number of records is large (500,000) and almost twice as many comments a drupal.org has. The "obvious" way to break up the table would be to use 1000 a smaller tables, but too many tables can also cause a problem. The bottom line is it will take some tweeking to get things "right" and that will depend on the details of the data and how the data is accesed.
Steve
If you're looking up records by a numeric primary key (which is most things in Drupal) or by some other properly indexed value, 500,000 records is nothing. A good RDBMS can handle millions of records. The keyspace for the primary key, if it's an integer, is somewhere around 3 million. Using an unsigned int or bigint will increase that even further. Just use the Drupal file API. It puts the files on disk and the path in the files table, and should scale to hundreds of thousands of records just fine if you're using a recent version of MySQL. --Larry Garfield
The "obvious" way to break up the table would be to use 1000 a smaller tables, but too many tables can also cause a problem.
You might also look at table partitioning: http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html Basically, it splits one tall table into many, smaller chunks that look and behave like a single table. So you don't have to change your queries but you could possibly get some performance benefits by not having to scan or load as much of a table into memory. I'm not a DBA, so I don't know how this really ends up working in practice, but that's the theory at least. -Mark
Ok, thanks, well, was considering if it would be necessary to use BLOB's to upload the images to a database between our server and the compunter of the client. The thing is that my boss wants to upload many images (corresponding with the company of the customer) to another database when the customer logs in on the website. This database will only be used for storing the images and the corresponding data. The only reason for this is to improve speed. When the customer selects a couple of images, it may only be a matter of milliseconds to select the images (and the data that corresponds with it) in the database and upload it to the screen of the user. thanks for the advice, Glenn
Date: Fri, 7 Sep 2007 10:20:27 -0500 From: mark.m.fredrickson@gmail.com To: development@drupal.org; nevets@mailbag.com Subject: Re: [development] table vs tables
The "obvious" way to break up the table would be to use 1000 a smaller tables, but too many tables can also cause a problem.
You might also look at table partitioning:
http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html
Basically, it splits one tall table into many, smaller chunks that look and behave like a single table. So you don't have to change your queries but you could possibly get some performance benefits by not having to scan or load as much of a table into memory.
I'm not a DBA, so I don't know how this really ends up working in practice, but that's the theory at least.
-Mark
_________________________________________________________________ Een dagje naar het strand? Neem je vrienden mee! http://get.libe.com/mobile/messenger
Hi Glenn, In the future, please create a new email instead of replying to a threaded one. Your question ended up in the middle of a long discussion about Drupal and GPL. Emails that are threaded are tagged so your email client can tell which emails relate. When you replied, your email got tagged making it appear being part of the GPL discussion. Creating a new (untagged) email, your email will be considered to be a new thread and will end up at the "root" level. Thank you, Jakob Persson Glenn Wybo wrote:
Ok, thanks,
well, was considering if it would be necessary to use BLOB's to upload the images to a database between our server and the compunter of the client. The thing is that my boss wants to upload many images (corresponding with the company of the customer) to another database when the customer logs in on the website. This database will only be used for storing the images and the corresponding data. The only reason for this is to improve speed. When the customer selects a couple of images, it may only be a matter of milliseconds to select the images (and the data that corresponds with it) in the database and upload it to the screen of the user.
thanks for the advice,
Glenn
Date: Fri, 7 Sep 2007 10:20:27 -0500 From: mark.m.fredrickson@gmail.com To: development@drupal.org; nevets@mailbag.com Subject: Re: [development] table vs tables
The "obvious" way to break up the table would be to use 1000 a smaller tables, but too many tables can also cause a problem.
You might also look at table partitioning:
http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html
Basically, it splits one tall table into many, smaller chunks that look and behave like a single table. So you don't have to change your queries but you could possibly get some performance benefits by not having to scan or load as much of a table into memory.
I'm not a DBA, so I don't know how this really ends up working in practice, but that's the theory at least.
-Mark
------------------------------------------------------------------------ Bekijk de beste Live Earth concerten op MSN 07/07/07 Live Earth <http://liveearth.be.msn.com/>
See I shot myself in the foot here. Quite embarrassing frankly... "Reply to Sender Only" is obviously not working as it should in my version of Thunderbird. Anyhow, do not make my mistake please. Thank you for your consideration. Sincerely, Jakob Persson Jakob Persson wrote:
Hi Glenn,
In the future, please create a new email instead of replying to a threaded one. Your question ended up in the middle of a long discussion about Drupal and GPL. Emails that are threaded are tagged so your email client can tell which emails relate. When you replied, your email got tagged making it appear being part of the GPL discussion. Creating a new (untagged) email, your email will be considered to be a new thread and will end up at the "root" level.
Thank you,
Jakob Persson
Having your web server serve the images as files off the filesystem disk is almost guaranteed to be faster than serving them out of BLOBs in a database. Don't put them in the database, unless you really need to, is a good general rule. A database with 500,000 records with a decent primary key will be plenty fast for everything else. ..chrisxj On 9/10/07, Glenn Wybo <glennwybo@hotmail.com> wrote:
Ok, thanks,
well, was considering if it would be necessary to use BLOB's to upload the images to a database between our server and the compunter of the client. The thing is that my boss wants to upload many images (corresponding with the company of the customer) to another database when the customer logs in on the website. This database will only be used for storing the images and the corresponding data. The only reason for this is to improve speed. When the customer selects a couple of images, it may only be a matter of milliseconds to select the images (and the data that corresponds with it) in the database and upload it to the screen of the user.
thanks for the advice,
Glenn
Date: Fri, 7 Sep 2007 10:20:27 -0500 From: mark.m.fredrickson@gmail.com To: development@drupal.org; nevets@mailbag.com Subject: Re: [development] table vs tables
The "obvious" way to break up the table would be to use 1000 a smaller tables, but too many tables can also cause a problem.
You might also look at table partitioning:
http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html
http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html
Basically, it splits one tall table into many, smaller chunks that look and behave like a single table. So you don't have to change your queries but you could possibly get some performance benefits by not having to scan or load as much of a table into memory.
I'm not a DBA, so I don't know how this really ends up working in practice, but that's the theory at least.
-Mark
________________________________ Bekijk de beste Live Earth concerten op MSN 07/07/07 Live Earth
You cant be more wrong ;) take a look at http://drupal.org/project/smfforum , this is in violation of GPL as per this latest discussion.
Yes but I questioned the sanity the whole of the discussion. To sum up: How could be any code designed by its author to be under the GPL be in violation of the GPL?
How could be any code designed by its author to be under the GPL be in violation of the GPL?
very simply by not complying to it ;) But thats the whole discussion is about as to under what circumstances this so called violation happens. GPL doesn't just defines the license it also defines the whole mumbo jumbo around interfacing. I am not sure most people here are aware but MySQL made their Libraries from LGPL to GPL but have given a small exception to PHP to include MySQL libraries. So basically if you connect a piece of software to another , in case of GPL , both have to comply, Unless an exception is granted. So in essence to be able to use any bridge Drupal have to grant exception to all such bridges. Which is not easy unless all the contributors can be tracked and they agree to it. ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/
----- Start Original Message ----- Sent: Thu, 6 Sep 2007 04:01:52 -0700 (PDT) From: Vivek Puri <crystalcube@yahoo.com> To: development@drupal.org Subject: Re: [development] Modules that integrate non-GPL PHP apps violate the GPL.
How could be any code designed by its author to be under the GPL be in violation of the GPL?
very simply by not complying to it ;)
But as GPL only covers the copy and the modification of the code ... it's my code I allow you to copy, distribute and modify under GPL... I do not get it. You are saying that calling a non-GPL code as PHP function takes away my rights to license my own code as I see fit?
Quoting Karoly Negyesi <karoly@negyesi.net>:
----- Start Original Message ----- Sent: Thu, 6 Sep 2007 04:01:52 -0700 (PDT) From: Vivek Puri <crystalcube@yahoo.com> To: development@drupal.org Subject: Re: [development] Modules that integrate non-GPL PHP apps violate the GPL.
How could be any code designed by its author to be under the GPL be in violation of the GPL?
very simply by not complying to it ;)
But as GPL only covers the copy and the modification of the code ... it's my code I allow you to copy, distribute and modify under GPL... I do not get it. You are saying that calling a non-GPL code as PHP function takes away my rights to license my own code as I see fit?
The GPL takes away that right why can't a non-GPL license take away that right? Earnie
Quoting Vivek Puri <crystalcube@yahoo.com>:
I am not sure most people here are aware but MySQL made their Libraries from LGPL to GPL but have given a small exception to PHP to include MySQL libraries.
So that's the reason why I need to go to MySql to get the PHP loadable module that PHP no longer distributes! PHP wants to be GPL free. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On 06.09-07:28, Earnie Boyd wrote: [ ... ]
So that's the reason why I need to go to MySql to get the PHP loadable module that PHP no longer distributes! PHP wants to be GPL free.
i do not think it is precicesly a 'legal' reason but more the divergance in doctrines. RMS' statement about not accepting people into a community because they choose not to join is the fundamental issue. freedoms cannot be given or taken away or chosen, they are rights of a free individual, all we can do as a society is choose to recognise them or not. this is an issue that we should talk about forever because basically it is far more important than software.
Quoting ttw+drupal@cobbled.net:
On 06.09-07:28, Earnie Boyd wrote: [ ... ]
So that's the reason why I need to go to MySql to get the PHP loadable module that PHP no longer distributes! PHP wants to be GPL free.
i do not think it is precicesly a 'legal' reason but more the divergance in doctrines. RMS' statement about not accepting people into a community because they choose not to join is the fundamental issue. freedoms cannot be given or taken away or chosen, they are rights of a free individual, all we can do as a society is choose to recognise them or not. this is an issue that we should talk about forever because basically it is far more important than software.
RMS strives to have everyone in one community and has created a license that removes your rights to join other communities. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Since the FSF does not hold the copyright for Drupal, all that matters is what the GPL actually says. To quote, "The FSF folks, when I asked about this, basically said that it was probably violating the spirit of the GPL but not the letter." I still think the wrong question was answered. The GPL is a one-way infection: non-free software cannot GPL components, but GPL code can use non-free components. To quote again: "While the GPL only covers distribution, they consider it a GPL violation to *distribute software that is intended to be used in violation of the GPL*. In other words, distributing a proprietary commercial piece of software that relies on GPL libraries, and telling people, 'We can't put X into our program, but you can to make it work...' is creating a GPL- derived program just as much as rolling the GPL'd libraries in and then distributing." There is a possibility that a third-party app may have a similarly viral license that is incompatible with the GPL. In that case, it would not be legal to distribute a module that makes use of the app. On Sep 3, 2007, at 11:32 PM, Jeff Eaton wrote:
On Sep 3, 2007, at 10:04 AM, Darren Oh wrote:
Based on the evidence presented in this discussion, it would not be against either the spirit or the letter of the GPL for a developer to distribute a module that integrates an existing third- party app that does not use Drupal and to which the developer does not own the rights.
This is exactly the opposite of what the FSF said when I asked them that question directly.
--Jeff
On Sep 3, 2007, at 6:43 PM, Darren Oh wrote:
I still think the wrong question was answered. The GPL is a one-way infection: non-free software cannot GPL components, but GPL code can use non-free components.
Your position is one interpretation of the GPL. It is contradicted by the GPL FAQ, and what the original authors of the GPL said when specifically asked. I can't really say anything more, I'm just relaying what I have been told. --Jeff
Quoting Jeff Eaton <jeff@viapositiva.net>:
On Sep 3, 2007, at 6:43 PM, Darren Oh wrote:
I still think the wrong question was answered. The GPL is a one-way infection: non-free software cannot GPL components, but GPL code can use non-free components.
Your position is one interpretation of the GPL. It is contradicted by the GPL FAQ, and what the original authors of the GPL said when specifically asked. I can't really say anything more, I'm just relaying what I have been told.
My GPL library, program, module, wrapper, etc cannot be a conduit for the GPL virus. I can use a non-GPL library (open source or proprietary) in my module and still license it as GPL. This doesn't cause the non-GPL library to then become GPL. What I can't do is use a non-GPL library whose license is incompatible with the GPL license and then distribute my module. An incompatible license is one that counteracts or conflicts with the statements of the GPL. I cannot distribute two differing viral licenses. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Darren Oh wrote:
I still think the wrong question was answered. The GPL is a one-way infection: non-free software cannot GPL components, but GPL code can use non-free components.
I'm not a lawyer, but I think that's impossible. The GPL cannot tell me what I can and cannot do with my own, proprietary code, even if I provide instructions to end users telling them to compile my code with a GPLed library. And unless calling a library's functions constitutes a derivative work (which it doesn't seem to, see <http://www.rosenlaw.com/lj19.htm>), the GPL cannot prevent me from downloading a GPL library and working on my own proprietary code that compiles against the library. I can then distribute that proprietary code with the aforementioned instructions (though not the library itself). I know this isn't how most people interpret the viral nature of the GPL, but I simply don't see the mechanism that the GPL would use to prevent proprietary software developers from compiling their code against GPLed libraries in development and distributing the proprietary source code in a non-GPL form to be compiled with GPL code by end users. At what point would the developers be forced to accept the GPL's terms? You have to agree to the GPL if you (re)distribute GPLed works -- but not if you only download them, use them, or install them. If you download a GPL library and develop proprietary code that uses the library, you have not been forced to accept the GPL. For this reason, I think it's ridiculous when GPLed programs ask me to "accept" the GPL on installation. The GPL is quite clear about this:
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.
Moreover:
You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works.
Now, if the GPL required that you accept it to *use* code, it might be a different matter because you would be agreeing to the infection clause in the library's license. But this infection clause seems to go well beyond what normal copyright would consider a derivative work. I would love to have someone clear up any errors in my interpretation. While I love the FSF, they have a vested interest in presenting the GPL as viral as possible. So, I don't consider their FAQ to be a reliable, unbiased source.
On Tuesday 04 September 2007, David Strauss wrote:
I would love to have someone clear up any errors in my interpretation. While I love the FSF, they have a vested interest in presenting the GPL as viral as possible. So, I don't consider their FAQ to be a reliable, unbiased source.
I think we're at the point where we all need to wait while someone finds a real lawyer to ask, since we're just going around in circles and even admitting it. :-) So, what pertinent questions should be asked of an actual lawyer, not employed by FSF, by whoever it is that is doing so (Drupal Association, a consulting firm, whoever)? I would start with: Scenario: There exists non-GPL system. A Drupal module is written that allows Drupal to access that system via its APIs within a PHP process. That module is committed to Drupal CVS, and therefore distributed under the GPL. Legal or illegal? Scenario: There exists non-GPL system. A Drupal module is written that allows Drupal to access that system via some external API (XML-RPC, SOAP, REST, HTTP, or some other non-shared-memory-space system). That module is committed to Drupal CVS, and therefore distributed under the GPL. Legal or illegal? Scenario: There exists a non-GPL system. A Drupal module is written that allows Drupal to access that system via either of the methods listed above (in-process or out-of-process). That module is provided by its author to a client/customer for use with their non-GPL system, without going through Drupal CVS. Under what licenses (GPL, non-GPL, or ownership transfer with reverse license) could that module be legally provided to said client? (Scenario 3 is actually a couple of scenarios rolled into one, but it's easier than restating every possible combination.) We're not lawyers. Let's find one so we can put this issue to rest and get back to writing GPLed code in the first place. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Sep 4, 2007, at 1:26 PM, David Strauss wrote:
You have to agree to the GPL if you (re)distribute GPLed works -- but not if you only download them, use them, or install them. If you download a GPL library and develop proprietary code that uses the library, you have not been forced to accept the GPL. For this reason, I think it's ridiculous when GPLed programs ask me to "accept" the GPL on installation.
The GPL is quite clear about this:
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.
Moreover:
You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works.
Now, if the GPL required that you accept it to *use* code, it might be a different matter because you would be agreeing to the infection clause in the library's license. But this infection clause seems to go well beyond what normal copyright would consider a derivative work.
I would love to have someone clear up any errors in my interpretation. While I love the FSF, they have a vested interest in presenting the GPL as viral as possible. So, I don't consider their FAQ to be a reliable, unbiased source.
The argument being made is that distributing a module that allows Drupal to use separately distributed third-party code would make the third-party code a modification of Drupal (and therefore illegal if the module author cannot also release the third-party code under the GPL). If that is really what the FSF is claiming, I too would question the reliability of their interpretation.
Darren Oh skrev:
The argument being made is that distributing a module that allows Drupal to use separately distributed third-party code would make the third-party code a modification of Drupal...
Assume you write a module for Drupal. Any meaningful module to Drupal implements at least one hook. That alone makes the module a derived work of Drupal. The law prohibits you to modify or distributing a work or its derivative works, unless the holder of the Intellectual Property Rights grants you permission to do otherwise. GPL grants you such rights *if and only if* you comply to certain terms and conditions. No one force you to accept these. But as stated in § 5 of the license: "nothing else grants you permission to modify or distribute the Program or its derivative works." So, if you distribute your module, either you have accepted the GPL or you are committing infringement on the intellectual property rights. I presume you are law-abiding, and hence indeed have accepted the GPL. :-) As a consequence, your module must also be distributed under the GPL. Now, suppose your module also make use of another program. If your module just invokes the other program's main function with some options and waiting for it to return, for instance by using fork and exec, there is nothing to worry about. But if your program and the other program are linked, even if it is done only at runtime, and make function calls to each other and share data structures, your module is a derivative work of the other program as well. Since you already have accepted to distribute your module under GPL and nothing by GPL, the license of the other program must allow its derivative works to be licensed under GPL. A license which allows that is said to be compatible with GPL. Examples of compatible licenses include the revised BSD and the MIT licenses. If the other program's license is not compatible with GPL, then you cannot distribute your module. It is as simple as that. There is however a way out. Drupal.org could add an exception to the license. Examples of such exceptions are described in the GPL FAQ: * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLib... * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingOverControl...
If that is really what the FSF is claiming, I too would question the reliability of their interpretation.
Some reading sugestions: * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLAndPlugins * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLib... * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#FSWithNFLibs Best regards, Thomas
That alone makes the module a derived work of Drupal.
But if your program and the other program are linked, even if it is done only at runtime, and make function calls to each other and share data structures, your module is a derivative work of the other program as well.
AAAAAAAAH! Finally somebody explained this whole situation clearly. So if I am writing a bridge to run with Drupal that's GPL because of Drupal and because it's considered a derivative of some non-GPL code that means I am breaking some clause in the *other* code licence and we know there is such a clause *because* it is non GPL compatible. So the issue looked cloudy because we know the bridge breaks some rule but it can not be told what without studying the other licence. This makes sense to my obsessed-with-math-logic mind. For the first time, this debacle makes sense even if not a pleasant one. However, there seems to be an escape! http://forum.joomla.org/index.php?topic=190545.0 this ends with "the LGPL would allow someone else to derive code based on it without any restriction you can make a LGPL bridge to buffer your proprietary extention (such as SMF) to a GPL program." So, if this holds up then we should allow LGPL code in our repo and ask the bridge module authors to LGPL their code. This is a ton easier than, say, changing the licence of Drupal core.
Quoting Karoly Negyesi <karoly@negyesi.net>:
That alone makes the module a derived work of Drupal.
But if your program and the other program are linked, even if it is done only at runtime, and make function calls to each other and share data structures, your module is a derivative work of the other program as well.
AAAAAAAAH! Finally somebody explained this whole situation clearly.
So if I am writing a bridge to run with Drupal that's GPL because of Drupal and because it's considered a derivative of some non-GPL code that means I am breaking some clause in the *other* code licence and we know there is such a clause *because* it is non GPL compatible. So the issue looked cloudy because we know the bridge breaks some rule but it can not be told what without studying the other licence. This makes sense to my obsessed-with-math-logic mind. For the first time, this debacle makes sense even if not a pleasant one.
Yes, but you could also be breaking a clause in the GPL (the most likely scenario). Yes, you must compare both licenses to determine if they fit together.
However, there seems to be an escape! http://forum.joomla.org/index.php?topic=190545.0 this ends with "the LGPL would allow someone else to derive code based on it without any restriction you can make a LGPL bridge to buffer your proprietary extention (such as SMF) to a GPL program."
I don't buy into it. The GPL and the LGPL are the same except that LGPL gives others the right to use the binary version of your API without GPL viral infection. If you provide no API then the exception is worthless. And the statements of the GPL state that you must GPL the combined work so you can't just apply the LGPL exception to your module because the Drupal license doesn't allow for it.
So, if this holds up then we should allow LGPL code in our repo and ask the bridge module authors to LGPL their code. This is a ton easier than, say, changing the licence of Drupal core.
The license of the Drupal core license is the one that rules in this situation. Since I must use Drupal API I must GPL accordingly. The only option is that the Drupal core license provide exceptions for the use of third party libraries. Note the LGPL here isn't sufficient (check out the FSF libstdc++ exceptions) since *source* code for the API must actually be included. The LGPL exception is for the *binary* use including the declaratives for the API but not code that is included by other files such as you might find in a C++ header or a PHP include file. It's not L'ibrary'GPL it is L'esser'GPL. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On 07.09-12:35, Karoly Negyesi wrote: [ ... ]
But if your program and the other program are linked, even if it is done only at runtime, and make function calls to each other and share data structures, your module is a derivative work of the other program as well.
AAAAAAAAH! Finally somebody explained this whole situation clearly.
i'm afraid this isn't possible. this situation is unclear, period. if you have a specific issue i suggest you reference the previous poster's suggestions on getting around the GPL's problem areas or talk to a lawyer. the LGPL is not about using the API it is about distributing code or binaries based upon that free code. for example i could write an photo gallery and use LGPL libraries, then package them up and sell them as a product. this would not be possible if they were GPL, you cannot distribute that code as part of something that does not have a compatible license. if those libraries were GPL i could still use them in my code but the person who installed my proprietry program would be required to find and either build or install the GPL libraries instead. this is considered, by many, to be a loophole. obviously, from the above the LGPL is not suitable for Drupal as it would allow me to write a module to extend Drupal and then distribute an entirely functioning product (which would be 90% stolen code) as my own, charge for it, and avoid sharing my module with the community. currently, nothing (that i know of) can stop me writing a module and distributing it under any license i like but my users would need to go to Drupal and get that product (where it would explain the relevance and need for free software) seperately. basically, if you wish to use free software to produce proprietry solutions question your conscience first, do the best you can in your sitation and double check the _specific_ decisions with community and legal references. i would suggest that, even if you are legally covered, if a specific community clearly does not wish you to interface their product with any proprietry code you must again ask your consience if you are stealing. but remember everyone has the same right of ownership to code as you this is the fundamental action (and power) of free code. if you are on the other side (i.e. releasing code) and want to figure out which license to use, guidance by the FSF around leveraging your input to help propogate free code is, if your code is 'competing' with widely available propietory code performing the same function, and, there is reasonable likely hood that allowing it to be used in non-free software will increase it's distribution and use then use the LGPL (simple example would be the code produced by a complier-compiler like yacc). in any other circumstance use the GPL. i.e. the LGPL will never be suitable for a Drupal module (except, perhaps, in legal dance where developers need to interface with another incompatible license ... of course, we all want you to fight for free software first in this situation, but you can't win them all :-). as you can tell from the complicated nature of this discussion this is not clear cut or defined. many do not want their code to be used at all unless it is propogating their notions of freedom or notions of freedom they deem compatible with their own. this is, quite obviously, contrary to the notion of freedom but unfortunately a popular 'free' political doctrine. it's understandable, people are basically using free code and products and then basically, re-branding it and selling it; which is pretty despicable practice. but that is freedom for you, we have people using the freedom of speech to say pretty despicable things too.
Karoly Negyesi skrev:
That alone makes the module a derived work of Drupal.
But if your program and the other program are linked, even if it is done only at runtime, and make function calls to each other and share data structures, your module is a derivative work of the other program as well.
AAAAAAAAH! Finally somebody explained this whole situation clearly.
So if I am writing a bridge to run with Drupal that's GPL because of Drupal and because it's considered a derivative of some non-GPL code that means I am breaking some clause in the *other* code licence and we know there is such a clause *because* it is non GPL compatible.
Correct.
So the issue looked cloudy because we know the bridge breaks some rule but it can not be told what without studying the other licence. This makes sense to my obsessed-with-math-logic mind. For the first time, this debacle makes sense even if not a pleasant one.
However, there seems to be an escape! http://forum.joomla.org/index.php?topic=190545.0 this ends with "the LGPL would allow someone else to derive code based on it without any restriction you can make a LGPL bridge to buffer your proprietary extention (such as SMF) to a GPL program."
There is no "escape". Since the module is a derived work of Drupal which is licensed to you under GPL, you must license your module under GPL as well. It is not allowed to use LGPL. The discussion in the J! thread is about integrating a third-party software which is licensed under LGPL. That is perfectly legal since LGPL is compatible with GPL.
So, if this holds up then we should allow LGPL code in our repo and ask the bridge module authors to LGPL their code. This is a ton easier than, say, changing the licence of Drupal core.
Sorry, it doesn't hold up However, if your module contains a large portion of code which is independent of Drupal, you could release that part as a library with a GPL compatible license, e.g. BSD, MIT or LGPL, and then use it with your module. Your library can now be distributed on its own under any license. But as part of your module, it will be distributed under GPL. Best regards, Thomas
On 9/7/07, Thomas Barregren <thomas@webbredaktoren.se> wrote:
But if your program and the other program are linked, even if it is done only at runtime, and make function calls to each other and share data structures, your module is a derivative work of the other program as well.
If this is true and legally correct (and I understand it), then we are lucky the FSF doesn't have the money to sue thousands of cases in court. Because every time a GPL program is compiled and run on a non-GPL operating system, it's going to be breaking this "rule." No GPL software could be run on Mac OS or Windows, if it called the OS or any GUI API. Such is the spiral of insanity that this provision of the GPL causes.
On 07.09-14:01, Chris Johnson wrote: [ ... ]
If this is true and legally correct (and I understand it), then we are lucky the FSF doesn't have the money to sue thousands of cases in court. Because every time a GPL program is compiled and run on a non-GPL operating system, it's going to be breaking this "rule." No GPL software could be run on Mac OS or Windows, if it called the OS or any GUI API.
there is in fact a specific exclusion clause to this effect. but yes, it is a spiral of insanity, people fighting against the precise freedoms they attempt to protect. a lawyer's wet dream.
Chris Johnson skrev:
On 9/7/07, Thomas Barregren <thomas@webbredaktoren.se> wrote:
But if your program and the other program are linked, even if it is done only at runtime, and make function calls to each other and share data structures, your module is a derivative work of the other program as well.
If this is true and legally correct (and I understand it), then we are lucky the FSF doesn't have the money to sue thousands of cases in court. Because every time a GPL program is compiled and run on a non-GPL operating system, it's going to be breaking this "rule." No GPL software could be run on Mac OS or Windows, if it called the OS or any GUI API.
You comment only proves that you in fact have not read the license. Please do that before you comment. Hint: § 3 of GPL v2. Thomas
On 9/8/07, Thomas Barregren <thomas@webbredaktoren.se> wrote:
Chris Johnson skrev:
On 9/7/07, Thomas Barregren <thomas@webbredaktoren.se> wrote:
But if your program and the other program are linked, even if it is done only at runtime, and make function calls to each other and share data structures, your module is a derivative work of the other program as well.
If this is true and legally correct (and I understand it), then we are lucky the FSF doesn't have the money to sue thousands of cases in court. Because every time a GPL program is compiled and run on a non-GPL operating system, it's going to be breaking this "rule." No GPL software could be run on Mac OS or Windows, if it called the OS or any GUI API.
You comment only proves that you in fact have not read the license. Please do that before you comment.
Hint: § 3 of GPL v2.
No, actually I was well aware of the exception clause. I've read GPL v2 dozens of times, and the exception itself was mentioned earlier in this very thread. The point is, what sorts of uses constitute valid exceptions and which do not. Just what is a "major component?" What is an "operating system?" You might be surprised just how various courts in various countries might define those terms. For instance, can a Mac OS X dashboard widget be GPL? They depend on more than just OS X -- they depend on an application program, which many would not consider to be a "major component" of the operating system. That is, once again, what is a derivative work? Paragraphs 2 and 3 are inadequate to define it. A dozen different courts could interpret it differently. Until there is well-established case law, we just don't know. So instead the question becomes, at what point does it stop making sense to split hairs? Or, how much legal protection can we reasonably afford to get? It might be more than adequate to simply require contrib authors to "sign" something that says they are aware of the GPL restrictions and that they hold Drupal/Dries harmless. Even though such clauses often don't hold up by themselves, it might be enough evidence to demonstrate that Drupal was making best efforts to comply at all times with the law, and thus keep us out of serious trouble.
On 07.09-00:28, Thomas Barregren wrote: [ ... ]
Assume you write a module for Drupal. Any meaningful module to Drupal implements at least one hook. That alone makes the module a derived work of Drupal.
this is wrong. it is an over zealous attempt to extend the legal coverage of copyright and licensing laws. you may interface to software as you like, what you cannot do is copy and modify and distribute that software as your own. i believe this would be defeated in court as were proprietry software vendors when attempting the same trick. i would also assert it is also an infrigement on the freedoms of free software and a direct contradiction of what free software is about. i would re-state what an earlier poster said which is, it would be better to put together a list of copyright holders and correct current licensing discrepancies. then tackle how you wish to address this issue internally. only then should you start propounding this sort of dictum.
Quoting ttw+drupal@cobbled.net:
On 07.09-00:28, Thomas Barregren wrote: [ ... ]
Assume you write a module for Drupal. Any meaningful module to Drupal implements at least one hook. That alone makes the module a derived work of Drupal.
this is wrong. it is an over zealous attempt to extend the legal coverage of copyright and licensing laws. you may interface to software as you like, what you cannot do is copy and modify and distribute that software as your own.
I don't see how Thomas is wrong. What he says is the heart of the GPL. --8<--
i would re-state what an earlier poster said which is, it would be better to put together a list of copyright holders and correct current licensing discrepancies. then tackle how you wish to address this issue internally. only then should you start propounding this sort of dictum.
While a preamble is indeed a good idea the lack thereof doesn't harm the copyright or the license with which the package is distributed. The copyright is owned by the producer of the code and the license allows the copyright holder to give you the right to use it. It can also be contrived that since I freely gave the code that is covered by my copyright to Drupal that I also transferred the copyright to Drupal. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Fri, 07 Sep 2007 15:34:39 -0400, Earnie Boyd <earnie@users.sourceforge.net> wrote:
While a preamble is indeed a good idea the lack thereof doesn't harm the copyright or the license with which the package is distributed. The copyright is owned by the producer of the code and the license allows the copyright holder to give you the right to use it. It can also be contrived that since I freely gave the code that is covered by my copyright to Drupal that I also transferred the copyright to Drupal.
Not true, unless you explicitly signed a document stating that you transfered copyright ownership to Dries Buytaert. Unless I missed it, there is no such automatic transfer involved in committing to CVS. (Some projects do have that, but not Drupal.) The "GPL means someone else owns my code now" line is a lie. Period. They can *use* your code, and can even redistribute it however they want as long as they do so under the GPL, but ownership remains with you until you legally turn it over to someone else. (This email, by the way, is copyright 2007 Larry Garfield. Forwarding it, including quoting it in a reply, counts as redistribution and is illegal under modern US copyright law without license. License to redistribute this email and its contents are hereby granted to all readers under the GNU GPL. That does not in any way shape or form diminish the copyright claim of Larry Garfield upon the work herein. Welcome to modern copyright law.) --Larry Garfield
On 9/7/07, Larry Garfield <larry@garfieldtech.com> wrote:
(This email, by the way, is copyright 2007 Larry Garfield. Forwarding it, including quoting it in a reply, counts as redistribution and is illegal under modern US copyright law without license. License to redistribute this email and its contents are hereby granted to all readers under the GNU GPL. That does not in any way shape or form diminish the copyright claim of Larry Garfield upon the work herein. Welcome to modern copyright law.)
--Larry Garfield
Email disclaimers, their validity and enforcement of, is a separate subject with an entirely different set of criteria and morass that is outside the scope of this discussion with it's own set of case law and associated technologies. Let's not complicate this already diverse thread with yet another indirect example that merely muddies the water further. Steven Peck Enterprise Email Admin
On Sep 7, 2007, at 2:32 PM, Larry Garfield wrote:
(This email, by the way, is copyright 2007 Larry Garfield. Forwarding it, including quoting it in a reply, counts as redistribution and is illegal under modern US copyright law without license. License to redistribute this email and its contents are hereby granted to all readers under the GNU GPL. That does not in any way shape or form diminish the copyright claim of Larry Garfield upon the work herein. Welcome to modern copyright law.)
But what about all the servers that are passing this email along through the net? What about all the people using Yahoo and GMail -- is reading a GPL-licensed email on a proprietary system a violation? Shall GPL emails be distributed and read only on GPL systems? Okay, that's being silly. However, I do not intend to muddy the waters. I'm wondering if we can agree on the questions at hand.... Where the line is drawn that makes something a derivative of Drupal (or whatever GPL-licensed system) seems to be the issue that will be at the crux of any legal challenge down the line, and sorry, I don't believe there is any cut-and-dried interpretation, except in the minds of advocates, and lawyers with vested interests. Sorting out these kinds of issues is what courts are for. So isn't the issue, then, what D.o should do about modules that claim to be GPL but possibly may not legitimately be so? If the module creator says the module is licensed as GPL, is that not enough? Or is it D.o's job to research all possible ways the module might touch a non-GPL system and, thereby, enforce what seems to be one not-quite- universal interpretation of GPL? Laura
Quoting Laura Scott <laura@pingv.com>:
So isn't the issue, then, what D.o should do about modules that claim to be GPL but possibly may not legitimately be so? If the module creator says the module is licensed as GPL, is that not enough? Or is it D.o's job to research all possible ways the module might touch a non-GPL system and, thereby, enforce what seems to be one not-quite- universal interpretation of GPL?
At the end of the day it will all come down to who has the biggest wallet that will win. There will only be an issue if some copyright holder gets upset and decides to sue. The question we need to ask is are we protected enough by the license we use to continue using it and do the modules that people contribute cause an issue that might harm Drupal as a community. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Quoting Larry Garfield <larry@garfieldtech.com>:
On Fri, 07 Sep 2007 15:34:39 -0400, Earnie Boyd <earnie@users.sourceforge.net> wrote:
While a preamble is indeed a good idea the lack thereof doesn't harm the copyright or the license with which the package is distributed. The copyright is owned by the producer of the code and the license allows the copyright holder to give you the right to use it. It can also be contrived that since I freely gave the code that is covered by my copyright to Drupal that I also transferred the copyright to Drupal.
Not true, unless you explicitly signed a document stating that you transfered copyright ownership to Dries Buytaert. Unless I missed it, there is no such automatic transfer involved in committing to CVS. (Some projects do have that, but not Drupal.)
The "GPL means someone else owns my code now" line is a lie. Period. They can *use* your code, and can even redistribute it however they want as long as they do so under the GPL, but ownership remains with you until you legally turn it over to someone else.
I said that it can be contrived to mean; meaning that some court *could* (not would) give Drupal that right. Copyright law changes with each courts interpretation. FSF forces the issue and makes you and everyone else that owns you sign a document for you to contribute code that is distributed by the FSF just to make it clear that FSF owns the copyright. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
So - a question regarding only the Drupal core - if the license was to be changed, would those who'd need to agree only be the core committers? Technically, only they have added any new code to Drupal core. For example the only change I might suggest is to change the license to GPL 2.0 or later, or to add a FOSS exception. I think one or both of these needs to be considered otherwise it seems that we are in trouble regarding Drupal integration with CiviCRM and other FOSS packages that are GPL 3.0 or GPL 3.0 compatible. -Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Wolanin schrieb:
So - a question regarding only the Drupal core - if the license was to be changed, would those who'd need to agree only be the core committers? Technically, only they have added any new code to Drupal core.
We may have added it, but that doesn't give us copyright on the code or make us the author.
For example the only change I might suggest is to change the license to GPL 2.0 or later, or to add a FOSS exception. I think one or both of these needs to be considered otherwise it seems that we are in trouble regarding Drupal integration with CiviCRM and other FOSS packages that are GPL 3.0 or GPL 3.0 compatible.
We may be, yes. But in order to change the license to anything else you'd have to find and get approval of all copyright holders/authors. Compiling the list of all these people will be fun. Some people's changes might have been removed by other people's changes. Some people's patches might be so small that they probably would not enjoy copyright protection, etc... It is probably simpler to ask who is opposed to any particular change, then you can stop asking after a small number of people. :p Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG4fYDfg6TFvELooQRAuqFAKCst6NuSEJgG3HBaMqGXSdS8n8NAACgjcle J8t4Jp+vBwwlkO4badov/8g= =Dq4L -----END PGP SIGNATURE-----
On 07.09-15:32, Larry Garfield wrote: [ ... ]
(This email, by the way, is copyright 2007 Larry Garfield. Forwarding it, including quoting it in a reply, counts as redistribution and is illegal under modern US copyright law without license. License to redistribute this email and its contents are hereby granted to all readers under the GNU GPL. That does not in any way shape or form diminish the copyright claim of Larry Garfield upon the work herein. Welcome to modern copyright law.)
:-D appreciate the humor but, actually, it's a good example. you can't do that. under copyright i may use your material, reply to it and comment on it even use it in satire or parody and there's not a thing you can do about it .. well you can sue me but you'd lose (i hope, or i just got myself in a world of #@$% ;-)
On 07.09-15:34, Earnie Boyd wrote: [ ... ]
Assume you write a module for Drupal. Any meaningful module to Drupal implements at least one hook. That alone makes the module a derived work of Drupal.
this is wrong. it is an over zealous attempt to extend the legal coverage of copyright and licensing laws. you may interface to software as you like, what you cannot do is copy and modify and distribute that software as your own.
I don't see how Thomas is wrong. What he says is the heart of the GPL.
because the GPL is a copyright license and this statement is in direct conflict with copyright law and, as such, is a zealous attempt to extend the coverage of copyright. for example, if your write a book and i quote your work (for any wide range of reasons) you cannot sue me under copyright. this is the comparitive legal situation. i would much rather assert a notion of freedom than discuss legal aspects of law. what is relevant on this list is what this community choses to enforce - let the legal aspects sort themselves out after that.
ttw+drupal@cobbled.net skrev:
On 07.09-15:34, Earnie Boyd wrote: [ ... ]
Assume you write a module for Drupal. Any meaningful module to Drupal implements at least one hook. That alone makes the module a derived work of Drupal.
this is wrong. it is an over zealous attempt to extend the legal coverage of copyright and licensing laws. you may interface to software as you like, what you cannot do is copy and modify and distribute that software as your own.
I don't see how Thomas is wrong. What he says is the heart of the GPL.
because the GPL is a copyright license and this statement is in direct conflict with copyright law and, as such, is a zealous attempt to extend the coverage of copyright. for example, if your write a book and i quote your work (for any wide range of reasons) you cannot sue me under copyright.
Quoting a book falls under the notion of Fair Use. Creating a derivative work doesn't. Read more at http://en.wikipedia.org/wiki/Fair_use. Thomas
On 10.09-00:25, Thomas Barregren wrote: [ ... ]
Quoting a book falls under the notion of Fair Use. Creating a derivative work doesn't.
correct. but only relevant because you define calling a defined interface a derivative work. you only call it this because it suits your political ends. _again_, for the cheap seats, this is pointless. what is relevant is the actions being taken to resolving the current licensing issues so that the community may make decisions to go forward.
ttw+drupal@cobbled.net skrev:
On 10.09-00:25, Thomas Barregren wrote: [ ... ]
Quoting a book falls under the notion of Fair Use. Creating a derivative work doesn't.
correct. but only relevant because you define calling a defined interface a derivative work. you only call it this because it suits your political ends.
Stupidity. I haven't define the term "derivative work" to suite my "political ends". It is a legal term used in the copyright laws around the world. Thomas
On 10.09-17:01, Thomas Barregren wrote: [ ... ]
correct. but only relevant because you define calling a defined interface a derivative work. you only call it this because it suits your political ends.
Stupidity. I haven't define the term "derivative work" to suite my "political ends". It is a legal term used in the copyright laws around the world.
you may not intimidate me with abuse. the term "derivative work" is not clearly defined within law and is thus open to interpretation. your interpretation is clearly one that suits your political ends and, in my opinion, is not only morally wrong but one that is legally untenable under US and European law.
ttw+drupal@cobbled.net wrote:
...the term "derivative work" is not clearly defined within law and is thus open to interpretation. your interpretation is clearly one that suits your political ends and, in my opinion, is not only morally wrong but one that is legally untenable under US and European law.
As for European law I don't know but Wikipedia claims there's such a definition what US law is concerned: http://en.wikipedia.org/wiki/Derivative_work ..."derivative work" is defined in 17 U.S.C. <http://en.wikipedia.org/wiki/Title_17_of_the_United_States_Code> § 101 <http://www.law.cornell.edu/uscode/17/101.html>: A "derivative work" is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a "derivative work". There are futher legal references in the same article. Also considering the number of references to "derivative work" in software licenses and contracts, I very much doubt the term is undefined in common legal practice. The Wikipedia article agrees with you on one point and that is regarding software: "The definition of derivative works of software is not entirely clear[5] <http://community.linux.com/article.pl?sid=02/11/13/117247&tid=87&tid=41&tid=12&tid=42>" [1] However this article is just one of many sources and I'd rather rely on a legal dictionary than Wikipedia to bring some real clarity. Further, the "rule of thumb" definition re softwate in the Wikipedia article [1] seems to support Thomas point of view since it only allows exception of the "derivative work" rule for applications that serve as plugins and use functions in a library. Since Drupal is not a library and a module is not a plugin the logical outcome is given; a module must be considered "derivative work" and is therefore subject to GPL. You'd have to challenge those two premises to criticize the conclusion Thomas has drawn. Further discussion can be found here: http://www.rosenlaw.com/lj19.htm I think the mud-slinging is regrettable and sad. Please stick to the point and quote sources instead of being inflammatory. We don't need a flamewar. I've never seen a flamewar leading to anything good. Since the whole discussion apparently boils down to this definition and the challenging of it, and there's no sign of agreement in sight, we'll need an arbitrator and Lawrence Rosen seems to be a candidate. [1] http://en.wikipedia.org/wiki/Derivative_work#Derivative_work_of_software
On Mon, 10 Sep 2007 18:19:16 +0200, Jakob Persson <jakob@jakob-persson.com> wrote:
Further, the "rule of thumb" definition re softwate in the Wikipedia article [1] seems to support Thomas point of view since it only allows exception of the "derivative work" rule for applications that serve as plugins and use functions in a library. Since Drupal is not a library and a module is not a plugin the logical outcome is given; a module must be considered "derivative work" and is therefore subject to GPL. You'd have to challenge those two premises to criticize the conclusion Thomas has drawn.
How exactly is a Drupal module not a plugin? (Not a troll, a genuine question.) I don't know of a legal definition of plugin, but from a technical standpoint they fit my understanding of what a plugin is, despite the name. In the generic sense "module" would mean "somewhat discrete component of a system", while "plugin" would mean "swappable and optional component of a system". (Again, not legal definitions.) --Larry Garfield
Larry Garfield wrote:
How exactly is a Drupal module not a plugin? (Not a troll, a genuine question.) I don't know of a legal definition of plugin, but from a technical standpoint they fit my understanding of what a plugin is, despite the name. In the generic sense "module" would mean "somewhat discrete component of a system", while "plugin" would mean "swappable and optional component of a system". (Again, not legal definitions.)
--Larry Garfield
Refering to the references I mentioned in my previous email the conclusion I draw is that a Drupal module that utlizes hooks cannot be considered a plugin since Drupal does not provide a defined interface. By defined interface I mean a discrete set of public routines that can be called by an application the same way Drupal uses GD to manipulate bitmap data. A Drupal module uses and can use not only hooks but a wide range of internal functions to Drupal (as well as of other modules) since it has not access to a limited scope but to all the internals of Drupal. The question here is not what a module does but what it is allowed to do. Since Drupal fails to provide a defined interface a Drupal module cannot be considered a plugin. Which may also be of relevance is that that a module is perceptually and behaviorally (from the user's POV) a part of Drupal. Therefore a module *is* derivative work. The same argument applies to a module that interfaces with third party non-GPL-compatible software in the same fashion (a so called bridge). Now this is old news. Jeff started this discussion quoting the FSF's experts reaching the same conclusion as I have. What we need to focus on is the issues that were raised - that is how do we allow Drupal modules to interface with software available under non-GPL-compatible licenses without violating the GPL. So far many good ideas have been posted and there are others with much more knowledge than I have who I know for certain can provide a viable strategy to bring every contributor's code safely back into the GPL fold.
On 10.09-20:26, Jakob Persson wrote: [ ... ]
Therefore a module *is* derivative work. [ ... ] So far many good ideas have been posted and there are others with much more knowledge than I have who I know for certain can provide a viable strategy to bring every contributor's code safely back into the GPL fold.
the continual propounding of this opinion is not beneficial to closing this thread and letting people move forward with development. this can only be asserted by a court of law in a specific duristiction. until the stated objective of the Drupal community is sanctioned by the listed copyright holders (i.e. they agree to sue non-complying parties), and correct ammendments are made to any incorrect files, and non-complying modules are removed from the distribution; the minority should refrain from pressing others with this dictum. n.b: i would still encourage all developers to release free code whenever possible and personally believe the GPL is a good license as it protects your code from 'consumption' by commercial entities
On 10.09-18:19, Jakob Persson wrote: [ ... ]
As for European law I don't know but Wikipedia claims there's such a definition what US law is concerned: http://en.wikipedia.org/wiki/Derivative_work [ ... ] There are futher legal references in the same article. Also considering the number of references to "derivative work" in software licenses and contracts, I very much doubt the term is undefined in common legal practice.
you have to be kidding. the bickering over semantics is ridiculous. this is "definition" does not effect the fact that this is open to interpretation in each specific case; which was the point being made. the quotation, quite clearly, does not clarify whether using hooks would be defined as a "derivative work" - which is the case in point. are you contesting this based upon your reference and suggesting that it is clearly defined? i apologise for repeating myself again and again but it makes no difference what we think the law says. what is immediately relevant is the currently licensing issues and the communities stance around these issues. [ ... ]
Since the whole discussion apparently boils down to this definition and the challenging of it, and there's no sign of agreement in sight, we'll need an arbitrator and Lawrence Rosen seems to be a candidate.
i disagree, as per our peers comments, it requires the collection of copyright holders and the tidying of current licensing. then, i suggest, it requires a debate on this specific subject (i.e. how shall we let module writers use our software), a vote, a resolution between the copyright holders and _only then_ does it requires a discussion on the legal enforcement of those issues. (if the community decides to exclude other incompatible licenses from using hooks then i expect you will be prove correct, it will boil down to that issue and we will need legal council to close that loophole)
On 07.09-15:34, Earnie Boyd wrote: [ ... ]
The copyright is owned by the producer of the code and the license allows the copyright holder to give you the right to use it. [ ... ]
giving someone freedoms to use your code does not allow you to dictate basic freedoms to them .. i.e. you cannot restrict the basic rights given to them in copyright law just because you are giving them more access than copyright law dictates.
ttw+drupal@cobbled.net skrev:
On 07.09-15:34, Earnie Boyd wrote: [ ... ]
The copyright is owned by the producer of the code and the license allows the copyright holder to give you the right to use it. [ ... ]
giving someone freedoms to use your code does not allow you to dictate basic freedoms to them .. i.e. you cannot restrict the basic rights given to them in copyright law just because you are giving them more access than copyright law dictates.
It seems to me that you don't know what you are talking about. Or worse, that you are trying to spread FUD. In any case, let me quote from the 13 pages short publication "The Open Source Legal Landscape" by the Australian lawyer Brendan Scott: 1.3 Copyright operates by prohibiting numerous categories of action in respect of a copyright work. [...] In the absence of a permission from the copyright holder, there is an absolute prohibition on exercising any of the rights comprised in copyright in respect of that work. 2.3 [...] Open source licences effectively exempt the permitted activities from copyright infringement, subject to compliance with certain conditions (which are different depending upon the licence). A failure to comply with the conditions in the licence will mean that the activities are no longer exempted from infringement of copyright. If the activity in question results in an infringement of copyright, then the copyright owner will have an action against the person engaging in the activity. You can download the full paper here: http://opensourcelaw.biz/publications/papers/BScott_OSS_Legal_Landscape_0603... Thomas
ttw+drupal@cobbled.net skrev:
On 07.09-00:28, Thomas Barregren wrote: [ ... ]
Assume you write a module for Drupal. Any meaningful module to Drupal implements at least one hook. That alone makes the module a derived work of Drupal.
this is wrong. it is an over zealous attempt to extend the legal coverage of copyright and licensing laws. you may interface to software as you like, what you cannot do is copy and modify and distribute that software as your own.
No, you are wrong. If your code link to another code and call functions and share data structures with that other code, your code becomes a derived work of the other code. It is however true that you don't have to worry about that if the other code is licensed to you under an open source license and as long as you don't distribute your code. But i f you distribute your code, even if it is without the other code, you must take the fact that your code is derived from the other code into consideration. If the other code is under BSD, MIT or similar license, it's easy: apply whichever license you like (almost). But if the other code is under GPL, you must use GPL yourself.
i believe this would be defeated in court as were proprietry software vendors when attempting the same trick. i would also assert it is also an infrigement on the freedoms of free software and a direct contradiction of what free software is about.
How can GPL infringe on the freedoms of free software? GPL was after all developed by RMS and other to protect the freedom.
i would re-state what an earlier poster said which is, it would be better to put together a list of copyright holders and correct current licensing discrepancies.
I agree that compiling a list of contributors, similar to the Linux kernel, would be a very good thing to do (if feasible).
then tackle how you wish to address this issue internally. only then should you start propounding this sort of dictum.
I have not propound any sort of dictum. I have only tried to shed light on something which great many people seems to be difficult. Thomas
On Sep 8, 2007, at 9:11 AM, Thomas Barregren wrote:
ttw+drupal@cobbled.net skrev:
On 07.09-00:28, Thomas Barregren wrote: [ ... ]
Assume you write a module for Drupal. Any meaningful module to Drupal implements at least one hook. That alone makes the module a derived work of Drupal.
this is wrong. it is an over zealous attempt to extend the legal coverage of copyright and licensing laws. you may interface to software as you like, what you cannot do is copy and modify and distribute that software as your own.
No, you are wrong.
If your code link to another code and call functions and share data structures with that other code, your code becomes a derived work of the other code.
You keep insisting this, but I don't agree its that cut and dry. Current literature on the subject suggests otherwise when calling code that is "designed as a library". Regardless as to whether it is statically linked or otherwise. Creating a derivative work is not a technical definition, it's a legal one. Most of the reading I've done outside of the GPL FAQ agrees with this. Drupal's strength IMHO relies on its community, and defining the risks we're willing to take in terms of technical semantics feels like a step in the wrong direction. I agree, that the SMF bridge case takes it too far. Distributing non-gpl code using the drupal infrastructure would be a step backward for us also. I think we should continue to feel free to distribute code that says it's GPL, no matter what, but not try and second guess lawyers on what is considered a derived work or not. If the drupal foundation decides that it want's to go after people who might bundle and distribute drupal core with other non-gpl code, I'd probably be supportive of that. I would not be supportive of the foundation going after contributers who develop modules to integrate drupal with proprietary systems and release those modules as GPL, whether we think they're wrong or not. And with that, I think I'm done with this thread.....
David Metzler skrev:
f your code link to another code and call functions and share data structures with that other code, your code becomes a derived work of the other code.
You keep insisting this, but I don't agree its that cut and dry.
I believe that legal issues never are cut and dry. GPL is no exception. It is always possible to construct circumventions to the intent of GPL. Tivoization is a good example.
Current literature on the subject suggests otherwise when calling code that is "designed as a library". Regardless as to whether it is statically linked or otherwise. Creating a derivative work is not a technical definition, it's a legal one. Most of the reading I've done outside of the GPL FAQ agrees with this.
I agree that code that links to a library, which were *designed* and *intended* to be used as a library, not necessarily makes the code a derived work of the library, but just a collective work. But as I understand it, that is not the subject matter. We are talking about modules that bridge Drupal with third-party software. Let me elaborate on my arguments: Drupal is not *designed* nor *intended* as a library. It is an application. A module, which links to Drupal, calls functions in Drupal and shares data structures with Drupal, can therefore not be said to merely using Drupal. In fact, the very purpose of the module is to modify how Drupal works. Therefore, Drupal and the module, as a whole, is a derived work of Drupal. And as a such, it must be under GPL. Now, suppose we develop a module that bridges Drupal with another application. The very need of a bridging module implies that the application is not *designed* nor *intended* as a library. As a bridge, the module must obviously link to the application, call functions in the application and share data structures with the application. In fact, the very purpose of the module is to be a proxy for the application. Therefore, the application and the module, as a whole, is a derived work of the application. And as a such, it must be under a license compatible with the license for the application. Thus, the module can only be licensed if and only if the license of the application is compatible with GPL. Q.E.D. :-)
Drupal's strength IMHO relies on its community, and defining the risks we're willing to take in terms of technical semantics feels like a step in the wrong direction. I agree, that the SMF bridge case takes it too far. Distributing non-gpl code using the drupal infrastructure would be a step backward for us also. I think we should continue to feel free to distribute code that says it's GPL, no matter what, but not try and second guess lawyers on what is considered a derived work or not.
I think your position is naive. Every time someone is downloading a contrib module, Drupal.org is distributing that module. By copyright laws, that is absolutely prohibited without permission. The GPL gives that permission. Now, suppose the module violates the GPL. A failure to comply with the conditions in the GPL will mean that downloading is no longer exempted from infringement of copyright. Ouch! Therefore it should be important for Drupal.org to make whatever is reasonable to control that the modules they distribute really do comply with GPL. Lack of such control can be utilized by unscrupulous. For an example, suppose a closed source company in the CRM business wants to put and end to its worst competitor: Drupal. They engage a decoy who check in a module bridging Drupal with their own closed source licensed CRM. Next, they sue Dries, in his capacity of owner of the drupal.org domain, for copyright infringement... Okay, it is not likely to happen (I hope), but it is an illustration why copyright and licensing should not be taken easily. Best regards, Thomas
On Sep 6, 2007, at 4:28 PM, Thomas Barregren wrote:
Assume you write a module for Drupal. Any meaningful module to Drupal implements at least one hook. That alone makes the module a derived work of Drupal.
I wonder whether that in fact is true. By this logic, if you write an application that interfaces with Word, then Microsoft owns it as a derivative of their product. Is that how copyright works? Every time two different applications touch, we have litigation as to who has the most cooties? If someone pulls on a door handle, does he become a derivative of the door? Some things are designed to be utilized by other systems. APIs exist in large part to allow different systems to interface with each other. To claim that not only must a bridge module (to use the example we've been tossing about) be GPL but anything it touches must be GPL as well seems to be a rather far-reaching legal claim ... or tragically self-isolating interpretation for policy. Can GPL exist only in isolation from all other systems? Does mere communication or interaction imply derivation? That's what the RIAA and MPAA claim in their dragnet lawsuits, pre-litigation settlement demands and things like the Sony Rootkit. What next? A GPL rootkit? I wonder how Lawrence Lessig would interpret GPL. Laura
On Fri, 7 Sep 2007 09:14:52 -0600, Laura Scott <laura@pingv.com> wrote:
On Sep 6, 2007, at 4:28 PM, Thomas Barregren wrote:
Assume you write a module for Drupal. Any meaningful module to Drupal implements at least one hook. That alone makes the module a derived work of Drupal.
I wonder whether that in fact is true. By this logic, if you write an application that interfaces with Word, then Microsoft owns it as a derivative of their product. Is that how copyright works? Every time two different applications touch, we have litigation as to who has the most cooties?
No, only if Word's license explicitly said that they own any Macros you write. AFAIK it doesn't (although I've not actually purchased a copy of Word since last century). If Word were GPLed, they still wouldn't own your macros. There is no transfer of ownership in the GPL. There is only a requirement of GPL re-licensing for derivative works, e.g., Word plus your Macros wrapped up together.
If someone pulls on a door handle, does he become a derivative of the door? Some things are designed to be utilized by other systems. APIs exist in large part to allow different systems to interface with each other. To claim that not only must a bridge module (to use the example we've been tossing about) be GPL but anything it touches must be GPL as well seems to be a rather far-reaching legal claim ... or tragically self-isolating interpretation for policy.
Can GPL exist only in isolation from all other systems? Does mere communication or interaction imply derivation? That's what the RIAA and MPAA claim in their dragnet lawsuits, pre-litigation settlement demands and things like the Sony Rootkit. What next? A GPL rootkit?
I wonder how Lawrence Lessig would interpret GPL.
Laura
The amount of FUD in this thread is starting to amaze me. (Not you specifically, Laura; in general.) I think some people here are reading from the Microsoft anti-GPL playbook with the "transfer of ownership" nonsense. Folks, the GPL is not as evil ("viral") as some here are making it out to be. It says, simply, "you can do anything you want with this code, but *if* you redistribute it, *even if it's part of a derivative work*, then it, and as a result the derivative work, must be distributed under the GPL." That is all. There is no transfer of ownership, no "viral infection", no "loss of property" (since copyright is not property to start with, but we won't get into that.) The only question at hand is exactly where the line for "derivative work" is, in particular for modules that interface with 3rd party systems. The only relevant questions here are: 1) If a Drupal module exists only to interface between Drupal and a non-GPL system using in-process PHP function calls, does that violate the GPL? (FSF, according to Jeff, believes it does. I say to ask a lawyer not in the FSF's employ in order to get a more unbiased answer.) 2) If a Drupal module exists only to interface between Drupal and a non-GPL system using non-in-process APIs (SOAP, RSS, REST, reading a CSV, exec/fork, etc.), does that violate the GPL? (FSF, according to Jeff, says "not in letter, but in spirit". Given the number of RSS feeds coming off of non-Free systems that we all read on a regular basis using Aggregator, I don't think many people agree with the "spiritual violation". For the letter, again, we should ask a lawyer.) Bottom line: Unless you are a lawyer or have recently spoken to one on this subject, you have nothing constructive to contribute to this thread any more. Yes, I include myself in that statement as I am not a lawyer. Can we move the GPL FUD to some other forum and get back to something useful, like getting Drupal 6 finished? --Larry Garfield
I think the core question in this still is, "What constitutes a derivative work", which if my research is correct, cannot be answered as a technical question. I actually just started with searching for wikipedia on the GPL and looked from there. Here are a couple of interesting things I found. Linus Torvald on the subject: from - http://lkml.org/lkml/2006/12/17/79 For example, glibc could easily have just come out and said the thing that is obvious to any sane person: "using this library as just a standard library does not make your program a derived work". ... and later in the same post.... And don't get me wrong: I do not say that "linking" _never_ creates derived works. I'm just saying that "linking" is just a technical step, and as such is not the answer to whether something is derived or not. Things can be derived works of each other _without_ being linked, and they may not be derived works even if they _are_ linked. And some other stuff from a Lawrence Rosen, a lawyer for OSPI: http://www.linuxjournal.com/article/6366 These questions are important because some licenses require you to publish the source code of your portion of the resulting derivative work program, a burden you may not want to accept. Here's how I would decide in the cases described above. 1) The primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work. 2) The meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs. When a company releases a scientific subroutine library, or a library of objects, for example, people who merely use the library, unmodified, perhaps without even looking at the source code, are not thereby creating derivative works of the library. 3) Derivative works are not going to encompass plugins and device drivers that are designed to be linked from off-the-shelf, unmodified, programs. If a GPL-covered program is designed to accept separately designed plugin programs, you don't create a derivative work by merely running such a plugin under it, even if you have to look at the source code to learn how. 4) In most cases we shouldn't care how the linkage between separate programs was technically done, unless that fact helps determine whether the creators of the programs designed them with some apparent common understanding of what a derivative work would look like. We should consider subtle market-based factors as indicators of intent, such as whether the resulting program is being sold as an ``enhanced'' version of the original, or whether the original was designed and advertised to be improvable ``like a library''. Anyway, I thought this might help us get past the technicalities of what "linking" means. Dave On Sep 7, 2007, at 8:33 AM, Larry Garfield wrote:
On Fri, 7 Sep 2007 09:14:52 -0600, Laura Scott <laura@pingv.com> wrote:
On Sep 6, 2007, at 4:28 PM, Thomas Barregren wrote:
Assume you write a module for Drupal. Any meaningful module to Drupal implements at least one hook. That alone makes the module a derived work of Drupal.
I wonder whether that in fact is true. By this logic, if you write an application that interfaces with Word, then Microsoft owns it as a derivative of their product. Is that how copyright works? Every time two different applications touch, we have litigation as to who has the most cooties?
No, only if Word's license explicitly said that they own any Macros you write. AFAIK it doesn't (although I've not actually purchased a copy of Word since last century).
If Word were GPLed, they still wouldn't own your macros. There is no transfer of ownership in the GPL. There is only a requirement of GPL re-licensing for derivative works, e.g., Word plus your Macros wrapped up together.
If someone pulls on a door handle, does he become a derivative of the door? Some things are designed to be utilized by other systems. APIs exist in large part to allow different systems to interface with each other. To claim that not only must a bridge module (to use the example we've been tossing about) be GPL but anything it touches must be GPL as well seems to be a rather far-reaching legal claim ... or tragically self-isolating interpretation for policy.
Can GPL exist only in isolation from all other systems? Does mere communication or interaction imply derivation? That's what the RIAA and MPAA claim in their dragnet lawsuits, pre-litigation settlement demands and things like the Sony Rootkit. What next? A GPL rootkit?
I wonder how Lawrence Lessig would interpret GPL.
Laura
The amount of FUD in this thread is starting to amaze me. (Not you specifically, Laura; in general.) I think some people here are reading from the Microsoft anti-GPL playbook with the "transfer of ownership" nonsense.
Folks, the GPL is not as evil ("viral") as some here are making it out to be. It says, simply, "you can do anything you want with this code, but *if* you redistribute it, *even if it's part of a derivative work*, then it, and as a result the derivative work, must be distributed under the GPL." That is all. There is no transfer of ownership, no "viral infection", no "loss of property" (since copyright is not property to start with, but we won't get into that.)
The only question at hand is exactly where the line for "derivative work" is, in particular for modules that interface with 3rd party systems. The only relevant questions here are:
1) If a Drupal module exists only to interface between Drupal and a non-GPL system using in-process PHP function calls, does that violate the GPL? (FSF, according to Jeff, believes it does. I say to ask a lawyer not in the FSF's employ in order to get a more unbiased answer.)
2) If a Drupal module exists only to interface between Drupal and a non-GPL system using non-in-process APIs (SOAP, RSS, REST, reading a CSV, exec/fork, etc.), does that violate the GPL? (FSF, according to Jeff, says "not in letter, but in spirit". Given the number of RSS feeds coming off of non-Free systems that we all read on a regular basis using Aggregator, I don't think many people agree with the "spiritual violation". For the letter, again, we should ask a lawyer.)
Bottom line: Unless you are a lawyer or have recently spoken to one on this subject, you have nothing constructive to contribute to this thread any more. Yes, I include myself in that statement as I am not a lawyer. Can we move the GPL FUD to some other forum and get back to something useful, like getting Drupal 6 finished?
--Larry Garfield
Further simplification of the claims being made now appears possible. There are two: 1. You cannot use a GPL-incompatible license for an app if it calls functions in Drupal or in a Drupal contributed module. This claim is not disputed. 2. You cannot use the GPL for code that calls functions in a third- party app if you cannot distribute your code and the third-party app together as a single work using the GPL. This claim is disputed. On Sep 7, 2007, at 6:28 AM, Thomas Barregren wrote:
Since you already have accepted to distribute your module under GPL and nothing by GPL, the license of the other program must allow its derivative works to be licensed under GPL. A license which allows that is said to be compatible with GPL. Examples of compatible licenses include the revised BSD and the MIT licenses. If the other program's license is not compatible with GPL, then you cannot distribute your module. It is as simple as that.
Here's the FAQ, by the Software Freedom Law Center, on why you can distribute CiviCRM (AGPL licensed, incompatible with GPL v2) as part of a GPL-licensed piece of software (e.g. drupal+civicrm distribution like civicspace was): http://civicrm.org/node/166 --mark On 9/9/07, Darren Oh <darrenoh@sidepotsinternational.com> wrote:
Further simplification of the claims being made now appears possible. There are two:
1. You cannot use a GPL-incompatible license for an app if it calls functions in Drupal or in a Drupal contributed module. This claim is not disputed.
2. You cannot use the GPL for code that calls functions in a third- party app if you cannot distribute your code and the third-party app together as a single work using the GPL. This claim is disputed.
On Sep 7, 2007, at 6:28 AM, Thomas Barregren wrote:
Since you already have accepted to distribute your module under GPL and nothing by GPL, the license of the other program must allow its derivative works to be licensed under GPL. A license which allows that is said to be compatible with GPL. Examples of compatible licenses include the revised BSD and the MIT licenses. If the other program's license is not compatible with GPL, then you cannot distribute your module. It is as simple as that.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 mark burdett schrieb:
Here's the FAQ, by the Software Freedom Law Center, on why you can distribute CiviCRM (AGPL licensed, incompatible with GPL v2) as part of a GPL-licensed piece of software (e.g. drupal+civicrm distribution like civicspace was): http://civicrm.org/node/166
Quote:
Can I distribute CiviCRM as part of a GPL-licensed piece of software? How does that work?
Yes, so long as CiviCRM is a separate and independent program from the GPL-licensed software. You cannot combine code licensed under both licenses into a single program and then redistribute that combination because the AGPL and the current version of the GPL are incompatible.
The problem is that it is disputed that CiviCRM would be an independent programm when using civicrm.module to hook into Drupal. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG5DcEfg6TFvELooQRAv7TAJ92fF3WCA/5YqF25957ittIkqbkngCgpN5D xU/RBTJCrnv2449B22NZvRE= =VsB+ -----END PGP SIGNATURE-----
I don't know what it means if SFLC conflicts with FSF on this issue :) But just wanted to point out SFLC's legal theory that the GPL civicrm module could call the CiviCRM API, even though the civicrm API files themselves are AGPL.. --mark On 9/9/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
mark burdett schrieb:
Here's the FAQ, by the Software Freedom Law Center, on why you can distribute CiviCRM (AGPL licensed, incompatible with GPL v2) as part of a GPL-licensed piece of software (e.g. drupal+civicrm distribution like civicspace was): http://civicrm.org/node/166
Quote:
Can I distribute CiviCRM as part of a GPL-licensed piece of software? How does that work?
Yes, so long as CiviCRM is a separate and independent program from the GPL-licensed software. You cannot combine code licensed under both licenses into a single program and then redistribute that combination because the AGPL and the current version of the GPL are incompatible.
The problem is that it is disputed that CiviCRM would be an independent programm when using civicrm.module to hook into Drupal.
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG5DcEfg6TFvELooQRAv7TAJ92fF3WCA/5YqF25957ittIkqbkngCgpN5D xU/RBTJCrnv2449B22NZvRE= =VsB+ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 mark burdett schrieb:
I don't know what it means if SFLC conflicts with FSF on this issue :) But just wanted to point out SFLC's legal theory that the GPL civicrm module could call the CiviCRM API, even though the civicrm API files themselves are AGPL..
Yeah, I know this theory and I used to think it is correct. Based on this theory I recommended to Donald Lobo that the civicrm module itself be dually licensed, to which he agreed. I am personally not too happy with the "new" situation. However, we need to resolve it. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG5P3Hfg6TFvELooQRAmZSAJ9mOCLud9DxaRxpipNYYs8LVN2gjQCfd2UH yMcSlVv4r0kTwEnldrAgYdU= =7PH1 -----END PGP SIGNATURE-----
mark burdett skrev:
Here's the FAQ, by the Software Freedom Law Center, on why you can distribute CiviCRM (AGPL licensed, incompatible with GPL v2) as part of a GPL-licensed piece of software (e.g. drupal+civicrm distribution like civicspace was): http://civicrm.org/node/166
The CiviCRM's FAQ about AGPL loudly and clearly states: You cannot combine code licensed under both licenses [AGPL and GPL] into a single program and then redistribute that combination because the AGPL and the current version of the GPL are incompatible. Thus, you cannot distribute CiviCRM as *part of* a software licensed under GPL. However, you can distribute CiviCRM as "a separate and independent program from the GPL-licensed software". It is important to make a distinction between "derived work" and "combined work". Derivative works are subject to the GPL’s reciprocity provision (a.k.a. copyleft) while combined works are not. The matter is thoroughly discussed in Lawrence Rosen's book "Open Source Licensing: Software Freedom and Intellectual Property Law" available online from http://www.rosenlaw.com/oslbook.htm. Rosen says in the book that he belief that GPL "will ultimately be read by the courts to mean that derivative works are subject to the GPL’s reciprocity provision, but collective works are not." Best regards, Thomas
In that case, Drupal modules that do not include third-party code are legal, since they merely allow Drupal to be combined with "separate and independent" programs. No work derived from the third-party code is being distributed. I know it's repetitive, but this discussion has been answering the wrong question. On Sep 10, 2007, at 5:40 PM, Thomas Barregren wrote:
The CiviCRM's FAQ about AGPL loudly and clearly states:
You cannot combine code licensed under both licenses [AGPL and GPL] into a single program and then redistribute that combination because the AGPL and the current version of the GPL are incompatible.
Thus, you cannot distribute CiviCRM as *part of* a software licensed under GPL. However, you can distribute CiviCRM as "a separate and independent program from the GPL-licensed software".
It is important to make a distinction between "derived work" and "combined work".
Derivative works are subject to the GPL’s reciprocity provision (a.k.a. copyleft) while combined works are not. The matter is thoroughly discussed in Lawrence Rosen's book "Open Source Licensing: Software Freedom and Intellectual Property Law" available online from
http://www.rosenlaw.com/oslbook.htm.
Rosen says in the book that he belief that GPL "will ultimately be read by the courts to mean that derivative works are subject to the GPL’s reciprocity provision, but collective works are not."
Best regards, Thomas
Darren Oh skrev:
In that case, Drupal modules that do not include third-party code are legal, since they merely allow Drupal to be combined with "separate and independent" programs. No work derived from the third-party code is being distributed.
No, it is not as simple as that. Suppose we develop a module that bridges Drupal with another program. If that is accomplished by just "using" the program, that is invoking the program's main function with some options and waiting for it to return, for instance by using pipes, sockets or command-line, then the module is not a derived work of the application. But, if the module "know" things internal to the program, that is the module links to the program, invokes functions and shares data structures, then the module and the program, as a whole, is a derived work of the program. Since the module and Drupal, as a whole, is a derived work of Drupal, GPL requires that the whole combined program has to be released under the GPL. That is why I think the license of the other program must be compatible with GPL if (but only if) the module "know things" internal to the program.
I know it's repetitive, but this discussion has been answering the wrong question. The really question, as I see it, is whether d.o. should continue to expose itself for the risk of being challenged in court for copyright infringement, or do something about modules that link to third-party programs with licenses not compatible with GPL. I suggest the latter. We can either follow J! and cease the distribution of contaminated modules, or add a FOSS Exception, Linked Under Controlled Interface Exception or something similar, or both.
I think I have said everything I can in this issue. So I should really "rest my case" now. Seeing is believing. :-) Best regards, Thomas (IANAL)
Then are you saying CiviCRM is wrong and that it is a license violation to distribute modules that allow Drupal to be combined with CiviCRM? A clarification of the claims you are making would be helpful. In a previous message I tried to sum them up: 1. You cannot use a GPL-incompatible license for an app designed to be used with Drupal or a Drupal module. 2. You cannot use the GPL for code designed to be used with a third- party app unless a) you are allowed to combine your code with the third-party app and distribute the combined work under the GPL or b) you add an exception clause giving up claim 1. Does this summary fairly represent what you are claiming? If not, please clarify it for the benefit of the rest of us. On Sep 10, 2007, at 9:02 PM, Thomas Barregren wrote:
Darren Oh skrev:
In that case, Drupal modules that do not include third-party code are legal, since they merely allow Drupal to be combined with "separate and independent" programs. No work derived from the third-party code is being distributed.
No, it is not as simple as that.
Suppose we develop a module that bridges Drupal with another program. If that is accomplished by just "using" the program, that is invoking the program's main function with some options and waiting for it to return, for instance by using pipes, sockets or command-line, then the module is not a derived work of the application. But, if the module "know" things internal to the program, that is the module links to the program, invokes functions and shares data structures, then the module and the program, as a whole, is a derived work of the program.
Since the module and Drupal, as a whole, is a derived work of Drupal, GPL requires that the whole combined program has to be released under the GPL. That is why I think the license of the other program must be compatible with GPL if (but only if) the module "know things" internal to the program.
I know it's repetitive, but this discussion has been answering the wrong question. The really question, as I see it, is whether d.o. should continue to expose itself for the risk of being challenged in court for copyright infringement, or do something about modules that link to third-party programs with licenses not compatible with GPL. I suggest the latter. We can either follow J! and cease the distribution of contaminated modules, or add a FOSS Exception, Linked Under Controlled Interface Exception or something similar, or both.
I think I have said everything I can in this issue. So I should really "rest my case" now. Seeing is believing. :-)
Best regards, Thomas (IANAL)
I wrote this quickly and failed to sum fully sum up the two claims being made. Clarification: 1. The first claim concerns third-party code: you cannot use a GPL- incompatible license for an app designed to be used with Drupal or a Drupal module. 2. The second claim concerns the code of Drupal and contributed modules: you cannot use the GPL for code designed to be used with a third-party app unless a) you can distribute your code and the third- party app together under the GPL as a combined work or b) you add an exception clause giving up the first claim. On Sep 9, 2007, at 11:43 PM, Darren Oh wrote:
Further simplification of the claims being made now appears possible. There are two:
1. You cannot use a GPL-incompatible license for an app if it calls functions in Drupal or in a Drupal contributed module. This claim is not disputed.
2. You cannot use the GPL for code that calls functions in a third- party app if you cannot distribute your code and the third-party app together as a single work using the GPL. This claim is disputed.
On 03.09-23:04, Darren Oh wrote: [ ... ]
The viral nature of the GPL means that an app that uses Drupal is automatically licensed under the GPL, whether or not the developer of the app says so. That's exactly what we want, and it's the reason Drupal is distributed under the GPL. [ ... ]
i am unsure who you define as "we" but if it's the reason that Drupal is distributed under the GPL then i would be severly disappointed. personally, i understand the purpose of the GPL (as opposed something like the BSD license) is to ensure that developments are returned to the community and that the code remains free. the "spirit" of the GPL can only be captured by capturing the spirit of freedom. this means accepting that people may use certain aspects of that freedom in a manner contrary to you expectation or wishes.
Karoly Negyesi wrote:
So the question that the list should debate: what are the questions that a lawyer should answer for us? Larry Rosen looks like a good candidate. (Or maybe two lawyers? One in the EU, one in the USA)
One good copyright lawyer in the EU is Jean Baptiste Soufron. He is affiliated with the EFF and is an expert on international copyright law. He regularly provides the Wikimedia Foundation with legal advice.
David Strauss skrev:
Jeff Eaton wrote:
This is very true. It's also important to keep in mind that the FSF gets annoyed when people distribute code that "Is GPL Compliant, Wink Wink Nudge Nudge" but doesn't actually do anything until you put it in the presence of non-GPL code.
So, while the GPL wouldn't prevent someone from whipping up a compatibility module themselves or a one-off module like that for a client, the FSF would consider it a violation of the GPL if that person distributed the resulting module with a see-no-evil "Well, it's just some code I wrote, people might install X and Y together, but how am I to know?" excuse.
To avoid this sort of GPL Hell, we have very specific terms on which we work with clients:
(1) The client owns the work we do specifically for them.
(2) The client licenses .module files and their dependencies back to us under the GPL, version 2, and all future versions as published by the FSF.
The terms of (2) mean their internal staff can contribute to the project, but the final working modules are licensed back to us in a GPL-clean way that allows us to return the work to the community.
The other way around works as well. You can keep the intellectual property rights yourself and license the software under GPL to your customer. Regards, Thomas
Thomas Barregren wrote:
To avoid this sort of GPL Hell, we have very specific terms on which we work with clients:
(1) The client owns the work we do specifically for them.
(2) The client licenses .module files and their dependencies back to us under the GPL, version 2, and all future versions as published by the FSF.
The terms of (2) mean their internal staff can contribute to the project, but the final working modules are licensed back to us in a GPL-clean way that allows us to return the work to the community.
The other way around works as well. You can keep the intellectual property rights yourself and license the software under GPL to your customer.
Doing it that way requires that the client transfer ownership of even their own employees' work on the project back to us. That's a lot harder to convince a client to do considering that they're paying you to do the work. If we desired the ability to relicense work, we would probably still use the scheme I mentioned but with a BSD (or similar) license.
David Strauss skrev:
Thomas Barregren wrote:
To avoid this sort of GPL Hell, we have very specific terms on which we work with clients:
(1) The client owns the work we do specifically for them.
(2) The client licenses .module files and their dependencies back to us under the GPL, version 2, and all future versions as published by the FSF.
The terms of (2) mean their internal staff can contribute to the project, but the final working modules are licensed back to us in a GPL-clean way that allows us to return the work to the community.
The other way around works as well. You can keep the intellectual property rights yourself and license the software under GPL to your customer.
Doing it that way requires that the client transfer ownership of even their own employees' work on the project back to us. That's a lot harder to convince a client to do considering that they're paying you to do the work.
The other way around approach is easy to use if you can isolate a module on which only your guys/gals work on. If the project team is a mix of your and your customers employees, I think your approach (which I never had though of - thank you) is better. Regards, Thomas
On Aug 31, 2007, at 4:48 PM, Thomas Barregren wrote:
To avoid this sort of GPL Hell, we have very specific terms on which we work with clients:
(1) The client owns the work we do specifically for them.
(2) The client licenses .module files and their dependencies back to us under the GPL, version 2, and all future versions as published by the FSF.
The terms of (2) mean their internal staff can contribute to the project, but the final working modules are licensed back to us in a GPL-clean way that allows us to return the work to the community.
The other way around works as well. You can keep the intellectual property rights yourself and license the software under GPL to your customer.
Does it? That's the real bone of contention in this thread, at least for me and I suspect not a few others. I guess that whether licensing the result of consulting/development work that is *not* work-for-hire constitutes "distribution." Laura
Laura Scott skrev:
On Aug 31, 2007, at 4:48 PM, Thomas Barregren wrote:
To avoid this sort of GPL Hell, we have very specific terms on which we work with clients:
(1) The client owns the work we do specifically for them.
(2) The client licenses .module files and their dependencies back to us under the GPL, version 2, and all future versions as published by the FSF.
The terms of (2) mean their internal staff can contribute to the project, but the final working modules are licensed back to us in a GPL-clean way that allows us to return the work to the community.
The other way around works as well. You can keep the intellectual property rights yourself and license the software under GPL to your customer.
Does it? That's the real bone of contention in this thread, at least for me and I suspect not a few others. I guess that whether licensing the result of consulting/development work that is *not* work-for-hire constitutes "distribution."
For consulting there is at least three different ways to do it: * The David Strauss way (which is very nice) * The other way around (as I described) * The neighbourly way By "the neighbourly way" I allude on "the freedom to redistribute copies so you can help your neighbor (freedom 2)". You download Drupal and distribute it without modifications to your customer. Then you help your customer to integrate their copy of Drupal with the non-GPLed software. Since the derived work never is distributed it is not a violation of GPL. Regards, Thomas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laura Scott schrieb:
On Aug 31, 2007, at 4:48 PM, Thomas Barregren wrote:
To avoid this sort of GPL Hell, we have very specific terms on which we work with clients:
(1) The client owns the work we do specifically for them.
(2) The client licenses .module files and their dependencies back to us under the GPL, version 2, and all future versions as published by the FSF.
The terms of (2) mean their internal staff can contribute to the project, but the final working modules are licensed back to us in a GPL-clean way that allows us to return the work to the community.
The other way around works as well. You can keep the intellectual property rights yourself and license the software under GPL to your customer.
Does it? That's the real bone of contention in this thread, at least for me and I suspect not a few others. I guess that whether licensing the result of consulting/development work that is *not* work-for-hire constitutes "distribution."
How can consulting/development work not be work for hire? Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG2KWpfg6TFvELooQRAuAIAKDERj5sflTc7W4xn6BH0wflmQxDswCfai+3 3N0vI35aZpYaG2uKrElVdBc= =lt20 -----END PGP SIGNATURE-----
On Aug 31, 2007, at 5:35 PM, Gerhard Killesreiter wrote:
How can consulting/development work not be work for hire?
IANAL, but my understanding after a lot of years in business, is this: In the US, "work for hire" is a legal phrase that implies that all you do is owned by your employer. That's how most employer/employee relationships are defined. However, most consulting and contracting jobs are not work for hire. The contractor does work under terms specified within the contract. Except for what is provided in the agreement, the contractor owns all of his/her own work. Rather OT, but since you asked... ;) Laura
Quoting Jeff Eaton <jeff@viapositiva.net>:
*** If you can, at any point, call debug_backtrace() and see BOTH drupal functions AND functions from a non-GPL-compatible piece of software, the terms of the GPL are being violated. ***
Then any project that uses PHP and claims to be GPL is violating the terms of the GPL as a rule of thumb. PHP isn't GPL licensed[1] and its functions are viewable in a debug_backtrace(). [1] http://www.php.net/license/3_01.txt Earnie
Earnie Boyd skrev:
Quoting Jeff Eaton <jeff@viapositiva.net>:
*** If you can, at any point, call debug_backtrace() and see BOTH drupal functions AND functions from a non-GPL-compatible piece of software, the terms of the GPL are being violated. ***
Then any project that uses PHP and claims to be GPL is violating the terms of the GPL as a rule of thumb. PHP isn't GPL licensed[1] and its functions are viewable in a debug_backtrace().
First, it is just a rule of thumb. (And a darn good one IMHO.) Second, this situation is explained in the GPL FAQ: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#InterpreterIncompa... Third, the best solution would be is Drupal included a FLOSS Exception: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLib... A good example of this is MySQL FLOSS Exception: http://www.mysql.com/company/legal/licensing/foss-exception.html Best regards, Thomas
ttw+drupal@cobbled.net skrev:
On 31.08-17:52, Thomas Barregren wrote: [ ... ]
The issue original brought up by Jeff Eaton was about the fact that it is not permissible to write modules that bridge software with a license not compatible with GPL.
[ ... ]
You surprise me. GPL has been around for *18 years* and this reciprocity (a.k.a. "copyleft") is the very heart of the license.
[ ... ]
Wrong. You are allowed to integrate GPL-application with any non-GPL application.
i believe you contradict yourself. the issue is the extension of GPL to include interfacing software, as below
No, I don't contradict myself. :-) The first snippet was meant to bring the discussion back to the original issue: what regulations applies to a module that tries to bridge GPLed code with non-GPLed code. I was a little careless in my choice of words. I should have written "distribute" instead of "write". Thus, the correct wording should have been: "The issue original brought up by Jeff Eaton was about the fact that it is not permissible to *distribute* modules that bridge software with a license not compatible with GPL." The third snippet states a fact. You are allowed to integrate GPL-application with any non-GPL application. I could perhaps have added that this right doesn't imply a right to also distribute the resulting derived work. But I didn't, because I thought it is a corollary of the following paragraph in my answer (which you didn't quote). I don't understand what the second snippet has to d with my alleged contradiction.
[ ... ]
* to study and modify the program.
--unless, of course, you want to bridge it with a non-GPL application, apparently.
Wrong. You are allowed to study and modify the program for any reason, including for the purpose of bridging it with non-GPL application.
[ ... ]
So, to solve the problem that the licensing of Drupal currently force us to "dumbing down" or "bypassing of established application methodologies", I suggest that the Drupal licensing is supplemented with an exception for module developers linking through hooks.
if you are allowed to study and modify the program for the purpose of bridging it with non-GPL code then there is no cross pollination of the licenses. this has traditionally been done (i.e. the use of GPL'd header files in compilation) but often brought under question by more aggressive GPL proponents.
You are allowed to study and modify the program as much as you want. No GPL proponents, aggressive or not, say something else (if they know what they are talking about). But, to *distribute* the derived work, you must license the derived work under GPL. If you cannot do that, for instance because you have integrated code under a license not compatible with GPL, you are not allowed to distribute it. But you may still use it.
i think the original author is confused about the exact status of GPL, especially, in relation to something like hooks where, it would appear to me, there is no issue. essentially, i see no reason you could not interface an application using hooks and keep that application propiertory. Generally, you cannot "interface an application using hooks and keep that application propiertory" as explained here:
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MoneyGuzzlerInc But, as this discussion is about, this can also pose a hindrance for situations where it can seem reasonable to include software with license not compatible with GPL. For an example, imagine someone who has put in a lot of effort to write code that integrates a popular but proprietary software with Drupal. So far it is okay under GPL. But now he wants to share his effort with the community. Since the integration code calls functions and share data structures with both the proprietary software and Drupal, it is not allowed. Fortunately, there is a solution. As long as you don't revoke any rights granted by GPL, you can add your own terms and conditions. This can be used to allow integration with software under a license incompatible with GPL. Two examples on this: * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLib... * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingOverControl... So, to solve the problem with bridging modules integrating 3rd party integration, I suggest that the Drupal licensing is supplemented with an exception for module developers linking through hooks. Best regards, Thomas
On Friday, 31. August 2007, Laura Scott wrote:
On Aug 31, 2007, at 6:05 AM, Thomas Barregren wrote:
So, to solve the problem that the licensing of Drupal currently force us to "dumbing down" or "bypassing of established application methodologies", I suggest that the Drupal licensing is supplemented with an exception for module developers linking through hooks.
All we need to do is track down everyone who has contributed code to the Drupal project and get their okay, right?
These, by the way, are exactly that kind of case where a proper copyright header would help enormously. You know, the kind of copyright header that is not used at all in standard Drupal code. Like proposed in the GPL's appendix, link: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html#SEC4 Can we please start adding such copyright headers *now*? The later those are added, the more inaccurate they will be. Please. Thanks, Jakob
Jeff Eaton wrote: <SNIP>
I should also clarify that in our discussions it was obvious that things like images, CSS, HTML, etc was NOT in fact covered. So, for example, it would be perfectly legal to create a Drupal theme that consists of nothing but images and CSS files (using drupal 6's new .info file format) and release it under a non-GPL license. Obviously, it couldn't be checked into Drupal's CVS repository in that case.
See also http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#WMS Best regards, Thomas
Jakob Petsovits skrev:
On Thursday, 30. August 2007, Jeff Eaton wrote:
For quite some time, it has been commonly understood in the Drupal community that non-GPL software (like a third-party PHP message board system) can be integrated into Drupal legally by using an intermediary 'bridge' module. After some in-depth emails with the Free Software foundation's license gurus, it's become clear that this is NOT the case.
Before going any further, I want to make clear that I'm not expressing approval or disapproval of this: I'm just relaying the conclusions that were reached after several days of discussion and questioning with the FSF.
Why do these modules violate the GPL?
1) Under the FSF's accepted interpretation of the GPL, if a module is integrating Drupal and another PHP script, by calling one's APIs when triggered by the other for example, its purpose is to make a single unit of software out of those parts.
My understanding was that non-GPL software may not be a derivative work of GPL code
Let us be careful with the wording here. As soon as you make a derivative of a GPL:ed code, it automatically becomes non-GPL:ed. That is because you and only you have the right to derivative work by copyright laws. GPL don't prohibit you from using the derivative. On the contrary, GPL was written to ensure you this right. It is one of the four fundamental freedoms that GPL strives to give you. But you are not allowed to *distribute* your derivative work without GPL it. Thus, any company or individual are free to download and integrate Drupal with their very secret and proprietary software. As long as they don't distribute it, they are not violating GPL. BTW, many people seems to believe that just because a derivative work is made from a GPL:ed software, they can demand a copy of the derivative work. If the derivative work never has been distributed, they are wrong. If the derivative work has been distributed including the source code, they are wrong. But, if the derivative work has been distributed with only an offer to obtain the source code, e.g. by downloading it, they are right. See § 3 (and § 3b in particular) in GPL v2.
, but that it can go the other way round. As David Strauss mentioned, it is indeed possible to write GPL software by using the Win32 or Cocoa API.
You can that because of an exception in § 3 of GPL v2.
Following this reasoning, it would mean the following for Drupal modules: - Drupal modules are based on Drupal, so they are GPL in any case. - Thus, modules may not incorporate code that make the integrated software derive (call functions) from Drupal or the module itself.
You are right so far.
- Whereas it should be possible to call functions from the integrated software from the module.
It depends on how the module calls the function in the integrated software. Read the FAQ: * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLAndPlugins
For example, that would mean no authentication in the integrated software that is based on Drupal users and passwords. Or displaying any information that comes from Drupal.
Again, this only applies to derivate works which is distributed.
But it should be possible to manage and display stuff from the integrated software from Drupal. Like is done with Apache, for example (which uses the GPLv2 incompatible Apache license). I'm sure there are lots of other good examples.
Would this make sense?
What do you mean? Drupal is not integrated with Apache HTTP Server (as far as I understand). It only runs on it.
2) If multiple programs are operating together and functioning as one unit, all the pieces must be GPL'd.
There are a lot of angles to approach the question from, but that's what it boils down to. From a developer's perspective, if debug_backtrace() can ever include functions from both Drupal and an external program, you've turned them into a single program.
David's argument that the GPL only covers distribution, not usage, is a good counter argument to this point of view. Of course, this is somewhat of a difficult issue, quite comparable to the kernel module blobs for the ATI and nVidia graphics card drivers which are widely considered a legal gray area.
Wrong. Jeff Eaton is right. If two programs are so tight integrated that "...debug_backtrace() can ever include functions from both...", both must be GPL:ed. The only exception is "...anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system..." according to § 3 in GPL v2.
Also, you could extend the issue not only to PHP code but also to XML-RPC calls, where you do not even know if the software that you communicate with is GPL or not.
I think you are wrong. PHP: The PHP license is not compatible with GNU v2. If you want to add a GPL:ed extension to PHP, that is a problem (which easily can be remedied with a FLOSS Exception). But it is not a problem from Drupal. Why? The GPL permits this because PHP falls under the exception in § 3 of GPL v2. XML-RPC: IMHO, a program accessing Drupal through XML-RPC need not to generally be under GPL. Why? In normal use of XML-RPC the client is separate from Drupal, and hence not subject for reciprocity of GPL. Compare this with one program calling another program though fork and exec. Read more in the FAQ: * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLAndPlugins Best regards, Thomas
Just for background this issue has come up because Joomla have decided to "fully" comply with GPL. This raised a few question for SMF team and they discussed it with FSF. The final result of that discussion is if php ( or any other scripting language ) which is distributed in source form is bridged to a non GPL software also distributed in source form then it violates the GPL. The immediate effect for drupal is that VB and SMF bridges are violating GPL. It doesn't matter if its being distributed via d.o. or not. This discussion is very interesting because it clearly highlights that for some people GPL means free software i.e. free as in beer ;) ____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/
I am all for system thinking and intended uses, but somehow I am losing the "parts" view here, things like responsibilities, consequences, legal or other. Suppose I write a spelling checker for MS Word in VBA (I don't really know VBA, just an example), with the clear intention to be used with MS Word and nothing else. I slap a GPL license file with no caveats on it and I distribute it. What happens now? What does it mean not to be GPL-compliant in this case, practically? MS or anyone else can take it, package it in some other software and sell it, claiming that it is not really GPL? Is that it? Also, because I have met lawyers before, are there any information about how the "system" interpretation ever did in court?
Cog Rusty wrote:
I am all for system thinking and intended uses, but somehow I am losing the "parts" view here, things like responsibilities, consequences, legal or other.
Suppose I write a spelling checker for MS Word in VBA (I don't really know VBA, just an example), with the clear intention to be used with MS Word and nothing else. I slap a GPL license file with no caveats on it and I distribute it. What happens now? What does it mean not to be GPL-compliant in this case, practically?
MS or anyone else can take it, package it in some other software and sell it, claiming that it is not really GPL? Is that it?
One of the beautiful things about the GPL is that, when it fails, normal copyright takes over. So, if the GPL is shown to be invalid on something you've created, other parties have *no rights* to distribute your work without other permission.
Also, because I have met lawyers before, are there any information about how the "system" interpretation ever did in court?
For better or worse, the GPL hasn't seen too much time in court.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Strauss schrieb:
Cog Rusty wrote:
I am all for system thinking and intended uses, but somehow I am losing the "parts" view here, things like responsibilities, consequences, legal or other.
Suppose I write a spelling checker for MS Word in VBA (I don't really know VBA, just an example), with the clear intention to be used with MS Word and nothing else. I slap a GPL license file with no caveats on it and I distribute it. What happens now? What does it mean not to be GPL-compliant in this case, practically?
MS or anyone else can take it, package it in some other software and sell it, claiming that it is not really GPL? Is that it?
One of the beautiful things about the GPL is that, when it fails, normal copyright takes over. So, if the GPL is shown to be invalid on something you've created, other parties have *no rights* to distribute your work without other permission.
Also, because I have met lawyers before, are there any information about how the "system" interpretation ever did in court?
For better or worse, the GPL hasn't seen too much time in court.
Not much, but there have been several recent cases in Germany where hardware vendors selling Linux based appliances were taken to court and the courts ordered them to abide by the GPL and include source code etc. See http://gpl-violations.org/ Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG2Ehxfg6TFvELooQRAv7mAJ46XYQtaRrlW+Rq05xzqT+mrDKJmwCgsIZs mp/lKjcDv/h3crOCsHPFm5c= =ggyT -----END PGP SIGNATURE-----
On 8/31/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Strauss schrieb:
Cog Rusty wrote:
I am all for system thinking and intended uses, but somehow I am losing the "parts" view here, things like responsibilities, consequences, legal or other.
Suppose I write a spelling checker for MS Word in VBA (I don't really know VBA, just an example), with the clear intention to be used with MS Word and nothing else. I slap a GPL license file with no caveats on it and I distribute it. What happens now? What does it mean not to be GPL-compliant in this case, practically?
MS or anyone else can take it, package it in some other software and sell it, claiming that it is not really GPL? Is that it?
One of the beautiful things about the GPL is that, when it fails, normal copyright takes over. So, if the GPL is shown to be invalid on something you've created, other parties have *no rights* to distribute your work without other permission.
I see. So practically nobody would have an interest in challenging the GPL status of my software, not MS or another vendor, not the user, not I (except if I changed my mind later). Only a project like Drupal might challenge it, with the intention to maintain the "virality" of its software.
Also, because I have met lawyers before, are there any information about how the "system" interpretation ever did in court?
For better or worse, the GPL hasn't seen too much time in court.
Not much, but there have been several recent cases in Germany where hardware vendors selling Linux based appliances were taken to court and the courts ordered them to abide by the GPL and include source code etc.
See http://gpl-violations.org/
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG2Ehxfg6TFvELooQRAv7mAJ46XYQtaRrlW+Rq05xzqT+mrDKJmwCgsIZs mp/lKjcDv/h3crOCsHPFm5c= =ggyT -----END PGP SIGNATURE-----
On 30 Aug 2007, at 09:08, Jeff Eaton wrote:
For quite some time, it has been commonly understood in the Drupal community that non-GPL software (like a third-party PHP message board system) can be integrated into Drupal legally by using an intermediary 'bridge' module. After some in-depth emails with the Free Software foundation's license gurus, it's become clear that this is NOT the case.
Because some people e-mailed me in private about this; it's going to take me a couple more days to respond to this thread. I'm also going to consult some other Open Source projects about this. In the mean time, keep on discussing as all input is valuable before we refine our stance. :) -- Dries Buytaert :: http://www.buytaert.net/
On 7-Sep-07, at 3:23 PM, Dries Buytaert wrote:
On 30 Aug 2007, at 09:08, Jeff Eaton wrote:
For quite some time, it has been commonly understood in the Drupal community that non-GPL software (like a third-party PHP message board system) can be integrated into Drupal legally by using an intermediary 'bridge' module. After some in-depth emails with the Free Software foundation's license gurus, it's become clear that this is NOT the case.
Because some people e-mailed me in private about this; it's going to take me a couple more days to respond to this thread. I'm also going to consult some other Open Source projects about this. In the mean time, keep on discussing as all input is valuable before we refine our stance. :)
Ok, I was keeping quiet in this thread, but since you seem to want input... IMO, the only thing we can do is exactly what Joomla! did: - Do not fork the GPL by creating our own interpretation of it (adding exceptions, etc.). Adding exceptions anyway is a physically impossibility; you'll never find all of the copyright holders of Drupal to sign off on it, and many of us would oppose such an action. - Remove any code from our repositories that combine with non-GPLed code. This would be things like SMF, vBulletin, CiviCRM integration bridges. If those companies want to put themselves in potential legal jeopardy by providing bridges for our CMS, then they can host it on their own infrastructure, not ours, or they can dual-license their software so that it's GPL-compatible. I think a lot of the discussion in this thread is just out-right denial. I'm quite sure that the folks at Open Source Matters looked into this issue extensively before Joomla! made their decision to quit distributing their SMF bridge, especially since the vast majority of their users are non-programmers who would never in a million years be able to create one by themselves, and since Joomla! does not have a core forum system of their own. On a personal note, I fully support the viral nature of GPL, and see it as a critical feature, not a bug. The GPL is part of the primary reasons I spend my time working on applications like Drupal; it preserves the freedoms I was given for all future users of my code. -Angie
Angela Byron skrev:
On 7-Sep-07, at 3:23 PM, Dries Buytaert wrote:
On 30 Aug 2007, at 09:08, Jeff Eaton wrote:
For quite some time, it has been commonly understood in the Drupal community that non-GPL software (like a third-party PHP message board system) can be integrated into Drupal legally by using an intermediary 'bridge' module. After some in-depth emails with the Free Software foundation's license gurus, it's become clear that this is NOT the case.
Because some people e-mailed me in private about this; it's going to take me a couple more days to respond to this thread. I'm also going to consult some other Open Source projects about this. In the mean time, keep on discussing as all input is valuable before we refine our stance. :)
Ok, I was keeping quiet in this thread, but since you seem to want input...
IMO, the only thing we can do is exactly what Joomla! did:
- Do not fork the GPL by creating our own interpretation of it (adding exceptions, etc.).
We should definitely *not* fork GPL. That would be committing hara-kiri. But adding a "FOSS Exception" or "Linked Under Controlled Interface Exception" is *not* forking. On the contrary! It is a proper way to solve situations like the one we are discussing. The technique is proposed and fully described with template and everything on FSF/GNU's web site: * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLib... * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingOverControl... In fact, it *might* be necessary to add a FOSS Exception for the PHP-license. Why? The PHP-license is not compatible with the GPL. That itself doesn't prevent PHP-programs to be distributed under GPL. But since Drupal *make use* of GD and other libraries distributed under the PHP-license, it is possible to argue that Drupal in part is a derivative of GD and the other libraries. If this cannot be deemed to fall under the platform exception in GPL, it is not possible to distribute Drupal under GPL without adding a notice saying that it is okay. Again, adding a such notice is not forking GPL.
Adding exceptions anyway is a physically impossibility; you'll never find all of the copyright holders of Drupal to sign off on it, and many of us would oppose such an action.
I am not completely convinced that it is a "physically impossibility". After all, it is a limited number of people who have committed code to the core. I suppose most of them are still members of Drupal.org, and hence possible to get in contact with. Why not try? Likely, a vast majority of all core contributors will accept a "FOSS Exception" and possible also a "Linked Under Controlled Interface Exception" for a "Module Programming Interface" (e.g. hooks and some utility functions). There will of course be some persons who cannot be contacted or who won't give their permission. But their numbers will probably be very small, and therefore easy to just replace their code with new code with the same functionality. After all, copyright doesn't protect ideas, only the expression of ideas. BTW, something similar has been done before, and in much larger scale, namely BSD.
- Remove any code from our repositories that combine with non-GPLed code. This would be things like SMF, vBulletin, CiviCRM integration bridges. If those companies want to put themselves in potential legal jeopardy by providing bridges for our CMS, then they can host it on their own infrastructure, not ours, or they can dual-license their software so that it's GPL-compatible.
Yea!
I think a lot of the discussion in this thread is just out-right denial. I'm quite sure that the folks at Open Source Matters looked into this issue extensively before Joomla! made their decision to quit distributing their SMF bridge, especially since the vast majority of their users are non-programmers who would never in a million years be able to create one by themselves, and since Joomla! does not have a core forum system of their own.
Very good point. I can only add, for those who think they can prove GPL unfeasible, that GPL has been around and scrutinized for 18 years.
On a personal note, I fully support the viral nature of GPL, and see it as a critical feature, not a bug.The GPL is part of the primary reasons I spend my time working on applications like Drupal; it preserves the freedoms I was given for all future users of my code.
I can only agree. Best regards, Thomas
On 8-Sep-07, at 5:51 AM, Thomas Barregren wrote:
Angela Byron skrev:
IMO, the only thing we can do is exactly what Joomla! did:
- Do not fork the GPL by creating our own interpretation of it (adding exceptions, etc.).
We should definitely *not* fork GPL. That would be committing hara- kiri.
But adding a "FOSS Exception" or "Linked Under Controlled Interface Exception" is *not* forking. On the contrary! It is a proper way to solve situations like the one we are discussing. The technique is proposed and fully described with template and everything on FSF/ GNU's web site:
* http://www.gnu.org/licenses/old-licenses/gpl-2.0- faq.html#GPLIncompatibleLibs * http://www.gnu.org/licenses/old-licenses/gpl-2.0- faq.html#LinkingOverControlledInterface
In fact, it *might* be necessary to add a FOSS Exception for the PHP-license. Why? The PHP-license is not compatible with the GPL. That itself doesn't prevent PHP-programs to be distributed under GPL. But since Drupal *make use* of GD and other libraries distributed under the PHP-license, it is possible to argue that Drupal in part is a derivative of GD and the other libraries. If this cannot be deemed to fall under the platform exception in GPL, it is not possible to distribute Drupal under GPL without adding a notice saying that it is okay. Again, adding a such notice is not forking GPL.
Fair enough. It still feels a bit "dirty" to me, though -- the fact that GPL doesn't have these exceptions written into "out of the box" it is definitely "by design," not an oversight.
Adding exceptions anyway is a physically impossibility; you'll never find all of the copyright holders of Drupal to sign off on it, and many of us would oppose such an action.
I am not completely convinced that it is a "physically impossibility". After all, it is a limited number of people who have committed code to the core. I suppose most of them are still members of Drupal.org, and hence possible to get in contact with. Why not try? Likely, a vast majority of all core contributors will accept a "FOSS Exception" and possible also a "Linked Under Controlled Interface Exception" for a "Module Programming Interface" (e.g. hooks and some utility functions).
Interesting. So the act of committing code transfers authorship? My offering up code and saying, "Please commit this to core" is synonymous with "I hereby abandon all rights I have as the author of this code, and trust that the core committers will not someday do something silly with it?" That's something I didn't know before. It was my understanding that copyright was retained by each individual who has contributed code to the project, regardless of who actually pulled the "commit" trigger.
BTW, something similar has been done before, and in much larger scale, namely BSD.
True. I don't argue that it _can't_ be done. I do argue that it might take much more time/resources than we want to spend on it. ;) Especially when we have a workaround (just boot the code from contrib that attempts to create a derivative work). However, your point about Drupal making use of GD and such is a good one that bears further investigation. Thanks a lot for your helpful contributions, Thomas. I've learned quite a bit from your interactions in this thread. -Angie
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Angela Byron schrieb:
On 8-Sep-07, at 5:51 AM, Thomas Barregren wrote:
I am not completely convinced that it is a "physically impossibility". After all, it is a limited number of people who have committed code to the core. I suppose most of them are still members of Drupal.org, and hence possible to get in contact with. Why not try? Likely, a vast majority of all core contributors will accept a "FOSS Exception" and possible also a "Linked Under Controlled Interface Exception" for a "Module Programming Interface" (e.g. hooks and some utility functions).
Interesting. So the act of committing code transfers authorship? My
No, no, no, and no. This does not happen. I think Thomas doesn't know how Drupal development works, which made him use the term "core committer". I hereby state that for none of the patches not written by me that I've committed to core or contrib I accept transfer of copyright or authorship (the latter is actually impossible under German law) of the code.
offering up code and saying, "Please commit this to core" is synonymous with "I hereby abandon all rights I have as the author of this code, and trust that the core committers will not someday do something silly with it?"
That's something I didn't know before. It was my understanding that copyright was retained by each individual who has contributed code to the project, regardless of who actually pulled the "commit" trigger.
That is my understanding too. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG4rpyfg6TFvELooQRAgbGAJ4nE1FCxwsXHqB0dwsGDd2cDwfrzQCbBDhQ PnHmlBl6GL1cy2xqf2vTH7A= =2QNh -----END PGP SIGNATURE-----
Gerhard Killesreiter skrev:
Interesting. So the act of committing code transfers authorship? My
No, no, no, and no. This does not happen. I think Thomas doesn't know how Drupal development works, which made him use the term "core committer".
Well, I think I know how Drupal development works. :-) As I answered Angie, I should have written "contributed" instead of "committed" in my reply. Best regards, Thomas
Quoting Gerhard Killesreiter <gerhard@killesreiter.de>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Angela Byron schrieb:
On 8-Sep-07, at 5:51 AM, Thomas Barregren wrote:
I am not completely convinced that it is a "physically impossibility". After all, it is a limited number of people who have committed code to the core. I suppose most of them are still members of Drupal.org, and hence possible to get in contact with. Why not try? Likely, a vast majority of all core contributors will accept a "FOSS Exception" and possible also a "Linked Under Controlled Interface Exception" for a "Module Programming Interface" (e.g. hooks and some utility functions).
Interesting. So the act of committing code transfers authorship? My
No, no, no, and no. This does not happen. I think Thomas doesn't know how Drupal development works, which made him use the term "core committer".
Where did Thomas you "core committer"? I see "core contributer". And while authorship doesn't transfer copyright can but for Drupal thus far copyright assignment hasn't been requested. And yet while both authorship and copyright have been retained by you; there is no document to prove it within the source itself. There is the ticket but there is not even a ChangeLog entry to indicate the changes. This is in itself a violation of the GPL as clearly stated in article 2a.
I hereby state that for none of the patches not written by me that I've committed to core or contrib I accept transfer of copyright or authorship (the latter is actually impossible under German law) of the code.
That is colorfully stated but no one has asked for transfer of ownership.
offering up code and saying, "Please commit this to core" is synonymous with "I hereby abandon all rights I have as the author of this code, and trust that the core committers will not someday do something silly with it?"
That's something I didn't know before. It was my understanding that copyright was retained by each individual who has contributed code to the project, regardless of who actually pulled the "commit" trigger.
That is my understanding too.
The only means by which you can transfer your copyright is by legal terms spelled out in writing and then signed by the original owners of the code. There can be stipulations that state that copyright is dually maintained so that both parties own a copyright. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Angela Byron skrev:
On 8-Sep-07, at 5:51 AM, Thomas Barregren wrote:
Angela Byron skrev:
IMO, the only thing we can do is exactly what Joomla! did:
- Do not fork the GPL by creating our own interpretation of it (adding exceptions, etc.).
We should definitely *not* fork GPL. That would be committing hara-kiri.
But adding a "FOSS Exception" or "Linked Under Controlled Interface Exception" is *not* forking. On the contrary! It is a proper way to solve situations like the one we are discussing. The technique is proposed and fully described with template and everything on FSF/GNU's web site:
* http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLib...
* http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingOverControl...
In fact, it *might* be necessary to add a FOSS Exception for the PHP-license. Why? The PHP-license is not compatible with the GPL. That itself doesn't prevent PHP-programs to be distributed under GPL. But since Drupal *make use* of GD and other libraries distributed under the PHP-license, it is possible to argue that Drupal in part is a derivative of GD and the other libraries. If this cannot be deemed to fall under the platform exception in GPL, it is not possible to distribute Drupal under GPL without adding a notice saying that it is okay. Again, adding a such notice is not forking GPL.
Fair enough. It still feels a bit "dirty" to me, though -- the fact that GPL doesn't have these exceptions written into "out of the box" it is definitely "by design," not an oversight.
You are definitely right. :-) RSM and FSF/GNU want everybody to use GPL. But they are also realists, and therefore provide these means to use GPL in conjunction with software not compatible with GPL.
Adding exceptions anyway is a physically impossibility; you'll never find all of the copyright holders of Drupal to sign off on it, and many of us would oppose such an action.
I am not completely convinced that it is a "physically impossibility". After all, it is a limited number of people who have committed code to the core. I suppose most of them are still members of Drupal.org, and hence possible to get in contact with. Why not try? Likely, a vast majority of all core contributors will accept a "FOSS Exception" and possible also a "Linked Under Controlled Interface Exception" for a "Module Programming Interface" (e.g. hooks and some utility functions).
Interesting. So the act of committing code transfers authorship?
No. I didn't said that.
My offering up code and saying, "Please commit this to core" is synonymous with "I hereby abandon all rights I have as the author of this code, and trust that the core committers will not someday do something silly with it?"
That's something I didn't know before. It was my understanding that copyright was retained by each individual who has contributed code to the project, regardless of who actually pulled the "commit" trigger.
It was not my intention to imply anything similar to what you say. Of course the author of the code keep the copyright. I should have written "contributed" instead of "committed" in my reply. BTW, remember that not all contributions is "copyrightable". It must have a certain level of creativity. For an example, a patch that just correct a simple spelling error (or similar) is probably not protected by the copyright laws. Furthermore, ideas are not protected by copyright, only their expression as code.
BTW, something similar has been done before, and in much larger scale, namely BSD.
True. I don't argue that it _can't_ be done. I do argue that it might take much more time/resources than we want to spend on it. ;) Especially when we have a workaround (just boot the code from contrib that attempts to create a derivative work).
I agree that we first of all should boot code that links to code and call functions and share data structures with another code which has a licnse not compatible with GPL. But we should of course not boot code that use another code using GPL compatible license (e.g. BSD, MIT and LGPL). The second most important thing we can do is to use GPL v3 instead of GPL v2. By doing so, many more licenses, most notable Apache, is compatible with GPL. But somewhere down the road I think we really should try to track contributors very much like how Linux kernel does.
However, your point about Drupal making use of GD and such is a good one that bears further investigation
That is one of the things I suggest Drupal Association bring up with a lawyer.
Thanks a lot for your helpful contributions, Thomas. I've learned quite a bit from your interactions in this thread.
I am glad to be any help. :-) Best regards, Thomas
Can I again suggest that the most pragmatic change would be to license core under "GPL 2.0 or any later version". Moving to only 3.0 would be a mistake, since there are contrib modules and other open source projects that may stay as GPL 2.0 only. -Peter On 9/8/07, Thomas Barregren <thomas@webbredaktoren.se> wrote: ...
I agree that we first of all should boot code that links to code and call functions and share data structures with another code which has a licnse not compatible with GPL. But we should of course not boot code that use another code using GPL compatible license (e.g. BSD, MIT and LGPL).
The second most important thing we can do is to use GPL v3 instead of GPL v2. By doing so, many more licenses, most notable Apache, is compatible with GPL.
...
Best regards, Thomas
Quoting Peter Wolanin <pwolanin@gmail.com>:
Can I again suggest that the most pragmatic change would be to license core under "GPL 2.0 or any later version". Moving to only 3.0 would be a mistake, since there are contrib modules and other open source projects that may stay as GPL 2.0 only.
This is resolved by changing to the GPL v3 version with a major release. Then modules must update with along with support for the newest version of Drupal. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
The second most important thing we can do is to use GPL v3 instead of GPL v2.
There is a slight problem with this. I do not like GPL v3. So, you do not need to chase the hundreds of core contributors, because I won't sign off such a change.
Karoly Negyesi skrev:
The second most important thing we can do is to use GPL v3 instead of GPL v2.
There is a slight problem with this. I do not like GPL v3. So, you do not need to chase the hundreds of core contributors, because I won't sign off such a change.
Karoly, I would be very interesting to here your reasons for not liking GPL v3. Best regards, Thomas
Quoting Karoly Negyesi <karoly@negyesi.net>:
The second most important thing we can do is to use GPL v3 instead of GPL v2.
There is a slight problem with this. I do not like GPL v3. So, you do not need to chase the hundreds of core contributors, because I won't sign off such a change.
IMO, you already have because of the "any future version" clause. So if Drupal.org decides to move to GPL v3 they do not need to contact anyone for permission as permission has already been given. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
IMO, you already have because of the "any future version" clause.
Which can be found exactly where..? Drupal tarball is distributed with the GPL v2, the contributions FAQ link to the GPL v2 and however hard I seek I can't find a single mention of that.
On 9-Sep-07, at 10:42 AM, Karoly Negyesi wrote:
IMO, you already have because of the "any future version" clause.
Which can be found exactly where..? Drupal tarball is distributed with the GPL v2, the contributions FAQ link to the GPL v2 and however hard I seek I can't find a single mention of that.
It's written in LICENSE.txt: " This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) ***any later version***. "
Angela, this text describes the copyright statement that *should* be in all the source files. As far as I can tell, since none of the files actually specify the version of the license tht applies, we're in a bit of a muddle. -Peter On 9/9/07, Angela Byron <drupal-devel@webchick.net> wrote:
On 9-Sep-07, at 10:42 AM, Karoly Negyesi wrote:
IMO, you already have because of the "any future version" clause.
Which can be found exactly where..? Drupal tarball is distributed with the GPL v2, the contributions FAQ link to the GPL v2 and however hard I seek I can't find a single mention of that.
It's written in LICENSE.txt:
" This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) ***any later version***. "
Peter Wolanin skrev:
Angela,
this text describes the copyright statement that *should* be in all the source files. As far as I can tell, since none of the files actually specify the version of the license tht applies, we're in a bit of a muddle.
Very interesting point. That would be another interesting question for Drupal Association to bring up with a lawyer. Regards, Thomas
Ok - enough talk - in Drupal things should be solved with patches ;-) Here's a patch to at least add the standard copyright statement from GPL 2.0 to the Drupal HEAD index.php file. right now since none of the source files have such a notice to even make it clear that they are GPl licensed: http://drupal.org/node/174226 On 9/9/07, Peter Wolanin <pwolanin@gmail.com> wrote:
Angela,
this text describes the copyright statement that *should* be in all the source files. As far as I can tell, since none of the files actually specify the version of the license tht applies, we're in a bit of a muddle.
-Peter
On 9/9/07, Angela Byron <drupal-devel@webchick.net> wrote:
On 9-Sep-07, at 10:42 AM, Karoly Negyesi wrote:
IMO, you already have because of the "any future version" clause.
Which can be found exactly where..? Drupal tarball is distributed with the GPL v2, the contributions FAQ link to the GPL v2 and however hard I seek I can't find a single mention of that.
It's written in LICENSE.txt:
" This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) ***any later version***. "
On Sunday, 9. September 2007, Peter Wolanin wrote:
Ok - enough talk - in Drupal things should be solved with patches ;-)
Here's a patch to at least add the standard copyright statement from GPL 2.0 to the Drupal HEAD index.php file. right now since none of the source files have such a notice to even make it clear that they are GPl licensed:
Yeah! Way to go!
Quoting Angela Byron <drupal-devel@webchick.net>:
Fair enough. It still feels a bit "dirty" to me, though -- the fact that GPL doesn't have these exceptions written into "out of the box" it is definitely "by design," not an oversight.
But even FSF adds exceptions to the GPL at times; e.g. libstdc++. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Hi, There's a lot of noise here that comes of us all not being legal experts, but as Dries has sanctioned discussion then I'll throw in my two pence of opinionated blaring. I hope nobody minds. My own rather basic reading of the law is that, as long as GPL and non-GPLed software types are not bundled together, then you're "more or less OK". You can infer my legal credentials from the fact that I use such obscure terminology. But this would mean that you can link your non-GPL application dynamically to GPL libraries, but you can't compile them in statically; you can develop the TinyMCE bridge, but the consumer of the software has to fetch TinyMCE separately. Angela Byron wrote:
On a personal note, I fully support the viral nature of GPL, and see it as a critical feature, not a bug.
Does this count as an email disclaimer? ;) If so, for the record I agree wholeheartedly with the above statement: the viral nature of GPL protects the freedoms expressed within it, at the expense of other freedoms that GPL instigators have deemed less fundamental. However, the virality stops at certain boundaries, doesn't it? If not, then: * How does Cygwin survive, translating the calls of potentially GPL programs to the language of the wholeheartedly un-GPL OS it sits in? By extension, how does any GPL program conscience working on Windows (by which I don't mean morally....)? How can something like Automatix work, sprinkling software of all sorts of licences like fairy dust through your Ubuntu box? * How can you build GPL webservice clients, and would their use in requesting data or processing from a non-GPLed webservice count as licence infringement? What would a GPLed webservice even look like? Richard Stallman, I think, is on record as saying that the proprietary nature of services such as Amazon's doesn't bother him, but it bothers other people. * How does networking software not transmit the GPL in its very packets, when it lets proprietary and GPL software communicate and potentially share processing? Before you wonder, I'm not saying that the above cases justify us playing fast and loose with the GPL, if that's indeed what we're doing. But I think we need to make sure we make a right and consistent decision, and maybe we can learn from more than just kissing cousins like Joomla. Cheers, J-P -- J-P Stacey +44 (0)1608 811870 http://torchbox.com
On Monday, 10. September 2007, J-P Stacey wrote:
However, the virality stops at certain boundaries, doesn't it? If not, then:
* How does Cygwin survive, translating the calls of potentially GPL programs to the language of the wholeheartedly un-GPL OS it sits in? By extension, how does any GPL program conscience working on Windows (by which I don't mean morally....)? How can something like Automatix work, sprinkling software of all sorts of licences like fairy dust through your Ubuntu box?
* How can you build GPL webservice clients, and would their use in requesting data or processing from a non-GPLed webservice count as licence infringement? What would a GPLed webservice even look like? Richard Stallman, I think, is on record as saying that the proprietary nature of services such as Amazon's doesn't bother him, but it bothers other people.
* How does networking software not transmit the GPL in its very packets, when it lets proprietary and GPL software communicate and potentially share processing?
I don't want to be rude, but all of these questions have already been answered in this thread. Before another well-explained, but extensive Thomas Barregren mail is coming up again, I suggest you look it up by yourself. Yeah, I know it's daunting to read and understand all of this thread, it's too large already.
Jakob Petsovits skrev:
On Monday, 10. September 2007, J-P Stacey wrote:
However, the virality stops at certain boundaries, doesn't it? If not, then:
* How does Cygwin survive, translating the calls of potentially GPL programs to the language of the wholeheartedly un-GPL OS it sits in? By extension, how does any GPL program conscience working on Windows (by which I don't mean morally....)? How can something like Automatix work, sprinkling software of all sorts of licences like fairy dust through your Ubuntu box?
* How can you build GPL webservice clients, and would their use in requesting data or processing from a non-GPLed webservice count as licence infringement? What would a GPLed webservice even look like? Richard Stallman, I think, is on record as saying that the proprietary nature of services such as Amazon's doesn't bother him, but it bothers other people.
* How does networking software not transmit the GPL in its very packets, when it lets proprietary and GPL software communicate and potentially share processing?
I don't want to be rude, but all of these questions have already been answered in this thread. Before another well-explained, but extensive Thomas Barregren mail is coming up again, I suggest you look it up by yourself.
Lol. I should perhaps "rest my case". :-)
Yeah, I know it's daunting to read and understand all of this thread, it's too large already.
The easiest way to see the whole thread, which currently consists of 198 messages, is by Nabble: * http://www.nabble.com/Modules-that-integrate-non-GPL-PHP-apps-violate-the-GP... If you prefer the "official" mailing archive, you have to jump around a little: * http://lists.drupal.org/archives/development/2007-08/threads.html#00568 * http://lists.drupal.org/archives/development/2007-09/threads.html#00000 * http://lists.drupal.org/archives/development/2007-09/threads.html#00025 * http://lists.drupal.org/archives/development/2007-09/threads.html#00082 * http://lists.drupal.org/archives/development/2007-09/threads.html#00200 Best regards, Thomas
I don't want to be rude, but all of these questions have already been answered in this thread.
Sorry about that: you're quite right. I'd got through around half of them this morning and the others had been marked as read (almost certainly by a slip of my mouse) so I didn't spot that. J-P ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On 10/09/2007, J-P Stacey <jp.stacey@torchbox.com> wrote:
My own rather basic reading of the law is that, as long as GPL and non-GPLed software types are not bundled together, then you're "more or less OK". You can infer my legal credentials from the fact that I use such obscure terminology. But this would mean that you can link your non-GPL application dynamically to GPL libraries, but you can't compile them in statically; you can develop the TinyMCE bridge, but the consumer of the software has to fetch TinyMCE separately.
No the reason TinyMCE isn't bundled with its bridge module isn't because of incompatible licenses but Drupal policies on only allowing GPL code in CVS. TinyMCE has a GPL compatible license (LGPL), so there is nothing wrong license wise with bundling up TinyMCE with a Drupal module and distributing it from your own server as a combined work under the GPL. The same is true with any other code with a GPL compatible license. So although distributing a SMF bridge module (which sparked this debate) appears to violate the GPL, distributing the TinyMCE bridge module wouldn't. -- Cheers Anton
The current Drupal CVS policy doesn't differentiate between GPL and non-GPL. The current policy is no third party code. As it's been explained to me, if users can get the code somewhere else, it doesn't belong in Drupal's CVS. Nedjo suggested some revisions to the CVS policy to make it easier for developers to include small javascript libraries back in March ( http://drupal.org/node/124978), but AFAIK the policy is still no third party code... GPL compatible or otherwise. ___ *Kevin Reynen* Integrated Media Coordinator Reynolds School of Journalism and Advanced Media Research University of Nevada, Reno On 9/10/07, Anton <anton.list@gmail.com> wrote:
On 10/09/2007, J-P Stacey <jp.stacey@torchbox.com> wrote:
My own rather basic reading of the law is that, as long as GPL and non-GPLed software types are not bundled together, then you're "more or less OK". You can infer my legal credentials from the fact that I use such obscure terminology. But this would mean that you can link your non-GPL application dynamically to GPL libraries, but you can't compile them in statically; you can develop the TinyMCE bridge, but the consumer of the software has to fetch TinyMCE separately.
No the reason TinyMCE isn't bundled with its bridge module isn't because of incompatible licenses but Drupal policies on only allowing GPL code in CVS.
TinyMCE has a GPL compatible license (LGPL), so there is nothing wrong license wise with bundling up TinyMCE with a Drupal module and distributing it from your own server as a combined work under the GPL. The same is true with any other code with a GPL compatible license.
So although distributing a SMF bridge module (which sparked this debate) appears to violate the GPL, distributing the TinyMCE bridge module wouldn't.
-- Cheers Anton
On 11/09/2007, Kevin Reynen <kreynen@gmail.com> wrote:
The current Drupal CVS policy doesn't differentiate between GPL and non-GPL. The current policy is no third party code. As it's been explained to me, if users can get the code somewhere else, it doesn't belong in Drupal's CVS.
Nedjo suggested some revisions to the CVS policy to make it easier for developers to include small javascript libraries back in March (http://drupal.org/node/124978), but AFAIK the policy is still no third party code... GPL compatible or otherwise.
The CVS handbook is explicit about only hosting GPL code: http://drupal.org/node/66113 http://drupal.org/node/103704 and nothing in Nedjos forum thread seemed to indicate that was changing. But that reinforces my point - it is Drupal policies (either no 3rd party code or GPL only code - take your pick) keeping TinyMCE out of cvs.drupal.org not any licensing violations. I chose to use the "GPL only" policy to make my point as jQuery makes the "no 3rd party code" policy a bit more open to exceptions. -- Cheers Anton
Hello everyone, Following this discussion thread, it seems that great many developers are not sufficiently familiar with copyright and licensing of free and open source software (FOSS). A very good brief on this matter, which I can really recommend to everyone to read, is the 13 pages short publication "The Open Source Legal Landscape" by the Australian lawyer Brendan Scott. Follow this link to download it as PDF: http://opensourcelaw.biz/publications/papers/BScott_OSS_Legal_Landscape_0603... Please, notice that the paper discusses *Australian* law. The law of other jurisdictions may (or may not) be different. With Brendan's kind permission, I have below included the most interesting parts with respect to our discussion. 1.3 Copyright operates by prohibiting numerous categories of action in respect of a copyright work. [...] In the absence of a permission from the copyright holder, there is an absolute prohibition on exercising any of the rights comprised in copyright in respect of that work. 1.4 For example, if a person buys both a screwdriver and some software from someone, they may do what they like with the screwdriver, including modifying it, improving it, renting it to others etc. However, the scope of actions that they can undertake with the software is strictly limited (subject to some qualifications) to those things over which they have been granted permission from (ie licensed by) the holder of copyright in the software. [...] 2.3 [...] Open source licences effectively exempt the permitted activities from copyright infringement, subject to compliance with certain conditions (which are different depending upon the licence). A failure to comply with the conditions in the licence will mean that the activities are no longer exempted from infringement of copyright. If the activity in question results in an infringement of copyright, then the copyright owner will have an action against the person engaging in the activity. 4.1 Open source licensing is a customer driven market reaction to the high transaction costs and anti-competitive effects that the old model has produced. It effectively says that, through judicious use of copyright, customers can acquire software with rights analogous to ownership. In the example above, if the software is open source software, the person acquiring the software would have property-like rights over the use of the software in a manner analogous to the rights they have over the screwdriver. 7.1 One of the characteristics of open source licences is that they must “/permit”/ the source code of modifications to the software to be licensed under an open source licence. [...] Some open source licences go further, not only permitting, but /requiring/ that modifications of the software or other, related, software be licensed under an open source licence, typically under the terms of the same licence. [...] 7.2 The GNU General Public License (GPL) is the best known, and perhaps the most widely implemented of the strong licences. It requires that if modifications to GPLed software are published or distributed, they must be licensed under the terms of the GPL. It further requires that works which: (a) include as part of them a modification of software licensed under the GPL; and (b) which are distributed must also be licensed under the GPL and that access to the source code of the software must also be provided. [...] 9.1 One of the consequences of strong licensing is that care must be exercised when combining source code from two or more different projects which are licensed under different licences. [...] If the requirements of these licences are /per se/ inconsistent then there is no legal basis on which the output product can be licensed. 14.5 The GPL permits the making of changes to the software and does not require the distribution of changes made. However, if you do distribute those changes, and they are “derived from” the software, you must distribute those changes on the terms of the GPL. This makes the GPL a strong licence. [...] I have deliberately omitted the paper's definition of "strong licence" above. That is because Brendan, in private correspondence, has asked me to downplay the characterization because he is increasing coming to the conclusion that distinction between "weak" and "strong" licenses is not all that clear. Please, read the full publication which can be downloaded from the web site of Open Source Law <http://www.opensourcelaw.biz/>. Best regards, Thomas (IANAL)
The same should be noted about other countries too: a lot of people chiming in on this discussion seem to assume there is just one legal system and the GPL is valid under it. Actually, some parts of the GPL are invalid in some legal systems and the matching provisions are automatically deemed unwritten in that case. This for instance the case with french law and provision 11 and 12 which are void when the user is an end-user. Accordingly, provision 7 could be interpreted as implying that this forbids any person, physical or moral, operating in France, to distribute GPL software he did not author. Other countries may have similar dispositions. This is actually one of the main points behind the creation of the CeCILL by the french government: it was designed to be applicable both under the french, US and some other legal systems, and also fixes a few technical problems like the definition of applicable law, which is missing from the GPL. Note that the FSF also worked on this problem: the equivalent provisions in GPLv3 (15 and 16) have been extended by provision 17 which takes into account the fact that the former writing was not applicable in some countries. In that regard at least, the GPLv3 should be more universal than GPLv2. ----- Original Message ----- From: "Thomas Barregren" <thomas@webbredaktoren.se> To: <development@drupal.org> Sent: Saturday, September 08, 2007 10:52 AM Subject: Re: [development] Modules that integrate non-GPL PHP apps violate the GPL. [...]
Following this discussion thread, it seems that great many developers are not sufficiently familiar with copyright and licensing of free and open source software (FOSS). A very good brief on this matter, which I can really recommend to everyone to read, is the 13 pages short publication "The Open Source Legal Landscape" by the Australian lawyer Brendan Scott. Follow this link to download it as PDF:
http://opensourcelaw.biz/publications/papers/BScott_OSS_Legal_Landscape_0603...
Please, notice that the paper discusses *Australian* law. The law of other jurisdictions may (or may not) be different.
[...]
FGM skrev:
The same should be noted about other countries too: a lot of people chiming in on this discussion seem to assume there is just one legal system and the GPL is valid under it.
[...]
Note that the FSF also worked on this problem: the equivalent provisions in GPLv3 (15 and 16) have been extended by provision 17 which takes into account the fact that the former writing was not applicable in some countries. In that regard at least, the GPLv3 should be more universal than GPLv2.
This alone is a VERY good reason for Drupal.org to move from to GPL v3. Best regards, Thomas
participants (36)
-
Angela Byron -
Anton -
Boris Mann -
Bryan Ruby -
Chris Johnson -
Cog Rusty -
Darren Oh -
David Metzler -
David Strauss -
Dries Buytaert -
Earnie Boyd -
FGM -
Gerhard Killesreiter -
Glenn Wybo -
Hunter C -
J-P Stacey -
Jakob Persson -
Jakob Petsovits -
Jeff Eaton -
jp.stacey＠torchbox.com
-
Karoly Negyesi -
Ken Rickard -
Kevin Reynen -
Larry Garfield -
Laura Scott -
mark burdett -
Mark Fredrickson -
Peter Wolanin -
Piermaria Maraziti -
Shai Gluskin -
Steve Ringwood -
Steven Peck -
Thomas Barregren -
ttw+drupal＠cobbled.net -
Vivek Puri -
Walt Daniels