Re: GR Proposal: GFDL statement
On Tue, Jan 03, 2006 at 09:17:24PM -0500, Nathanael Nerode [EMAIL PROTECTED] wrote a message of 19 lines which said: I think -legal came to a very definite consensus that licensing the documentation under the exact same license as the program was always the right thing to do. I agree. In some countries (I checked for France), it is the default (the documentation of a software is regarded as software). It saves *so* much trouble. But not all documentation is attached to a software. For instance, if I write a book Software development on Debian, releasing it under the GFDL is still the reasonable thing to do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is libreludedb DFSG compliant?
Scripsit Mickael Profeta [EMAIL PROTECTED] If you link LibPreludeDB against other code all of which is itself licensed under the terms of the GNU General Public License version 2 dated June 1991 (GPL v2) or compatible, then you may use LibpreludeDB under the terms of the GPL v2,as appearing in the file COPYING. If the file COPYING is missing, you can obtain a copy of the GPL v2 from the Free Software Foundation Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. I worries me that one has to do linking in order to get the freedoms we need. I'm not sure that such a requirement should be considered free. Why on earth do they not just license it as GPL straight away? That would not prevent them from offering other license terms in addition for a fee (or without one) as they see fit. -- Henning Makholm The great secret, known to internists and learned early in marriage by internists' wives, but still hidden from the general public, is that most things get better by themselves. Most things, in fact, are better by morning. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is libreludedb DFSG compliant?
Henning Makholm wrote: Why on earth do they not just license it as GPL straight away? That would not prevent them from offering other license terms in addition for a fee (or without one) as they see fit. They may be worried about whether dynamic linking against their software creates a derivative work. With that language, they try to take away that worry. Arnoud -- Arnoud Engelfriet, Dutch European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR Proposal: GFDL statement
On Thu, Jan 05, 2006 at 10:34:46AM +0100, Stephane Bortzmeyer wrote: It saves *so* much trouble. But not all documentation is attached to a software. For instance, if I write a book Software development on Debian, releasing it under the GFDL is still the reasonable thing to do. Not if you want it to be part of Debian. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR Proposal: GFDL statement
On Thu, Jan 05, 2006 at 12:08:23PM +0100, Wouter Verhelst [EMAIL PROTECTED] wrote a message of 15 lines which said: I write a book Software development on Debian, releasing it under the GFDL is still the reasonable thing to do. Not if you want it to be part of Debian. It still works for the rest of the world which is large enough for my Wikipedia contributions (GFDL) and my lectures (GFDL too). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is libreludedb DFSG compliant?
Scripsit Arnoud Engelfriet [EMAIL PROTECTED] Henning Makholm wrote: Why on earth do they not just license it as GPL straight away? That would not prevent them from offering other license terms in addition for a fee (or without one) as they see fit. They may be worried about whether dynamic linking against their software creates a derivative work. With that language, they try to take away that worry. I am aware of that controversy, yet it is not even clear to me in which direction the proposed language is supposed to resolve it. -- Henning MakholmThere is a danger that curious users may occasionally unplug their fiber connector and look directly into it to watch the bits go by at 100 Mbps. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
the FSF's GPLv3 launch conference
Howdy legal mavens, Don Armstrong and I are going to be at the FSF's GPLv3 launch conference[1] in Boston, Massachusetts on 16 and 17 January. Because the text of the first public draft is being held back until the actual conference, there is as yet nothing to review. (If there are pre-release drafts in circulation outside the FSF, I'm not aware of it.) The FSF, however, is not hosting this conference so that they can present a new revision of the GPL as a fait accompli to a captive audience. Rather, they want the community's feedback. (See ยง1.4 of the GPLv3 Process Definition document[2].) To that end, I want to be as good a representative as I can be of the Debian Project's views on the GPL -- what's good about it, what's not so good, and what we'd like to see in a future revision. I have therefore created a page on our Wiki where our developers and users can share there thoughts[3]. I realize not everyone is going to have the same opinions and goals. It is not time yet to attempt to forge a position statement on GPLv3 -- we haven't even yet seen the first draft of it. Instead, what I seek is to take the temperature of the project on the GPL generally. Don and I will represent the viewpoints as faithfully as we can. I'll be making a posting to -project separately, but I explicitly wanted to invite the involvement of the subscribers to this list. This is, after all, the place where the majority of our license analyses take place. Please take the time to visit http://wiki.debian.org/GPL_v3_Launch_Comments in the next week or so and share your ideas. Thank you. I look forward to representing the Project on this exciting occasion. [1] http://gplv3.fsf.org/launch [2] http://gplv3.fsf.org/process-definition [3] http://wiki.debian.org/GPL_v3_Launch_Comments -- G. Branden Robinson Debian Project Leader [EMAIL PROTECTED] http://people.debian.org/~branden/ signature.asc Description: Digital signature
Re: Is libreludedb DFSG compliant?
On Thu, Jan 05, 2006 at 11:18:15AM +0100, Arnoud Engelfriet wrote: Henning Makholm wrote: Why on earth do they not just license it as GPL straight away? That would not prevent them from offering other license terms in addition for a fee (or without one) as they see fit. They may be worried about whether dynamic linking against their software creates a derivative work. With that language, they try to take away that worry. But they can't do that (at least not in any consistent way). You can't say this software is available under the GPL only when used in noncommercial ways. The result is inconsistent and useless, and not the GPL, or GPL-compatible, at all. (GPL-compatible software can not prohibit commercial use, since the GPL doesn't do so.) Likewise, you can't say available under the GPL only when linked against something else that's GPL-compatible. (Well, you can, but the result is confusing and not very useful, and can't be linked against stuff actually under the GPL, since it's GPL-incompatible.) Now, if what they mean is this is available under the GPL once it's been linked against something GPL-compatible, but if you stop linking against it, it's *still* available under the GPL, then that's fine. It's silly (just dual-license it under the GPL to begin with), but you can just do the one-time-linking, remove it, and then remove the weird text (which is no longer relevant). But I don't know why they'd intend this. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the FSF's GPLv3 launch conference
The gang should better stop misstating the copyright act, to begin with. But actually it doesn't really matter given that Wallace is going to put the entire GPL'd code base into quasi public domain pretty soon anyway (antitrust violation - copyright misuse - quasi public domain/copyright impotence). http://www.ip-wars.net/public_docs/wallace_v_fsf_36.pdf regards, alexander.
Re: Is libreludedb DFSG compliant?
On Wed, 4 Jan 2006, Marco Franzen wrote: What if I don't want to link it? I may want to - just publish (parts of) the source code (or (of) a modified version) - modify it into something that isn't a library and publish the source - paste code fragments into an embedded/free-standing application (which does not link against anything, not even libc), maybe with some modifications to fit the new environment - copy code fragments into documentation Couldn't you just link it with something, putting it under the terms of the GPL, then unlink it, whereupon it's still under the terms of the GPL, then use it as above? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is libreludedb DFSG compliant?
Glenn Maynard wrote: On Thu, Jan 05, 2006 at 11:18:15AM +0100, Arnoud Engelfriet wrote: They may be worried about whether dynamic linking against their software creates a derivative work. With that language, they try to take away that worry. But they can't do that (at least not in any consistent way). Well, you can always make exceptions to the GPL (like the exception in the eCos license). And publicly saying I believe that the term 'derivative work' should be interpreted as follows surely has some effect? Now, if what they mean is this is available under the GPL once it's been linked against something GPL-compatible, but if you stop linking against it, it's *still* available under the GPL, then that's fine. That's what they are saying. I think they were trying to say if you want to link your software against ours, yours has to be GPL but it's a very strange wording. Not the strangest claim about the GPL I've seen by far though. Arnoud -- Arnoud Engelfriet, Dutch European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is libreludedb DFSG compliant?
On Thu, Jan 05, 2006 at 07:50:04PM +0100, Arnoud Engelfriet wrote: Well, you can always make exceptions to the GPL (like the exception in the eCos license). And publicly saying I believe Exceptions remove restrictions, not add them. It's saying, the work is under the GPL; and you also have permission to copy and do other things under these circumstances, too. That doesn't contradict the GPL itself. Saying it's under the GPL, except that you can't do this and that does. You can probably still do it, if you're careful, but the result isn't under the GPL at all, since you're removing permissions that the GPL ordinarily grants. that the term 'derivative work' should be interpreted as follows surely has some effect? I'd hope not. Derivative works are defined by copyright law. If you don't have any copyright claim to a work because it's not a derivative work of yours, you don't get to change that by redefining the term derivative work. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
Given this, I would like to once again suggest that the Pear Group consider removing the PHP License from their list of accepted licenses. As previously discussed, existing projects may take time to be relicensed, but I see no reason to allow new Pear projects to use the PHP License (which developers may blindly accept as the PHP default). We can only recommand to do not use it for pear. That is all I was hoping to ask. :-) Pear projects previously adopted the PHP License almost by default. If it is still problematic, then it should not be recommended. If you have strong feelings to the contrary, I would be most interested in hearing them. My hope is that in the long term we will be able to come to a solution that allows Debian to freely distribute the bulk of the Pear projects. But I somehow miss the point here, as all softwares using the PHP License will only be available through php.net, the legal issues having been solved, what is the current stopping point? Besides these clauses, they were already reported as non free but in no way illegal. I mean it is the reason why PHP is not GPL compatible but it does not make the PHP license illegal, or useless for packages available under the php.net umbrella. Or am I missing something? You are correct that the big illegalities were dealt with. But there some of the original problematic clauses still remain. I'll attempt to briefly summarize here. 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 [EMAIL PROTECTED] It is unclear whether this clause is even viable for PHP itself. This looks like something that should be handled by a trademark, not by a copyright. That said, this clause is only relevant when applied to PHP itself. What does it mean that the name 'PHP' must not be used to endorse or promote products derived from CodeGen_PECL? Does that mean that any derivitves of that package must modify the description which currently states CodeGen_PECL (formerly known as PECL_Gen) is a pure PHP replacement for the ext_skel shell script. Does the phrase pure PHP replacement use the name PHP to promote your product? I simply can't think of a single case in which it would even be desirable for a Pear package derivitive to be forbidden from using the name PHP for its endorsement or promotion. Regardless of what you think about the clause's applicibility to PHP itself, it is clearly absolutely irrelevant to Pear packages. 4. Products derived from this software may not be called PHP, nor may PHP appear in their name, without prior written permission from [EMAIL PROTECTED] You may indicate that your software works in conjunction with PHP by saying Foo for PHP instead of calling it PHP Foo or phpfoo The obvious intent of this clause is to prevent someone from making a derivitive of PHP and the calling it PHP Improved or SpeedyPHP. It is understandable that PHP wouldn't want any of its derivitives to be confused with the real PHP, or be incorrectly perceived as official improvements/extensions to PHP. But what does it mean when applied to Pear modules? If I make a derivitive of your Image_Transform package, I can't call it PHP_Image_Transform? Or take phpDocumentor, released under the PHP License. If I were to create a derivitive I would be forbidden from calling it phpDocumentor2 (even though the original was called phpDocumentor). No Pear program (nor any other program besides PHP) is aversely affected by a derivitive including PHP in its name. This clause simply is of no value to anything except for PHP itself. All right, that was probably more than you wanted to hear, but hopefully it makes things more clear. :-) Given that the only functionaly useful clauses in the PHP Licence when used by Pear programs are those in the BSD License, it seems reasonable to simply use that instead. Charles -- On curves ahead Remember, sonny That rabbit's foot Didn't save The bunny Burma-Shave http://burma-shave.org/jingles/1950/on_curves_ahead signature.asc Description: Digital signature
Re: the FSF's GPLv3 launch conference
quote who=Branden Robinson / Debian Project Leader date=Thu, Jan 05, 2006 at 02:37:47PM -0500 Don Armstrong and I are going to be at the FSF's GPLv3 launch conference[1] in Boston, Massachusetts on 16 and 17 January. I'll be there as well and will be happy to represent and communicate Debian's questions and comments as well. :) Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
PHP License
I just wanted to make sure that all relevant RC bugs were aware of the following debian-legal post by MJ Ray: The PHP licence could be OK for any software which has PHP Group contribution (regardless who is licensing later), but would require lying about other software. So, it is possible for others to use it 'freely' when PHP Group was involved upstream and avoid the problem you describe. Please leave the PHP licence bugs open for software which has no contribution by the PHP Group (which seems true for one or two pear packages IIRC). I don't think the PHP licence can be accepted as always-OK for others yet. http://lists.debian.org/debian-legal/2005/12/msg00142.html Of course his comments are not binding on Debian, but they do express a train of thought which has not been satisfactorily refuted on debian-legal. To summarize the long and continuing thread on Clarification regarding PHP License and DFSG status, there have been many comments questioning the freeness of the PHP License, but there has been no refutal to my proposal (agreed to by MJ above) that whatever the status of the PHP License in Debian, it be applied equally to PHP and PHP Group software. cheers, Charles -- A better buy -- why not try Burma-Shave http://burma-shave.org/jingles/1939/a_better_buy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is libreludedb DFSG compliant?
Marco Franzen wrote: Josh Triplett wrote: Mickael Profeta wrote: If you link LibPreludeDB against other code all of which is itself ^^^ licensed under the terms of the GNU General Public License version 2 dated June 1991 (GPL v2) or compatible, then you may use LibpreludeDB under the terms of the GPL v2,as appearing in the file COPYING. If the ^ file COPYING is missing, you can obtain a copy of the GPL v2 from the Free Software Foundation Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. This looks fine to me. What if I don't want to link it? I may want to - just publish (parts of) the source code (or (of) a modified version) - modify it into something that isn't a library and publish the source - paste code fragments into an embedded/free-standing application (which does not link against anything, not even libc), maybe with some modifications to fit the new environment - copy code fragments into documentation With the above I have no license to do any of that. I am not even sure I am allowed to make a private copy (jurisdiction dependency?). This may not look like a freeness issue because one could always do some trivial linking first to get the GPL grant. But if the code does not compile on any system available to me, then I have no licence to change it into something that I can compile and link... I think what the licensor really means is to license it under the GPL, so they should do just that rather than trying to paraphrase the GPL in one sentence or trying to grant the GPL licence conditionally or whatever it is they are trying there. I think they just mean to say that the GPL is not the LGPL. If they feel they really need to say that, they can do so outside the formal licence grant: use the standard This is free software... boilerplate and then add something not legally binding, like Note that the GNU GPL requires you... if they must. Although I'd prefer they didn't. Hmmm. When I read this statement, I interpreted link broadly here, in the sense which includes combinations with other code that do not necessarily involve invoking a linker. Furthermore, I read it not as you must link it with GPL or compatible software in order to be used under this license, but as for all software linked to it, that software must be GPL or compatible, making it still vacuously true that the software is GPL if linked with nothing else. Thus, the statement seemed compatible with (and redundant given) the GPL. If either of those two assumptions was not the intended reading of the statement, then I agree entirely with your argument that the statment renders the software non-free. In any case, yes, the simplest solution is to avoid making such explanations in a form that makes them look like additional conditions of the license. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: GR Proposal: GFDL statement
Stephane Bortzmeyer [EMAIL PROTECTED] But not all documentation is attached to a software. For instance, if I write a book Software development on Debian, releasing it under the GFDL is still the reasonable thing to do. It's reasonable if you want to attach adverts to it and allow others to do so, while witholding the freedom to edit or remove those adverts. If one wants to forbid all changes, then releasing under a CC-nd licence is a reasonable action. Not free software, though, which is what this list usually likes and a free software operating system should have free software manuals. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the FSF's GPLv3 launch conference [OT]
Alexander Terekhov wrote: The gang should better stop misstating the copyright act, to begin with. But actually it doesn't really matter given that Wallace is going to put the entire GPL'd code base into quasi public domain pretty soon anyway (antitrust violation - copyright misuse - quasi public domain/copyright impotence). http://www.ip-wars.net/public_docs/wallace_v_fsf_36.pdf (first, obligatory IANAL) I think this is unlikely, given that the plaintiff's claim there is based on a false assertion. Quoted from your cited document, page 4: [begin quote] The GPL term 2(b) also fixes the maximum price at no charge for the market value of a derivative or collective computer program thus created by the pooled code. All future third parties who accept the GPL copyright license must distribute their collaborative creations at no charge. [end quote] This is not true. 2(b) says that you must *license* work you derive from GPL'ed material and distribute for free, but section 1 specifically says You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. There is no limit specified on the fee that may be charged. Those interested in this case may note that this is the plaintiff's *fourth* amendment of his original complaint; the judge dismissed his third amended complaint without prejudice here: http://www.internetcases.com/library/cases/2005-11-28_wallace_v_fsf.pdf Some more references are available from Wikipedia: http://en.wikipedia.org/wiki/Daniel_Wallace_(plaintiff) -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the FSF's GPLv3 launch conference [OT]
On 1/5/06, Kevin B. McCarty [EMAIL PROTECTED] wrote: Alexander Terekhov wrote: The gang should better stop misstating the copyright act, to begin with. But actually it doesn't really matter given that Wallace is going to put the entire GPL'd code base into quasi public domain pretty soon anyway (antitrust violation - copyright misuse - quasi public domain/copyright impotence). http://www.ip-wars.net/public_docs/wallace_v_fsf_36.pdf (first, obligatory IANAL) I think this is unlikely, given that the plaintiff's claim there is based on a false assertion. It might sound false to you but only if you take it out of context which is cost of intellectual property and not cost of media, warranty, or whatnot. To quote the FSF's own brief (#35): By facilitating the development and distribution of software to consumers at no cost other than the cost of the media on which it is distributed, the GNU General Public License (GPL) ... violaties the antitrust laws. And even OSI knows it. The general counsel for the Open Source Initiative acknowledges in his recent treatise: There is also a problem that may prevent enforcement of the GPL's at no charge provision. It may be an illegal restraint of trade in some countries. Ordinarily, companies are allowed to set their own prices, and it is improper for a GPL licensor to restrain that in anyway. L. Rosen, Open Source Licensing 132 (2004), http://www.rosenlaw.com/Rosen_Ch06.pdf regards, alexander.
Re: GR Proposal: GFDL statement
On 1/5/06, MJ Ray [EMAIL PROTECTED] wrote: Stephane Bortzmeyer [EMAIL PROTECTED] But not all documentation is attached to a software. For instance, if I write a book Software development on Debian, releasing it under the GFDL is still the reasonable thing to do. It's reasonable if you want to attach adverts to it and allow others to do so, while witholding the freedom to edit or remove those adverts. If one wants to forbid all changes, then releasing under a CC-nd licence is. a reasonable action. Not free software, though, which is what this list usually likes and a free software operating system should have free software manuals. I've been a Debian user for eight years. I can count on one hand the number of times I've used proprietary software in all of that time; well, unless you count helping people out by answering their (MS Windows or MAC OS) questions or looking over their shoulder. I'm also working with Wikipedia, CC, FSF on licensing issues. I'm an academic scientist. I run a 70 processor cluster (Debian stable OpenSSI.) I do synthetic biology. I work on Personal Genomics; my mentor's article about the work is the cover story for January's Scientific American. I hate proprietary academic publishing, so, I'd like to see a pipeline from Academic Wikis to Academic Journals to Wikipedia. That pipeline will almost certainly be GFDL/CC-BY-SA. It's really sad to see blood boil over these licenses. Since I am talking to people at FSF CC regularly, I would be more than happy to bring Debian concerns to both groups in a, hopefuly, productive fashion.If there's a desire for that, just get in touch with me. Thanks, and Happy New Year, Sasha PS. I'm often on AIM/Google Talk as alexanderwait and or Freenode as asw or await. -- http://freelogy.org/wiki/User:AlexanderWait (GnuPG ID 4153 C516)
Re: Is libreludedb DFSG compliant?
Ken Arromdee wrote: On Wed, 4 Jan 2006, Marco Franzen wrote: What if I don't want to link it? I may want to - just publish (parts of) the source code (or (of) a modified version) - modify it into something that isn't a library and publish the source - paste code fragments into an embedded/free-standing application (which does not link against anything, not even libc), maybe with some modifications to fit the new environment - copy code fragments into documentation Couldn't you just link it with something, putting it under the terms of the GPL, then unlink it, whereupon it's still under the terms of the GPL, then use it as above? As I tried to say two paragraphs later, in order to link it it needs to compile first, and you cannot make changes to get it to compile before you have a license. OK, if you are lucky and it compiles for you without changes, you could take the GNU GPLv2 grant for your throw-away linking, remove the trigger condition and re-publish it under plain GNU GPLv2 for the rest of the world. However, there would still be some risk that they (or their successor in copyright) sue you for violation of their copyright, claiming that their If meant As long rather than Once. That it was not a trigger for a GNU GPLv2 grant but a grant of a modified license, namely the licence that results when you add their linking condition to the GNU GPLv2. This so-modified-GPL would not only be GNU-GPLv2 incompatible, but with this particular condition (IMHO) non-free: 1. It would /require/ linking against /some/ other code that is licensed both GNU-GPLv2 compatibly (to satisfy the added restriction) and so-modified-GPLv2 compatibly (so /its/ licensing allows this linking - the GNU GPLv2 itself does not). 2. It would /forbid/ linking against /any/ code that is /not/ licensed both GNU-GPLv2 compatibly and so-modified-GPL compatibly. The code linked against could for example be dually licensed GNU GPLv2 and so-modified GPL, or it could be under a single liberal licence. (Each of these two requirements would be non-free, IMHO. Having to link, as argued in the quoted paragraph. Having to licence your contributions more liberally than the original software would fail DFSG#3.) But I doubt they really mean any of that silliness. It might be possible to convince them to give a simple GNU GPLv2 grant. It might actually be what they meant to do in the first place. Some clarification seems necessary in any case. -- Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is libreludedb DFSG compliant?
Josh Triplett wrote: Marco Franzen wrote: Josh Triplett wrote: Mickael Profeta wrote: If you link LibPreludeDB against other code all of which is itself ^^^ licensed under the terms of the GNU General Public License version 2 dated June 1991 (GPL v2) or compatible, then you may use LibpreludeDB under the terms of the GPL v2,as appearing in the file COPYING. ^ This looks fine to me. What if I don't want to link it? I may want to [...] With the above I have no license to do any of that. I am not even sure I am allowed to make a private copy (jurisdiction dependency?). Hmmm. When I read this statement, I interpreted link broadly here, in the sense which includes combinations with other code that do not necessarily involve invoking a linker. When I hear someone talking about the GNU GPL, compatible licences and linking, I expect them to talk about differences between it and the GNU LGPL, about shared libraries and so on. Furthermore, I read it not as you must link it with GPL or compatible software in order to be used under this license, but as for all software linked to it, that software must be GPL or compatible, making it still vacuously true that the software is GPL if linked with nothing else. That may well be what they mean, but it is not what they say. (That is probably just a bug in the grant.) Thus, the statement seemed compatible with (and redundant given) the GPL. Yes, likely they mean just to restate parts of (what they think) the GNU GPLv2 itself says or means. In that case they should not refuse to just grant the GNU GPLv2 directly. If they did refuse then that would be suspicious. If either of those two assumptions was not the intended reading of the statement, then I agree entirely with your argument that the statment renders the software non-free. In any case, yes, the simplest solution is to avoid making such explanations in a form that makes them look like additional conditions of the license. - Josh Triplett Probably neither linking nor compatible has a clear enough meaning to be used without further explanation in a meaningful licence grant. Let's hope they'll adopt the standard boilerplate (ideally also avoiding mentioning the name of the software in the grant as the last minor nit). -- Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP License
Just to clarify the context of my previous message, in November Pierre from the Pear Group reported[1] that the PHP License was modified to address the most severe of our concerns about its freeness. The resultant license, unlike the previous version, appears to at least apply equally to PHP and other PHP Group software, such as Pear packages. While debian-legal still feels that the license remains problematic, and it is probably a good idea to encourage your upstream package maintainer to adopt a new license, it is not entirely clear whether or not these bugs are truly release critical, assuming that they deal with Pear packages, which I have not taken the time to verify. The PHP License clearly remains unacceptable for all non-PHP Group software. Charles 1. http://lists.debian.org/debian-legal/2005/11/msg00260.html -Original Message- From: Charles Fry [EMAIL PROTECTED] Subject: PHP License Date: Thu, 5 Jan 2006 16:10:33 -0500 I just wanted to make sure that all relevant RC bugs were aware of the following debian-legal post by MJ Ray: The PHP licence could be OK for any software which has PHP Group contribution (regardless who is licensing later), but would require lying about other software. So, it is possible for others to use it 'freely' when PHP Group was involved upstream and avoid the problem you describe. Please leave the PHP licence bugs open for software which has no contribution by the PHP Group (which seems true for one or two pear packages IIRC). I don't think the PHP licence can be accepted as always-OK for others yet. http://lists.debian.org/debian-legal/2005/12/msg00142.html Of course his comments are not binding on Debian, but they do express a train of thought which has not been satisfactorily refuted on debian-legal. To summarize the long and continuing thread on Clarification regarding PHP License and DFSG status, there have been many comments questioning the freeness of the PHP License, but there has been no refutal to my proposal (agreed to by MJ above) that whatever the status of the PHP License in Debian, it be applied equally to PHP and PHP Group software. cheers, Charles -- A better buy -- why not try Burma-Shave http://burma-shave.org/jingles/1939/a_better_buy -- Film protects Your neck And chin So your razor Won't dig in Burma-Shave http://burma-shave.org/jingles/1963/film_protects signature.asc Description: Digital signature
