Re: filebench: bison generated parser + CDDL
Hi Martin, Sorry about this, but I have no answers. If licens...@gnu.org does not answer, I don't know what else I could do. Akim Le 24 juil. 2012 à 16:34, Martin Steigerwald a écrit : Am Mittwoch, 4. Juli 2012 schrieb Akim Demaille: Hi all, Hi Akim and Brett, I have added Bret in CC, as he is the one to deal with licenses and exceptions. Any progress? Thanks, Martin Le 3 juil. 2012 à 09:47, Martin Steigerwald a écrit : Please keep Cc, as I am not subscribed to help-bison or filebench-developers. Dear bison developers, dear FSF licensing team, dear filebench developers, Alex Mestiashvili and I have packaged filebench for Debian. But now I wonder whether we may legally distribute it. Bison uses a bison generated parser from parser_gram.y and these generated files are: | Files: parser_gram.c parser_gram.h | Copyright: 1984, 1989, 1990, 2000-2011 Free Software Foundation, Inc. | | C LALR(1) parser skeleton written by Richard Stallman, by | simplifying the original so-called semantic parser. | | License: GPL-3+ with exception | This package is free software; you can redistribute it and/or modify | […] | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. | . | This special exception was added by the Free Software Foundation in | version 2.2 of Bison. Is this compatible with CDDL-1? If you fall into case one (you just use Bison the regular way), yes it is (IANAL, but that was a design goal when the exception was designed: Bison's output _can_ be used to produce proprietary software) As far as I understand CDDL-1 and GPL are not compatible, but when I read this special exception correctly, in the case that no new parser generator is done any terms, any license can be used for the resulting work. I asked this already on debian-legal and got an IANAL response back that indicates that the exception could be interpreted from its intent or its wording and this gives different results as to the redistributability of the software – see below. Dear FSF licensing team, dear bison developers, can you elaborate on that? If its not clearly redistributable then what changes could make it so? Thanks, Martin -- Weitergeleitete Nachricht -- Betreff: Re: filebench: bison generated parser + CDDL Datum: Samstag, 2. Juni 2012, 22:29:41 Von: Mark Weyer m...@weyer-zuhause.de An: debian-legal@lists.debian.org On Fri, Jun 01, 2012 at 01:45:06PM +0200, Martin Steigerwald wrote: Am Montag, 7. Mai 2012 schrieb Mark Weyer: Just a quick note: If you are right about the incompatibility of CDDL-1 and GPLv3 (others on this list will know if you are), then the combined work is non-free: Its license terms discriminate against a field of endeavour, namely developing a parser generator. I don´t understand this. I understand the exception | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. so that it allows distributing the software under any other license as long as the generated parser isn´t a parser generator in itself. I don´t think that the parser in here is a parser generator. As far as I understand parser_gram.c and parser_gram.h just parses loadable workload descriptions. Really, parse-gram.[ch] are invisible internal details about the implementation of Bison, that's not what we are referring to. Skeletons are the templates that are in data/ (yacc.c, glr.c, etc.) which are parameterized by bison (the executable). The exception is designed to state that as long as you use Bison as is, you don't have constraints. But if you modify skeletons or Bison itself, then the GPLv3 applies without the exception clause. It is less clear than I thought. Let A be a work with a parser generated by bison and assume that A is not a parser generator. It appears that the exception allows the authors of A to place A under any
Re: filebench: bison generated parser + CDDL
Am Dienstag, 31. Juli 2012 schrieb Akim Demaille: Hi Martin, Hi Akim, Sorry about this, but I have no answers. If licens...@gnu.org does not answer, I don't know what else I could do. Hmmm… Anyone a suggestion on how to move forward? Thanks, Martin Akim Le 24 juil. 2012 à 16:34, Martin Steigerwald a écrit : Am Mittwoch, 4. Juli 2012 schrieb Akim Demaille: Hi all, Hi Akim and Brett, I have added Bret in CC, as he is the one to deal with licenses and exceptions. Any progress? Thanks, Martin Le 3 juil. 2012 à 09:47, Martin Steigerwald a écrit : Please keep Cc, as I am not subscribed to help-bison or filebench-developers. Dear bison developers, dear FSF licensing team, dear filebench developers, Alex Mestiashvili and I have packaged filebench for Debian. But now I wonder whether we may legally distribute it. Bison uses a bison generated parser from parser_gram.y and these generated files are: | Files: parser_gram.c parser_gram.h | Copyright: 1984, 1989, 1990, 2000-2011 Free Software Foundation, Inc. | | C LALR(1) parser skeleton written by Richard Stallman, by | simplifying the original so-called semantic parser. | | License: GPL-3+ with exception | This package is free software; you can redistribute it and/or modify | […] | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. | . | This special exception was added by the Free Software Foundation in | version 2.2 of Bison. Is this compatible with CDDL-1? If you fall into case one (you just use Bison the regular way), yes it is (IANAL, but that was a design goal when the exception was designed: Bison's output _can_ be used to produce proprietary software) As far as I understand CDDL-1 and GPL are not compatible, but when I read this special exception correctly, in the case that no new parser generator is done any terms, any license can be used for the resulting work. I asked this already on debian-legal and got an IANAL response back that indicates that the exception could be interpreted from its intent or its wording and this gives different results as to the redistributability of the software – see below. Dear FSF licensing team, dear bison developers, can you elaborate on that? If its not clearly redistributable then what changes could make it so? Thanks, Martin -- Weitergeleitete Nachricht -- Betreff: Re: filebench: bison generated parser + CDDL Datum: Samstag, 2. Juni 2012, 22:29:41 Von: Mark Weyer m...@weyer-zuhause.de An: debian-legal@lists.debian.org On Fri, Jun 01, 2012 at 01:45:06PM +0200, Martin Steigerwald wrote: Am Montag, 7. Mai 2012 schrieb Mark Weyer: Just a quick note: If you are right about the incompatibility of CDDL-1 and GPLv3 (others on this list will know if you are), then the combined work is non-free: Its license terms discriminate against a field of endeavour, namely developing a parser generator. I don´t understand this. I understand the exception | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. so that it allows distributing the software under any other license as long as the generated parser isn´t a parser generator in itself. I don´t think that the parser in here is a parser generator. As far as I understand parser_gram.c and parser_gram.h just parses loadable workload descriptions. Really, parse-gram.[ch] are invisible internal details about the implementation of Bison, that's not what we are referring to. Skeletons are the templates that are in data/ (yacc.c, glr.c, etc.) which are parameterized by bison (the executable). The exception is designed to state that as long as you use Bison as is, you don't have constraints. But if you modify skeletons or Bison itself
Re: filebench: bison generated parser + CDDL
Am Mittwoch, 4. Juli 2012 schrieb Akim Demaille: Hi all, Hi Akim and Brett, I have added Bret in CC, as he is the one to deal with licenses and exceptions. Any progress? Thanks, Martin Le 3 juil. 2012 à 09:47, Martin Steigerwald a écrit : Please keep Cc, as I am not subscribed to help-bison or filebench-developers. Dear bison developers, dear FSF licensing team, dear filebench developers, Alex Mestiashvili and I have packaged filebench for Debian. But now I wonder whether we may legally distribute it. Bison uses a bison generated parser from parser_gram.y and these generated files are: | Files: parser_gram.c parser_gram.h | Copyright: 1984, 1989, 1990, 2000-2011 Free Software Foundation, Inc. | | C LALR(1) parser skeleton written by Richard Stallman, by | simplifying the original so-called semantic parser. | | License: GPL-3+ with exception | This package is free software; you can redistribute it and/or modify | […] | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. | . | This special exception was added by the Free Software Foundation in | version 2.2 of Bison. Is this compatible with CDDL-1? If you fall into case one (you just use Bison the regular way), yes it is (IANAL, but that was a design goal when the exception was designed: Bison's output _can_ be used to produce proprietary software) As far as I understand CDDL-1 and GPL are not compatible, but when I read this special exception correctly, in the case that no new parser generator is done any terms, any license can be used for the resulting work. I asked this already on debian-legal and got an IANAL response back that indicates that the exception could be interpreted from its intent or its wording and this gives different results as to the redistributability of the software – see below. Dear FSF licensing team, dear bison developers, can you elaborate on that? If its not clearly redistributable then what changes could make it so? Thanks, Martin -- Weitergeleitete Nachricht -- Betreff: Re: filebench: bison generated parser + CDDL Datum: Samstag, 2. Juni 2012, 22:29:41 Von: Mark Weyer m...@weyer-zuhause.de An: debian-legal@lists.debian.org On Fri, Jun 01, 2012 at 01:45:06PM +0200, Martin Steigerwald wrote: Am Montag, 7. Mai 2012 schrieb Mark Weyer: Just a quick note: If you are right about the incompatibility of CDDL-1 and GPLv3 (others on this list will know if you are), then the combined work is non-free: Its license terms discriminate against a field of endeavour, namely developing a parser generator. I don´t understand this. I understand the exception | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. so that it allows distributing the software under any other license as long as the generated parser isn´t a parser generator in itself. I don´t think that the parser in here is a parser generator. As far as I understand parser_gram.c and parser_gram.h just parses loadable workload descriptions. Really, parse-gram.[ch] are invisible internal details about the implementation of Bison, that's not what we are referring to. Skeletons are the templates that are in data/ (yacc.c, glr.c, etc.) which are parameterized by bison (the executable). The exception is designed to state that as long as you use Bison as is, you don't have constraints. But if you modify skeletons or Bison itself, then the GPLv3 applies without the exception clause. It is less clear than I thought. Let A be a work with a parser generated by bison and assume that A is not a parser generator. It appears that the exception allows the authors of A to place A under any license they want to, effectively overriding the GPL-and-exception. Suppose they choose something like the MIT
Re: filebench: bison generated parser + CDDL
Hi all, I have added Bret in CC, as he is the one to deal with licenses and exceptions. Le 3 juil. 2012 à 09:47, Martin Steigerwald a écrit : Please keep Cc, as I am not subscribed to help-bison or filebench-developers. Dear bison developers, dear FSF licensing team, dear filebench developers, Alex Mestiashvili and I have packaged filebench for Debian. But now I wonder whether we may legally distribute it. Bison uses a bison generated parser from parser_gram.y and these generated files are: | Files: parser_gram.c parser_gram.h | Copyright: 1984, 1989, 1990, 2000-2011 Free Software Foundation, Inc. | C LALR(1) parser skeleton written by Richard Stallman, by | simplifying the original so-called semantic parser. | License: GPL-3+ with exception | This package is free software; you can redistribute it and/or modify | […] | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. | . | This special exception was added by the Free Software Foundation in | version 2.2 of Bison. Is this compatible with CDDL-1? If you fall into case one (you just use Bison the regular way), yes it is (IANAL, but that was a design goal when the exception was designed: Bison's output _can_ be used to produce proprietary software) As far as I understand CDDL-1 and GPL are not compatible, but when I read this special exception correctly, in the case that no new parser generator is done any terms, any license can be used for the resulting work. I asked this already on debian-legal and got an IANAL response back that indicates that the exception could be interpreted from its intent or its wording and this gives different results as to the redistributability of the software – see below. Dear FSF licensing team, dear bison developers, can you elaborate on that? If its not clearly redistributable then what changes could make it so? Thanks, Martin -- Weitergeleitete Nachricht -- Betreff: Re: filebench: bison generated parser + CDDL Datum: Samstag, 2. Juni 2012, 22:29:41 Von: Mark Weyer m...@weyer-zuhause.de An: debian-legal@lists.debian.org On Fri, Jun 01, 2012 at 01:45:06PM +0200, Martin Steigerwald wrote: Am Montag, 7. Mai 2012 schrieb Mark Weyer: Just a quick note: If you are right about the incompatibility of CDDL-1 and GPLv3 (others on this list will know if you are), then the combined work is non-free: Its license terms discriminate against a field of endeavour, namely developing a parser generator. I don´t understand this. I understand the exception | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. so that it allows distributing the software under any other license as long as the generated parser isn´t a parser generator in itself. I don´t think that the parser in here is a parser generator. As far as I understand parser_gram.c and parser_gram.h just parses loadable workload descriptions. Really, parse-gram.[ch] are invisible internal details about the implementation of Bison, that's not what we are referring to. Skeletons are the templates that are in data/ (yacc.c, glr.c, etc.) which are parameterized by bison (the executable). The exception is designed to state that as long as you use Bison as is, you don't have constraints. But if you modify skeletons or Bison itself, then the GPLv3 applies without the exception clause. It is less clear than I thought. Let A be a work with a parser generated by bison and assume that A is not a parser generator. It appears that the exception allows the authors of A to place A under any license they want to, effectively overriding the GPL-and-exception. Suppose they choose something like the MIT license. Then they, or someone else, retrieves the parser skeleton (now under the MIT license) from A and uses it as a parser skeleton for a commercial parser generator B. The exception is clearly not intended
Re: filebench: bison generated parser + CDDL
Am Samstag, 2. Juni 2012 schrieb Mark Weyer: On Fri, Jun 01, 2012 at 01:45:06PM +0200, Martin Steigerwald wrote: Am Montag, 7. Mai 2012 schrieb Mark Weyer: Just a quick note: If you are right about the incompatibility of CDDL-1 and GPLv3 (others on this list will know if you are), then the combined work is non-free: Its license terms discriminate against a field of endeavour, namely developing a parser generator. I don´t understand this. I understand the exception | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. so that it allows distributing the software under any other license as long as the generated parser isn´t a parser generator in itself. I don´t think that the parser in here is a parser generator. As far as I understand parser_gram.c and parser_gram.h just parses loadable workload descriptions. It is less clear than I thought. […] The true question is, of course, whether a court would judge in favour of the exception's letter or its intent. If it judges in favour of its intent: Taking the CDDL'ed filebench for A and some modified version B of A, by copyleft (of both the GPL-and-exception and the CDDL) we have the same license situation in B as in A. Now if B is as above, the exception is not applicable and thus (assuming that GPL and CDDL are incompatible) B is not distributable. Thus the combined licenses forbid distribution of (some) modified versions and the package is non-free. If the court judges in favour of the exception's letter, then your upstream can put parser_gram.c and parser_gram.h under the CDDL and everything is fine (You can't do that yourself, because A: the exception grants that right only to the creator of the larger work and B: if upstream does not exercise the right of the exception, then they do not have the right to distribute filebench under anything other than the GPL.) I am not a lawyer, this is not legal advice, et cetera. Thanks a lot for your detailed explaination. I forwarded the question upstream and to the FSF licensing team. (See my other mail, I kept debian-legal in Cc.) Ciao, -- Martin Steigerwald - teamix GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207030949.27903...@teamix.de
Fwd: Re: filebench: bison generated parser + CDDL
Sorry, forgot to Cc debian-legal mailing list. Please keep Cc, as I am not subscribed to help-bison or filebench-developers. Dear bison developers, dear FSF licensing team, dear filebench developers, Alex Mestiashvili and I have packaged filebench for Debian. But now I wonder whether we may legally distribute it. Bison uses a bison generated parser from parser_gram.y and these generated files are: | Files: parser_gram.c parser_gram.h | Copyright: 1984, 1989, 1990, 2000-2011 Free Software Foundation, Inc. | C LALR(1) parser skeleton written by Richard Stallman, by | simplifying the original so-called semantic parser. | License: GPL-3+ with exception | This package is free software; you can redistribute it and/or modify | […] | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. | . | This special exception was added by the Free Software Foundation in | version 2.2 of Bison. Is this compatible with CDDL-1? As far as I understand CDDL-1 and GPL are not compatible, but when I read this special exception correctly, in the case that no new parser generator is done any terms, any license can be used for the resulting work. I asked this already on debian-legal and got an IANAL response back that indicates that the exception could be interpreted from its intent or its wording and this gives different results as to the redistributability of the software – see below. Dear FSF licensing team, dear bison developers, can you elaborate on that? If its not clearly redistributable then what changes could make it so? Thanks, Martin -- Weitergeleitete Nachricht -- Betreff: Re: filebench: bison generated parser + CDDL Datum: Samstag, 2. Juni 2012, 22:29:41 Von: Mark Weyer m...@weyer-zuhause.de An: debian-legal@lists.debian.org On Fri, Jun 01, 2012 at 01:45:06PM +0200, Martin Steigerwald wrote: Am Montag, 7. Mai 2012 schrieb Mark Weyer: Just a quick note: If you are right about the incompatibility of CDDL-1 and GPLv3 (others on this list will know if you are), then the combined work is non-free: Its license terms discriminate against a field of endeavour, namely developing a parser generator. I don´t understand this. I understand the exception | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. so that it allows distributing the software under any other license as long as the generated parser isn´t a parser generator in itself. I don´t think that the parser in here is a parser generator. As far as I understand parser_gram.c and parser_gram.h just parses loadable workload descriptions. It is less clear than I thought. Let A be a work with a parser generated by bison and assume that A is not a parser generator. It appears that the exception allows the authors of A to place A under any license they want to, effectively overriding the GPL-and-exception. Suppose they choose something like the MIT license. Then they, or someone else, retrieves the parser skeleton (now under the MIT license) from A and uses it as a parser skeleton for a commercial parser generator B. The exception is clearly not intended to allow that. Reading its letter, I do not see that it actually achieves that intent. How I read the exception on May 7, I thought that it would not be deleted by relicensing, but that its requirement would persist in all modified version of A. Which is the only way (I can see) that the exception achieves its intent. The true question is, of course, whether a court would judge in favour of the exception's letter or its intent. If it judges in favour of its intent: Taking the CDDL'ed filebench for A and some modified version B of A, by copyleft (of both the GPL-and-exception and the CDDL) we have the same license situation in B as in A. Now if B is as above, the exception is not applicable and thus (assuming that GPL and CDDL are incompatible) B is not distributable. Thus the combined licenses forbid
Re: filebench: bison generated parser + CDDL
On Fri, Jun 01, 2012 at 01:45:06PM +0200, Martin Steigerwald wrote: Am Montag, 7. Mai 2012 schrieb Mark Weyer: Just a quick note: If you are right about the incompatibility of CDDL-1 and GPLv3 (others on this list will know if you are), then the combined work is non-free: Its license terms discriminate against a field of endeavour, namely developing a parser generator. I don´t understand this. I understand the exception | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. so that it allows distributing the software under any other license as long as the generated parser isn´t a parser generator in itself. I don´t think that the parser in here is a parser generator. As far as I understand parser_gram.c and parser_gram.h just parses loadable workload descriptions. It is less clear than I thought. Let A be a work with a parser generated by bison and assume that A is not a parser generator. It appears that the exception allows the authors of A to place A under any license they want to, effectively overriding the GPL-and-exception. Suppose they choose something like the MIT license. Then they, or someone else, retrieves the parser skeleton (now under the MIT license) from A and uses it as a parser skeleton for a commercial parser generator B. The exception is clearly not intended to allow that. Reading its letter, I do not see that it actually achieves that intent. How I read the exception on May 7, I thought that it would not be deleted by relicensing, but that its requirement would persist in all modified version of A. Which is the only way (I can see) that the exception achieves its intent. The true question is, of course, whether a court would judge in favour of the exception's letter or its intent. If it judges in favour of its intent: Taking the CDDL'ed filebench for A and some modified version B of A, by copyleft (of both the GPL-and-exception and the CDDL) we have the same license situation in B as in A. Now if B is as above, the exception is not applicable and thus (assuming that GPL and CDDL are incompatible) B is not distributable. Thus the combined licenses forbid distribution of (some) modified versions and the package is non-free. If the court judges in favour of the exception's letter, then your upstream can put parser_gram.c and parser_gram.h under the CDDL and everything is fine (You can't do that yourself, because A: the exception grants that right only to the creator of the larger work and B: if upstream does not exercise the right of the exception, then they do not have the right to distribute filebench under anything other than the GPL.) I am not a lawyer, this is not legal advice, et cetera. Mark Weyer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602202941.GA1911@debian
Re: filebench: bison generated parser + CDDL
Hi! Am Montag, 7. Mai 2012 schrieb Martin Steigerwald: Hi! Alex and I almost finished packaging filebench: VCS is at: Vcs-Git: git://git.debian.org/collab-maint/filebench.git Vcs-Browser: http://git.debian.org/?p=collab-maint/filebench.git;a=summary There is some licensing questions left: 1) Most files use: * CDDL HEADER START * * The contents of this file are subject to the terms of the * Common Development and Distribution License (the License). * You may not use this file except in compliance with the License. * * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE * or http://www.opensolaris.org/os/licensing. * See the License for the specific language governing permissions * and limitations under the License. * * When distributing Covered Code, include this CDDL HEADER in each * file and include the License file at usr/src/OPENSOLARIS.LICENSE. * If applicable, add the following below this CDDL HEADER, with the * fields enclosed by brackets [] replaced with your own identifying * information: Portions Copyright [] [name of copyright owner] * * CDDL HEADER END template header. Is it safe to assume that this refers to CDDL-1.0 as in: http://opensource.org/licenses/CDDL-1.0 Well http://hub.opensolaris.org/bin/download/Main/licensing/cddllicense.txt refers to that version of the license as well. So that seems to be the case. Except for this notice: NOTICE PURSUANT TO SECTION 9 OF THE COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) The OpenSolaris code released under the CDDL shall be governed by the laws of the State of California (excluding conflict-of-law provisions). Any litigation relating to this License shall be subject to the jurisdiction of the Federal Courts of the Northern District of California and the state courts of the State of California, with venue lying in Santa Clara County, California. 2) It uses a bison generated parser from parser_gram.y and these generated files are: Files: parser_gram.c parser_gram.h Copyright: 1984, 1989, 1990, 2000-2011 Free Software Foundation, Inc. C LALR(1) parser skeleton written by Richard Stallman, by simplifying the original so-called semantic parser. License: GPL-3+ with exception This package is free software; you can redistribute it and/or modify […] You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/ . On Debian systems, the complete text of the GNU General Public License version 3 can be found in /usr/share/common-licenses/GPL-3. . As a special exception, you may create a larger work that contains part or all of the Bison parser skeleton and distribute that work under terms of your choice, so long as that work isn't itself a parser generator using the skeleton or a modified version thereof as a parser skeleton. Alternatively, if you modify or redistribute the parser skeleton itself, you may (at your option) remove this special exception, which will cause the skeleton and the resulting Bison output files to be licensed under the GNU General Public License without this special exception. . This special exception was added by the Free Software Foundation in version 2.2 of Bison. Is this compatible with CDDL-1? As far as I understand CDDL-1 and GPL are not compatible, but when I read this special exception correctly, in the case that no new parser generator is done any terms, any license can be used for the resulting work. Would it make sense to include an URL to the license in the copyright file? I did not see an extra field in the machine readable file format description, but I could always include it at the end of the license text if thats wanted. Any answer on that one that allows Alex and me to proceed? Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206011338.12181.mar...@lichtvoll.de
Re: filebench: bison generated parser + CDDL
Hi Mark! Am Montag, 7. Mai 2012 schrieb Mark Weyer: As far as I understand CDDL-1 and GPL are not compatible, but when I read this special exception correctly, in the case that no new parser generator is done any terms, any license can be used for the resulting work. Just a quick note: If you are right about the incompatibility of CDDL-1 and GPLv3 (others on this list will know if you are), then the combined work is non-free: Its license terms discriminate against a field of endeavour, namely developing a parser generator. I don´t understand this. I understand the exception | As a special exception, you may create a larger work that contains | part or all of the Bison parser skeleton and distribute that work | under terms of your choice, so long as that work isn't itself a | parser generator using the skeleton or a modified version thereof | as a parser skeleton. Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. so that it allows distributing the software under any other license as long as the generated parser isn´t a parser generator in itself. I don´t think that the parser in here is a parser generator. As far as I understand parser_gram.c and parser_gram.h just parses loadable workload descriptions. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206011345.07099.mar...@lichtvoll.de
filebench: bison generated parser + CDDL
Hi! Alex and I almost finished packaging filebench: VCS is at: Vcs-Git: git://git.debian.org/collab-maint/filebench.git Vcs-Browser: http://git.debian.org/?p=collab-maint/filebench.git;a=summary There is some licensing questions left: 1) Most files use: * CDDL HEADER START * * The contents of this file are subject to the terms of the * Common Development and Distribution License (the License). * You may not use this file except in compliance with the License. * * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE * or http://www.opensolaris.org/os/licensing. * See the License for the specific language governing permissions * and limitations under the License. * * When distributing Covered Code, include this CDDL HEADER in each * file and include the License file at usr/src/OPENSOLARIS.LICENSE. * If applicable, add the following below this CDDL HEADER, with the * fields enclosed by brackets [] replaced with your own identifying * information: Portions Copyright [] [name of copyright owner] * * CDDL HEADER END template header. Is it safe to assume that this refers to CDDL-1.0 as in: http://opensource.org/licenses/CDDL-1.0 Well http://hub.opensolaris.org/bin/download/Main/licensing/cddllicense.txt refers to that version of the license as well. So that seems to be the case. Except for this notice: NOTICE PURSUANT TO SECTION 9 OF THE COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) The OpenSolaris code released under the CDDL shall be governed by the laws of the State of California (excluding conflict-of-law provisions). Any litigation relating to this License shall be subject to the jurisdiction of the Federal Courts of the Northern District of California and the state courts of the State of California, with venue lying in Santa Clara County, California. 2) It uses a bison generated parser from parser_gram.y and these generated files are: Files: parser_gram.c parser_gram.h Copyright: 1984, 1989, 1990, 2000-2011 Free Software Foundation, Inc. C LALR(1) parser skeleton written by Richard Stallman, by simplifying the original so-called semantic parser. License: GPL-3+ with exception This package is free software; you can redistribute it and/or modify […] You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/ . On Debian systems, the complete text of the GNU General Public License version 3 can be found in /usr/share/common-licenses/GPL-3. . As a special exception, you may create a larger work that contains part or all of the Bison parser skeleton and distribute that work under terms of your choice, so long as that work isn't itself a parser generator using the skeleton or a modified version thereof as a parser skeleton. Alternatively, if you modify or redistribute the parser skeleton itself, you may (at your option) remove this special exception, which will cause the skeleton and the resulting Bison output files to be licensed under the GNU General Public License without this special exception. . This special exception was added by the Free Software Foundation in version 2.2 of Bison. Is this compatible with CDDL-1? As far as I understand CDDL-1 and GPL are not compatible, but when I read this special exception correctly, in the case that no new parser generator is done any terms, any license can be used for the resulting work. Would it make sense to include an URL to the license in the copyright file? I did not see an extra field in the machine readable file format description, but I could always include it at the end of the license text if thats wanted. Thanks, -- Martin Steigerwald - teamix GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205071243.02440...@teamix.de
filebench: bison generated parser + CDDL
Also sent to ITP bug for documentation. Hi! Alex and I almost finished packaging filebench: VCS is at: Vcs-Git: git://git.debian.org/collab-maint/filebench.git Vcs-Browser: http://git.debian.org/?p=collab-maint/filebench.git;a=summary There is some licensing questions left: 1) Most files use: * CDDL HEADER START * * The contents of this file are subject to the terms of the * Common Development and Distribution License (the License). * You may not use this file except in compliance with the License. * * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE * or http://www.opensolaris.org/os/licensing. * See the License for the specific language governing permissions * and limitations under the License. * * When distributing Covered Code, include this CDDL HEADER in each * file and include the License file at usr/src/OPENSOLARIS.LICENSE. * If applicable, add the following below this CDDL HEADER, with the * fields enclosed by brackets [] replaced with your own identifying * information: Portions Copyright [] [name of copyright owner] * * CDDL HEADER END template header. Is it safe to assume that this refers to CDDL-1.0 as in: http://opensource.org/licenses/CDDL-1.0 Well http://hub.opensolaris.org/bin/download/Main/licensing/cddllicense.txt refers to that version of the license as well. So that seems to be the case. Except for this notice: NOTICE PURSUANT TO SECTION 9 OF THE COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) The OpenSolaris code released under the CDDL shall be governed by the laws of the State of California (excluding conflict-of-law provisions). Any litigation relating to this License shall be subject to the jurisdiction of the Federal Courts of the Northern District of California and the state courts of the State of California, with venue lying in Santa Clara County, California. 2) It uses a bison generated parser from parser_gram.y and these generated files are: Files: parser_gram.c parser_gram.h Copyright: 1984, 1989, 1990, 2000-2011 Free Software Foundation, Inc. C LALR(1) parser skeleton written by Richard Stallman, by simplifying the original so-called semantic parser. License: GPL-3+ with exception This package is free software; you can redistribute it and/or modify […] You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/ . On Debian systems, the complete text of the GNU General Public License version 3 can be found in /usr/share/common-licenses/GPL-3. . As a special exception, you may create a larger work that contains part or all of the Bison parser skeleton and distribute that work under terms of your choice, so long as that work isn't itself a parser generator using the skeleton or a modified version thereof as a parser skeleton. Alternatively, if you modify or redistribute the parser skeleton itself, you may (at your option) remove this special exception, which will cause the skeleton and the resulting Bison output files to be licensed under the GNU General Public License without this special exception. . This special exception was added by the Free Software Foundation in version 2.2 of Bison. Is this compatible with CDDL-1? As far as I understand CDDL-1 and GPL are not compatible, but when I read this special exception correctly, in the case that no new parser generator is done any terms, any license can be used for the resulting work. Would it make sense to include an URL to the license in the copyright file? I did not see an extra field in the machine readable file format description, but I could always include it at the end of the license text if thats wanted. Thanks, -- Martin Steigerwald - teamix GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205071246.42524...@teamix.de
Re: filebench: bison generated parser + CDDL
As far as I understand CDDL-1 and GPL are not compatible, but when I read this special exception correctly, in the case that no new parser generator is done any terms, any license can be used for the resulting work. Just a quick note: If you are right about the incompatibility of CDDL-1 and GPLv3 (others on this list will know if you are), then the combined work is non-free: Its license terms discriminate against a field of endeavour, namely developing a parser generator. I am not a lawyer. Hope this helps, Mark Weyer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120507120813.GA1864@debian
Re: CDDL/GPL and Nexenta (with CDDL libc)
* Don Armstrong: You're conflating GPLv2 with v3. They are very different with regards to the System Library exception, as I explained in my original message. Please consider rereading it and pointing out precisely where I have misread the license along with supporting quotations from the licence itself if you feel that I am misrepresenting the ramifications of GPLv3'd works in regards to the System Library exception when linking to a CDDL'ed libc. Okay, let's review this paragraph: | The System Libraries of an executable work include anything, other | than the work as a whole, that (a) is included in the normal form of | packaging a Major Component, but which is not part of that Major | Component, and (b) serves only to enable use of the work with that | Major Component, or to implement a Standard Interface for which an | implementation is available to the public in source code form. A | Major Component, in this context, means a major essential component | (kernel, window system, and so on) of the specific operating system | (if any) on which the executable work runs, or a compiler used to | produce the work, or an object code interpreter used to run it. libc is part of the Debian base system, which is a Major Component. libc is normally included in the base system. It is a required part of the base system. So case (a) does not apply. I would agree that the language in draft 2 of GPL version 3 would have covered a CDDL libc. But that language was deemed unacceptable because it would have included OpenSSL, too. So it has to be changed. Whether the changes where done in such a way to exclude a CDDL libc, too, I don't know. The FSF FAQ does not shed light on this issue, either. There's another problem: the System Libraries clause only waives the need to provide source code. The requirement to license a modified work (including its source code), as a whole, under the GPL remains in effect. Now the CDDL requires that the license for the Executable form does not attempt to limit or alter the recipient’s rights in the Source Code form from the rights set forth in this License, and it is quite difficult to tell if a GPL/CDDL agglomerate isn't trying to do precisely that (due to the patent-related provisions in the GPL). -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oc3mo24g@mid.deneb.enyo.de
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Thu, 23 Sep 2010 23:42:07 +0200 Josselin Mouette wrote: [...] The constraints for a CDDL’ed OS are the same as for a proprietary one. This looks correct to me, since I am personally convinced that CDDL'ed works fail to comply with the DFSG and are therefore non-free... My detailed analysis is here: http://lists.debian.org/debian-legal/2005/09/msg00206.html -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpsdZDFuHYAm.pgp Description: PGP signature
Re: CDDL/GPL and Nexenta (with CDDL libc)
This one time, at band camp, Florian Weimer said: * Don Armstrong: CDDL'ed libc (and other System Library) and GPLv3+ work: OK I think the FSF wants us not to be able to use the System Library exception. It is only intended for proprietary operating systems. Does no one else see a license exception that is easier for a proprietary OS than a free one as problematic? -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: CDDL/GPL and Nexenta (with CDDL libc)
Le jeudi 23 septembre 2010 à 20:42 +0100, Stephen Gran a écrit : This one time, at band camp, Florian Weimer said: * Don Armstrong: CDDL'ed libc (and other System Library) and GPLv3+ work: OK I think the FSF wants us not to be able to use the System Library exception. It is only intended for proprietary operating systems. Does no one else see a license exception that is easier for a proprietary OS than a free one as problematic? Well, it would be if that was the case. But if a proprietary software vendor wanted to distribute a GPL program built on proprietary libraries, he could not. The constraints for a CDDL’ed OS are the same as for a proprietary one. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Wed, 22 Sep 2010, Florian Weimer wrote: * Don Armstrong: CDDL'ed libc (and other System Library) and GPLv3+ work: OK I think the FSF wants us not to be able to use the System Library exception. It is only intended for proprietary operating systems. It's intended for cases where you're running a GPLed work on a system which is GPL-incompatible. The FSF also unconditionally labels the CDDL als GPL-incompatible (although it is not clear if the license overview was thoroughly updated for GPL version 3). They're referring to the common case where the System Library exception is not invoked. There used to be a GNU libc port to the SunOS kernel. Perhaps the Nexenta folks can revive that? My suggestion was to link GPLed binaries to such a libc which circumvents most of these problems. However, because of design considerations, the libc-kernel interface is not as stable in SunOS as it is in linux, which makes this a long-term labor intensive process. Don Armstrong -- Nearly all men can stand adversity, but if you really want to test his character, give him power. -- Abraham Lincoln http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100924001854.gk6...@teltox.donarmstrong.com
Re: CDDL/GPL and Nexenta (with CDDL libc)
* Don Armstrong: CDDL'ed libc (and other System Library) and GPLv3+ work: OK I think the FSF wants us not to be able to use the System Library exception. It is only intended for proprietary operating systems. The FSF also unconditionally labels the CDDL als GPL-incompatible (although it is not clear if the license overview was thoroughly updated for GPL version 3). There used to be a GNU libc port to the SunOS kernel. Perhaps the Nexenta folks can revive that? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4mdhe2q@mid.deneb.enyo.de
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Fri, Sep 3, 2010 at 9:21 AM, Anil Gulecha a...@nexenta.org wrote: * I would like to understand further the rational behind using the distribution of libraries boundary at Debian project level, rather than at a package/binary level, which seems a more natural fit for delineation. Simply because accompanies is open to interpretation. Clearly a Win32 binary downloaded from ftp.gnome.org does not accompany Microsoft Windows. It isn't quite as clear that an ELF executable in the gimp binary package on a Debian CD does not accompany the ELF executables in the libc6 package. * If we do choose the entire project as the boundary, then in the specific case of packages that are GPLv2 only (linking with libc), we have been considering building these with a statically linked, license compatible libc (one of the small implementations). I would also like to hear your thoughts on this as a technical/legal solution. That sounds problematic to get right for every package in the archive (I'm thinking about the license compatibility nightmares caused by OpenSSL). BTW, whatever happened to Debian GNU/kOpenSolaris? http://csclub.uwaterloo.ca/~dtbartle/opensolaris/ Also, what would be the upstream of a possible Debian OpenSolaris based port? I read that Oracle is closing down OpenSolaris and moving development behind closed doors. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=1zykz2konnrdvjxfwm51fhlaux41bg9+l+...@mail.gmail.com
Re: CDDL/GPL and Nexenta (with CDDL libc)
Also, what would be the upstream of a possible Debian OpenSolaris based port? I read that Oracle is closing down OpenSolaris and moving development behind closed doors. Illumos will be the upstream. Illumos project started out as a branch of OpenSolaris code, but is now effectively a fork of OpenSolaris codebase. As an added positive, it is replacing all of the closed bits (previously distributed as binary blobs) with open code. A major portion of this is already done. Site: https://www.illumos.org Note: It is the current understanding that development will be within Oracle, but the code itself will be opened after binary releases.. so we'll mostly see a big drop of code after every solaris release. Regards Anil http://www.nexenta.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimkz=a2corftooxb-prdr7cypgp13x-bp+6j...@mail.gmail.com
Re: CDDL/GPL and Nexenta (with CDDL libc)
Anil Gulecha a...@nexenta.org writes: Illumos will be the upstream. Illumos project started out as a branch of OpenSolaris code, but is now effectively a fork of OpenSolaris codebase. I don't understand the distinction being made there. What is different between “a branch of the code” versus “a fork of the codebase”? As an added positive, it is replacing all of the closed bits (previously distributed as binary blobs) with open code. A major portion of this is already done. Great news, I'm glad people are enthusiastic enough to make a free software version of this code. -- \ “We must find our way to a time when faith, without evidence, | `\disgraces anyone who would claim it.” —Sam Harris, _The End of | _o__) Faith_, 2004 | Ben Finney -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aanzfgyl@benfinney.id.au
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Fri, Sep 3, 2010 at 12:31 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Anil Gulecha a...@nexenta.org writes: Illumos will be the upstream. Illumos project started out as a branch of OpenSolaris code, but is now effectively a fork of OpenSolaris codebase. I don't understand the distinction being made there. What is different between “a branch of the code” versus “a fork of the codebase”? The idea initally was not to explicitly be a fork (go on a different development path). lllumos was to follow OpenSolaris closely, except replacing closed binaries and maintaining drivers upstream may drop. I guess you can technically call this a fork.. but the idea was to be close. Now, Illumos has no real upstream, and is maintaining the last code drop, and will merge changes from future code drops. Regards, Anil http://www.gulecha.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin4zialo42xm8i7rpx+yng-n7sxtonj=-w_9...@mail.gmail.com
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Fri Sep 03 14:04, Paul Wise wrote: BTW, whatever happened to Debian GNU/kOpenSolaris? http://csclub.uwaterloo.ca/~dtbartle/opensolaris/ How would the licence interactions work here, with a CDDL kernel and a GPL libc/userland? Does the fact that it's specifically the kernel satisfy the exceptions in the GPL? Matt signature.asc Description: Digital signature
CDDL/GPL and Nexenta (with CDDL libc)
In the course of Debconf10, I was asked a few questions about CDDL'ed libc, Nexenta, GPLed works and what would be necessary to have GPLed works which linked to a CDDLed libc so Nexenta could possibly become a Debian port. To make sure I haven't lept off the edge; I just wanted to run this by everyone. The quick ruberic is the following: CDDL'ed libc (and other System Library) and GPLv3+ work: OK CDDL'ed libc (and other System Library) and GPLv2 work: Probably Not OK * and GPLv2+ work + CDDL work (non-System Library): Not OK More lengthly explanation: The real question for GPLed works which link to solaris libc is whether or not solaris libc fits in with the system library exception. It's my understanding that for GPLv2 and v3, if you're not shipping the system library yourself, you don't need to concern yourself with license compatibility, and can just ship it anyway. This isn't the case for Debian or Nextenta, though, so we don't even need to contemplate it. For GPLv2 (not GPLv2+), the situtation when you are shipping both is more difficult; the key question here is what the precise meaning is of 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. My understanding is that for GPLv2, that means that we must also have the source, and we must ship it in compliance with the GPL, which we cannot do with CDDL works. [The critical aspect here is what precisely is meant by accompanies the executable, we've long assumed[1] that Debian's distribution of libraries means that they are accompanying the executable.] For GPLv3 (and GPLv2+, where we can choose GPLv3), the critical question is whether libc is a System Library. The System Libraries of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A Major Component, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. So, starting from the bottom, it's clear that libc is a majorq essential component of the OS. It implements a Standard Interface for which we have source code. The remaining question is what precisely is meant by subpart (a); I believe that libc is included with the C compiler or kernel Major Component, but isn't itself the kernel or compiler. So I believe that in the case of a libc licensed under the CDDL, things that are GPLv3 or GPLv2+ can be distributed and link against it. In the case of GPLv2 only (or cases of GPLv2+ where we have to choose GPLv2), we cannot link to a CDDLed libc, and must instead link with a libc which is compatible with the GPL. [There is eglibc running on the solaris kernel, but the Solaris kernel doesn't maintain as tight of an API as the linux kernel; it instead relies on libc to present that API.] Don Armstrong -- Who is thinking this? I am. -- Greg Egan _Diaspora_ p38 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100902224530.gm22...@rzlab.ucr.edu
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Fri, Sep 3, 2010 at 4:15 AM, Don Armstrong d...@debian.org wrote: In the course of Debconf10, I was asked a few questions about CDDL'ed libc, Nexenta, GPLed works and what would be necessary to have GPLed works which linked to a CDDLed libc so Nexenta could possibly become a Debian port. To make sure I haven't lept off the edge; I just wanted to run this by everyone. The quick ruberic is the following: CDDL'ed libc (and other System Library) and GPLv3+ work: OK CDDL'ed libc (and other System Library) and GPLv2 work: Probably Not OK * and GPLv2+ work + CDDL work (non-System Library): Not OK More lengthly explanation: The real question for GPLed works which link to solaris libc is whether or not solaris libc fits in with the system library exception. It's my understanding that for GPLv2 and v3, if you're not shipping the system library yourself, you don't need to concern yourself with license compatibility, and can just ship it anyway. This isn't the case for Debian or Nextenta, though, so we don't even need to contemplate it. For GPLv2 (not GPLv2+), the situtation when you are shipping both is more difficult; the key question here is what the precise meaning is of 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. My understanding is that for GPLv2, that means that we must also have the source, and we must ship it in compliance with the GPL, which we cannot do with CDDL works. [The critical aspect here is what precisely is meant by accompanies the executable, we've long assumed[1] that Debian's distribution of libraries means that they are accompanying the executable.] For GPLv3 (and GPLv2+, where we can choose GPLv3), the critical question is whether libc is a System Library. The System Libraries of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A Major Component, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. So, starting from the bottom, it's clear that libc is a majorq essential component of the OS. It implements a Standard Interface for which we have source code. The remaining question is what precisely is meant by subpart (a); I believe that libc is included with the C compiler or kernel Major Component, but isn't itself the kernel or compiler. So I believe that in the case of a libc licensed under the CDDL, things that are GPLv3 or GPLv2+ can be distributed and link against it. In the case of GPLv2 only (or cases of GPLv2+ where we have to choose GPLv2), we cannot link to a CDDLed libc, and must instead link with a libc which is compatible with the GPL. [There is eglibc running on the solaris kernel, but the Solaris kernel doesn't maintain as tight of an API as the linux kernel; it instead relies on libc to present that API.] Hi All, I'll be posting on behalf of the Nexenta project. Thanks to Don and Zack for their time and patience, and providing insight into this matter. A few clarifications/observations: * Nexenta referred to here is the Nexenta Core Platform, the project hosted at nexenta.org. * I would like to understand further the rational behind using the distribution of libraries boundary at Debian project level, rather than at a package/binary level, which seems a more natural fit for delineation. * If we do choose the entire project as the boundary, then in the specific case of packages that are GPLv2 only (linking with libc), we have been considering building these with a statically linked, license compatible libc (one of the small implementations). I would also like to hear your thoughts on this as a technical/legal solution. (Don, did you mean to add a reference to [1] in your mail?) Regards, Anil http://www.gulecha.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=vypnmbd5dcqi+ehdiamexoe_eldhxwqfio...@mail.gmail.com
Re: Java, GPL and CDDL
Josselin Mouette wrote: Le vendredi 16 novembre 2007 ? 16:23 +0100, Joerg Schilling a ?crit : If you talk to lawyers and ask them about the GPL, they will tell you that the GPL is a contract offer that needs to be explicitely acepted by the licensee. This is of course completely wrong. Unless you accept the terms of the GPL, the author's rights apply by default, so you don't have the right to use, distribute or modify the software. Which doesn't change the fact that the GPL is a contract whose terms must be accepted before the distributor of the software can be held to them. Arnoud -- Arnoud Engelfriet, Dutch European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ Arnoud blogt nu ook: http://blog.iusmentis.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java, GPL and CDDL
Arnoud Engelfriet [EMAIL PROTECTED] writes: Josselin Mouette wrote: This is of course completely wrong. Unless you accept the terms of the GPL, the author's rights apply by default, so you don't have the right to use, distribute or modify the software. Which doesn't change the fact that the GPL is a contract whose terms must be accepted before the distributor of the software can be held to them. No. A contract requires agreement from all parties, otherwise it is binding on none of them. The GPL applies *whether or not* the recipient agrees to it: it is a unilateral license grant, not a contract. It does nothing more than unilaterally extend specific rights to the recipient of the work, above and beyond those granted by copyright law, with *no* specific agreement required from any party. -- \I took a course in speed waiting. Now I can wait an hour in | `\ only ten minutes. -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java, GPL and CDDL
On 16/11/2007, Alexander Terekhov [EMAIL PROTECTED] wrote: Yeah, sort of vexed. But have you ever noticed GPL is a license not a contract folks citing ANY authority to back that legal nonsense claim? Consider: [lots and lots of case citations] It may or may not be correct, but I don't see how it is a nonsense. It is certainly possible (under common law systems at least) to have a non-contractual licence. Whether the GPL falls into that category, and what the consequences of that are, is a different question, and one which I'm not sure your citations answer. Anyway, on reflection I'm not sure it makes a huge difference to the principles involved even if the GPL is held to be a contract. Under English law, at least, you could probably put an argument together saying that the release of software under the GPL constitutes an offer to the world by the original licensor. The outcome remains essentially the same, as regards the argument in my previous email. John (TINLA) PS - no need to cc me, as I'm subscribed to the thread. Alternatively, I'm happy to take this discussion off-list, as it is getting increasingly OT. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java, GPL and CDDL
John Halton [EMAIL PROTECTED] wrote: On 16/11/2007, Alexander Terekhov [EMAIL PROTECTED] wrote: Yeah, sort of vexed. But have you ever noticed GPL is a license not a contract folks citing ANY authority to back that legal nonsense claim? Consider: [lots and lots of case citations] It may or may not be correct, but I don't see how it is a nonsense. It is certainly possible (under common law systems at least) to have a non-contractual licence. Whether the GPL falls into that category, and what the consequences of that are, is a different question, and one which I'm not sure your citations answer. There is nothing like a license in the usual law systems. The GPL is a contract for this and other reasons. Anyway, on reflection I'm not sure it makes a huge difference to the principles involved even if the GPL is held to be a contract. Under English law, at least, you could probably put an argument together saying that the release of software under the GPL constitutes an offer to the world by the original licensor. The outcome remains essentially the same, as regards the argument in my previous email. Note that the program in question seems to be a work from a French person. For this reason, European (French) right applies. If you talk to lawyers and ask them about the GPL, they will tell you that the GPL is a contract offer that needs to be explicitely acepted by the licensee. This could be done either by sending a textual agreement back to the owner of the code or by an implicit (non-verbal) agreement. In Germany the latter is called: Konkludentes Verhalten. Anyway, in Europe you cannot agree on a contract that you do not yet know and for this reason, a text like GPLv2 or any later is void. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java, GPL and CDDL
Joerg Schilling wrote: Anyway, in Europe you cannot agree on a contract that you do not yet know and for this reason, a text like GPLv2 or any later is void. Why? Assuming the rest of your characterizations for the sake of argument, two contracts currently exist which meet those criteria. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java, GPL and CDDL
Le vendredi 16 novembre 2007 à 16:23 +0100, Joerg Schilling a écrit : If you talk to lawyers and ask them about the GPL, they will tell you that the GPL is a contract offer that needs to be explicitely acepted by the licensee. This is of course completely wrong. Unless you accept the terms of the GPL, the author's rights apply by default, so you don't have the right to use, distribute or modify the software. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Java, GPL and CDDL
On 15/11/2007, Joerg Schilling [EMAIL PROTECTED] wrote: You first need to be very carefull to find out the license for this software. It does not mention the GPL version number, which makes it hard to find the authors will. Given the fact that a lot of the files have not been touched since the GPLv3 has been published, the Author most likely intended to put the software under GPLv2. Given the fact that it is illegal to agree on a license that is unknown at the time a contact has been signed, the old files cannot ever be under GPLv3. As GPLv2 and GPLv3 are incompatible, we need to asume that CaRMetal is under GPLv2. It is possible the licence uses the version two or later version of the GPL, which would allow the software to be distributed under GPL v.3, but I agree it looks more likely that the current version is under GPL v.2. If GPLv2 applies then the analysis is much the same as in my previous email, but the assessment that has to be made (based on clause 3 of GPLv2) is whether colorchooser is either: a. a module contained in CaRMetal; b. an associated interface definition file of CaRMetal; or c. a script used to control compilation and installation of the executable (I'm guessing no to that one). I'll leave it to the coders to answer that one. If the answer to any of those questions is yes then we next have to consider whether it falls under GPL v2's major components exception, which is narrower than that in GPL v3. GPLv3's definition of major component includes a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, *or a compiler used to produce the work, or an object code interpreter used to run it* (emphasis added). The equivalent provision in GPLv2 only refers to anything that is normally distributed ... with the major components (compiler, kernel, and so on) of the operating system on which the executable runs. It seems pretty clear that colorchooser doesn't meet that criterion.But that is only an issue if colorchooser meets one of the criteria set out in (a) to (c) above. CarMetal uses colorchooser https://colorchooser.dev.java.net/ wich is CDDL licensed. If colorchooser has been developed independently from CaRMetal, and only CaRMetal calls colorchooser, it is indeed similar to what happens with mkisofs and the license mix you describe is legal too. As set out above, the question is whether colorchooser fits within the GPL v2 wording covering (a) modules, (b) interface definition files or (c) build scripts. If CaRMetal's calling colorchooser brings it into one of those headings, then there is a licensing issue at that point. But I don't know the answer to that one. John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java, GPL and CDDL
John Halton [EMAIL PROTECTED] wrote: On 15/11/2007, Joerg Schilling [EMAIL PROTECTED] wrote: You first need to be very carefull to find out the license for this software. It does not mention the GPL version number, which makes it hard to find the authors will. Given the fact that a lot of the files have not been touched since the GPLv3 has been published, the Author most likely intended to put the software under GPLv2. Given the fact that it is illegal to agree on a license that is unknown at the time a contact has been signed, the old files cannot ever be under GPLv3. As GPLv2 and GPLv3 are incompatible, we need to asume that CaRMetal is under GPLv2. It is possible the licence uses the version two or later version of the GPL, which would allow the software to be distributed under GPL v.3, but I agree it looks more likely that the current version is under GPL v.2. The Author seems to be French and in Europe, the clause version two or later is void as I already tried to explain. If GPLv2 applies then the analysis is much the same as in my previous email, but the assessment that has to be made (based on clause 3 of GPLv2 §3 tells you what to do in case you like to publish binaries. If you cannot publish binaries, the software is still not illegal. For other aspects, it seems to be important that the GPL was listed as non-free license before the FSF declared that the ambiguous parts need to be interpreted in a way that makes the GPL compliant to the OpenSource definition from Bruce Perens http://www.opensource.org/docs/osd, in special §9. GPLv2) is whether colorchooser is either: a. a module contained in CaRMetal; This is obviously not true as it is not contained as far as I can see. BTW: This is (if ever) a requirement of GPlv2 §2) not §3. While GPLv2 §3) talks about the whole source, GPLv2 §2) only talks about the work. As CaRMetal is not part of the work colorchooser this does not apply. b. an associated interface definition file of CaRMetal; or This is obviously a missunderstaning of the GPLv2: GPLv2 §3) may force you to publish the colorchooser source together with the CaRMetal source if you publish binaries but as CaRMetal is not part of the work colorchooser, there is no requirement to put colorchooser under GPL. c. a script used to control compilation and installation of the executable (I'm guessing no to that one). colorchooser is most likely part of the full source of CaRMetal. If you publish CaRMetal binaries, you need to publish colorchooser together with CaRMetal. This does however not influence the license of colorchooser. I'll leave it to the coders to answer that one. If the answer to any of those questions is yes then we next have to consider whether it falls under GPL v2's major components exception, which is narrower than that in GPL v3. THIS is definitely a missunderstaning of the GPL. See above for more information. CarMetal uses colorchooser https://colorchooser.dev.java.net/ wich is CDDL licensed. If colorchooser has been developed independently from CaRMetal, and only CaRMetal calls colorchooser, it is indeed similar to what happens with mkisofs and the license mix you describe is legal too. As set out above, the question is whether colorchooser fits within the GPL v2 wording covering (a) modules, (b) interface definition files or (c) build scripts. If CaRMetal's calling colorchooser brings it into one of those headings, then there is a licensing issue at that point. But I don't know the answer to that one. You seem to confuse the fact that GPLv2 §3) requires to publish _more_ source than just the work with the requirement from GPLv2 §2) to put all of the work under GPL. §2 and §3 are unrelated. If the intention of the author of GPLv2 was to require GPL for the full source, then GPLv2 §3) would need to mention this explicitely. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java, GPL and CDDL
Le jeudi 15 novembre 2007 à 17:04 +0100, Joerg Schilling a écrit : CarMetal uses colorchooser https://colorchooser.dev.java.net/ wich is CDDL licensed. If colorchooser has been developed independently from CaRMetal, and only CaRMetal calls colorchooser, it is indeed similar to what happens with mkisofs and the license mix you describe is legal too. Please don't take Jörg Schilling's dreams for reality. This case is different from cdrtools, and easier to solve. You only need to get a specific exception from the authors of CarMetal to allow its linking to colorchooser; much like the OpenSSL exception that is present in many GPL applications. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Java, GPL and CDDL
On Thu, Nov 15, 2007 at 09:09:04PM +0100, Alexander Terekhov wrote: I think that being a lawyer you will agree that existing version or later is *at most* a permission given by the original licensor to direct licensees (i.e. parties entering version two contract) to SUBLICENSE (licensees can become sublicensors if they wish) licensed work to other parties under later version of license contract. Original licensor just can't somehow magically become a party to a contract which wasn't even drafted at the time when license contract offer was made to public. I agree that the wording in question is concerned with sublicensing rather than changing the original licence terms. The relevant wording is you can redistribute it and/or modify it under either version 2 of the License, or (at your option) any later version. And it's redistribution that I was referring to in my email. The other rather curious aspect regarding GPLv3 and sublicensing is that the GPL actually bites itself: while original GPLv2 licensors may well allow sublicensing under the GPLv3, in its Automatic Licensing of Downstream Recipients provision the GPLv3 names *original licensors* and not sublicensors as parties offering a license to downstream recipients. And that means GPLv2, not GPLv3. Go figure. I confess I've not really given much thought to how clause 10 of v3 interacts with v2. The problem seems to be that v2 is saying You, the licensee, can sublicense under v3, when it arrives, while v3 is saying You, the licensee, can't sublicense, and instead of this the original licensor is now deemed to have licensed the person to whom you convey the work. I suspect the argument would be that a licensor who has included the or later wording has, by doing so, given permission to the downstream users. And that is the fundamental issue from the downstream user's POV: has the original licensor given me permission to use this software? A sublicence is just an indirect way for the original licensor to do that, so the conceptual jump between v2 and v3 isn't really a problem. If we get away from ambiguous, technical-sounding terms like licence and think instead in terms of permissions, GPL v2 says I, the licensor, give you, the licensee, permission to sublicence to the downstream user under v3 (even though I don't yet know what that says, because it hasn't been written yet). But that is not really any different from saying, I, the licensor, [indirectly] give the downstream user permission to use this software in accordance with v3. Which is what clause 10 of v3 says. All this is highly OT, of course, and the question probably comes down to whether one views the GPL as a non-contractual licence or as a contract: a highly vexed question that is probably best avoided here for now, except to say that the above argument would seem to fall apart if the GPL is a contract. John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java, GPL and CDDL
On Thu, 15 Nov 2007 17:15:25 + John Halton wrote: On 15/11/2007, Joerg Schilling [EMAIL PROTECTED] wrote: [usual unbacked assertions and handwaving by Mr. Schilling...] It is possible the licence uses the version two or later version of the GPL, which would allow the software to be distributed under GPL v.3, but I agree it looks more likely that the current version is under GPL v.2. Wait, wait! *If* the copyright holder of the work under question stated that it is redistributable under the terms of the GNU GPL, without mentioning any license version number[1], then Section 9 of GPLv2 kicks in[2]: | If the Program does not specify a version number of | this License, you may choose any version ever published by the Free | Software Foundation. Hence such work would be distributable under the terms of any published version of the GNU GPL (currently v1, v2, or v3, and in the future any later version, as well). [1] I haven't checked myself, but *if* this is the case... [2] assuming the license text that accompanies the work is the GNU GPLv2 (GPLv3 has a nearly indentical clause anyway) -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpFGoeyt1YR1.pgp Description: PGP signature
Re: Java, GPL and CDDL
I am wondering if Java GPLed application can link with CDDL classes? Case looks like the cdrecord question i saw in the archive. The case is in CarMetal (geometrical program derived from the wondeful CaR from René Grothman) http://db-maths.nuxit.net/CaRMetal/ You first need to be very carefull to find out the license for this software. It does not mention the GPL version number, which makes it hard to find the authors will. Given the fact that a lot of the files have not been touched since the GPLv3 has been published, the Author most likely intended to put the software under GPLv2. Given the fact that it is illegal to agree on a license that is unknown at the time a contact has been signed, the old files cannot ever be under GPLv3. As GPLv2 and GPLv3 are incompatible, we need to asume that CaRMetal is under GPLv2. This makes things easier, as the GPLv2 is less restrictive than GPLv3. CarMetal uses colorchooser https://colorchooser.dev.java.net/ wich is CDDL licensed. If colorchooser has been developed independently from CaRMetal, and only CaRMetal calls colorchooser, it is indeed similar to what happens with mkisofs and the license mix you describe is legal too. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java, GPL and CDDL
On 13/11/2007, Ben Finney [EMAIL PROTECTED] wrote: Yves Combe [EMAIL PROTECTED] writes: I am wondering if Java GPLed application can link with CDDL classes? Case looks like the cdrecord question i saw in the archive. To understand whether there's a license conflict, there needs to be an understanding of whether copyright is invoked by linking. In many jurisdictions, this boils down to whether the action of distributing a work, Foo, that links to work Bar, is thus distributing a derivative work of Bar. ISTM the key issue is whether the CDDL classes would constitute part of the Corresponding Source (in GPL v3 language) of the Java application, rather than a dynamic vs static linking issue. That in turn hinges on whether the CDDL classes would be regarded as forming part of the System Libraries for the work. The questions to ask are then: a. Are the CDDL libraries included in the normal form of packaging a Major Component, but ... not part of that Major Component? (Would the Major Component here be the JDK?) b. If so, do these serve only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form? If the answer to both those questions is yes then the CDDL-licensed classes are not required to be distributed as part of the Corresponding Source for the GPLed code. If, however, the answer to either (or both) of those questions is no then the classes will form part of the Corresponding Source of the application, and will need to be distributed under the GPL. (It's worth noting that the GPL v3 appears to be more helpful here than GPL v2, which defines the major components exception more narrowly.) CarMetal uses colorchooser https://colorchooser.dev.java.net/ wich is CDDL licensed. Is that ok for dfsg ? As mentioned above, I think what needs to be done is to ask those two questions about whether colorchooser forms part of the System Libraries for CarMetal. If colorchooser is not normally included in the Sun JDK(?) - and the fact it is made available for separate download suggests to me it isn't - then I'd say there is a licensing problem here. This isn't a DFSG problem so much as a GPL/CDDL incompatibility issue more generally. If colorchooser is strikedistributed/strike conveyed under the GPL then this will breach the CDDL. If colorchooser is not included with the Corresponding Source of CarMetal then this will breach the GPL. If I've wildly missed the point somewhere along the line - I'm still new here - then I'm sure someone will point this out, so I'd wait to see if anyone leaps in now! John (TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java, GPL and CDDL
Yves Combe [EMAIL PROTECTED] writes: I am wondering if Java GPLed application can link with CDDL classes? Case looks like the cdrecord question i saw in the archive. To understand whether there's a license conflict, there needs to be an understanding of whether copyright is invoked by linking. In many jurisdictions, this boils down to whether the action of distributing a work, Foo, that links to work Bar, is thus distributing a derivative work of Bar. This, in turn, depends on the technicalities of what's happening in the instance of links to; I don't know Java well enough to say definitely. The FSF's legal theory is that, in the case where Foo is a program and Bar is a library in the C programming model, Foo links to Bar is sufficient to satisfy Foo is a derivative work of Bar. To my knowledge, this theory has not yet been tested in any court. If the FSF is correct on the above, I don't know how far this would extend to other links to implementations in other languages. The case is in CarMetal (geometrical program derived from the wondeful CaR from René Grothman) http://db-maths.nuxit.net/CaRMetal/ CarMetal uses colorchooser https://colorchooser.dev.java.net/ wich is CDDL licensed. Is that ok for dfsg ? I hope the above helps the issue become clearer — or at least points out where the gnarly details are :-) (please cc-me) Done. -- \ A society that will trade a little liberty for a little order | `\will lose both, and deserve neither. -- Thomas Jefferson, in | _o__) a letter to Madison | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NetBeans ITP [was Re: CDDL]
\Anthony W. Youngman\ [EMAIL PROTECTED] And what happens if you DON'T have a place in common where you trade? [...] I don't know and it sounds like a common case in this global software distribution game. I just tried to add a trackback to this thread from the previously-cited article and was told 'ERROR: Comments and Trackbacks are disabled for the entry you specified.' Clearly comments are enabled, as a comment appears on that page. I'll try a cc on this mail, but I feel Sun people are loudly claiming to be easy to talk to, yet aren't really. Irritated, -- 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: NetBeans ITP [was Re: CDDL]
MJ Ray wrote: I just tried to add a trackback to this thread from the previously-cited article and was told 'ERROR: Comments and Trackbacks are disabled for the entry you specified.' Clearly comments are enabled, as a comment appears on that page. I'll try a cc on this mail, but I feel Sun people are loudly claiming to be easy to talk to, yet aren't really. Simon's blog entry is from a while ago, so yes the comments are closed. But you can comment here, send an e-mail to [EMAIL PROTECTED], and/or get me on IRC (tmarble on OFTC #debian-java or #openjdk ). Regards, --Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NetBeans ITP [was Re: CDDL]
Tom Marble [EMAIL PROTECTED] Simon's blog entry is from a while ago, so yes the comments are closed. Radical interface design idea: why not remove the links instead of letting people waste time sending to an error-bouncer? But you can comment here, send an e-mail to [EMAIL PROTECTED], and/or get me on IRC (tmarble on OFTC #debian-java or #openjdk ). My comments can be seen here earlier in this thread, I'm waiting for an email reply and I don't IRC much any more. Hope that explains, -- 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: NetBeans ITP [was Re: CDDL]
In message [EMAIL PROTECTED], MJ Ray [EMAIL PROTECTED] writes Tom Marble [EMAIL PROTECTED] wrote: Indeed allow me to appeal to everyone to reconsider CDDL *as is* given the clarification that Simon has provided in this regard [1]. In essence, this is the same claim we have heard before: If, however, you are an individual, or a company that trades in only one of the places in which the other party also trades, the only jurisdiction that can hear the case is the one you share in common with the other party. In this circumstance, the choice of venue clause has no effect - no reasonable court would hear a case involving a party with no connection to the court. So, as I've repeatedly stated before, to accept such a choice of venue as not being an effective cost, we need to be sure the court is reasonable. I've no idea whether Santa Clara County California (SCCC) is reasonable and I'm not going to take Simon's word because: And what happens if you DON'T have a place in common where you trade? A lot of EU software is sold from Ireland, or maybe I bought it mail-order from America? That argument fails on the obvious problem that in some circumstances it would leave a plaintiff with no recourse. I'm guessing choice of venue WOULD be valid in those circumstances, and by UK standards it would also be blatantly unfair - in the UK, with any suit by a corporation against an individual, the individual can have it moved (regardless of the corp's wishes) to the individual's local court. Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NetBeans ITP [was Re: CDDL]
Hi, On Sat, Dec 02, 2006, Tom Marble wrote: Once the the full JVM is available under GPL then running applications on top of it *are* compatible with any license as this was the specific rationale for adding the Classpath exception [1]. I think it can even go in contrib if it ends up being considered free, which is the place for free software which requires non-free software. It doesn't change a lot for the autobuilding of the Netbeans package which is probably arch: all, but it would mean it is in Debian proper (the non-free section is not part of Debian, it's just supported on a best-effort basis). It sounds like you are not aware that Daniel Baumann already uploaded Netbeans with Section: contrib/devel in the diff. You can watch packages pending reviewal by the Debian Ftp Masters in the NEW queue at: http://ftp-master.debian.org/new.html And Daniel Baumann explained he uploads all packages on his personal repository as well, so you can check the .diff.gz of his proposed package at: http://archive.daniel-baumann.ch/debian/packages/netbeans/5.5-1/ (where you should find debian/control with the Section:) Bye, -- Loïc Minier [EMAIL PROTECTED] You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shutdown.-- Zapp Brannigan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NetBeans ITP [was Re: CDDL]
Tom Marble [EMAIL PROTECTED] wrote: Indeed allow me to appeal to everyone to reconsider CDDL *as is* given the clarification that Simon has provided in this regard [1]. In essence, this is the same claim we have heard before: If, however, you are an individual, or a company that trades in only one of the places in which the other party also trades, the only jurisdiction that can hear the case is the one you share in common with the other party. In this circumstance, the choice of venue clause has no effect - no reasonable court would hear a case involving a party with no connection to the court. So, as I've repeatedly stated before, to accept such a choice of venue as not being an effective cost, we need to be sure the court is reasonable. I've no idea whether Santa Clara County California (SCCC) is reasonable and I'm not going to take Simon's word because: 1. I suspect it may be in the interest of Sun employees to claim it is reasonable even if it is not; 2. No documentary evidence of SCCC practice is shown (in god we trust, all others must bring data); 3. He writes elsewhere This is [...] intended as legal advice to no-one. and more importantly: 4. The idea of corporations doing the equivalent of extraordinary rendition on the strength of a choice of venue clause is a literalist fantasy. If the US is similar to the UK, copyright infringement is a criminal act; and the US can extradite corporation chiefs from the UK, using our terrible Extradition Act 2003. That is, a corporation equivalent of extraordinary rendition already happens! When someone shows us evidence detailing how SCCC works in this situation, I'll believe SCCC is reasonable in that way. There seem to be some bogus justifications in the article, like: The main beneficiary of a choice of venue clause in an open source license is actually the smaller US business. [...] Sun is not a smaller US business, so that paragraph seems irrelevant. Ultimately, if it has no beneficial effect *for Sun*, why is *Sun* putting it in their licences? Also, as mentioned in another post recently, the CDDL discriminates against support agents of any Contributor, which may prevent CDDL'd work being free software. CDDL remains a check each case carefully licence. Hope that explains, -- 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: NetBeans ITP [was Re: CDDL]
On Sat, 2 Dec 2006 21:01:08 + (UTC) Mark Wielaard wrote: The FAQ even says: Q: How does this announcement affect Java EE? A: Sun's implementation of Java EE 5 has been available as open-source under the CDDL license through the GlassFish Community since June of 2005. In order to gain all of the benefits of the GPL v2 license and to be able to offer implementations of the entire set of Java platforms under the same license, the GlassFish application server source code will be made available under the GPL v2 license with Classpath exception in addition to the CDDL, By adding a second license, we simplify the process of combining and distributing GlassFish code with other GPL licensed communities. By offering all of Java under a common license, developers can now more easily collaborate on and distribute updated versions of Java SE, Java EE, and Java ME together. A similar argument could be made for NetBeans. Indeed! I really think that the quickest and safest way for NetBeans to be accepted in Debian main is to be relicensed (or dual-licensed) under the GNU GPL v2. It's really the way to go. Since Sun claims to have understood the benefits of GPL-compatibility, I don't see a reason that would block such a relicensing or dual-licensing. The alternative is starting up the n-th debian-legal discussion about the CDDL, which could be really lengthy this time and still fail to reach consensus. We have already tried to analyze the CDDL and there are diverging opinions about it: some (including myself) think it doesn't meet the DFSG, others feel that it is possibly acceptable on a case-by-case basis, others think that it's basically OK. But even assuming it's acceptable (I don't think it actually is, but let's assume it is, for the sake of the argument), it's still GPL-incompatible, thus placing significant barriers to collaboration among GPL-using communities. -- But it is also tradition that times *must* and always do change, my friend. -- from _Coming to America_ . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp3yjDk3xl7q.pgp Description: PGP signature
Re: CDDL
[EMAIL PROTECTED] wrote: I watched Sun's Simon Phipps' talk at debconf 2006 few weeks ago. It was mentioned that the choice of venue was useless and would be removed from CDDL, thus making CDDL DSFG-compliant. There is no consensus that choice of venue clauses are not DSFG-compliant, anyway. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
NetBeans ITP [was Re: CDDL]
Marco d'Itri wrote: [EMAIL PROTECTED] wrote: I watched Sun's Simon Phipps' talk at debconf 2006 few weeks ago. It was mentioned that the choice of venue was useless and would be removed from CDDL, thus making CDDL DSFG-compliant. There is no consensus that choice of venue clauses are not DSFG-compliant, anyway. Indeed allow me to appeal to everyone to reconsider CDDL *as is* given the clarification that Simon has provided in this regard [1]. Why is this important? Because Sun has several software projects that are licensed under CDDL that we would really, really like accepted into Debian. The key example is our NetBeans IDE. The purpose of packaging NetBeans for Debian is to give Free Software developers *a chance* to evaluate this development tool and compare it to other tools available. Until very, very recently this hasn't even been possible as we are fully aware that NetBeans has had various non-free dependencies (which would have blocked it's inclusion in main). Thus the primary rationale for liberating javac and JavaHelp as part of the Java Open Source launch [2] was to free these key dependencies for NetBeans. Today NetBeans also depends on the Sun Java runtime. We have done some research with Free Java implementations to demonstrate functionality on a runtime currently in main and this work is ongoing. So you can transparently see the trajectory of Sun Java becoming itself a Free Java runtime in early 2007 [2]. In the interim I am very pleased in our work together to date to get Sun Java into non-free under the DLJ [3]. And so the trajectory for NetBeans, therefore, is we would like to package all dependent parts which are recognized as DFSG compliant for main (CDDL, GPL packages) and prepare a NetBeans package under CDDL which depends (initially) on the non-free Sun Java runtime [3] such that upon the full liberation of Sun Java that NetBeans will become a candidate for main. I know that CDDL has been discussed many, many times on d-l in the past. In light of Sun's commitment to Free Software and our desire to make this software available to Debian Developers and users it is apropos to work towards consensus on the DFSG status of CDDL. I welcome your comments and concerns. Respectfully, --Tom [1] http://blogs.sun.com/webmink/entry/choice_of_venue [2] http://www.sun.com/software/opensource/java/ [3] http://packages.qa.debian.org/s/sun-java5.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NetBeans ITP [was Re: CDDL]
Le samedi 02 décembre 2006 18:18, Tom Marble a écrit : Marco d'Itri wrote: [EMAIL PROTECTED] wrote: I watched Sun's Simon Phipps' talk at debconf 2006 few weeks ago. It was mentioned that the choice of venue was useless and would be removed from CDDL, thus making CDDL DSFG-compliant. There is no consensus that choice of venue clauses are not DSFG-compliant, anyway. Indeed allow me to appeal to everyone to reconsider CDDL *as is* given the clarification that Simon has provided in this regard [1]. Why is this important? Because Sun has several software projects that are licensed under CDDL that we would really, really like accepted into Debian. The key example is our NetBeans IDE. The purpose of packaging NetBeans for Debian is to give Free Software developers *a chance* to evaluate this development tool and compare it to other tools available. Thanks for mentioning Netbeans, Tom. This is exactly the application I had in mind. I chose it over Eclipse for my Java development and I'd like very much to be part of main some day. Regards, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NetBeans ITP [was Re: CDDL]
Tom Marble Tom.Marble at Sun.COM writes: Until very, very recently this hasn't even been possible as we are fully aware that NetBeans has had various non-free dependencies (which would have blocked it's inclusion in main). Thus the primary rationale for liberating javac and JavaHelp as part of the Java Open Source launch [2] was to free these key dependencies for NetBeans. Today NetBeans also depends on the Sun Java runtime. We have done some research with Free Java implementations to demonstrate functionality on a runtime currently in main and this work is ongoing. We did some work for the upcoming 0.93 release of GNU Classpath trying to get NetBeans running, but this is still some way in the future. There are some parts/plugins which partially startup/run, but for getting the full IDE working some serious effort will still be needed. And so the trajectory for NetBeans, therefore, is we would like to package all dependent parts which are recognized as DFSG compliant for main (CDDL, GPL packages) and prepare a NetBeans package under CDDL which depends (initially) on the non-free Sun Java runtime [3] such that upon the full liberation of Sun Java that NetBeans will become a candidate for main. I know that CDDL has been discussed many, many times on d-l in the past. In light of Sun's commitment to Free Software and our desire to make this software available to Debian Developers and users it is apropos to work towards consensus on the DFSG status of CDDL. I welcome your comments and concerns. One really nice thing of Sun's announcement was the fact that they streamlined the licensing process of all of the Java editions. Not just jse (openjdk), but also jme and jee. The FAQ even says: Q: How does this announcement affect Java EE? A: Sun's implementation of Java EE 5 has been available as open-source under the CDDL license through the GlassFish Community since June of 2005. In order to gain all of the benefits of the GPL v2 license and to be able to offer implementations of the entire set of Java platforms under the same license, the GlassFish application server source code will be made available under the GPL v2 license with Classpath exception in addition to the CDDL, By adding a second license, we simplify the process of combining and distributing GlassFish code with other GPL licensed communities. By offering all of Java under a common license, developers can now more easily collaborate on and distribute updated versions of Java SE, Java EE, and Java ME together. A similar argument could be made for NetBeans. While there is a discussion about the CDDL and whether it is acceptable according to DFSG or needs modernizing please do start packaging the various NetBeans dependencies. There is already a packaging effort on the way for the GPLed javac. And since JavaHelp has now be released under GPL+exception it can also immediately be packaged. While packaging eclipse a lot of work was needed for extracting all the dependencies bundled upstream into separate packages for easy reuse and making it possible to update the independent parts easily. Starting early on that is a good idea, especially since the separate parts might be beneficial on their own and as dependencies for other applications (like Glashfish for example). Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NetBeans ITP [was Re: CDDL]
Le samedi 02 décembre 2006 à 11:18 -0600, Tom Marble a écrit : Why is this important? Because Sun has several software projects that are licensed under CDDL that we would really, really like accepted into Debian. The key example is our NetBeans IDE. The purpose of packaging NetBeans for Debian is to give Free Software developers *a chance* to evaluate this development tool and compare it to other tools available. Please note that we don't accept software in Debian just because it is useful, but also because it is free. That said, I agree with some of the arguments given about the choice-of-venue clause. It is a bad clause, but I don't think it makes a piece of software non-free. There is no consensus about it on debian-legal. About Netbeans, I don't understand how it would be distributable if running over a GPL JVM, as the CDDL and the GPL are incompatible. Cheers, -- Josselin Mouette/\./\ Do you have any more insane proposals for me? signature.asc Description: Ceci est une partie de message numériquement signée
Re: NetBeans ITP [was Re: CDDL]
Josselin Mouette wrote: Please note that we don't accept software in Debian just because it is useful, but also because it is free. Understood. That said, I agree with some of the arguments given about the choice-of-venue clause. It is a bad clause, but I don't think it makes a piece of software non-free. There is no consensus about it on debian-legal. The ideal outcome of this thread would be that the interpretation of the choice-of-venue clause would permit packages (such as NetBeans) to be accepted in Debian. About Netbeans, I don't understand how it would be distributable if running over a GPL JVM, as the CDDL and the GPL are incompatible. The interim solution is depending on the DLJ JVM (non-free) which would mean that during that period NetBeans, also, would need to be in non-free. Once the the full JVM is available under GPL then running applications on top of it *are* compatible with any license as this was the specific rationale for adding the Classpath exception [1]. Thanks, --Tom [1] http://www.sun.com/software/opensource/java/faq.jsp#g6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
CDDL
Hi, I watched Sun's Simon Phipps' talk at debconf 2006 few weeks ago. It was mentioned that the choice of venue was useless and would be removed from CDDL, thus making CDDL DSFG-compliant. Does anybody know if is it still a work in progress? Does anyone have contacts with Sun people about the issue? Thanks. Regards, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL
On Fri, Dec 01, 2006 at 12:03:46PM +0100, Jérôme Marant [EMAIL PROTECTED] wrote: Hi, I watched Sun's Simon Phipps' talk at debconf 2006 few weeks ago. It was mentioned that the choice of venue was useless and would be removed from CDDL, thus making CDDL DSFG-compliant. Does anybody know if is it still a work in progress? Does anyone have contacts with Sun people about the issue? Note that even if that happens, that won't change the licensing terms for the software already released under current CDDL. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL
Le vendredi 01 décembre 2006 18:44, Mike Hommey a écrit : On Fri, Dec 01, 2006 at 12:03:46PM +0100, Jérôme Marant [EMAIL PROTECTED] wrote: Hi, I watched Sun's Simon Phipps' talk at debconf 2006 few weeks ago. It was mentioned that the choice of venue was useless and would be removed from CDDL, thus making CDDL DSFG-compliant. Does anybody know if is it still a work in progress? Does anyone have contacts with Sun people about the issue? Note that even if that happens, that won't change the licensing terms for the software already released under current CDDL. Unless they upgrade the license of such software, I guess? -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL
On Fri, Dec 01, 2006 at 06:47:30PM +0100, Jérôme Marant [EMAIL PROTECTED] wrote: Le vendredi 01 décembre 2006 18:44, Mike Hommey a écrit : On Fri, Dec 01, 2006 at 12:03:46PM +0100, Jérôme Marant [EMAIL PROTECTED] wrote: Hi, I watched Sun's Simon Phipps' talk at debconf 2006 few weeks ago. It was mentioned that the choice of venue was useless and would be removed from CDDL, thus making CDDL DSFG-compliant. Does anybody know if is it still a work in progress? Does anyone have contacts with Sun people about the issue? Note that even if that happens, that won't change the licensing terms for the software already released under current CDDL. Unless they upgrade the license of such software, I guess? Which would be relicensing and requires agreement from all contributors, as any other relicensing. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL
Unless they upgrade the license of such software, I guess? Which would be relicensing and requires agreement from all contributors, as any other relicensing. Exactly. But it should not be a problem for Sun products I'm thinking about. Thanks. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL
=?iso-8859-15?q?J=E9r=F4me_Marant?= [EMAIL PROTECTED] I watched Sun's Simon Phipps' talk at debconf 2006 few weeks ago. It was mentioned that the choice of venue was useless and would be removed from CDDL, thus making CDDL DSFG-compliant. CDDL also discriminates against agents acting on behalf of any Contributor, thanks to section 3.4 combined with section 9: 3.4. Application of Additional Terms. [...] You may choose to offer, and to charge a fee for, warranty, support, indemnity or liability obligations to one or more recipients of Covered Software. However, you may do so only on Your own behalf, and not on behalf of the Initial Developer or any Contributor. You must make it absolutely clear that any such warranty, support, indemnity or liability obligation is offered by You alone, and You hereby agree to indemnify the Initial Developer and every Contributor for any liability incurred by the Initial Developer or such Contributor as a result of warranty, support, indemnity or liability terms You offer. [...] 9. [...] This License represents the complete agreement concerning subject matter hereof. [...] I mean, it's obvious what they were trying to do, but they cut out a lot of potential commerce because they don't allow supplementary agreements. Does anybody know if is it still a work in progress? Does anyone have contacts with Sun people about the issue? Not I. -- 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: CDDL
Mike Hommey [EMAIL PROTECTED] wrote: Note that even if that happens, that won't change the licensing terms for the software already released under current CDDL. It will, unless the Initial Developer says not: 4.2. Effect of New Versions. You may always continue to use, distribute or otherwise make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. If the Initial Developer includes a notice in the Original Software prohibiting it from being distributed or otherwise made available under any subsequent version of the License, You must distribute and make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. Otherwise, You may also choose to use, distribute or otherwise make the Covered Software available under the terms of any subsequent version of the License published by the license steward. Hope that explains, -- 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: [Fwd: Debian and CDDL and DFSG]
George Danchev [EMAIL PROTECTED] wrote: The venue could make significant difference here, because the licensor could be terribly wrong in one jurisdiction and correct in another. That's a problem with choice of law, not choice of venue. Furthermore you can hadly measure whether the licensor is evil or not, and can not just rely on his good faith. And that's an argument in favour of not shipping any software at all. This kind of 'moving sands' via patch clauses are quite similar to GFDL's invariant sections which Debian considers non-free. They're about as similar to invariant sections as I am. Keeping the variable sections of a license separate and easy to locate is useful - look at the vast number of slightly different versions of the 4-clause BSD, and how as a result there's a need to check that it's actually the same license in all cases rather than having been subtly modified. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
Cc'ing because I forgot to look and mdpoole cc'd. Please do not cc me on replies to debian-legal. Martin Man [EMAIL PROTECTED] wrote: Is there any document that describes why debian considers CDDL[1] to not be DFSG compliant (if that statement still holds true)? There is no single document on this licence. I'm not sure there is consensus yet. My notes say CDDL is copyleft, but each case needs checking for active patents and the licensors' behaviour on identification, both of which can make software under CDDL fail to follow the DFSG. If there is no such document, could I get CDDL licensed software to main? Should I ask first debian-legal? what would be the answer? What software are you wanting to get into main? Yes, I think you should ask debian-legal, as per policy. I won't predict the answer at this time. I could find only a lot of FUD and inconsistencies on various blogs wrt/ choice of venue paragraph present in CDDL. Different people have different opinions. That should not surprise anyone. We are not a group-think corporation presenting a party line. I don't think you should dismiss the venue problem as mere FUD so quickly. For a licensor as big as Sun to require developers to travel thousands of miles apparently on a whim is at best abusive and at worst a fee. If people are misunderstanding the venue clause (remember, U is uncertainty), then please explain, not flame. Hope that explains, -- 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: Debian and CDDL and DFSG
On Monday 07 August 2006 17:02, Martin Man wrote: Please do not cc me on replies to debian-legal. Hi all, Hi, I was searching around the web regadring the $subj, but I was unable to find any official statement from Debian concerning the issue. Is there any document that describes why debian considers CDDL[1] to not be DFSG compliant (if that statement still holds true)? If there is no such document, could I get CDDL licensed software to main? Should I ask first debian-legal? what would be the answer? I don't think there is official statement too, but you can see some concerns from past discussions [1]. I could find only a lot of FUD and inconsistencies on various blogs wrt/ choice of venue paragraph present in CDDL. Right, but rebuttals like Myth1 [2] doesn't work either. So, each author can specify whatever venue they prefer, but there are people which dislike exotic jurisdictions (jurisdictions changes, and there is no way to know them all along with their habits). I've been told about a contra argument: having stipulated c-o-v clause the author can protect his right better since he can do that in his jurisdiction. the contra argument is that he can do that in his jurisdiction even without c-o-v patch clause to the license. Also noone explained why DFSG#5 couldn't be invoked in this case, e.g. discriminating against people who dislike c-o-v patch clauses ? I agree that Myth2 [2] is actually a myth. Ok, I have some questions for you, seems like you should be able to give an authoritative answer (this does not make CDDL 1.0 non-free, of course): * Is CDDL 1.0 incompatible with GPL v2 ? * If it is incompatible, what makes it incompatible and why it has been done that way? Thanks for your replies. [1] http://lists.debian.org/debian-legal/2005/09/index.html [2] http://blogs.sun.com/roller/page/harpster?entry=your_venue_or_mine -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
Hi all, MJ Ray wrote On 2006-08-09 11:56,: Martin Man [EMAIL PROTECTED] wrote: I could find only a lot of FUD and inconsistencies on various blogs wrt/ choice of venue paragraph present in CDDL. Different people have different opinions. That should not surprise anyone. We are not a group-think corporation presenting a party line. fair enough, but if ftpmasters decide on inclusion/exclusion of certain software, there should at least be common consensus concerting certain license. I don't think you should dismiss the venue problem as mere FUD so quickly. For a licensor as big as Sun to require developers to travel thousands of miles apparently on a whim is at best abusive and at worst a fee. If people are misunderstanding the venue clause (remember, U is uncertainty), then please explain, not flame. I do understand it in this way: - c-o-v as required by paragraph 9. of CDDL is a note attached to the license itself, to my understanding you can put there any jurisdiction you want (you as the author or contributor), and yes, it's there to predict and ensure that case will be treated properly (according to the state of law in a jurisdiction you put to the clause) - GPL does not have such c-o-v clause at all, which means that I can take anyone to any court I decide to, so to me, if I want to sue you, GPL gives me even more chance to manipulate the case and choose the jurisdiction that will give me most advantages in my case. Hope that explains, HTH, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian and CDDL and DFSG
Hi Goeorge, George Danchev wrote On 2006-08-09 12:11,: Ok, I have some questions for you, seems like you should be able to give an authoritative answer (this does not make CDDL 1.0 non-free, of course): I will try, my answer is not authoritative, but based on what I read and how I understand it * Is CDDL 1.0 incompatible with GPL v2 ? could you explain what you mean by incompatibile? to my understanding GPL is only compatibile with itself and less strict licenses, CDDL is pretty much on the same line of strictness as GPL. * If it is incompatible, what makes it incompatible and why it has been done that way? it has been done that way to allow you to - develop commercial software based on a CDDL based product (you can do this with APL, with LGPL, but not with GPL) - combination of CDDL + private source code files - allow opensourcing effort of opensolaris (lot of code under various IP rights that can't be relicensed to GPL because of non-existance of original IP holders) see [1] for more info Thanks for your replies. just my .2 cents, Martin [1] http://www.opensolaris.org/os/about/faq/licensing_faq/#CDDL-combo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
Martin Man [EMAIL PROTECTED] wrote: fair enough, but if ftpmasters decide on inclusion/exclusion of certain software, there should at least be common consensus concerting certain license. Yes, there should be, but I doubt everyone gets it right every time and ftpmasters are not exactly debian-legal or vice-versa. Sometimes there's not consensus to act against accepting a questionable licence either, until there's an active dispute. Depending on which archive section a package is in and what the remaining questions are, it may not even be clearly a bug, and debian-legal is as short-handed as many other vital parts of the project. [...] I do understand it in this way: - c-o-v as required by paragraph 9. of CDDL is a note attached to the license itself, to my understanding you can put there any jurisdiction you want (you as the author or contributor), and yes, it's there to predict and ensure that case will be treated properly (according to the state of law in a jurisdiction you put to the clause) - GPL does not have such c-o-v clause at all, which means that I can take anyone to any court I decide to, so to me, if I want to sue you, GPL gives me even more chance to manipulate the case and choose the jurisdiction that will give me most advantages in my case. You're justifying choice of law. I can understand the benefits of choice of law, which can help make the licences more predictable. I do not understand why you need choice of venue. Unless we know how that venue treats absent defendants, any ambiguous terms in the licence and some other things, it looks rather like a licensor trying to get some advantage, such as being able to use their usual legal team against a smaller defendant and stopping that defendant being judged by their own state's people when appropriate. As you note, it isn't usual for free software licences to specify venue, as there are other agreements which do that. Why is choice of venue needed? The particular choice of Santa Clara County, California for opensolaris scares me - after all, it's where Adobe of freesklyarov.org fame chooses as venue for its licence disputes. But opensolaris isn't up for inclusion in debian itself, is it? What CDDL package is under discussion here? I await your reply with interest. Regards, -- 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: [Fwd: Debian and CDDL and DFSG]
MJ Ray wrote On 2006-08-09 15:23,: Martin Man [EMAIL PROTECTED] wrote: I do understand it in this way: - c-o-v as required by paragraph 9. of CDDL is a note attached to the license itself, to my understanding you can put there any jurisdiction you want (you as the author or contributor), and yes, it's there to predict and ensure that case will be treated properly (according to the state of law in a jurisdiction you put to the clause) - GPL does not have such c-o-v clause at all, which means that I can take anyone to any court I decide to, so to me, if I want to sue you, GPL gives me even more chance to manipulate the case and choose the jurisdiction that will give me most advantages in my case. You're justifying choice of law. I can understand the benefits of choice of law, which can help make the licences more predictable. I do not understand why you need choice of venue. Unless we know how that venue treats absent defendants, any ambiguous terms in the licence and some other things, it looks rather like a licensor trying to get some advantage, such as being able to use their usual legal team against a smaller defendant and stopping that defendant being judged by their own state's people when appropriate. As you note, it isn't usual for free software licences to specify venue, as there are other agreements which do that. Why is choice of venue needed? IANAL, and I have not designed CDDL, but as I understand it, choice of venue in CDDL == choce of law, don't know whether it would have been enough from the lawyer's perspective to put in the license [any litigations] ... will be held by any jurisdiction in USA... an interesting question by itself, I'll try to seek the answer by questioning our experts. The particular choice of Santa Clara County, California for opensolaris scares me - after all, it's where Adobe of freesklyarov.org fame chooses as venue for its licence disputes. But opensolaris isn't up for inclusion in debian itself, is it? What CDDL package is under discussion here? the original package in question was cdrtools by Joerg Schelling, Joerg was claiming that debian refuses to upgrade to a newer version of his sources because of CDDL, and because I could not believe his statement, I'm trying myself to get the information clarified (FYI: debian stable of course ships latest available stable cdrtools) but more generally, the code at opensolaris.org (not necessarily kernel) is and will be probably mostly licensed under CDDL, because CDDL is more commercial friendly than GPL (pretty much the same way as APL is), so my question was about any code that is CDDL and might be useful for debian (SMF[1] comes to my mind as an example) I await your reply with interest. Regards, thanx, Martin [1] http://www.opensolaris.org/os/community/smf/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
On Wednesday 09 August 2006 17:01, Martin Man wrote: MJ Ray wrote On 2006-08-09 15:23,: Martin Man [EMAIL PROTECTED] wrote: --cut-- the original package in question was cdrtools by Joerg Schelling, Joerg was claiming that debian refuses to upgrade to a newer version of his sources because of CDDL, and because I could not believe his statement, I'm trying myself to get the information clarified (FYI: debian stable of course ships latest available stable cdrtools) The problem is the obscure mix of GPL and CDDL licensed code (hence my previous question to what degree these are compatible). See bug #377109 for full explanation: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109 this has been beaten to death, the clear resolution is to dual-license the whole product under GPL/CDDL and it all be fine. but more generally, the code at opensolaris.org (not necessarily kernel) is and will be probably mostly licensed under CDDL, because CDDL is more commercial friendly than GPL (pretty much the same way as APL is), so my question was about any code that is CDDL and might be useful for debian (SMF[1] comes to my mind as an example) You seem to be confusing commercial and proprietary usage. For example Red Hat and Novell go commercial with GPL. Anyone can do that with Debian if s/he wants. Turning a free software into proprietary one is a regression. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
Hi George, George Danchev wrote On 2006-08-09 16:22,: On Wednesday 09 August 2006 17:01, Martin Man wrote: MJ Ray wrote On 2006-08-09 15:23,: Martin Man [EMAIL PROTECTED] wrote: --cut-- the original package in question was cdrtools by Joerg Schelling, Joerg was claiming that debian refuses to upgrade to a newer version of his sources because of CDDL, and because I could not believe his statement, I'm trying myself to get the information clarified (FYI: debian stable of course ships latest available stable cdrtools) The problem is the obscure mix of GPL and CDDL licensed code (hence my previous question to what degree these are compatible). See bug #377109 for full explanation: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109 this has been beaten to death, the clear resolution is to dual-license the whole product under GPL/CDDL and it all be fine. I see, thanx for the link You seem to be confusing commercial and proprietary usage. For example Red Hat and Novell go commercial with GPL. Anyone can do that with Debian if s/he wants. Turning a free software into proprietary one is a regression. I was talking about mixing opensource code (CDDL) with proprietary files in order to make a product that will bring you money, not pure commerce out of GPLed code, just to make it clear. thanx, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
Martin Man writes: Hi all, MJ Ray wrote On 2006-08-09 11:56,: Martin Man [EMAIL PROTECTED] wrote: I could find only a lot of FUD and inconsistencies on various blogs wrt/ choice of venue paragraph present in CDDL. Different people have different opinions. That should not surprise anyone. We are not a group-think corporation presenting a party line. fair enough, but if ftpmasters decide on inclusion/exclusion of certain software, there should at least be common consensus concerting certain license. This would be ideal, but neither law nor the DFSG are as repeatable as computer programs, so they are subject to reasonable disagreements. I don't think you should dismiss the venue problem as mere FUD so quickly. For a licensor as big as Sun to require developers to travel thousands of miles apparently on a whim is at best abusive and at worst a fee. If people are misunderstanding the venue clause (remember, U is uncertainty), then please explain, not flame. I do understand it in this way: - c-o-v as required by paragraph 9. of CDDL is a note attached to the license itself, to my understanding you can put there any jurisdiction you want (you as the author or contributor), and yes, it's there to predict and ensure that case will be treated properly (according to the state of law in a jurisdiction you put to the clause) - GPL does not have such c-o-v clause at all, which means that I can take anyone to any court I decide to, so to me, if I want to sue you, GPL gives me even more chance to manipulate the case and choose the jurisdiction that will give me most advantages in my case. There are existing rules about proper venue and jurisdiction that generally protect defendants against having to appear in places they have no regular or relevant presence. (At the least, the rules make it much easier to have such a lawsuit dismissed for improper venue.) The objection to c-o-v clauses is that they remove this kind of protection. I believe the general consensus is that c-o-v clauses are acceptable if they limit themselves to lawsuits naming the licensor as defendant, since those do not expose licensees to any adverse effects. In contrast, choice-of-law clauses are useful because they provide a frame of reference and set of definitions for terms of art. It is possible that certain choices of law would be non-free, but so far that is more an academic concern than actual. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
Marcel Ray [EMAIL PROTECTED] wrote: I do not understand why you need choice of venue. Unless we know how that venue treats absent defendants, any ambiguous terms in the licence and some other things, it looks rather like a licensor trying to get some advantage, such as being able to use their usual legal team against a smaller defendant and stopping that defendant being judged by their own state's people when appropriate. As you note, it isn't usual for free software licences to specify venue, as there are other agreements which do that. Why is choice of venue needed? (Small copyright holder with limited resources, large company with no business presence in copyright holder's state, copyright violation, but I think we've had this conversation before) The particular choice of Santa Clara County, California for opensolaris scares me - after all, it's where Adobe of freesklyarov.org fame chooses as venue for its licence disputes. It's where Sun are based, so it's hardly surprising. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
On Wednesday 09 August 2006 18:49, Matthew Garrett wrote: Marcel Ray [EMAIL PROTECTED] wrote: I do not understand why you need choice of venue. Unless we know how that venue treats absent defendants, any ambiguous terms in the licence and some other things, it looks rather like a licensor trying to get some advantage, such as being able to use their usual legal team against a smaller defendant and stopping that defendant being judged by their own state's people when appropriate. As you note, it isn't usual for free software licences to specify venue, as there are other agreements which do that. Why is choice of venue needed? (Small copyright holder with limited resources, large company with no business presence in copyright holder's state, copyright violation, but I think we've had this conversation before) An evil author (as copyright holder) despite his limited resources could cause lots of damage to a large company which has never violated his copyrights. This is even more scary. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
George Danchev [EMAIL PROTECTED] wrote: An evil author (as copyright holder) despite his limited resources could cause lots of damage to a large company which has never violated his copyrights. This is even more scary. Someone of sufficient evilness can do that whether they're acting within a license or not. They're already dishonest - who's going to stop them lying about the license contents? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
Matthew Garrett writes: George Danchev [EMAIL PROTECTED] wrote: An evil author (as copyright holder) despite his limited resources could cause lots of damage to a large company which has never violated his copyrights. This is even more scary. Someone of sufficient evilness can do that whether they're acting within a license or not. They're already dishonest - who's going to stop them lying about the license contents? Nobody can or will *stop* someone else from lying. But the liar can face penalties from the legal system: sanctions; liability for malicious prosecution and/or perjury; for the lawyer, potential disbarment. These go away if the license explicitly permits one side to be evil in this way. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
Michael Poole [EMAIL PROTECTED] wrote: Nobody can or will *stop* someone else from lying. But the liar can face penalties from the legal system: sanctions; liability for malicious prosecution and/or perjury; for the lawyer, potential disbarment. These go away if the license explicitly permits one side to be evil in this way. And choice of venue makes absolutely no difference here. Either the licensor is evil (in which case they'll end up losing and having to pay damages, providing that the licensee has had sufficient money to pay for the entire costs of the case) - or the licensor is correct in their lawsuit, in which case choice of venue merely lets them defend themselves more sensibly. Discriminating against choice of venue has no significant cost to evil licensors, but hurts wronged licensors. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
Matthew Garrett writes: Michael Poole [EMAIL PROTECTED] wrote: Nobody can or will *stop* someone else from lying. But the liar can face penalties from the legal system: sanctions; liability for malicious prosecution and/or perjury; for the lawyer, potential disbarment. These go away if the license explicitly permits one side to be evil in this way. And choice of venue makes absolutely no difference here. Either the licensor is evil (in which case they'll end up losing and having to pay damages, providing that the licensee has had sufficient money to pay for the entire costs of the case) - or the licensor is correct in their lawsuit, in which case choice of venue merely lets them defend themselves more sensibly. US jurisdictions in general are not loser-pays systems. From first-hand experience, regardless of eventual cost, it is a major inconvenience and impediment to fight a lawsuit 3000 miles away. (That experience is a large part of why I am so strongly opposed to this kind of clause.) Aside from the non-economic costs of an inconvenient forum, there is also no strong assurance of a defendant with a bulletproof case breaking even in a strictly monetary sense -- if the evil plaintiff is sufficiently evil or careful, he will have little or no recoverable assets by the end of the lawsuit, but he will have driven the defendant into serious financial inconvenience or bankruptcy. For background: Software lawsuits are generally federal cases in the US, which means the cost of entry is mid-five-figures USD. That goes up quickly if there is much fact discovery or motion practice; mid-six-figures is common, assuming one party can afford it. Finally, if the defendant settles -- for economic or other reasons -- before a court finally decides in his favor, no loser-pays law or contract clause will help. Discriminating against choice of venue has no significant cost to evil licensors, but hurts wronged licensors. Choice of venue makes life much easier on licensor plaintiffs, whether they are evil, honestly mistaken, or paragons of rightness. It makes life much harder on licensees. If you can find a legal system that makes trials convenient regardless of the parties' geographic locations, I expect it would be a valid choice of venue. Until then, one side must get preferential treatment, and I would rather it be the licensee. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
On Wed, 09 Aug 2006, Matthew Garrett wrote: Marcel Ray [EMAIL PROTECTED] wrote: I do not understand why you need choice of venue. Unless we know how that venue treats absent defendants, any ambiguous terms in the licence and some other things, it looks rather like a licensor trying to get some advantage, such as being able to use their usual legal team against a smaller defendant and stopping that defendant being judged by their own state's people when appropriate. As you note, it isn't usual for free software licences to specify venue, as there are other agreements which do that. Why is choice of venue needed? (Small copyright holder with limited resources, large company with no business presence in copyright holder's state, copyright violation, but I think we've had this conversation before) The choice of venue won't do anything to help in the cases where you allege a copyright violation, unless you also allege a license violation where the violator agreed to the license. If you're a small company going after a big company and the case is clear cut enough to be worth persuing, there are attorneys who will fight for commission, so even that isn't particularly useful. [Plus, we're generally talking about Free Software here, so the ultimate goal of any court challenge is (or should be) compliance, not renumeration. In those battles the SFLC and similar groups are quite capable of helping without the need of choice of venue.] As a final note, the only clearly legitimate case for choice of venue is for defensive purposes, where the licensor is the defendant; but for copyright, patents, etc. the plantiff won't have agreed to the license, so the clause is almost useless. [I suppose it may give you added protection against claims of negligence and similar, but that's about it.] Don Armstrong -- Identical parts aren't. -- Beach's Law http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Debian and CDDL and DFSG]
On Thursday 10 August 2006 01:07, Matthew Garrett wrote: Michael Poole [EMAIL PROTECTED] wrote: Nobody can or will *stop* someone else from lying. But the liar can face penalties from the legal system: sanctions; liability for malicious prosecution and/or perjury; for the lawyer, potential disbarment. These go away if the license explicitly permits one side to be evil in this way. And choice of venue makes absolutely no difference here. Either the licensor is evil (in which case they'll end up losing and having to pay damages, providing that the licensee has had sufficient money to pay for the entire costs of the case) - or the licensor is correct in their lawsuit, in which case choice of venue merely lets them defend themselves more sensibly. The venue could make significant difference here, because the licensor could be terribly wrong in one jurisdiction and correct in another. Furthermore you can hadly measure whether the licensor is evil or not, and can not just rely on his good faith. That why I believe that everyone (licensors and licensees) should be subject to his own jurisdiction, which they know best, and it is jurisdiction's (or state's) job to deal with legislation differences, bipartite agreements, repatration if necessary and so forth. Having that specified in the license inselt as a patch clause (act in an arbitrary manner) leaves room for speculations. This kind of 'moving sands' via patch clauses are quite similar to GFDL's invariant sections which Debian considers non-free. And yes, I don't think that CDDL license creators are evil and made that on purpose, instead I believe that they've made an unwitting mistake which will probably be corrected in the next version of the license, or at least I hope so. Discriminating against choice of venue has no significant cost to evil licensors, but hurts wronged licensors. That could depend on various circumstances. P.S. IANAL, but I discussed that with a friend of mine which is a lawyer. Since the lawyers tend to be conservative beasts, I challenge you to do the same. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Fwd: Debian and CDDL and DFSG]
Forwarding once again my email, since it seems it has not gone through to the list for the first time. ---BeginMessage--- Hi all, I was searching around the web regadring the $subj, but I was unable to find any official statement from Debian concerning the issue. Is there any document that describes why debian considers CDDL[1] to not be DFSG compliant (if that statement still holds true)? If there is no such document, could I get CDDL licensed software to main? Should I ask first debian-legal? what would be the answer? I could find only a lot of FUD and inconsistencies on various blogs wrt/ choice of venue paragraph present in CDDL. thanx for clarification, Martin 1. http://www.opensolaris.org/os/licensing/opensolaris_license/ ___ gnusol-users mailing list [EMAIL PROTECTED] http://lists.sonic.net/mailman/listinfo/gnusol-users ---End Message---
Re: [Fwd: Debian and CDDL and DFSG]
Martin Man writes: Forwarding once again my email, since it seems it has not gone through to the list for the first time. From: Martin Man [EMAIL PROTECTED] Subject: Debian and CDDL and DFSG To: [EMAIL PROTECTED], gnusol-users@gnusolaris.org Date: Mon, 07 Aug 2006 16:02:49 +0200 Hi all, I was searching around the web regadring the $subj, but I was unable to find any official statement from Debian concerning the issue. Is there any document that describes why debian considers CDDL[1] to not be DFSG compliant (if that statement still holds true)? If there is no such document, could I get CDDL licensed software to main? Should I ask first debian-legal? what would be the answer? I could find only a lot of FUD and inconsistencies on various blogs wrt/ choice of venue paragraph present in CDDL. Choice of venue provisions are often argued to impose fees upon redistribution. The fee-shifting provision seems even more problematic to me. The contract construction clause worries me to a lesser extent -- it seems superfluous but not necessarily harmful. Some people argue that forced self-identification (section 3.3) is impermissible. If you want an official statement from Debian one way or the other, you will probably need to find a sponsor for a general resolution; as far as I know, Debian has not appointed anyone with specific power to decide such questions in general. FTP-masters have the power to decide in particular cases by accepting or rejecting packages in NEW, but that is based on their judgment and not an official position. Michael Poole (Not a Debian Developer; not a lawyer) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
On Fri, 24 Mar 2006 01:28:37 + Måns Rullgård wrote: Francesco Poli [EMAIL PROTECTED] writes: On Tue, 21 Mar 2006 18:19:52 +0100 Eduard Bloch wrote: Don't count much on dvdrtools, it has no active upstream at all (no, I don't mean the guys whoes only heroic act was the replacement of the Schilly build system with autodev-stuff). That's a good reason to find someone willing to take over dvdrtools maintenance and development... We should really seek someone interested. Umm... they released a new version just a couple of weeks ago. What do you require of a project to count it as active? That's a question for Eduard, he is the one saying that dvdrtools lacks an active upstream... I was just concerned by the situation depicted by Eduard! ;-) -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpWvrqvcKw15.pgp Description: PGP signature
Re: cdrtools - GPL code with CDDL build system
On Tue, 21 Mar 2006 18:19:52 +0100 Eduard Bloch wrote: #include hallo.h * Francesco Poli [Tue, Mar 21 2006, 12:18:37AM]: [...] I used to hope that ignoring upstream insane statements doesn't include ignoring DFSG-freeness issues with the package, though!! :-( Relax. Let's expect an answer to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350739 - either cdrtools will be declared as licensed under the GPL or not under GPL, then we know what we are on. And yes, we shold face the possibility of the removal of cdrtools from Debian. It's hard to relax in these strange days, when some serious licensing bugs are magically declared non-bugs by the majority of the project (see GR-2006-001)... :-( Anyway, let's go on waiting (I've been waiting since september 2004...). since dvdrtools is in non-free too... Someone's launched an investigation into the reason for this. Let's wait and see what comes back. Assuming that its debian/copyright file is accurate (in Debian sid), it seems that the same license (and added restrictions, passed off as license interpretation) applies. If this is the case, my bet is that dvdrtools is in non-free for pretty the same reason why cdrtools should not be in main (at least, not as it is now)... Awkward! :-((( Don't count much on dvdrtools, it has no active upstream at all (no, I don't mean the guys whoes only heroic act was the replacement of the Schilly build system with autodev-stuff). That's a good reason to find someone willing to take over dvdrtools maintenance and development... We should really seek someone interested. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp26yzUJcVvu.pgp Description: PGP signature
Re: cdrtools - GPL code with CDDL build system
Francesco Poli [EMAIL PROTECTED] writes: On Tue, 21 Mar 2006 18:19:52 +0100 Eduard Bloch wrote: Don't count much on dvdrtools, it has no active upstream at all (no, I don't mean the guys whoes only heroic act was the replacement of the Schilly build system with autodev-stuff). That's a good reason to find someone willing to take over dvdrtools maintenance and development... We should really seek someone interested. Umm... they released a new version just a couple of weeks ago. What do you require of a project to count it as active? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
#include hallo.h * Francesco Poli [Tue, Mar 21 2006, 12:18:37AM]: D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Aaargh! :-( I was hoping this problem had been fixed... [...] How can such a package still be in main with this non-freeness? I'm surprised that nobody filed a serious bug for this... I guess everyone has just gotten used to Schilling's inane ramblings, and ignores him without further thought. I used to hope that ignoring upstream insane statements doesn't include ignoring DFSG-freeness issues with the package, though!! :-( Relax. Let's expect an answer to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350739 - either cdrtools will be declared as licensed under the GPL or not under GPL, then we know what we are on. And yes, we shold face the possibility of the removal of cdrtools from Debian. since dvdrtools is in non-free too... Someone's launched an investigation into the reason for this. Let's wait and see what comes back. Assuming that its debian/copyright file is accurate (in Debian sid), it seems that the same license (and added restrictions, passed off as license interpretation) applies. If this is the case, my bet is that dvdrtools is in non-free for pretty the same reason why cdrtools should not be in main (at least, not as it is now)... Awkward! :-((( Don't count much on dvdrtools, it has no active upstream at all (no, I don't mean the guys whoes only heroic act was the replacement of the Schilly build system with autodev-stuff). Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
On Mon, 20 Mar 2006 01:21:08 + Måns Rullgård wrote: Francesco Poli [EMAIL PROTECTED] writes: On Sat, 18 Mar 2006 22:05:53 + Måns Rullgård wrote: Eduard Bloch [EMAIL PROTECTED] writes: Hello debian-legal experts ;-), I need a bit support to clarify the issue with cdrtools' build system. Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Aaargh! :-( I was hoping this problem had been fixed... [...] How can such a package still be in main with this non-freeness? I'm surprised that nobody filed a serious bug for this... I guess everyone has just gotten used to Schilling's inane ramblings, and ignores him without further thought. I used to hope that ignoring upstream insane statements doesn't include ignoring DFSG-freeness issues with the package, though!! :-( Just use dvdrtools instead. ITYM dvd+rw-tools, That's what I use for burning DVDs. It doesn't handle CDs though. Ouch! It seems that we are left with *no* DFSG-free tools to burn CDs in Debian, until someone forks cdrtools (from a version prior to the license clarifications) or implements an equivalent program suite... since dvdrtools is in non-free too... Someone's launched an investigation into the reason for this. Let's wait and see what comes back. Assuming that its debian/copyright file is accurate (in Debian sid), it seems that the same license (and added restrictions, passed off as license interpretation) applies. If this is the case, my bet is that dvdrtools is in non-free for pretty the same reason why cdrtools should not be in main (at least, not as it is now)... Awkward! :-((( -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpEeLBCn5Ul1.pgp Description: PGP signature
Re: cdrtools - GPL code with CDDL build system
Francesco Poli [EMAIL PROTECTED] writes: On Mon, 20 Mar 2006 01:21:08 + Måns Rullgård wrote: Francesco Poli [EMAIL PROTECTED] writes: On Sat, 18 Mar 2006 22:05:53 + Måns Rullgård wrote: Just use dvdrtools instead. ITYM dvd+rw-tools, That's what I use for burning DVDs. It doesn't handle CDs though. Ouch! It seems that we are left with *no* DFSG-free tools to burn CDs in Debian, until someone forks cdrtools (from a version prior to the license clarifications) or implements an equivalent program suite... JS insists that his clarifications also apply to previous versions of cdrecord... since dvdrtools is in non-free too... Someone's launched an investigation into the reason for this. Let's wait and see what comes back. Assuming that its debian/copyright file is accurate (in Debian sid), it seems that the same license (and added restrictions, passed off as license interpretation) applies. If this is the case, my bet is that dvdrtools is in non-free for pretty the same reason why cdrtools should not be in main (at least, not as it is now)... The dvdrtools web page has this paragraph: dvdrtools is a fork of cdrtools, with the primary goals of remaining 100% Free Software (dvdrtools is a fork of the last version of cdrtools without any you are not allowed to modify this section comments), and adding support for DVD-R/DVD-RW drives and media. Checking the source, none of the troublesome bits from cdrtools are there, and the build system is replaced with automake. I can't see any problem with it. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
#include hallo.h * Måns Rullgård [Sun, Mar 19 2006, 01:50:24AM]: Sam Morris [EMAIL PROTECTED] writes: These are the bits I'm referring to, from cdrecorc.c (sorry for the long lines, but that's how it's written): ---BEGIN QUOTE--- /* * Begin restricted code for quality assurance. * * Warning: you are not allowed to modify or to remove the * Copyright and version printing code below! * See also GPL § 2 subclause c) ... For completeness, here's GPL 2c: ---BEGIN QUOTE--- c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) ---END QUOTE--- Take note that cdrecord is never interactive, so GPL 2c doesn't apply. Wrong. It displays messages by default and tells you how to stop the command etc. IMO this can clearly be interpreted as interaction. And since it does print such an announcement by default then it should be kept. However, I disagree on the level appropriateness - stuff like This is a broken Linux system does not belong to the disclaimer/copyright category. I don't know why JS refers to it, but then JS does a lot of things that nobody understands. This question is out of scope here. Eduard.
Re: cdrtools - GPL code with CDDL build system
Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Måns Rullgård [Sun, Mar 19 2006, 01:50:24AM]: Sam Morris [EMAIL PROTECTED] writes: These are the bits I'm referring to, from cdrecorc.c (sorry for the long lines, but that's how it's written): ---BEGIN QUOTE--- /* * Begin restricted code for quality assurance. * * Warning: you are not allowed to modify or to remove the * Copyright and version printing code below! * See also GPL § 2 subclause c) ... For completeness, here's GPL 2c: ---BEGIN QUOTE--- c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) ---END QUOTE--- Take note that cdrecord is never interactive, so GPL 2c doesn't apply. Wrong. It displays messages by default and tells you how to stop the command etc. IMO this can clearly be interpreted as interaction. It does not read commands interactively, which is the provision for GPL 2c applying. If every program that exits when it receives certain signals is interactive, then all programs are interactive (think SIGKILL). And since it does print such an announcement by default then it should be kept. However, I disagree on the level appropriateness - stuff like This is a broken Linux system does not belong to the disclaimer/copyright category. It is clearly not a copyright notice or disclaimer, and not being this restricting its removal is non-free. -- Måns Rullgård [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
* Mns Rullgrd [EMAIL PROTECTED] [060319 01:14]: Don Armstrong [EMAIL PROTECTED] writes: Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. I think derivative or not is not the question here, but the GPL explicitly demands that the build system is available under GPL-compatible changes. from Section 2 of the GPL: # b) You must cause any work that you distribute or publish, that in # whole or in part contains or is derived from the Program or any # part thereof, to be licensed as a whole at no charge to all third # parties under the terms of this License. from Section 3 of the GPLL: # Accompany it with the complete corresponding machine-readable # source code, which must be distributed under the terms of Sections # 1 and 2 above on a medium [...] # For an executable work, complete source # code means all the source code for all modules it contains, plus any # associated interface definition files, plus the scripts used to # control compilation and installation of the executable. scripts used to control compilation is clearly what we currently refer to as build system. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Bernhard R. Link [EMAIL PROTECTED] writes: * Mns Rullgrd [EMAIL PROTECTED] [060319 01:14]: Don Armstrong [EMAIL PROTECTED] writes: Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. I think derivative or not is not the question here, but the GPL explicitly demands that the build system is available under GPL-compatible changes. from Section 2 of the GPL: # b) You must cause any work that you distribute or publish, that in # whole or in part contains or is derived from the Program or any # part thereof, to be licensed as a whole at no charge to all third # parties under the terms of this License. from Section 3 of the GPLL: # Accompany it with the complete corresponding machine-readable # source code, which must be distributed under the terms of Sections # 1 and 2 above on a medium [...] # For an executable work, complete source # code means all the source code for all modules it contains, plus any # associated interface definition files, plus the scripts used to # control compilation and installation of the executable. scripts used to control compilation is clearly what we currently refer to as build system. Point taken. The obvious solution is to replace the build system with an acceptably licensed one. While at it, one could also make it work properly. Incidentally, this is what the dvdrtools folks have already done. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Eduard Bloch wrote: ---BEGIN QUOTE--- c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) ---END QUOTE--- Take note that cdrecord is never interactive, so GPL 2c doesn't apply. Wrong. It displays messages by default and tells you how to stop the command etc. IMO this can clearly be interpreted as interaction. Even if, for the sake of argument, we accept that send SIGINT to stop this program satisfies read[ing] commands interactively when run, notice the first part of the the text: If the *modified* program normally... So, if I modify the program to no longer prompt, I am no longer required to include that notice. What that clause is really covering is stuff like this: [EMAIL PROTECTED]:~$ bc bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. bc, unlike cdrecord, does actually read commands from standard input (its a calculator, if you're not familiar with it) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Måns Rullgård wrote: Incidentally, this is what the dvdrtools folks have already done. Ummm, come to think of it, why is dvdrtools in non-free while cdrecord is in main? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
#include hallo.h * Anthony DeRobertis [Sun, Mar 19 2006, 11:42:58AM]: Måns Rullgård wrote: Incidentally, this is what the dvdrtools folks have already done. Ummm, come to think of it, why is dvdrtools in non-free while cdrecord is in main? I am waiting for the answer of its maintainer. I suggest to desist from further speculation before it arrives. Eduard.
Re: cdrtools - GPL code with CDDL build system
On Sun, 19 Mar 2006 13:12:25 + Måns Rullgård wrote: And since it does print such an announcement by default then it should be kept. However, I disagree on the level appropriateness - stuff like This is a broken Linux system does not belong to the disclaimer/copyright category. It is clearly not a copyright notice or disclaimer, and not being this restricting its removal is non-free. Definitely non-free. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpjd3dj1VyIU.pgp Description: PGP signature
Re: cdrtools - GPL code with CDDL build system
On Sat, 18 Mar 2006 22:05:53 + Måns Rullgård wrote: Eduard Bloch [EMAIL PROTECTED] writes: Hello debian-legal experts ;-), I need a bit support to clarify the issue with cdrtools' build system. Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Aaargh! :-( I was hoping this problem had been fixed... I pointed out this very issue on debian-legal back in September _2004_: http://lists.debian.org/debian-legal/2004/09/msg3.html Steve McIntyre stated that cdrtools should have been forked from a version prior to the license clarifications: http://lists.debian.org/debian-legal/2004/09/msg9.html I thought that this was going to happen soon, and then had no more time to follow the issue. Now I see that the issue is still there! :-(( How can such a package still be in main with this non-freeness? I'm surprised that nobody filed a serious bug for this... Just use dvdrtools instead. ITYM dvd+rw-tools, since dvdrtools is in non-free too... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpAVfjedavUo.pgp Description: PGP signature
Re: cdrtools - GPL code with CDDL build system
Francesco Poli [EMAIL PROTECTED] writes: On Sat, 18 Mar 2006 22:05:53 + Måns Rullgård wrote: Eduard Bloch [EMAIL PROTECTED] writes: Hello debian-legal experts ;-), I need a bit support to clarify the issue with cdrtools' build system. Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Aaargh! :-( I was hoping this problem had been fixed... [...] How can such a package still be in main with this non-freeness? I'm surprised that nobody filed a serious bug for this... I guess everyone has just gotten used to Schilling's inane ramblings, and ignores him without further thought. Just use dvdrtools instead. ITYM dvd+rw-tools, That's what I use for burning DVDs. It doesn't handle CDs though. since dvdrtools is in non-free too... Someone's launched an investigation into the reason for this. Let's wait and see what comes back. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
On 3/18/06, Eduard Bloch [EMAIL PROTECTED] wrote: [...] Now the question: how GPL-compatible should we consider this CDDL-like license? And what's the scale and gradations for GPL-compatibility in your brainwashed (linking triggers GPL-incompatibility) mind? I just wonder. hahaha regards, alexander.
Re: cdrtools - GPL code with CDDL build system
Eduard Bloch [EMAIL PROTECTED] writes: Hello debian-legal experts ;-), I need a bit support to clarify the issue with cdrtools' build system. Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Just use dvdrtools instead. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
#include hallo.h * Alexander Terekhov [Sat, Mar 18 2006, 10:44:54PM]: On 3/18/06, Eduard Bloch [EMAIL PROTECTED] wrote: [...] Now the question: how GPL-compatible should we consider this CDDL-like license? And what's the scale and gradations for GPL-compatibility in your brainwashed (linking triggers GPL-incompatibility) mind? I just wonder. hahaha Troll feeding day is friday. You are too late, please come next week. Eduard. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Eduard Bloch [EMAIL PROTECTED] wrote: Now the question: how GPL-compatible should we consider this CDDL-like license? See http://www.gnu.org/licenses/license-list.html for details. The CDDL and GPL are incompatible. We have the option of splitting the source package into code (GPLed) and meta-code (CDDL). Would that be suitable for main? No. In fact, you can not even distribute it in non-free. You have to replace the build system. Sorry for the bad news. Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
On Sat, 18 Mar 2006, Eduard Bloch wrote: Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. Can we just fork from a version of the build system which did not contain the CDDL and make whatever changes to it are necessary for it to build? In #350739, the reporter claims that we and JS are violating the GPL because not all files required to create the executable work are available under the GPL license. It's not that they have to be available, it's just that they have to be compatible. [Moreover, JS violation of the GPL isn't interesting because he's presumably the copyright holder, and can therefore do whatever he wants with his work.] CDDL is considered GPL-incompatible for linking with GPLed code. Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. Discussion with upstream in hope to make it double-licensed was not very fruitfull. He defines his tarball as medium (in terms of our DFSG!) where the two parts of the software (code and build system) are allowed to coexist, and if we would not allow that, then we had prooved that GPL violates the DFSG (because it infects other software on the same medium, hahaha). It would then activate the GPL's mere aggregation clause, but that's clearly not the case here. Now the question: how GPL-compatible should we consider this CDDL-like license? See http://www.gnu.org/licenses/license-list.html for details. The FSF's summary on this issue is fairly authoritative. Indeed, the patent reciprocity clause may also render software under this license non-free. We have the option of splitting the source package into code (GPLed) and meta-code (CDDL). Would that be suitable for main? I don't see how this would get around the GPL incompatibility issues, as the build system is only useful for cdrecord. Don Armstrong -- When I was a kid I used to pray every night for a new bicycle. Then I realised that the Lord doesn't work that way so I stole one and asked Him to forgive me. -- Emo Philips. http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
