|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 | Next > |
|
|
Re: Modules that integrate non-GPL PHP apps violatethe GPL.On Fri, 7 Sep 2007 09:14:52 -0600, Laura Scott <laura@...> 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 |
|
|
Re: Modules that integrate non-GPL PHP apps violate the GPL.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@...> wrote: > Quoting mark burdett <mfburdett@...>: > > > 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/ > > |
|
|
Re: Modules that integrate non-GPL PHP apps violate the GPL.Quoting mark burdett <mfburdett@...>:
> 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@.... </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? |
|
|
Re: Modules that integrate non-GPL PHP apps violate the GPL.Quoting ttw+drupal@...:
> 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/ |
|
|
Re: Modules that integrate non-GPL PHP apps violate the GPL.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/ |
|
|
Re: Modules that integrate non-GPL PHP apps violate the GPL.Quoting ttw+drupal@...:
> 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/ |
|
|
Re: Modules that integrate non-GPL PHP apps violate the GPL.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 |
|
|
Re: Modules that integrate non-GPL PHP appsviolate the GPL.On Fri, 07 Sep 2007 15:34:39 -0400, Earnie Boyd <earnie@...> 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 |
|
|
Re: Modules that integrate non-GPL PHP appsviolate the GPL.On 9/7/07, Larry Garfield <larry@...> 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 |
|
|
Re: Modules that integrate non-GPL PHP appsviolate the GPL.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 |
|
|
Re: Modules that integrate non-GPL PHP appsviolate the GPL.Quoting Laura Scott <laura@...>:
> > 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/ |
|
|
Re: Modules that integrate non-GPL PHP appsviolate the GPL.Quoting Larry Garfield <larry@...>:
> > On Fri, 07 Sep 2007 15:34:39 -0400, Earnie Boyd > <earnie@...> 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/ |
|
|
Re: Modules that integrate non-GPL PHP appsviolate the GPL.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 |
|
|
Re: Modules that integrate non-GPL PHP appsviolate the GPL.-----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----- |
|
|
Re: Modules that integrate non-GPL PHP apps violatethe GPL.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@...> > 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 > |
|
|
Re: Modules that integrate non-GPL PHP apps violate the GPL.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_060328.pdf 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) |
|
|
Re: Modules that integrate non-GPL PHP apps violate the GPL.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@...> To: <development@...> 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_060328.pdf > > Please, notice that the paper discusses *Australian* law. The law of > other jurisdictions may (or may not) be different. [...] |
|
|
Re: Modules that integrate non-GPL PHP apps violate the GPL.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#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. > 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 |
|
|
Re: Modules that integrate non-GPL PHP apps violate the GPL.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 |
|
|
Re: Modules that integrate non-GPL PHP apps violate the GPL.-----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----- |
| < Prev | 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |