Using GPLv3 in the build?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Using GPLv3 in the build?

Christofer Dutz
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/

Reply | Threaded
Open this post in threaded view
|

Re: Using GPLv3 in the build?

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Using GPLv3 in the build?

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" <[hidden email]>:

    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 <[hidden email]> 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: [hidden email]
    For additional commands, e-mail: [hidden email]
   
   


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Using GPLv3 in the build?

William A Rowe Jr
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 [hidden email]
inquiry with a corresponding Jira to have a binding conclusion.

On Wed, Jan 9, 2019, 10:04 Christofer Dutz <[hidden email] wrote:

> 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" <[hidden email]>:
>
>     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 <[hidden email]>
> 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: [hidden email]
>     For additional commands, e-mail: [hidden email]
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Using GPLv3 in the build?

Matt Sicker
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 <[hidden email]> 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 [hidden email]
> inquiry with a corresponding Jira to have a binding conclusion.
>
> On Wed, Jan 9, 2019, 10:04 Christofer Dutz <[hidden email] wrote:
>
> > 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" <[hidden email]>:
> >
> >     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 <[hidden email]>
> > 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: [hidden email]
> >     For additional commands, e-mail: [hidden email]
> >
> >
> >
> >



--
Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Using GPLv3 in the build?

Christofer Dutz
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 <[hidden email]>
Sent: Friday, January 11, 2019 6:06:25 PM
To: [hidden email]
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 <[hidden email]> 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 [hidden email]
> inquiry with a corresponding Jira to have a binding conclusion.
>
> On Wed, Jan 9, 2019, 10:04 Christofer Dutz <[hidden email] wrote:
>
> > 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" <[hidden email]>:
> >
> >     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 <[hidden email]>
> > 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: [hidden email]
> >     For additional commands, e-mail: [hidden email]
> >
> >
> >
> >



--
Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]