You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by Peter Kelly <pm...@apache.org> on 2015/08/17 16:34:19 UTC
Is using Bison & Flex ok?
I’m currently doing writing some experimental code for developing & testing a type inference algorithm that will eventually become of Flat. Because the latter is not at a sufficient stage of maturity, I’m using Bison & Flex to parse a simple C-like programming language upon which I’m doing the analysis.
I’d like to include this code in the repository, but wanted to confirm whether this is within the legal guidelines for dependent software. Bison is GPL, but has a special exception for the generated code (which contains part of Bison itself):
https://www.gnu.org/software/bison/manual/html_node/Conditions.html
Flex’s license appears to be BSD(-like), which I’m assuming should be ok:
http://flex.sourceforge.net/manual/Copyright.html#Copyright
My use of both of these tools is for experimental purposes only - my intention is for Flat to eventually subsume both. I do not anticipate that we would include the code that requires these for building as part of an actual Corinthia release.
Note also that these tools are required at build time only, and do not require extra libraries to be distributed with the generated code.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Is using Bison & Flex ok?
Posted by jan i <ja...@apache.org>.
On Monday, August 17, 2015, jan i <ja...@apache.org> wrote:
>
>
> On Monday, August 17, 2015, Peter Kelly <pmkelly@apache.org
> <javascript:_e(%7B%7D,'cvml','pmkelly@apache.org');>> wrote:
>
>> I’m currently doing writing some experimental code for developing &
>> testing a type inference algorithm that will eventually become of Flat.
>> Because the latter is not at a sufficient stage of maturity, I’m using
>> Bison & Flex to parse a simple C-like programming language upon which I’m
>> doing the analysis.
>>
>> I’d like to include this code in the repository, but wanted to confirm
>> whether this is within the legal guidelines for dependent software. Bison
>> is GPL, but has a special exception for the generated code (which contains
>> part of Bison itself):
>>
>> https://www.gnu.org/software/bison/manual/html_node/Conditions.html
>>
>> Flex’s license appears to be BSD(-like), which I’m assuming should be ok:
>>
>> http://flex.sourceforge.net/manual/Copyright.html#Copyright
>>
>> My use of both of these tools is for experimental purposes only - my
>> intention is for Flat to eventually subsume both. I do not anticipate that
>> we would include the code that requires these for building as part of an
>> actual Corinthia release.
>>
>> Tools are not a concern for. a release, the source files are, having read
> the 2 copy rigths I do not see a problem to include the files.
>
> To avoid a tedious discussion with Dennis just do it, without putting
> attention on it.
>
apologies this remark was not intented to go public, I have no wish to hang
out people by name.
however our continued licensing discussions are getting tiresome, and do
not bring us forward.
rgds
jan i
>
> Later when it comes to release time we might need to dig deeper into the
> bison license. For now it is close enough that I can truthfully say I do
> not see a problem.
>
> rgds
> jan i
>
>> Note also that these tools are required at build time only, and do not
>> require extra libraries to be distributed with the generated code.
>>
>> —
>> Dr Peter M. Kelly
>> pmkelly@apache.org
>>
>> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key
>> >
>> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>>
>>
>
> --
> Sent from My iPad, sorry for any misspellings.
>
--
Sent from My iPad, sorry for any misspellings.
Re: Is using Bison & Flex ok?
Posted by jan i <ja...@apache.org>.
On Monday, August 17, 2015, Peter Kelly <pm...@apache.org> wrote:
> I’m currently doing writing some experimental code for developing &
> testing a type inference algorithm that will eventually become of Flat.
> Because the latter is not at a sufficient stage of maturity, I’m using
> Bison & Flex to parse a simple C-like programming language upon which I’m
> doing the analysis.
>
> I’d like to include this code in the repository, but wanted to confirm
> whether this is within the legal guidelines for dependent software. Bison
> is GPL, but has a special exception for the generated code (which contains
> part of Bison itself):
>
> https://www.gnu.org/software/bison/manual/html_node/Conditions.html
>
> Flex’s license appears to be BSD(-like), which I’m assuming should be ok:
>
> http://flex.sourceforge.net/manual/Copyright.html#Copyright
>
> My use of both of these tools is for experimental purposes only - my
> intention is for Flat to eventually subsume both. I do not anticipate that
> we would include the code that requires these for building as part of an
> actual Corinthia release.
>
> Tools are not a concern for. a release, the source files are, having read
the 2 copy rigths I do not see a problem to include the files.
To avoid a tedious discussion with Dennis just do it, without putting
attention on it.
Later when it comes to release time we might need to dig deeper into the
bison license. For now it is close enough that I can truthfully say I do
not see a problem.
rgds
jan i
> Note also that these tools are required at build time only, and do not
> require extra libraries to be distributed with the generated code.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org <javascript:;>
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
--
Sent from My iPad, sorry for any misspellings.
Re: Is using Bison & Flex ok?
Posted by jan i <ja...@apache.org>.
On 17 August 2015 at 18:16, Dennis E. Hamilton <de...@acm.org>
wrote:
> I think there are two aspects to the question of code-generation tools. I
> think it is an useful topic to raise.
>
> First, the best maintainable source needs to be included (e.g., the input
> to Bison). That is part of the Open Source Definition as I recall, and it
> applies to Apache projects.
>
> Secondly, if you intend to include the generated output (technically, a
> convenience, but not binary), that seems like the right thing to do also.
>
> Ideally the generation is reproducible by anyone who chooses to do so, and
> information on how it was generated can be included in the source.
>
> (If the *generated* file were modified manually later, I would make that a
> separate derived result, so someone can figure it out from the released
> source.)
>
> I don't think the build step needs to be part of the cmake process or
> whatever process for building from a Corinthia release, even though any
> script used might be part of the generation information. A generation step
> is only needed by developers who want to make a derivative of the Bison
> input, and anyone capable of doing that will certainly obtain the necessary
> tooling for their own use.
>
> So, don't provide the tool, don't have it as an external dependency, and
> provide enough information so someone who cared could do the generation
> from Bison input themselves.
>
Of course not, we also do not provide compilers etc.
>
> CAVEAT #1: If the generation tool's license places conditions on the
> generated output that are more restrictive than the ALv2, that becomes a
> problem. That depends on the Bison "special-exception" that is provided on
> the generated files themselves, it seems to me.
>
Having read them, I do not see them as more restrictive.
>
> CAVEAT #2: The way to deal with this is not to have it be a matter of
> opinion, if there remains any doubt about the "special-exception"
> statement. There is a LEGAL section on the ASF JIRA for raising such
> specific questions (and I am a bit amazed that this has not happened
> already).
>
Why would we call for LEGAL help on a subject that is
a) an experiment, and probably will not come into production code
b) There is a fairly clear text, that do not seem stricter than ALv2
(because we do not modify the code)
c) You saw from the release discussion, that tools are irrelevant for a
release (together with libraries not included)
d) If every project that had an idea would ask LEGAL first, they would be
overburdened, we need them for real problems.
So in my opinion, let us wait and see, if Peter decides to use it in
production code, that is the point where we need to dig deeper. Bear in
mind we did exactly the same with the web editor.
rgds
jan i
>
> - Dennis
>
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org]
> Sent: Monday, August 17, 2015 07:34
> To: dev@corinthia.incubator.apache.org
> Subject: Is using Bison & Flex ok?
>
> I’m currently doing writing some experimental code for developing &
> testing a type inference algorithm that will eventually become of Flat.
> Because the latter is not at a sufficient stage of maturity, I’m using
> Bison & Flex to parse a simple C-like programming language upon which I’m
> doing the analysis.
>
> I’d like to include this code in the repository, but wanted to confirm
> whether this is within the legal guidelines for dependent software. Bison
> is GPL, but has a special exception for the generated code (which contains
> part of Bison itself):
>
> https://www.gnu.org/software/bison/manual/html_node/Conditions.html
>
> [ ... ]
>
>
>
RE: Is using Bison & Flex ok?
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Yes, I think using the source .y and .l files and requiring the proper build tools to generate the parser code is the safest bet.
- Dennis
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Monday, August 17, 2015 17:30
To: dev@corinthia.incubator.apache.org
Subject: Re: Is using Bison & Flex ok?
[ ... ]
It’s my opinion though that, like you, i feel it’s best to include the source grammar.y and lexer.l in the tree, since this is the only representation that is meaningfully usable by a developer. For experimental code, I don’t see a need for the generated output to be in the repository. For a release perhaps, though even then I’d argue for requiring bison & flex to be installed for a build.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Is using Bison & Flex ok?
Posted by Peter Kelly <pm...@apache.org>.
> On 18 Aug 2015, at 12:19 am, Dennis E. Hamilton <de...@acm.org> wrote:
>
> I looked around a bit more, and inclusion of the generated file might be a problem in the sense that it is not modifiable except under the GPL, if I understand the explanation at
>
> <https://en.wikipedia.org/wiki/GNU_bison> and the illustration of what a generated file is like at <http://git.savannah.gnu.org/cgit/bison.git/tree/src/parse-gram.c>.
Not that this is relevant (since I do not intend on making it release code; it’s experimental only) but the intention of the exception at https://www.gnu.org/software/bison/manual/html_node/Conditions.html reads to me as though they it’s fine to include generated code in any product (including commercial), regardless of license.
It’s my opinion though that, like you, i feel it’s best to include the source grammar.y and lexer.l in the tree, since this is the only representation that is meaningfully usable by a developer. For experimental code, I don’t see a need for the generated output to be in the repository. For a release perhaps, though even then I’d argue for requiring bison & flex to be installed for a build.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Is using Bison & Flex ok?
Posted by jan i <ja...@apache.org>.
On Monday, August 17, 2015, Dennis E. Hamilton <de...@acm.org>
wrote:
> I looked around a bit more, and inclusion of the generated file might be a
> problem in the sense that it is not modifiable except under the GPL, if I
> understand the explanation at
>
> <https://en.wikipedia.org/wiki/GNU_bison> and the illustration of what a
> generated file is like at <
> http://git.savannah.gnu.org/cgit/bison.git/tree/src/parse-gram.c>.
>
> It strikes me that it could be difficult to include the generated file in
> a Corinthia source release, even as it has the skeleton interspersed in it,
> if I understand the difference between the generated parser and the
> skeleton correctly. I am not certain that having an optionally-accessed
> external is enough, whether worthwhile otherwise.
>
> I can't imagine that this specific case hasn't come up before and it would
> be useful to know what the determination is. In any case, there is nothing
> wrong with presenting this specific case to legal-discuss and create a
> LEGAL JIRA issue about it.
>
> If it is in our repository, I think it would be good to have a settled
> understanding in advance of any decision about inclusion in a release.
Just to be sure everyone understands, having it in our repo in a directory
called experiments while finding a lasting solution, cannot be compared
with a release, that is 2 different things.
There are many things we might not or cannot release due to license
restrictions, but that should not stop us experimenting. To find a solution
you need to see the road, and to find the road you need to experiment.
Please stop talking about releases, both peter and I have clearly stated it
will probably never be released. this is our Qt discussion once again,
please stop dreaming about what might happen if we do X, let us concentrate
on the issue at hand (no release).
rgds
jan i
>
> - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org <javascript:;>]
> Sent: Monday, August 17, 2015 09:16
> To: dev@corinthia.incubator.apache.org <javascript:;>
> Subject: RE: Is using Bison & Flex ok?
>
> I think there are two aspects to the question of code-generation tools. I
> think it is an useful topic to raise.
>
> First, the best maintainable source needs to be included (e.g., the input
> to Bison). That is part of the Open Source Definition as I recall, and it
> applies to Apache projects.
>
> Secondly, if you intend to include the generated output (technically, a
> convenience, but not binary), that seems like the right thing to do also.
>
> Ideally the generation is reproducible by anyone who chooses to do so, and
> information on how it was generated can be included in the source.
>
> (If the *generated* file were modified manually later, I would make that a
> separate derived result, so someone can figure it out from the released
> source.)
>
> I don't think the build step needs to be part of the cmake process or
> whatever process for building from a Corinthia release, even though any
> script used might be part of the generation information. A generation step
> is only needed by developers who want to make a derivative of the Bison
> input, and anyone capable of doing that will certainly obtain the necessary
> tooling for their own use.
>
> So, don't provide the tool, don't have it as an external dependency, and
> provide enough information so someone who cared could do the generation
> from Bison input themselves.
>
> CAVEAT #1: If the generation tool's license places conditions on the
> generated output that are more restrictive than the ALv2, that becomes a
> problem. That depends on the Bison "special-exception" that is provided on
> the generated files themselves, it seems to me.
>
> CAVEAT #2: The way to deal with this is not to have it be a matter of
> opinion, if there remains any doubt about the "special-exception"
> statement. There is a LEGAL section on the ASF JIRA for raising such
> specific questions (and I am a bit amazed that this has not happened
> already).
>
> - Dennis
>
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org <javascript:;>]
> Sent: Monday, August 17, 2015 07:34
> To: dev@corinthia.incubator.apache.org <javascript:;>
> Subject: Is using Bison & Flex ok?
>
> I’m currently doing writing some experimental code for developing &
> testing a type inference algorithm that will eventually become of Flat.
> Because the latter is not at a sufficient stage of maturity, I’m using
> Bison & Flex to parse a simple C-like programming language upon which I’m
> doing the analysis.
>
> I’d like to include this code in the repository, but wanted to confirm
> whether this is within the legal guidelines for dependent software. Bison
> is GPL, but has a special exception for the generated code (which contains
> part of Bison itself):
>
> https://www.gnu.org/software/bison/manual/html_node/Conditions.html
>
> [ ... ]
>
>
>
--
Sent from My iPad, sorry for any misspellings.
RE: Is using Bison & Flex ok?
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I looked around a bit more, and inclusion of the generated file might be a problem in the sense that it is not modifiable except under the GPL, if I understand the explanation at
<https://en.wikipedia.org/wiki/GNU_bison> and the illustration of what a generated file is like at <http://git.savannah.gnu.org/cgit/bison.git/tree/src/parse-gram.c>.
It strikes me that it could be difficult to include the generated file in a Corinthia source release, even as it has the skeleton interspersed in it, if I understand the difference between the generated parser and the skeleton correctly. I am not certain that having an optionally-accessed external is enough, whether worthwhile otherwise.
I can't imagine that this specific case hasn't come up before and it would be useful to know what the determination is. In any case, there is nothing wrong with presenting this specific case to legal-discuss and create a LEGAL JIRA issue about it.
If it is in our repository, I think it would be good to have a settled understanding in advance of any decision about inclusion in a release.
- Dennis
-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Monday, August 17, 2015 09:16
To: dev@corinthia.incubator.apache.org
Subject: RE: Is using Bison & Flex ok?
I think there are two aspects to the question of code-generation tools. I think it is an useful topic to raise.
First, the best maintainable source needs to be included (e.g., the input to Bison). That is part of the Open Source Definition as I recall, and it applies to Apache projects.
Secondly, if you intend to include the generated output (technically, a convenience, but not binary), that seems like the right thing to do also.
Ideally the generation is reproducible by anyone who chooses to do so, and information on how it was generated can be included in the source.
(If the *generated* file were modified manually later, I would make that a separate derived result, so someone can figure it out from the released source.)
I don't think the build step needs to be part of the cmake process or whatever process for building from a Corinthia release, even though any script used might be part of the generation information. A generation step is only needed by developers who want to make a derivative of the Bison input, and anyone capable of doing that will certainly obtain the necessary tooling for their own use.
So, don't provide the tool, don't have it as an external dependency, and provide enough information so someone who cared could do the generation from Bison input themselves.
CAVEAT #1: If the generation tool's license places conditions on the generated output that are more restrictive than the ALv2, that becomes a problem. That depends on the Bison "special-exception" that is provided on the generated files themselves, it seems to me.
CAVEAT #2: The way to deal with this is not to have it be a matter of opinion, if there remains any doubt about the "special-exception" statement. There is a LEGAL section on the ASF JIRA for raising such specific questions (and I am a bit amazed that this has not happened already).
- Dennis
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Monday, August 17, 2015 07:34
To: dev@corinthia.incubator.apache.org
Subject: Is using Bison & Flex ok?
I’m currently doing writing some experimental code for developing & testing a type inference algorithm that will eventually become of Flat. Because the latter is not at a sufficient stage of maturity, I’m using Bison & Flex to parse a simple C-like programming language upon which I’m doing the analysis.
I’d like to include this code in the repository, but wanted to confirm whether this is within the legal guidelines for dependent software. Bison is GPL, but has a special exception for the generated code (which contains part of Bison itself):
https://www.gnu.org/software/bison/manual/html_node/Conditions.html
[ ... ]
RE: Is using Bison & Flex ok?
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I think there are two aspects to the question of code-generation tools. I think it is an useful topic to raise.
First, the best maintainable source needs to be included (e.g., the input to Bison). That is part of the Open Source Definition as I recall, and it applies to Apache projects.
Secondly, if you intend to include the generated output (technically, a convenience, but not binary), that seems like the right thing to do also.
Ideally the generation is reproducible by anyone who chooses to do so, and information on how it was generated can be included in the source.
(If the *generated* file were modified manually later, I would make that a separate derived result, so someone can figure it out from the released source.)
I don't think the build step needs to be part of the cmake process or whatever process for building from a Corinthia release, even though any script used might be part of the generation information. A generation step is only needed by developers who want to make a derivative of the Bison input, and anyone capable of doing that will certainly obtain the necessary tooling for their own use.
So, don't provide the tool, don't have it as an external dependency, and provide enough information so someone who cared could do the generation from Bison input themselves.
CAVEAT #1: If the generation tool's license places conditions on the generated output that are more restrictive than the ALv2, that becomes a problem. That depends on the Bison "special-exception" that is provided on the generated files themselves, it seems to me.
CAVEAT #2: The way to deal with this is not to have it be a matter of opinion, if there remains any doubt about the "special-exception" statement. There is a LEGAL section on the ASF JIRA for raising such specific questions (and I am a bit amazed that this has not happened already).
- Dennis
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Monday, August 17, 2015 07:34
To: dev@corinthia.incubator.apache.org
Subject: Is using Bison & Flex ok?
I’m currently doing writing some experimental code for developing & testing a type inference algorithm that will eventually become of Flat. Because the latter is not at a sufficient stage of maturity, I’m using Bison & Flex to parse a simple C-like programming language upon which I’m doing the analysis.
I’d like to include this code in the repository, but wanted to confirm whether this is within the legal guidelines for dependent software. Bison is GPL, but has a special exception for the generated code (which contains part of Bison itself):
https://www.gnu.org/software/bison/manual/html_node/Conditions.html
[ ... ]