From MAILER-DAEMON Tue Jul 03 12:06:20 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Sm5cK-0002dW-Ek for mharc-help-bison@gnu.org; Tue, 03 Jul 2012 12:06:20 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Slxoh-0007Hn-Pw for help-bison@gnu.org; Tue, 03 Jul 2012 03:46:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Slxob-00005B-4k for help-bison@gnu.org; Tue, 03 Jul 2012 03:46:35 -0400 Received: from postman.teamix.net ([194.150.191.120]:60941 helo=rproxy.teamix.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Slxoa-00004v-S1 for help-bison@gnu.org; Tue, 03 Jul 2012 03:46:29 -0400 Received: from zimbra.of.teamix.net (unknown [172.21.242.23]) by rproxy.teamix.net (Postfix) with ESMTP id 94B5D7A0A7; Tue, 3 Jul 2012 09:46:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.of.teamix.net (Postfix) with ESMTP id 7B07C146C76; Tue, 3 Jul 2012 09:46:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at of.teamix.net Received: from zimbra.of.teamix.net ([127.0.0.1]) by localhost (zimbra.of.teamix.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqbS7v6I2R7A; Tue, 3 Jul 2012 09:46:16 +0200 (CEST) Received: from mango.localnet (mango.of.teamix.net [172.21.123.1]) by zimbra.of.teamix.net (Postfix) with ESMTPSA id D025D146C75; Tue, 3 Jul 2012 09:46:16 +0200 (CEST) From: Martin Steigerwald Organization: teamix GmbH To: help-bison@gnu.org, licensing@fsf.org Subject: Fwd: Re: filebench: bison generated parser + CDDL Date: Tue, 3 Jul 2012 09:47:58 +0200 User-Agent: KMail/1.13.7 (Linux/3.4-trunk-amd64; KDE/4.8.3; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201207030947.59044.ms@teamix.de> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 194.150.191.120 X-Mailman-Approved-At: Tue, 03 Jul 2012 12:06:17 -0400 Cc: filebench-developers@lists.sourceforge.net, Sebastian Harl , Alex Mestiashvili X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 07:46:42 -0000 Please keep Cc, as I am not subscribed to help-bison or filebench-developer= s. Dear bison developers, dear FSF licensing team, dear filebench developers, Alex Mestiashvili and I have packaged filebench for Debian. But now I wonde= r=20 whether we may legally distribute it. Bison uses a bison generated parser from parser_gram.y and these generated= =20 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 | [=E2=80=A6] | 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 t= his=20 special exception correctly, in the case that no new parser generator is do= ne=20 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=20 indicates that the exception could be interpreted from its intent or its=20 wording and this gives different results as to the redistributability of th= e=20 software =E2=80=93 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 =2D--------- Weitergeleitete Nachricht ---------- Betreff: Re: filebench: bison generated parser + CDDL Datum: Samstag, 2. Juni 2012, 22:29:41 Von: Mark Weyer 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. >=20 > I don=C2=B4t understand this. >=20 > I understand the exception >=20 > | 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. >=20 > so that it allows distributing the software under any other license as=20 > long as the generated parser isn=C2=B4t a parser generator in itself. >=20 > I don=C2=B4t think that the parser in here is a parser generator. As far = as I=20 > understand parser_gram.c and parser_gram.h just parses loadable workload= =20 > 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 i= ts 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 fi= ne (You can't do that yourself, because A: the exception grants that right only to the creator of the larger work a= nd B: if upstream does not exercise the right of the exception, then they do n= ot have the right to distribute filebench under anything other than the GPL= =2E) I am not a lawyer, this is not legal advice, et cetera. Mark Weyer =2D- To UNSUBSCRIBE, email to debian-legal-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.o= rg Archive: http://lists.debian.org/20120602202941.GA1911@debian =2D------------------------------------------------------------ Ciao, =2D-=20 Martin Steigerwald - teamix GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 From MAILER-DAEMON Tue Jul 03 12:06:21 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Sm5cK-0002e3-M5 for mharc-help-bison@gnu.org; Tue, 03 Jul 2012 12:06:20 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sly54-0001KP-M4 for help-bison@gnu.org; Tue, 03 Jul 2012 04:03:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sly4y-0004hM-Sa for help-bison@gnu.org; Tue, 03 Jul 2012 04:03:30 -0400 Received: from postman.teamix.net ([194.150.191.120]:38165 helo=rproxy.teamix.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sly4y-0004h9-K8 for help-bison@gnu.org; Tue, 03 Jul 2012 04:03:24 -0400 Received: from zimbra.of.teamix.net (unknown [172.21.242.23]) by rproxy.teamix.net (Postfix) with ESMTP id 3F9B27A0A7; Tue, 3 Jul 2012 10:03:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.of.teamix.net (Postfix) with ESMTP id 2E304146C76; Tue, 3 Jul 2012 10:03:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at of.teamix.net Received: from zimbra.of.teamix.net ([127.0.0.1]) by localhost (zimbra.of.teamix.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4KMGPO6VnD1; Tue, 3 Jul 2012 10:03:13 +0200 (CEST) Received: from mango.localnet (mango.of.teamix.net [172.21.123.1]) by zimbra.of.teamix.net (Postfix) with ESMTPSA id 6E476146C75; Tue, 3 Jul 2012 10:03:13 +0200 (CEST) To: help-bison@gnu.org, licensing@fsf.org Subject: Fwd: Re: filebench: bison generated parser + CDDL From: Martin Steigerwald Organization: teamix GmbH Date: Tue, 3 Jul 2012 10:04:55 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201207031004.55822.ms@teamix.de> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 194.150.191.120 X-Mailman-Approved-At: Tue, 03 Jul 2012 12:06:18 -0400 Cc: filebench-developers@lists.sourceforge.net, debian-legal@lists.debian.org, Sebastian Harl , Alex Mestiashvili X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 08:03:32 -0000 Sorry, forgot to Cc debian-legal mailing list. Please keep Cc, as I am not subscribed to help-bison or filebench-developer= s. Dear bison developers, dear FSF licensing team, dear filebench developers, Alex Mestiashvili and I have packaged filebench for Debian. But now I wonde= r=20 whether we may legally distribute it. Bison uses a bison generated parser from parser_gram.y and these generated= =20 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 | [=E2=80=A6] | 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 t= his=20 special exception correctly, in the case that no new parser generator is do= ne=20 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=20 indicates that the exception could be interpreted from its intent or its=20 wording and this gives different results as to the redistributability of th= e=20 software =E2=80=93 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 =2D--------- Weitergeleitete Nachricht ---------- Betreff: Re: filebench: bison generated parser + CDDL Datum: Samstag, 2. Juni 2012, 22:29:41 Von: Mark Weyer 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. >=20 > I don=C2=B4t understand this. >=20 > I understand the exception >=20 > | 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. >=20 > so that it allows distributing the software under any other license as=20 > long as the generated parser isn=C2=B4t a parser generator in itself. >=20 > I don=C2=B4t think that the parser in here is a parser generator. As far = as I=20 > understand parser_gram.c and parser_gram.h just parses loadable workload= =20 > 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 i= ts 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 fi= ne (You can't do that yourself, because A: the exception grants that right only to the creator of the larger work a= nd B: if upstream does not exercise the right of the exception, then they do n= ot have the right to distribute filebench under anything other than the GPL= =2E) I am not a lawyer, this is not legal advice, et cetera. Mark Weyer =2D- To UNSUBSCRIBE, email to debian-legal-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.o= rg Archive: http://lists.debian.org/20120602202941.GA1911@debian =2D------------------------------------------------------------ Ciao, =2D-=20 Martin Steigerwald - teamix GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 From MAILER-DAEMON Wed Jul 04 03:24:45 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SmJx7-0005Bp-Hp for mharc-help-bison@gnu.org; Wed, 04 Jul 2012 03:24:45 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmJwz-00058n-C9 for help-bison@gnu.org; Wed, 04 Jul 2012 03:24:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmJww-0000dV-Ct for help-bison@gnu.org; Wed, 04 Jul 2012 03:24:36 -0400 Received: from sao-paulo.lrde.epita.fr ([163.5.55.1]:60015 helo=kualalumpur.lrde.epita.fr) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmJww-0000NX-3y for help-bison@gnu.org; Wed, 04 Jul 2012 03:24:34 -0400 Received: from erebus.lrde.epita.fr ([192.168.101.165]) by kualalumpur.lrde.epita.fr with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1SmJwO-0006tz-UY; Wed, 04 Jul 2012 09:24:01 +0200 Subject: Re: filebench: bison generated parser + CDDL Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Akim Demaille In-Reply-To: <201207030947.59044.ms@teamix.de> Date: Wed, 4 Jul 2012 09:24:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201207030947.59044.ms@teamix.de> To: Martin Steigerwald X-Mailer: Apple Mail (2.1278) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 163.5.55.1 Cc: Sebastian Harl , Alex Mestiashvili , Brett Smith , debian-legal@lists.debian.org, filebench-developers@lists.sourceforge.net, licensing@fsf.org, Bison Help X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 07:24:43 -0000 Hi all, I have added Bret in CC, as he is the one to deal with licenses and exceptions. Le 3 juil. 2012 =E0 09:47, Martin Steigerwald a =E9crit : > Please keep Cc, as I am not subscribed to help-bison or = filebench-developers. >=20 >=20 >=20 > Dear bison developers, dear FSF licensing team, dear filebench = developers, >=20 > Alex Mestiashvili and I have packaged filebench for Debian. But now I = wonder=20 > whether we may legally distribute it. >=20 > Bison uses a bison generated parser from parser_gram.y and these = generated=20 > files are: >=20 > | 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 > | [=85] > | 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. >=20 > 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=20 > special exception correctly, in the case that no new parser generator = is done=20 > any terms, any license can be used for the resulting work. >=20 > I asked this already on debian-legal and got an IANAL response back = that=20 > indicates that the exception could be interpreted from its intent or = its=20 > wording and this gives different results as to the redistributability = of the=20 > software =96 see below. >=20 > Dear FSF licensing team, dear bison developers, can you elaborate on = that? >=20 > If its not clearly redistributable then what changes could make it so? >=20 > Thanks, > Martin >=20 >=20 > ---------- Weitergeleitete Nachricht ---------- >=20 > Betreff: Re: filebench: bison generated parser + CDDL > Datum: Samstag, 2. Juni 2012, 22:29:41 > Von: Mark Weyer > An: debian-legal@lists.debian.org >=20 > 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. >>=20 >> I don=B4t understand this. >>=20 >> I understand the exception >>=20 >> | 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. >>=20 >> so that it allows distributing the software under any other license = as=20 >> long as the generated parser isn=B4t a parser generator in itself. >>=20 >> I don=B4t think that the parser in here is a parser generator. As far = as I=20 >> understand parser_gram.c and parser_gram.h just parses loadable = workload=20 >> 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. >=20 > 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. Skeletons are really dynamic, they are not plain files with simple substitutions, they are "run" by M4. So this scenario does not make sense in practice, IMHO. > 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. >=20 > The true question is, of course, whether a court would judge in favour = of > the exception's letter or its intent. >=20 > 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. >=20 > 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.) >=20 > I am not a lawyer, this is not legal advice, et cetera. >=20 > Mark Weyer >=20 >=20 > -- > To UNSUBSCRIBE, email to debian-legal-REQUEST@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact = listmaster@lists.debian.org > Archive: http://lists.debian.org/20120602202941.GA1911@debian >=20 >=20 > ------------------------------------------------------------- >=20 > Ciao, > --=20 > Martin Steigerwald - teamix GmbH - http://www.teamix.de > gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 >=20 > _______________________________________________ > help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison From MAILER-DAEMON Thu Jul 05 10:52:35 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SmnQ3-0004M7-94 for mharc-help-bison@gnu.org; Thu, 05 Jul 2012 10:52:35 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmnPw-0004LL-QN for help-bison@gnu.org; Thu, 05 Jul 2012 10:52:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmnPp-0003iB-Nb for help-bison@gnu.org; Thu, 05 Jul 2012 10:52:28 -0400 Received: from sao-paulo.lrde.epita.fr ([163.5.55.1]:56555 helo=kualalumpur.lrde.epita.fr) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmnPa-0003dB-H2; Thu, 05 Jul 2012 10:52:07 -0400 Received: from erebus.lrde.epita.fr ([192.168.101.165]) by kualalumpur.lrde.epita.fr with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1SmnPX-0007x8-QM; Thu, 05 Jul 2012 16:52:03 +0200 From: Akim Demaille Subject: bison-2.5.90 released [beta] Date: Thu, 5 Jul 2012 16:52:03 +0200 Message-Id: To: Bison Bugs Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 163.5.55.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: coordinator@translationproject.org, Bison Help , Bison Patches X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 14:52:34 -0000 The Bison team is happy to announce the forthcoming release of Bison 2.6. In this release, a special emphasis was put on producing more complete, and more usable, parser headers. Here are the compressed sources: ftp://alpha.gnu.org/gnu/bison/bison-2.5.90.tar.gz (2.9MB) ftp://alpha.gnu.org/gnu/bison/bison-2.5.90.tar.xz (1.6MB) Here are the GPG detached signatures[*]: ftp://alpha.gnu.org/gnu/bison/bison-2.5.90.tar.gz.sig ftp://alpha.gnu.org/gnu/bison/bison-2.5.90.tar.xz.sig Use a mirror for higher download bandwidth: http://www.gnu.org/order/ftp.html [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify bison-2.5.90.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys 0DDCAA3278D5264E and rerun the 'gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.69 Automake 1.12.1 Flex 2.5.35 Gettext 0.18.1 Gnulib v0.0-7503-gbe2b039 NEWS * Noteworthy changes in release 2.5.90 (2012-07-05) [beta] ** Future Changes The next major release of Bison will drop support for the following deprecated features. Please report disagreements to bug-bison@gnu.org. *** K&C parsers Support for generating parsers in K&R C will be removed. Parsers generated for C support ISO C90, and are tested with ISO C99 and ISO C11 compilers. *** Features deprecated since Bison 1.875 The definitions of yystype and yyltype will be removed; use YYSTYPE and YYLTYPE. YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of %parse-param and %lex-param, will no longer be supported. Support for the preprocessor symbol YYERROR_VERBOSE will be removed, use %error-verbose. *** The generated header will be included (yacc.c) Instead of duplicating the content of the generated header (definition of YYSTYPE, yyparse declaration etc.), the generated parser will include it, as is already the case for GLR or C++ parsers. This change is deferred because existing versions of ylwrap (e.g., Automake 1.12.1) do not support it. ** Generated Parser Headers *** Guards (yacc.c, glr.c, glr.cc) The generated headers are now guarded, as is already the case for C++ parsers (lalr1.cc). For instance, with --defines=foo.h: #ifndef YY_FOO_H # define YY_FOO_H ... #endif /* !YY_FOO_H */ *** New declarations (yacc.c, glr.c) The generated header now declares yydebug and yyparse. Both honor --name-prefix=bar_, and yield int bar_parse (void); rather than #define yyparse bar_parse int yyparse (void); in order to facilitate the inclusion of several parser headers inside a single compilation unit. *** Exported symbols in C++ The symbols YYTOKEN_TABLE and YYERROR_VERBOSE, which were defined in the header, are removed, as they prevent the possibility of including several generated headers from a single compilation unit. *** YYLSP_NEEDED For the same reasons, the undocumented and unused macro YYLSP_NEEDED is no longer defined. ** New %define variable: api.prefix Now that the generated headers are more complete and properly protected against multiple inclusions, constant names, such as YYSTYPE are a problem. While yyparse and others are properly renamed by %name-prefix, YYSTYPE, YYDEBUG and others have never been affected by it. Because it would introduce backward compatibility issues in projects not expecting YYSTYPE to be renamed, instead of changing the behavior of %name-prefix, it is deprecated in favor of a new %define variable: api.prefix. The following examples compares both: %name-prefix "bar_" | %define api.prefix "bar_" %token FOO %token FOO %union { int ival; } %union { int ival; } %% %% exp: 'a'; exp: 'a'; bison generates: #ifndef BAR_FOO_H #ifndef BAR_FOO_H # define BAR_FOO_H # define BAR_FOO_H /* Enabling traces. */ /* Enabling traces. */ # ifndef YYDEBUG | # ifndef BAR_DEBUG > # if defined YYDEBUG > # if YYDEBUG > # define BAR_DEBUG 1 > # else > # define BAR_DEBUG 0 > # endif > # else # define YYDEBUG 0 | # define BAR_DEBUG 0 > # endif # endif | # endif # if YYDEBUG | # if BAR_DEBUG extern int bar_debug; extern int bar_debug; # endif # endif /* Tokens. */ /* Tokens. */ # ifndef YYTOKENTYPE | # ifndef BAR_TOKENTYPE # define YYTOKENTYPE | # define BAR_TOKENTYPE enum yytokentype { | enum bar_tokentype { FOO = 258 FOO = 258 }; }; # endif # endif #if ! defined YYSTYPE \ | #if ! defined BAR_STYPE \ && ! defined YYSTYPE_IS_DECLARED | && ! defined BAR_STYPE_IS_DECLARED typedef union YYSTYPE | typedef union BAR_STYPE { { int ival; int ival; } YYSTYPE; | } BAR_STYPE; # define YYSTYPE_IS_DECLARED 1 | # define BAR_STYPE_IS_DECLARED 1 #endif #endif extern YYSTYPE bar_lval; | extern BAR_STYPE bar_lval; int bar_parse (void); int bar_parse (void); #endif /* !BAR_FOO_H */ #endif /* !BAR_FOO_H */ From MAILER-DAEMON Tue Jul 17 11:53:46 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SrA5q-0007zi-CR for mharc-help-bison@gnu.org; Tue, 17 Jul 2012 11:53:46 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sr2hz-0002hg-EM for help-bison@gnu.org; Tue, 17 Jul 2012 04:00:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sr2hx-0003l5-Mi for help-bison@gnu.org; Tue, 17 Jul 2012 04:00:39 -0400 Received: from mail-vc0-f169.google.com ([209.85.220.169]:49781) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sr2hx-0003kX-FQ for help-bison@gnu.org; Tue, 17 Jul 2012 04:00:37 -0400 Received: by vcbfl10 with SMTP id fl10so99243vcb.0 for ; Tue, 17 Jul 2012 01:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qOxjK9vXCdKUCiB7C+iacWZ70MawJV3gA9RTvNRSNdU=; b=dyIme2eiFvhSrZ7Eo25zdhhcE9/A234VfM79OFiVQ7mB73LYCQvFuUOysvnEOPwEDT Fik17gbCAXgF/JEy//tlKspfj3gIQ086ZDO0PjM3YX9KW4mJcN2GbTxn6I1PQ8ixUpLt EyYdy4g8Zi+BFMhh5b2SaKIO44wjbavVANYia8ud/4VNi+AxgXM/+aswQd4uEo4IwdcE 0y79HTD4SqXvYakV7JD3hEbjdZW0/DDI7ypj+wOfMR4G7sVR5q1B3u9uRhU57jRYk7LS q7U9gDyOsh/fi1txbLTWtoh+bw2dSOtUVFJTcItK5rzGcGSKleAyQbp7cRs23cfxdCvF uXcg== MIME-Version: 1.0 Received: by 10.220.219.69 with SMTP id ht5mr22866vcb.2.1342512036008; Tue, 17 Jul 2012 01:00:36 -0700 (PDT) Received: by 10.220.9.198 with HTTP; Tue, 17 Jul 2012 01:00:35 -0700 (PDT) Date: Tue, 17 Jul 2012 10:00:35 +0200 Message-ID: Subject: fixed size stack From: Claudio Eterno To: help-bison@gnu.org X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.220.169 X-Mailman-Approved-At: Tue, 17 Jul 2012 11:53:45 -0400 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 08:00:45 -0000 Hi folks, I'm writing here due to some configuration problems on bison. My question: I would like to use bison for an embedded application (based on a uC with only 16kb of ram a 256 kb of flash). Due to the limited resources reasons and also I know exactly the maximum size of the necessary stack, I don't want to occupy the memory with me unuseful library functions (like malloc for example). Anyway, is this possible to remove the alloc/malloc/realloc functions during compilation? Thank you, Claudio -- Claudio Eterno via colle dell'Assietta 17 10036 Settimo Torinese (TO) Linux user n. 499785 registered on linuxcounter.net From MAILER-DAEMON Tue Jul 17 11:53:49 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SrA5t-00087C-G6 for mharc-help-bison@gnu.org; Tue, 17 Jul 2012 11:53:49 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sr3v2-0003ld-Jn for help-bison@gnu.org; Tue, 17 Jul 2012 05:18:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sr3uv-0007od-6T for help-bison@gnu.org; Tue, 17 Jul 2012 05:18:12 -0400 Received: from mail-vb0-f41.google.com ([209.85.212.41]:64346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sr3uu-0007nq-QT for help-bison@gnu.org; Tue, 17 Jul 2012 05:18:05 -0400 Received: by vbkv13 with SMTP id v13so145288vbk.0 for ; Tue, 17 Jul 2012 02:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cXHtcoRhhky47hh23Vsd/MSzKR6S4aBG5g6msm8xPrE=; b=p+9TmzzvyXcFuKUKtxkbgyHTf90OwAEX1/q877kfh/VVV3cnRV8olLiIwliaVPU+FF i1Gn5gp41456FH4mXnzN84EzBCPECrD4nutSVvzc+rm1WMPznMrM+iOZUd2kSjMFl8vS 76xzFPNgVWSBsGAWQiCrXw5qZ4uPUworaA3rdf8YPuLajGI3a88xgyZXsMv+3IDLhzfg N3Wkv0xYFFdTw+IVpoW+nPoEv7KNFA3DgHA7y5HFd3HNWcntjMjFyhFjRvJlJp0KjZgT SYRHkxfFojKBmMeAfKXwAR/sCbqszqmViMXbkrwimyFpRHkS3DkCt39ahdT+Lc3QNqjJ P7nQ== MIME-Version: 1.0 Received: by 10.220.219.69 with SMTP id ht5mr117693vcb.2.1342516684075; Tue, 17 Jul 2012 02:18:04 -0700 (PDT) Received: by 10.220.9.198 with HTTP; Tue, 17 Jul 2012 02:18:04 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Jul 2012 11:18:04 +0200 Message-ID: Subject: fixed size stack From: Claudio Eterno To: help-bison@gnu.org X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.41 X-Mailman-Approved-At: Tue, 17 Jul 2012 11:53:48 -0400 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 09:18:16 -0000 Hi folks, I'm writing here due to some configuration problems on bison. My question: I would like to use bison for an embedded application (based on a uC with only 16kb of ram a 256 kb of flash). Due to the limited resources reasons and also I know exactly the maximum size of the necessary stack, I don't want to occupy the memory with me unuseful library functions (like malloc for example). Anyway, is this possible to remove the alloc/malloc/realloc functions during compilation? Thank you, Claudio -- Claudio Eterno via colle dell'Assietta 17 10036 Settimo Torinese (TO) Linux user n. 499785 registered on linuxcounter.net -- Claudio Eterno via colle dell'Assietta 17 10036 Settimo Torinese (TO) Linux user n. 499785 registered on linuxcounter.net From MAILER-DAEMON Wed Jul 18 03:56:49 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SrP7p-0007dF-ND for mharc-help-bison@gnu.org; Wed, 18 Jul 2012 03:56:49 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrP7n-0007cw-7c for help-bison@gnu.org; Wed, 18 Jul 2012 03:56:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SrP7m-0005Cp-5Y for help-bison@gnu.org; Wed, 18 Jul 2012 03:56:47 -0400 Received: from sao-paulo.lrde.epita.fr ([163.5.55.1]:58648 helo=kualalumpur.lrde.epita.fr) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrP7l-0005Ck-T8 for help-bison@gnu.org; Wed, 18 Jul 2012 03:56:46 -0400 Received: from erebus.lrde.epita.fr ([192.168.101.165]) by kualalumpur.lrde.epita.fr with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1SrP7l-0007QH-CV; Wed, 18 Jul 2012 09:56:45 +0200 Subject: Re: fixed size stack Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Akim Demaille In-Reply-To: Date: Wed, 18 Jul 2012 09:56:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F1093CB-5FD9-452C-ABF0-D2B78767CED0@lrde.epita.fr> References: To: Claudio Eterno X-Mailer: Apple Mail (2.1278) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 163.5.55.1 Cc: help-bison@gnu.org X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 07:56:48 -0000 Le 17 juil. 2012 =E0 10:00, Claudio Eterno a =E9crit : > Hi folks, > I'm writing here due to some configuration problems on bison. > My question: I would like to use bison for an embedded application = (based > on a uC with only 16kb of ram a 256 kb of flash). Due to the limited > resources reasons and also I know exactly the maximum size of > the necessary stack, I don't want to occupy the memory with me = unuseful > library functions (like malloc for example). Anyway, is this possible = to > remove the alloc/malloc/realloc functions during compilation? Hi Claudio, A quick test seems to be conclusive. Did you experiment differently? $ cat /tmp/foo.y %code { # include # define YYINITDEPTH 10 # define YYMAXDEPTH YYINITDEPTH void yyerror(const char* msg) { fprintf (stderr, "%s\n", msg); } void *malloc(size_t s) { (void) s; yyerror ("called malloc"); return 0; } int yylex() { return '1'; } } %% exp: '1' | '1' exp; %% int main () { return !!yyparse(); } $ bison foo.y $ gcc-mp-4.8 -Wall -Wextra foo.tab.c $ ./a.out memory exhausted $ nm a.out 0000000100002060 S _NXArgc 0000000100002068 S _NXArgv 0000000100002078 S ___progname U ___stderrp 0000000100000000 A __mh_execute_header 0000000100002070 S _environ U _exit U _fprintf U _free 0000000100001c70 T _main 0000000100001540 T _malloc U _memcpy 0000000100002000 s _pvars 0000000100002080 S _yychar 0000000100001e7c s _yycheck 0000000100001e6a s _yydefact 0000000100001e6f s _yydefgoto 000000010000156a t _yydestruct 0000000100001510 T _yyerror 000000010000155f T _yylex 0000000100002084 S _yylval 0000000100002088 S _yynerrs 0000000100001e71 s _yypact 000000010000158f T _yyparse 0000000100001e76 s _yypgoto 0000000100001e62 s _yyr1 0000000100001e66 s _yyr2 0000000100001e80 s _yystos 0000000100001e78 s _yytable 0000000100001d60 s _yytranslate U dyld_stub_binder 00000001000014d4 T start $ You show read the generated code, and see, for instance, that verbose error message for instance, do require malloc. From MAILER-DAEMON Wed Jul 18 15:33:25 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SrZzx-0005kC-Q0 for mharc-help-bison@gnu.org; Wed, 18 Jul 2012 15:33:25 -0400 Received: from eggs.gnu.org ([208.118.235.92]:57313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrZzu-0005iM-6y for help-bison@gnu.org; Wed, 18 Jul 2012 15:33:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SrZzs-0005U6-7B for help-bison@gnu.org; Wed, 18 Jul 2012 15:33:22 -0400 Received: from smtp201.alice.it ([82.57.200.97]:40081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrZzr-0005Tf-Sh for help-bison@gnu.org; Wed, 18 Jul 2012 15:33:20 -0400 Received: from [192.168.1.161] (87.8.9.235) by smtp201.alice.it (8.6.023.02) (authenticated as lucamarzolla) id 5006060E00093AE9; Wed, 18 Jul 2012 21:33:17 +0200 Message-ID: <50070F80.5070309@tin.it> Date: Wed, 18 Jul 2012 21:33:20 +0200 From: Luca User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Claudio Eterno Subject: Re: fixed size stack References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.57.200.97 Cc: help-bison@gnu.org X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 19:33:24 -0000 As a compiler and firmware writer, I think this is a very interesting issue. First, take into account to use the bison macro YYMALLOC and YYFREE (see bison output c file). Then I can suggest to use a tiny and efficient memory manager like this one: http://eli.thegreenplace.net/2008/10/17/memmgr-a-fixed-pool-memory-allocator/ I used it on a uC with 96 KB of RAM, without bison but with a RTOS running many task: a TCP-IP task to manage a webserver, a SPI task, many tasks for UART and also with two proprietary interpreters. Moreover, the library allows a printout of allocation statistics that will help to understand how the memory is used. Luca On 17/07/2012 10:00, Claudio Eterno wrote: > Hi folks, > I'm writing here due to some configuration problems on bison. > My question: I would like to use bison for an embedded application (based > on a uC with only 16kb of ram a 256 kb of flash). Due to the limited > resources reasons and also I know exactly the maximum size of > the necessary stack, I don't want to occupy the memory with me unuseful > library functions (like malloc for example). Anyway, is this possible to > remove the alloc/malloc/realloc functions during compilation? > Thank you, > Claudio > From MAILER-DAEMON Thu Jul 19 03:26:32 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Srl84-0003XV-Fu for mharc-help-bison@gnu.org; Thu, 19 Jul 2012 03:26:32 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Srl81-0003Vb-HP for help-bison@gnu.org; Thu, 19 Jul 2012 03:26:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Srl7x-0003mo-4Z for help-bison@gnu.org; Thu, 19 Jul 2012 03:26:29 -0400 Received: from mail-vc0-f169.google.com ([209.85.220.169]:38565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Srl7x-0003mk-0W for help-bison@gnu.org; Thu, 19 Jul 2012 03:26:25 -0400 Received: by vcbfl10 with SMTP id fl10so2163631vcb.0 for ; Thu, 19 Jul 2012 00:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=INM5UX58fLacOseL4IhZV2kYRipx2ZWfNkWpuLBGsV4=; b=qhJccqfTt7jCRYpfqzZazAQlCOaGUWt2WI/3OYItGqP5+Ol5AyN88Dld9NBTQTeKVT JGXDCY7vdN23MiryOxmYEwzAwhAygUKEoEMFpeNs5j7oORdQqW7bAf+DLbaxMwHtmrAG AI2rUgch43zl7Go937AWM2x/nX0eQbj28fKPsj31Qlwdsr+Lqw7hzrMgb6GGD2r+aGXZ /Z62GCub9ig2trVqed7Ha5MyMUypjoeatPIivSNBchiY/GfwyoTrQzG3NUii5B90RlIg xgwB3xS+pt+bEGUUvwbYdUcUtn1kSNGCfjhHC2M07KdMf5IrIQ0oLChBt74vrDLqVUY8 JJAA== MIME-Version: 1.0 Received: by 10.221.12.81 with SMTP id ph17mr391528vcb.47.1342682784180; Thu, 19 Jul 2012 00:26:24 -0700 (PDT) Received: by 10.220.9.198 with HTTP; Thu, 19 Jul 2012 00:26:23 -0700 (PDT) In-Reply-To: <50070F80.5070309@tin.it> References: <50070F80.5070309@tin.it> Date: Thu, 19 Jul 2012 09:26:23 +0200 Message-ID: Subject: Re: fixed size stack From: Claudio Eterno To: help-bison@gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.220.169 X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 07:26:30 -0000 Hi, probably(but I'll be sure in next days) one possible solution is: #define YYINITDEPTH 100 #define YYMAXDEPTH 0 #define YYSTACK_ALLOC(size) 0 in the code generated: ---------------------------------------------------------------- # ifndef YYSTACK_RELOCATE goto yyexhaustedlab; # else /* Extend the stack our own way. */ if (YYMAXDEPTH <=3D yystacksize) goto yyexhaustedlab; yystacksize *=3D 2; if (YYMAXDEPTH < yystacksize) yystacksize =3D YYMAXDEPTH; { yytype_int16 *yyss1 =3D yyss; union yyalloc *yyptr =3D (union yyalloc *) YYSTACK_ALLOC (YYSTACK_BYTES (yystacksize)); if (! yyptr) goto yyexhaustedlab; YYSTACK_RELOCATE (yyss); YYSTACK_RELOCATE (yyvs); # undef YYSTACK_RELOCATE if (yyss1 !=3D yyssa) YYSTACK_FREE (yyss1); } # endif ---------------------------------------------------------------- the row 'if (YYMAXDEPTH <=3D yystacksize)' will generate always a negative sentence. So the code after the 'if' will be removed by optimizer.. Claudio 2012/7/18 Luca > > As a compiler and firmware writer, I think this is a very interesting iss= ue. > > First, take into account to use the bison macro YYMALLOC and YYFREE (see = bison output c file). > Then I can suggest to use a tiny and efficient memory manager like this o= ne: > http://eli.thegreenplace.net/2008/10/17/memmgr-a-fixed-pool-memory-alloca= tor/ > I used it on a uC with 96 KB of RAM, without bison but with a RTOS runnin= g many task: a TCP-IP task to manage a webserver, a SPI task, many tasks fo= r UART and also with two proprietary interpreters. Moreover, the library al= lows a printout of allocation statistics that will help to understand how t= he memory is used. > > Luca > > > > On 17/07/2012 10:00, Claudio Eterno wrote: >> >> Hi folks, >> I'm writing here due to some configuration problems on bison. >> My question: I would like to use bison for an embedded application (base= d >> on a uC with only 16kb of ram a 256 kb of flash). Due to the limited >> resources reasons and also I know exactly the maximum size of >> the necessary stack, I don't want to occupy the memory with me unuseful >> library functions (like malloc for example). Anyway, is this possible to >> remove the alloc/malloc/realloc functions during compilation? >> Thank you, >> Claudio >> > -- Claudio Eterno via colle dell'Assietta 17 10036 Settimo Torinese (TO) Linux user n. 499785 registered on linuxcounter.net From MAILER-DAEMON Thu Jul 19 10:38:33 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Srrs9-00054R-Bc for mharc-help-bison@gnu.org; Thu, 19 Jul 2012 10:38:33 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Srrs1-00053L-FV for help-bison@gnu.org; Thu, 19 Jul 2012 10:38:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Srrrt-0001Db-8X for help-bison@gnu.org; Thu, 19 Jul 2012 10:38:25 -0400 Received: from sao-paulo.lrde.epita.fr ([163.5.55.1]:49582 helo=kualalumpur.lrde.epita.fr) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrrrR-0000vw-RY; Thu, 19 Jul 2012 10:37:50 -0400 Received: from erebus.lrde.epita.fr ([192.168.101.165]) by kualalumpur.lrde.epita.fr with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1SrrrP-0001JF-VN; Thu, 19 Jul 2012 16:37:47 +0200 Content-Type: text/plain; charset=us-ascii Subject: bison-2.6 released [stable] Mime-Version: 1.0 (Apple Message framework v1278) From: Akim Demaille Date: Thu, 19 Jul 2012 16:37:47 +0200 Content-Transfer-Encoding: 7bit Message-Id: To: GNU Announcements List X-Mailer: Apple Mail (2.1278) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 163.5.55.1 Cc: coordinator@translationproject.org, Bison Help , Bison Bugs , Bison Patches X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Bison Bugs List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 14:38:31 -0000 Bison 2.6 is born, the parents are well, and happy. In this release, a special emphasis was put on producing more complete, and more usable, parser headers. Here are the compressed sources: ftp://ftp.gnu.org/gnu/bison/bison-2.6.tar.gz (2.9MB) ftp://ftp.gnu.org/gnu/bison/bison-2.6.tar.xz (1.6MB) Here are the GPG detached signatures[*]: ftp://ftp.gnu.org/gnu/bison/bison-2.6.tar.gz.sig ftp://ftp.gnu.org/gnu/bison/bison-2.6.tar.xz.sig Use a mirror for higher download bandwidth: http://www.gnu.org/order/ftp.html [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify bison-2.6.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys 0DDCAA3278D5264E and rerun the 'gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.69 Automake 1.12.2 Flex 2.5.35 Gettext 0.18.1 Gnulib v0.0-7534-gcabce6b NEWS * Noteworthy changes in release 2.6 (2012-07-19) [stable] ** Future Changes The next major release of Bison will drop support for the following deprecated features. Please report disagreements to bug-bison@gnu.org. *** K&C parsers Support for generating parsers in K&R C will be removed. Parsers generated for C support ISO C90, and are tested with ISO C99 and ISO C11 compilers. *** Features deprecated since Bison 1.875 The definitions of yystype and yyltype will be removed; use YYSTYPE and YYLTYPE. YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of %parse-param and %lex-param, will no longer be supported. Support for the preprocessor symbol YYERROR_VERBOSE will be removed, use %error-verbose. *** The generated header will be included (yacc.c) Instead of duplicating the content of the generated header (definition of YYSTYPE, yyparse declaration etc.), the generated parser will include it, as is already the case for GLR or C++ parsers. This change is deferred because existing versions of ylwrap (e.g., Automake 1.12.1) do not support it. ** Generated Parser Headers *** Guards (yacc.c, glr.c, glr.cc) The generated headers are now guarded, as is already the case for C++ parsers (lalr1.cc). For instance, with --defines=foo.h: #ifndef YY_FOO_H # define YY_FOO_H ... #endif /* !YY_FOO_H */ *** New declarations (yacc.c, glr.c) The generated header now declares yydebug and yyparse. Both honor --name-prefix=bar_, and yield int bar_parse (void); rather than #define yyparse bar_parse int yyparse (void); in order to facilitate the inclusion of several parser headers inside a single compilation unit. *** Exported symbols in C++ The symbols YYTOKEN_TABLE and YYERROR_VERBOSE, which were defined in the header, are removed, as they prevent the possibility of including several generated headers from a single compilation unit. *** YYLSP_NEEDED For the same reasons, the undocumented and unused macro YYLSP_NEEDED is no longer defined. ** New %define variable: api.prefix Now that the generated headers are more complete and properly protected against multiple inclusions, constant names, such as YYSTYPE are a problem. While yyparse and others are properly renamed by %name-prefix, YYSTYPE, YYDEBUG and others have never been affected by it. Because it would introduce backward compatibility issues in projects not expecting YYSTYPE to be renamed, instead of changing the behavior of %name-prefix, it is deprecated in favor of a new %define variable: api.prefix. The following examples compares both: %name-prefix "bar_" | %define api.prefix "bar_" %token FOO %token FOO %union { int ival; } %union { int ival; } %% %% exp: 'a'; exp: 'a'; bison generates: #ifndef BAR_FOO_H #ifndef BAR_FOO_H # define BAR_FOO_H # define BAR_FOO_H /* Enabling traces. */ /* Enabling traces. */ # ifndef YYDEBUG | # ifndef BAR_DEBUG > # if defined YYDEBUG > # if YYDEBUG > # define BAR_DEBUG 1 > # else > # define BAR_DEBUG 0 > # endif > # else # define YYDEBUG 0 | # define BAR_DEBUG 0 > # endif # endif | # endif # if YYDEBUG | # if BAR_DEBUG extern int bar_debug; extern int bar_debug; # endif # endif /* Tokens. */ /* Tokens. */ # ifndef YYTOKENTYPE | # ifndef BAR_TOKENTYPE # define YYTOKENTYPE | # define BAR_TOKENTYPE enum yytokentype { | enum bar_tokentype { FOO = 258 FOO = 258 }; }; # endif # endif #if ! defined YYSTYPE \ | #if ! defined BAR_STYPE \ && ! defined YYSTYPE_IS_DECLARED | && ! defined BAR_STYPE_IS_DECLARED typedef union YYSTYPE | typedef union BAR_STYPE { { int ival; int ival; } YYSTYPE; | } BAR_STYPE; # define YYSTYPE_IS_DECLARED 1 | # define BAR_STYPE_IS_DECLARED 1 #endif #endif extern YYSTYPE bar_lval; | extern BAR_STYPE bar_lval; int bar_parse (void); int bar_parse (void); #endif /* !BAR_FOO_H */ #endif /* !BAR_FOO_H */ From MAILER-DAEMON Tue Jul 24 10:31:52 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Stg9Q-0002uf-6W for mharc-help-bison@gnu.org; Tue, 24 Jul 2012 10:31:52 -0400 Received: from eggs.gnu.org ([208.118.235.92]:57034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Stg9L-0002tQ-S4 for help-bison@gnu.org; Tue, 24 Jul 2012 10:31:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Stg9F-00021x-80 for help-bison@gnu.org; Tue, 24 Jul 2012 10:31:47 -0400 Received: from postman.teamix.net ([194.150.191.120]:58875 helo=rproxy.teamix.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Stg9E-00021h-UU for help-bison@gnu.org; Tue, 24 Jul 2012 10:31:41 -0400 Received: from zimbra.of.teamix.net (unknown [172.21.242.23]) by rproxy.teamix.net (Postfix) with ESMTP id 63E2D7A0A6; Tue, 24 Jul 2012 16:31:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.of.teamix.net (Postfix) with ESMTP id 4D51B146C1B; Tue, 24 Jul 2012 16:31:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at of.teamix.net Received: from zimbra.of.teamix.net ([127.0.0.1]) by localhost (zimbra.of.teamix.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo3K9DL9EGKQ; Tue, 24 Jul 2012 16:31:37 +0200 (CEST) Received: from mango.localnet (mango.of.teamix.net [172.21.123.1]) by zimbra.of.teamix.net (Postfix) with ESMTPSA id 170CB146BA5; Tue, 24 Jul 2012 16:31:37 +0200 (CEST) From: Martin Steigerwald Organization: teamix GmbH To: debian-legal@lists.debian.org Subject: Re: filebench: bison generated parser + CDDL Date: Tue, 24 Jul 2012 16:34:17 +0200 User-Agent: KMail/1.13.7 (Linux/3.4-trunk-amd64; KDE/4.8.4; x86_64; ; ) References: <201207030947.59044.ms@teamix.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201207241634.17856.ms@teamix.de> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 194.150.191.120 Cc: Sebastian Harl , Alex Mestiashvili , Brett Smith , Akim Demaille , filebench-developers@lists.sourceforge.net, licensing@fsf.org, Bison Help X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 14:31:49 -0000 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 >=20 > Le 3 juil. 2012 =E0 09:47, Martin Steigerwald a =E9crit : > > Please keep Cc, as I am not subscribed to help-bison or > > filebench-developers. > >=20 > >=20 > >=20 > > Dear bison developers, dear FSF licensing team, dear filebench > > developers, > >=20 > > Alex Mestiashvili and I have packaged filebench for Debian. But now I > > wonder whether we may legally distribute it. > >=20 > > Bison uses a bison generated parser from parser_gram.y and these > > generated > >=20 > > files are: > > | Files: parser_gram.c parser_gram.h > > | Copyright: 1984, 1989, 1990, 2000-2011 Free Software Foundation, Inc. > > |=20 > > | C LALR(1) parser skeleton written by Richard Stallman, by > > | simplifying the original so-called "semantic" parser. > > |=20 > > | License: GPL-3+ with exception > > | This package is free software; you can redistribute it and/or modify > > | [=85] > > | 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. > >=20 > > Is this compatible with CDDL-1? >=20 > 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) >=20 > > As far as I understand CDDL-1 and GPL are not compatible, but when I re= ad > > 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. > >=20 > > 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 =96 see below. > >=20 > > Dear FSF licensing team, dear bison developers, can you elaborate on > > that? > >=20 > > If its not clearly redistributable then what changes could make it so? > >=20 > > Thanks, > > Martin > >=20 > >=20 > > ---------- Weitergeleitete Nachricht ---------- > >=20 > > Betreff: Re: filebench: bison generated parser + CDDL > > Datum: Samstag, 2. Juni 2012, 22:29:41 > > Von: Mark Weyer > > An: debian-legal@lists.debian.org > >=20 > > 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= =2D1 > >>> 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. > >>=20 > >> I don=B4t understand this. > >>=20 > >> I understand the exception > >>=20 > >> | 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. > >>=20 > >> so that it allows distributing the software under any other license as > >> long as the generated parser isn=B4t a parser generator in itself. > >>=20 > >> I don=B4t 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 worklo= ad > >> descriptions. >=20 > 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. >=20 > > It is less clear than I thought. > >=20 > > Let A be a work with a parser generated by bison and assume that A is n= ot > > 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. >=20 > Skeletons are really dynamic, they are not plain files with > simple substitutions, they are "run" by M4. So this scenario > does not make sense in practice, IMHO. >=20 > > How I read the exception on May 7, I thought that it would not be delet= ed > > 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. > >=20 > > The true question is, of course, whether a court would judge in favour = of > > the exception's letter or its intent. > >=20 > > 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. > >=20 > > 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 wo= rk > > and B: if upstream does not exercise the right of the exception, then > > they do not > >=20 > > have the right to distribute filebench under anything other than the > > GPL.) > >=20 > > I am not a lawyer, this is not legal advice, et cetera. > >=20 > > Mark Weyer > >=20 > > -- > > To UNSUBSCRIBE, email to debian-legal-REQUEST@lists.debian.org > > with a subject of "unsubscribe". Trouble? Contact > > listmaster@lists.debian.org Archive: > > http://lists.debian.org/20120602202941.GA1911@debian > >=20 > >=20 > > ------------------------------------------------------------- > >=20 > > Ciao, =2D-=20 Martin Steigerwald Trainer / Consultant teamix GmbH Solide IT-Infrastruktur S=FCdwestpark 35 90449 N=FCrnberg fon: +49 (911) 30999- 0 fax: +49 (911) 30999-99 mail: ms@teamix.de web: http://www.teamix.de vcf: http://www.teamix.de/vcf/ms.vcf gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 Amtsgericht N=FCrnberg, HRB 18320 Gesch=E4ftsf=FChrer: Oliver K=FCgow, Richard M=FCller From MAILER-DAEMON Tue Jul 31 02:26:15 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Sw5uJ-0004ey-36 for mharc-help-bison@gnu.org; Tue, 31 Jul 2012 02:26:15 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sw5uG-0004eg-Si for help-bison@gnu.org; Tue, 31 Jul 2012 02:26:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sw5uF-0000cM-0e for help-bison@gnu.org; Tue, 31 Jul 2012 02:26:12 -0400 Received: from sao-paulo.lrde.epita.fr ([163.5.55.1]:42959 helo=kualalumpur.lrde.epita.fr) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sw5uE-0000cI-L4; Tue, 31 Jul 2012 02:26:10 -0400 Received: from mna75-4-82-225-76-247.fbx.proxad.net ([82.225.76.247] helo=[192.168.0.12]) by kualalumpur.lrde.epita.fr with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1Sw5tp-0003jY-OP; Tue, 31 Jul 2012 08:25:45 +0200 Subject: Re: filebench: bison generated parser + CDDL Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Akim Demaille In-Reply-To: <201207241634.17856.ms@teamix.de> Date: Tue, 31 Jul 2012 08:25:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9ABDB6E6-CF87-42E4-8FDA-D8A888B44691@lrde.epita.fr> References: <201207030947.59044.ms@teamix.de> <201207241634.17856.ms@teamix.de> To: Martin Steigerwald X-Mailer: Apple Mail (2.1278) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 163.5.55.1 Cc: Sebastian Harl , Alex Mestiashvili , Brett Smith , licensing@gnu.org, debian-legal@lists.debian.org, licensing@fsf.org, filebench-developers@lists.sourceforge.net, Bison Help X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 06:26:14 -0000 Hi Martin, Sorry about this, but I have no answers. If licensing@gnu.org does not answer, I don't know what else I could do. Akim Le 24 juil. 2012 =E0 16:34, Martin Steigerwald a =E9crit : > Am Mittwoch, 4. Juli 2012 schrieb Akim Demaille: >> Hi all, >=20 > Hi Akim and Brett, >=20 >> I have added Bret in CC, as he is the one to deal with licenses >> and exceptions. >=20 > Any progress? >=20 > Thanks, > Martin >=20 >>=20 >> Le 3 juil. 2012 =E0 09:47, Martin Steigerwald a =E9crit : >>> Please keep Cc, as I am not subscribed to help-bison or >>> filebench-developers. >>>=20 >>>=20 >>>=20 >>> Dear bison developers, dear FSF licensing team, dear filebench >>> developers, >>>=20 >>> Alex Mestiashvili and I have packaged filebench for Debian. But now = I >>> wonder whether we may legally distribute it. >>>=20 >>> Bison uses a bison generated parser from parser_gram.y and these >>> generated >>>=20 >>> files are: >>> | Files: parser_gram.c parser_gram.h >>> | Copyright: 1984, 1989, 1990, 2000-2011 Free Software Foundation, = Inc. >>> |=20 >>> | C LALR(1) parser skeleton written by Richard Stallman, by >>> | simplifying the original so-called "semantic" parser. >>> |=20 >>> | License: GPL-3+ with exception >>> | This package is free software; you can redistribute it and/or = modify >>> | [=85] >>> | 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. >>>=20 >>> Is this compatible with CDDL-1? >>=20 >> 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) >>=20 >>> 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. >>>=20 >>> 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 =96 see below. >>>=20 >>> Dear FSF licensing team, dear bison developers, can you elaborate on >>> that? >>>=20 >>> If its not clearly redistributable then what changes could make it = so? >>>=20 >>> Thanks, >>> Martin >>>=20 >>>=20 >>> ---------- Weitergeleitete Nachricht ---------- >>>=20 >>> Betreff: Re: filebench: bison generated parser + CDDL >>> Datum: Samstag, 2. Juni 2012, 22:29:41 >>> Von: Mark Weyer >>> An: debian-legal@lists.debian.org >>>=20 >>> 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. >>>>=20 >>>> I don=B4t understand this. >>>>=20 >>>> I understand the exception >>>>=20 >>>> | 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. >>>>=20 >>>> so that it allows distributing the software under any other license = as >>>> long as the generated parser isn=B4t a parser generator in itself. >>>>=20 >>>> I don=B4t 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. >>=20 >> 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. >>=20 >>> It is less clear than I thought. >>>=20 >>> 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. >>=20 >> Skeletons are really dynamic, they are not plain files with >> simple substitutions, they are "run" by M4. So this scenario >> does not make sense in practice, IMHO. >>=20 >>> 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. >>>=20 >>> The true question is, of course, whether a court would judge in = favour of >>> the exception's letter or its intent. >>>=20 >>> 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. >>>=20 >>> 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 >>>=20 >>> have the right to distribute filebench under anything other than = the >>> GPL.) >>>=20 >>> I am not a lawyer, this is not legal advice, et cetera. >>>=20 >>> Mark Weyer >>>=20 >>> -- >>> To UNSUBSCRIBE, email to debian-legal-REQUEST@lists.debian.org >>> with a subject of "unsubscribe". Trouble? Contact >>> listmaster@lists.debian.org Archive: >>> http://lists.debian.org/20120602202941.GA1911@debian >>>=20 >>>=20 >>> ------------------------------------------------------------- >>>=20 >>> Ciao, >=20 >=20 > --=20 > Martin Steigerwald > Trainer / Consultant >=20 > teamix GmbH > Solide IT-Infrastruktur > S=FCdwestpark 35 > 90449 N=FCrnberg >=20 > fon: +49 (911) 30999- 0 > fax: +49 (911) 30999-99 > mail: ms@teamix.de > web: http://www.teamix.de > vcf: http://www.teamix.de/vcf/ms.vcf > gpg: 19E3 8D42 896F D004 08AC > A0CA 1E10 C593 0399 AE90 >=20 > Amtsgericht N=FCrnberg, HRB 18320 > Gesch=E4ftsf=FChrer: Oliver K=FCgow, Richard M=FCller From MAILER-DAEMON Tue Jul 31 03:29:46 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Sw6tm-0002HQ-QT for mharc-help-bison@gnu.org; Tue, 31 Jul 2012 03:29:46 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sw6tj-0002HC-Mu for help-bison@gnu.org; Tue, 31 Jul 2012 03:29:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sw6th-0000gW-V7 for help-bison@gnu.org; Tue, 31 Jul 2012 03:29:43 -0400 Received: from postman.teamix.net ([194.150.191.120]:55003 helo=rproxy.teamix.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sw6th-0000gN-Is; Tue, 31 Jul 2012 03:29:41 -0400 Received: from zimbra.of.teamix.net (unknown [172.21.242.23]) by rproxy.teamix.net (Postfix) with ESMTP id B4E847A0AC; Tue, 31 Jul 2012 09:29:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.of.teamix.net (Postfix) with ESMTP id 9DCCC146C1D; Tue, 31 Jul 2012 09:29:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at of.teamix.net Received: from zimbra.of.teamix.net ([127.0.0.1]) by localhost (zimbra.of.teamix.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2k9Ye37KYtw; Tue, 31 Jul 2012 09:29:38 +0200 (CEST) Received: from mango.localnet (mango.of.teamix.net [172.21.123.1]) by zimbra.of.teamix.net (Postfix) with ESMTPSA id BF344146B91; Tue, 31 Jul 2012 09:29:38 +0200 (CEST) From: Martin Steigerwald Organization: teamix GmbH To: Akim Demaille Subject: Re: filebench: bison generated parser + CDDL Date: Tue, 31 Jul 2012 09:32:36 +0200 User-Agent: KMail/1.13.7 (Linux/3.4-trunk-amd64; KDE/4.8.4; x86_64; ; ) References: <201207030947.59044.ms@teamix.de> <201207241634.17856.ms@teamix.de> <9ABDB6E6-CF87-42E4-8FDA-D8A888B44691@lrde.epita.fr> In-Reply-To: <9ABDB6E6-CF87-42E4-8FDA-D8A888B44691@lrde.epita.fr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201207310932.37103.ms@teamix.de> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 194.150.191.120 Cc: Sebastian Harl , Alex Mestiashvili , Brett Smith , licensing@gnu.org, debian-legal@lists.debian.org, licensing@fsf.org, filebench-developers@lists.sourceforge.net, Bison Help X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 07:29:45 -0000 Am Dienstag, 31. Juli 2012 schrieb Akim Demaille: > Hi Martin, Hi Akim, =20 > Sorry about this, but I have no answers. If licensing@gnu.org > does not answer, I don't know what else I could do. Hmmm=85 Anyone a suggestion on how to move forward? Thanks, Martin >=20 > Akim >=20 > Le 24 juil. 2012 =E0 16:34, Martin Steigerwald a =E9crit : > > Am Mittwoch, 4. Juli 2012 schrieb Akim Demaille: > >> Hi all, > >=20 > > Hi Akim and Brett, > >=20 > >> I have added Bret in CC, as he is the one to deal with licenses > >> and exceptions. > >=20 > > Any progress? > >=20 > > Thanks, > > Martin > >=20 > >> Le 3 juil. 2012 =E0 09:47, Martin Steigerwald a =E9crit : > >>> Please keep Cc, as I am not subscribed to help-bison or > >>> filebench-developers. > >>>=20 > >>>=20 > >>>=20 > >>> Dear bison developers, dear FSF licensing team, dear filebench > >>> developers, > >>>=20 > >>> Alex Mestiashvili and I have packaged filebench for Debian. But now I > >>> wonder whether we may legally distribute it. > >>>=20 > >>> Bison uses a bison generated parser from parser_gram.y and these > >>> generated > >>>=20 > >>> files are: > >>> | Files: parser_gram.c parser_gram.h > >>> | Copyright: 1984, 1989, 1990, 2000-2011 Free Software Foundation, In= c. > >>> |=20 > >>> | C LALR(1) parser skeleton written by Richard Stallman, by > >>> | simplifying the original so-called "semantic" parser. > >>> |=20 > >>> | License: GPL-3+ with exception > >>> | This package is free software; you can redistribute it and/or modify > >>> | [=85] > >>> | 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. > >>>=20 > >>> Is this compatible with CDDL-1? > >>=20 > >> 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) > >>=20 > >>> 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. > >>>=20 > >>> 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 =96 see below. > >>>=20 > >>> Dear FSF licensing team, dear bison developers, can you elaborate on > >>> that? > >>>=20 > >>> If its not clearly redistributable then what changes could make it so? > >>>=20 > >>> Thanks, > >>> Martin > >>>=20 > >>>=20 > >>> ---------- Weitergeleitete Nachricht ---------- > >>>=20 > >>> Betreff: Re: filebench: bison generated parser + CDDL > >>> Datum: Samstag, 2. Juni 2012, 22:29:41 > >>> Von: Mark Weyer > >>> An: debian-legal@lists.debian.org > >>>=20 > >>> 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. > >>>>=20 > >>>> I don=B4t understand this. > >>>>=20 > >>>> I understand the exception > >>>>=20 > >>>> | 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. > >>>>=20 > >>>> so that it allows distributing the software under any other license = as > >>>> long as the generated parser isn=B4t a parser generator in itself. > >>>>=20 > >>>> I don=B4t think that the parser in here is a parser generator. As fa= r as > >>>> I understand parser_gram.c and parser_gram.h just parses loadable > >>>> workload descriptions. > >>=20 > >> 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. > >>=20 > >>> It is less clear than I thought. > >>>=20 > >>> 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. > >>=20 > >> Skeletons are really dynamic, they are not plain files with > >> simple substitutions, they are "run" by M4. So this scenario > >> does not make sense in practice, IMHO. > >>=20 > >>> 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. > >>>=20 > >>> The true question is, of course, whether a court would judge in favour > >>> of the exception's letter or its intent. > >>>=20 > >>> 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 th= us > >>> (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. > >>>=20 > >>> 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 > >>>=20 > >>> have the right to distribute filebench under anything other than the > >>> GPL.) > >>>=20 > >>> I am not a lawyer, this is not legal advice, et cetera. > >>>=20 > >>> Mark Weyer > >>>=20 > >>> -- > >>> To UNSUBSCRIBE, email to debian-legal-REQUEST@lists.debian.org > >>> with a subject of "unsubscribe". Trouble? Contact > >>> listmaster@lists.debian.org Archive: > >>> http://lists.debian.org/20120602202941.GA1911@debian > >>>=20 > >>>=20 > >>> ------------------------------------------------------------- > >>>=20 > >>> Ciao, =2D-=20 Martin Steigerwald Trainer / Consultant teamix GmbH Solide IT-Infrastruktur S=FCdwestpark 35 90449 N=FCrnberg fon: +49 (911) 30999- 0 fax: +49 (911) 30999-99 mail: ms@teamix.de web: http://www.teamix.de vcf: http://www.teamix.de/vcf/ms.vcf gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 Amtsgericht N=FCrnberg, HRB 18320 Gesch=E4ftsf=FChrer: Oliver K=FCgow, Richard M=FCller From MAILER-DAEMON Tue Jul 31 05:36:02 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Sw8ry-0005PE-GF for mharc-help-bison@gnu.org; Tue, 31 Jul 2012 05:36:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sw8rv-0005Me-Ox for help-bison@gnu.org; Tue, 31 Jul 2012 05:36:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sw8ru-00051M-BS for help-bison@gnu.org; Tue, 31 Jul 2012 05:35:59 -0400 Received: from smarthost02.mail.zen.net.uk ([212.23.1.2]:59797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sw8ru-00050w-5P for help-bison@gnu.org; Tue, 31 Jul 2012 05:35:58 -0400 Received: from [82.70.243.134] (helo=[192.168.1.33]) by smarthost02.mail.zen.net.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Sw8rq-0005ZR-Gl; Tue, 31 Jul 2012 09:35:54 +0000 Message-ID: <5017A6F9.8020305@cyconix.com> Date: Tue, 31 Jul 2012 10:35:53 +0100 From: Evan Lavelle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Martin Steigerwald Subject: Re: filebench: bison generated parser + CDDL References: <201207030947.59044.ms@teamix.de> <201207241634.17856.ms@teamix.de> <9ABDB6E6-CF87-42E4-8FDA-D8A888B44691@lrde.epita.fr> <201207310932.37103.ms@teamix.de> In-Reply-To: <201207310932.37103.ms@teamix.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Smarthost02-IP: [82.70.243.134] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 212.23.1.2 Cc: filebench-developers@lists.sourceforge.net, Bison Help X-BeenThere: help-bison@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Bison parser generator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 09:36:01 -0000 You'll never get an answer from the FSF on licensing; they'll just send you a form mail asking you for money. So, don't bother asking. You have to ask yourself two questions: 1 - Is filebench a parser generator? From what you've said, it seems that it isn't. If it isn't a parser generator (ie. if it just *contains* a parser, and it isn't a program (like yacc/Bison/Antlr/etc) which actually *creates* a parser) then you can distribute filebench under any licence you want, even though you have used Bison to generate a parser which you have included in filebench, and even though filebench uses the Bison skeleton. This much is obvious; Bison would be unusable in most environments without this exception. 2 - Do you actually *want* to distribute filebench with a *more* restrictive licence that contaminates the rest of your code, and restricts your ability to distribute your code freely? If so, you can. This is what the "Alternatively" section is about. You can completely ignore the "Alternatively" section, unless you have some sort of ideology issue with licences. I think your confusion is: > 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 No - you can't over-ride the "GPL-and-exception". You can only over-ride the "-and-exception": > | 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. In other words, you can make the licensing *more* restrictive, by reverting back to GPL, but you can't make it *less* restrictive. I'm sure you're Ok. But, if you're really concerned, you can always switch to Antlr, which has a free licence, rather than a "Free" licence. -Evan