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.hamil...@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:pmke...@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 [ ... ]
