Re: Using GPLv3 in the build?
Unfortunately the till in question turned out to support serialisation only theoretically, only in Java and that only POC quality ... Will stick with helping that Daffodil pulling write a code generator. But good to know the "GPL in the build" thing :-) Chris Outlook for Android<https://aka.ms/ghei36> herunterladen From: Matt Sicker Sent: Friday, January 11, 2019 6:06:25 PM To: general@incubator.apache.org Subject: Re: Using GPLv3 in the build? Let's also not forget that OpenJDK is also GPLv2 with CP, though we use it everywhere instead of continuing development on Harmony. And then who knows how many GPL utilities were used in the original version of httpd? ;) On Fri, 11 Jan 2019 at 00:17, William A Rowe Jr wrote: > > Yup. This seems concordant with most of the GPL exception clauses on > generated output. That is fine, we don't prohibit through use of GPL for > target architecture buildable tarballs of sources, so long as the consumers > of those source tarballs are not imposed restrictions beyond the AL 2.0. > > Many projects generate tarballs from AutoMake/AutoConf, and this seems to > sort in that category, but to be sure, present this as a legal-discuss@a.o > inquiry with a corresponding Jira to have a binding conclusion. > > On Wed, Jan 9, 2019, 10:04 Christofer Dutz > > Ok ... so that was quick, > > > > I looked up the guy doing most of the commits and asked him. Here his > > reply: > > > > "As with majority of the compilers (gcc, clang, etc), Kaitai Struct > > compiler does not make any special takes on the output. If you own the > > input, you totally own the output, and free to specify your own > > conditions on its licensing. > > > > If you use something from our formats repo — http://formats.kaitai.io/ > > — it's generally safe to assume that output license equals to KSY > > input file license (of course, I'm not a lawyer, I can't provide legal > > advice, blah, blah, etc, the regular disclaimer you've probably seen > > tons of times already). As most of formats in that repo are > > CC0-licensed, basically it's public domain, you can do whatever you > > want with them." > > > > So if we input a definition which we write as part of the PLC4X project > > and which is naturally Apache 2.0, so the output would be Apache 2.0 too > > ... so that sounds good. > > > > Unfortunately he also told me that even if the parsing code was already > > good, the serialization code is in very early stages and would probably not > > be up to our expectations :-( > > > > So we probably shouldn't base our project on that ... but thanks for the > > fast response Richard :-) > > > > Chris > > > > > > > > Am 09.01.19, 16:26 schrieb "Richard Eckart de Castilho" : > > > > Hi Chris, > > > > This seems to be a similar situation as for tools such as automake > > (which I believe is used by several Apache projects). > > > > To the best of my knowledge (I am not a lawyer), the the copyleft > > clause of the GPLv3 does not impose and restrictions on the output of tools > > under the license. E.g. if you have a text editor published under GPLv3, > > the copyleft doesn't affect to the texts you have written with it. > > > > In the case of a code generator (like a compiler or like automake) > > you'd best check if the generated output contains anything that is licensed > > under the problematic license. For example, the compiler might generate a > > boot loader block into every application and this boot loader block might > > be under a copyleft license - that could be a problem. For this reason, > > e.g. automake has special exceptions to the GPLv3: > > https://www.gnu.org/licenses/exceptions.en.html > > > > If the compiler you want to use does not mention any such exceptions > > as part of their FAQ/license description, maybe best enter into contact > > with the developers and ask them. > > > > Cheers, > > > > -- Richard > > > > > On 9. Jan 2019, at 15:53, Christofer Dutz > > wrote: > > > > > > Hi all, > > > > > > I just double checked the text on the GPLv3 compatibility. > > > Stupid thing is the problem I’m having isn’t really covered by that > > [1]. > > > > > > The case I’m currently having is that there is a toolset called > > Kaitai [2], which sounds interesting for the Apache PLC4X project. > > > In general you define a data-format and have it generate model, > > serializer and pa
Re: Using GPLv3 in the build?
Let's also not forget that OpenJDK is also GPLv2 with CP, though we use it everywhere instead of continuing development on Harmony. And then who knows how many GPL utilities were used in the original version of httpd? ;) On Fri, 11 Jan 2019 at 00:17, William A Rowe Jr wrote: > > Yup. This seems concordant with most of the GPL exception clauses on > generated output. That is fine, we don't prohibit through use of GPL for > target architecture buildable tarballs of sources, so long as the consumers > of those source tarballs are not imposed restrictions beyond the AL 2.0. > > Many projects generate tarballs from AutoMake/AutoConf, and this seems to > sort in that category, but to be sure, present this as a legal-discuss@a.o > inquiry with a corresponding Jira to have a binding conclusion. > > On Wed, Jan 9, 2019, 10:04 Christofer Dutz > > Ok ... so that was quick, > > > > I looked up the guy doing most of the commits and asked him. Here his > > reply: > > > > "As with majority of the compilers (gcc, clang, etc), Kaitai Struct > > compiler does not make any special takes on the output. If you own the > > input, you totally own the output, and free to specify your own > > conditions on its licensing. > > > > If you use something from our formats repo — http://formats.kaitai.io/ > > — it's generally safe to assume that output license equals to KSY > > input file license (of course, I'm not a lawyer, I can't provide legal > > advice, blah, blah, etc, the regular disclaimer you've probably seen > > tons of times already). As most of formats in that repo are > > CC0-licensed, basically it's public domain, you can do whatever you > > want with them." > > > > So if we input a definition which we write as part of the PLC4X project > > and which is naturally Apache 2.0, so the output would be Apache 2.0 too > > ... so that sounds good. > > > > Unfortunately he also told me that even if the parsing code was already > > good, the serialization code is in very early stages and would probably not > > be up to our expectations :-( > > > > So we probably shouldn't base our project on that ... but thanks for the > > fast response Richard :-) > > > > Chris > > > > > > > > Am 09.01.19, 16:26 schrieb "Richard Eckart de Castilho" : > > > > Hi Chris, > > > > This seems to be a similar situation as for tools such as automake > > (which I believe is used by several Apache projects). > > > > To the best of my knowledge (I am not a lawyer), the the copyleft > > clause of the GPLv3 does not impose and restrictions on the output of tools > > under the license. E.g. if you have a text editor published under GPLv3, > > the copyleft doesn't affect to the texts you have written with it. > > > > In the case of a code generator (like a compiler or like automake) > > you'd best check if the generated output contains anything that is licensed > > under the problematic license. For example, the compiler might generate a > > boot loader block into every application and this boot loader block might > > be under a copyleft license - that could be a problem. For this reason, > > e.g. automake has special exceptions to the GPLv3: > > https://www.gnu.org/licenses/exceptions.en.html > > > > If the compiler you want to use does not mention any such exceptions > > as part of their FAQ/license description, maybe best enter into contact > > with the developers and ask them. > > > > Cheers, > > > > -- Richard > > > > > On 9. Jan 2019, at 15:53, Christofer Dutz > > wrote: > > > > > > Hi all, > > > > > > I just double checked the text on the GPLv3 compatibility. > > > Stupid thing is the problem I’m having isn’t really covered by that > > [1]. > > > > > > The case I’m currently having is that there is a toolset called > > Kaitai [2], which sounds interesting for the Apache PLC4X project. > > > In general you define a data-format and have it generate model, > > serializer and parser in multiple languages (Similar to Thrift or Protobuf, > > but with a focus on the transport data-format and not the model). > > > > > > This consists of a compiler and a runtime. > > > > > > The compiler generates code from sources which use the runtime > > libraries. > > > The runtime libraries are Apache 2.0 and MIT licensed, so this would > > be ok > > > The compiler however is GPLv3 … > > > > > > Now we would not be bunding the compiler and the users wouldn’t need > > to use it when using PLC4X as it’s only needed in the code-generation phase > > of the build. > > > > > > So before I throw the idea over board, I just wanted to double-check > > this special case. > > > > > > Chris > > > > > > > > > > > > [1] https://www.apache.org/licenses/GPL-compatibility.html > > > [2] https://kaitai.io/ > > > > > > > > > - > > To unsubscribe, e-mail:
Re: Using GPLv3 in the build?
Yup. This seems concordant with most of the GPL exception clauses on generated output. That is fine, we don't prohibit through use of GPL for target architecture buildable tarballs of sources, so long as the consumers of those source tarballs are not imposed restrictions beyond the AL 2.0. Many projects generate tarballs from AutoMake/AutoConf, and this seems to sort in that category, but to be sure, present this as a legal-discuss@a.o inquiry with a corresponding Jira to have a binding conclusion. On Wed, Jan 9, 2019, 10:04 Christofer Dutz Ok ... so that was quick, > > I looked up the guy doing most of the commits and asked him. Here his > reply: > > "As with majority of the compilers (gcc, clang, etc), Kaitai Struct > compiler does not make any special takes on the output. If you own the > input, you totally own the output, and free to specify your own > conditions on its licensing. > > If you use something from our formats repo — http://formats.kaitai.io/ > — it's generally safe to assume that output license equals to KSY > input file license (of course, I'm not a lawyer, I can't provide legal > advice, blah, blah, etc, the regular disclaimer you've probably seen > tons of times already). As most of formats in that repo are > CC0-licensed, basically it's public domain, you can do whatever you > want with them." > > So if we input a definition which we write as part of the PLC4X project > and which is naturally Apache 2.0, so the output would be Apache 2.0 too > ... so that sounds good. > > Unfortunately he also told me that even if the parsing code was already > good, the serialization code is in very early stages and would probably not > be up to our expectations :-( > > So we probably shouldn't base our project on that ... but thanks for the > fast response Richard :-) > > Chris > > > > Am 09.01.19, 16:26 schrieb "Richard Eckart de Castilho" : > > Hi Chris, > > This seems to be a similar situation as for tools such as automake > (which I believe is used by several Apache projects). > > To the best of my knowledge (I am not a lawyer), the the copyleft > clause of the GPLv3 does not impose and restrictions on the output of tools > under the license. E.g. if you have a text editor published under GPLv3, > the copyleft doesn't affect to the texts you have written with it. > > In the case of a code generator (like a compiler or like automake) > you'd best check if the generated output contains anything that is licensed > under the problematic license. For example, the compiler might generate a > boot loader block into every application and this boot loader block might > be under a copyleft license - that could be a problem. For this reason, > e.g. automake has special exceptions to the GPLv3: > https://www.gnu.org/licenses/exceptions.en.html > > If the compiler you want to use does not mention any such exceptions > as part of their FAQ/license description, maybe best enter into contact > with the developers and ask them. > > Cheers, > > -- Richard > > > On 9. Jan 2019, at 15:53, Christofer Dutz > wrote: > > > > Hi all, > > > > I just double checked the text on the GPLv3 compatibility. > > Stupid thing is the problem I’m having isn’t really covered by that > [1]. > > > > The case I’m currently having is that there is a toolset called > Kaitai [2], which sounds interesting for the Apache PLC4X project. > > In general you define a data-format and have it generate model, > serializer and parser in multiple languages (Similar to Thrift or Protobuf, > but with a focus on the transport data-format and not the model). > > > > This consists of a compiler and a runtime. > > > > The compiler generates code from sources which use the runtime > libraries. > > The runtime libraries are Apache 2.0 and MIT licensed, so this would > be ok > > The compiler however is GPLv3 … > > > > Now we would not be bunding the compiler and the users wouldn’t need > to use it when using PLC4X as it’s only needed in the code-generation phase > of the build. > > > > So before I throw the idea over board, I just wanted to double-check > this special case. > > > > Chris > > > > > > > > [1] https://www.apache.org/licenses/GPL-compatibility.html > > [2] https://kaitai.io/ > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > > >
Re: Using GPLv3 in the build?
Ok ... so that was quick, I looked up the guy doing most of the commits and asked him. Here his reply: "As with majority of the compilers (gcc, clang, etc), Kaitai Struct compiler does not make any special takes on the output. If you own the input, you totally own the output, and free to specify your own conditions on its licensing. If you use something from our formats repo — http://formats.kaitai.io/ — it's generally safe to assume that output license equals to KSY input file license (of course, I'm not a lawyer, I can't provide legal advice, blah, blah, etc, the regular disclaimer you've probably seen tons of times already). As most of formats in that repo are CC0-licensed, basically it's public domain, you can do whatever you want with them." So if we input a definition which we write as part of the PLC4X project and which is naturally Apache 2.0, so the output would be Apache 2.0 too ... so that sounds good. Unfortunately he also told me that even if the parsing code was already good, the serialization code is in very early stages and would probably not be up to our expectations :-( So we probably shouldn't base our project on that ... but thanks for the fast response Richard :-) Chris Am 09.01.19, 16:26 schrieb "Richard Eckart de Castilho" : Hi Chris, This seems to be a similar situation as for tools such as automake (which I believe is used by several Apache projects). To the best of my knowledge (I am not a lawyer), the the copyleft clause of the GPLv3 does not impose and restrictions on the output of tools under the license. E.g. if you have a text editor published under GPLv3, the copyleft doesn't affect to the texts you have written with it. In the case of a code generator (like a compiler or like automake) you'd best check if the generated output contains anything that is licensed under the problematic license. For example, the compiler might generate a boot loader block into every application and this boot loader block might be under a copyleft license - that could be a problem. For this reason, e.g. automake has special exceptions to the GPLv3: https://www.gnu.org/licenses/exceptions.en.html If the compiler you want to use does not mention any such exceptions as part of their FAQ/license description, maybe best enter into contact with the developers and ask them. Cheers, -- Richard > On 9. Jan 2019, at 15:53, Christofer Dutz wrote: > > Hi all, > > I just double checked the text on the GPLv3 compatibility. > Stupid thing is the problem I’m having isn’t really covered by that [1]. > > The case I’m currently having is that there is a toolset called Kaitai [2], which sounds interesting for the Apache PLC4X project. > In general you define a data-format and have it generate model, serializer and parser in multiple languages (Similar to Thrift or Protobuf, but with a focus on the transport data-format and not the model). > > This consists of a compiler and a runtime. > > The compiler generates code from sources which use the runtime libraries. > The runtime libraries are Apache 2.0 and MIT licensed, so this would be ok > The compiler however is GPLv3 … > > Now we would not be bunding the compiler and the users wouldn’t need to use it when using PLC4X as it’s only needed in the code-generation phase of the build. > > So before I throw the idea over board, I just wanted to double-check this special case. > > Chris > > > > [1] https://www.apache.org/licenses/GPL-compatibility.html > [2] https://kaitai.io/ > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Using GPLv3 in the build?
Hi Chris, This seems to be a similar situation as for tools such as automake (which I believe is used by several Apache projects). To the best of my knowledge (I am not a lawyer), the the copyleft clause of the GPLv3 does not impose and restrictions on the output of tools under the license. E.g. if you have a text editor published under GPLv3, the copyleft doesn't affect to the texts you have written with it. In the case of a code generator (like a compiler or like automake) you'd best check if the generated output contains anything that is licensed under the problematic license. For example, the compiler might generate a boot loader block into every application and this boot loader block might be under a copyleft license - that could be a problem. For this reason, e.g. automake has special exceptions to the GPLv3: https://www.gnu.org/licenses/exceptions.en.html If the compiler you want to use does not mention any such exceptions as part of their FAQ/license description, maybe best enter into contact with the developers and ask them. Cheers, -- Richard > On 9. Jan 2019, at 15:53, Christofer Dutz wrote: > > Hi all, > > I just double checked the text on the GPLv3 compatibility. > Stupid thing is the problem I’m having isn’t really covered by that [1]. > > The case I’m currently having is that there is a toolset called Kaitai [2], > which sounds interesting for the Apache PLC4X project. > In general you define a data-format and have it generate model, serializer > and parser in multiple languages (Similar to Thrift or Protobuf, but with a > focus on the transport data-format and not the model). > > This consists of a compiler and a runtime. > > The compiler generates code from sources which use the runtime libraries. > The runtime libraries are Apache 2.0 and MIT licensed, so this would be ok > The compiler however is GPLv3 … > > Now we would not be bunding the compiler and the users wouldn’t need to use > it when using PLC4X as it’s only needed in the code-generation phase of the > build. > > So before I throw the idea over board, I just wanted to double-check this > special case. > > Chris > > > > [1] https://www.apache.org/licenses/GPL-compatibility.html > [2] https://kaitai.io/ > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Using GPLv3 in the build?
Hi all, I just double checked the text on the GPLv3 compatibility. Stupid thing is the problem I’m having isn’t really covered by that [1]. The case I’m currently having is that there is a toolset called Kaitai [2], which sounds interesting for the Apache PLC4X project. In general you define a data-format and have it generate model, serializer and parser in multiple languages (Similar to Thrift or Protobuf, but with a focus on the transport data-format and not the model). This consists of a compiler and a runtime. The compiler generates code from sources which use the runtime libraries. The runtime libraries are Apache 2.0 and MIT licensed, so this would be ok The compiler however is GPLv3 … Now we would not be bunding the compiler and the users wouldn’t need to use it when using PLC4X as it’s only needed in the code-generation phase of the build. So before I throw the idea over board, I just wanted to double-check this special case. Chris [1] https://www.apache.org/licenses/GPL-compatibility.html [2] https://kaitai.io/
