corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Is using Bison & Flex ok?
Date Mon, 17 Aug 2015 17:19:07 GMT
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

<> and the illustration of what a generated file
is like at <>.

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 [] 
Sent: Monday, August 17, 2015 09:16
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 [] 
Sent: Monday, August 17, 2015 07:34
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):

[ ... ]

View raw message