[libgpiod] consider changing the license of the C++ bindings

[libgpiod] consider changing the license of the C++ bindings

[Helmut Grohne]

Hi,

I've recently encountered libgpiod and found that its API is nice to
work with. Thank you for this piece of software.

IANAL

The library is licensed LGPL, which makes it available to non-free uses
in principle. For the C library, I think this is a good license. For the
C++ bindings, LGPL poses a little problem as code can be generated from
the header. For instance, libgpiodcxx is using `ctor() = default;`.
Strict intepretation of the LGPL would mean that a downstream user
should be able to recompile the whole product using libgpiodcxx.
Effectively, libgpiodcxx can be considered GPL (not LGPL) licensed for
practical purposes. You can find more background at:
 * https://blogs.msmvps.com/gdicanio/2016/07/11/the-lgpl-and-libraries-exposing-a-c-interface/
 * Eigen was initially LGPL and was converted to MPL2:
   https://eigen.tuxfamily.org/index.php?title=News:Relicensing_to_MPL2!
 * QT4 has also encountred this:
   https://lwn.net/Articles/315251/
I think that the LGPL when applied to C++ results in an unclear
licensing situation at best and an effective GPL at a strict
interpretation. Varying license interpretation rarely results in
anything good.

For these reasons, I ask you to consider changing the license for
libgpiodcxx only (and not for libgpiod nor for the Python bindings). I
propose following Eigen and switching to MPL2. If however, the intention
is the strict reading of the non-lesser GPL, consider switching to that
instead. Either change improves the clarity of the licensing and makes
the intention visible.

Thank you for considering

Helmut

Re: [libgpiod] consider changing the license of the C++ bindings

[Bartosz Golaszewski]

śr., 12 lut 2020 o 08:48 Helmut Grohne <helmut.grohne@intenta.de> napisał(a):
>
> Hi,
>
> I've recently encountered libgpiod and found that its API is nice to
> work with. Thank you for this piece of software.
>
> IANAL
>
> The library is licensed LGPL, which makes it available to non-free uses
> in principle. For the C library, I think this is a good license. For the
> C++ bindings, LGPL poses a little problem as code can be generated from
> the header. For instance, libgpiodcxx is using `ctor() = default;`.
> Strict intepretation of the LGPL would mean that a downstream user
> should be able to recompile the whole product using libgpiodcxx.
> Effectively, libgpiodcxx can be considered GPL (not LGPL) licensed for
> practical purposes. You can find more background at:
>  * https://blogs.msmvps.com/gdicanio/2016/07/11/the-lgpl-and-libraries-exposing-a-c-interface/
>  * Eigen was initially LGPL and was converted to MPL2:
>    https://eigen.tuxfamily.org/index.php?title=News:Relicensing_to_MPL2!
>  * QT4 has also encountred this:
>    https://lwn.net/Articles/315251/
> I think that the LGPL when applied to C++ results in an unclear
> licensing situation at best and an effective GPL at a strict
> interpretation. Varying license interpretation rarely results in
> anything good.
>
> For these reasons, I ask you to consider changing the license for
> libgpiodcxx only (and not for libgpiod nor for the Python bindings). I
> propose following Eigen and switching to MPL2. If however, the intention
> is the strict reading of the non-lesser GPL, consider switching to that
> instead. Either change improves the clarity of the licensing and makes
> the intention visible.
>

Hi Helmut,

thank you for this e-mail. I admit I'm not very well versed in
software licensing. What you're saying makes sense and the links you
posted seem to confirm it. I'll still try to get a second opinion on
this. Anyway: my intention is to make the library available to
non-free projects - including C++ bindings - so MPL2 makes sense.

There's only one significant contributor (new features, not bug-fixes)
to C++ bindings other than me (Cc'ed Kent Gibson) from whom I'd need
an ack on relicensing, so it shouldn't be very difficult to do.

While at it: LGPL is the only license used by all libgpiod components.
Do you know if it makes sense to use regular GPL for programs that are
part of the repo and LGPL for libraries only (except C++ bindings)?

Best regards,
Bartosz Golaszewski

Re: [libgpiod] consider changing the license of the C++ bindings

[Kent Gibson]

On Wed, Feb 12, 2020 at 11:00:56AM +0100, Bartosz Golaszewski wrote:
> śr., 12 lut 2020 o 08:48 Helmut Grohne <helmut.grohne@intenta.de> napisał(a):
> >
> > Hi,
> >
> > I've recently encountered libgpiod and found that its API is nice to
> > work with. Thank you for this piece of software.
> >
> > IANAL
> >
> > The library is licensed LGPL, which makes it available to non-free uses
> > in principle. For the C library, I think this is a good license. For the
> > C++ bindings, LGPL poses a little problem as code can be generated from
> > the header. For instance, libgpiodcxx is using `ctor() = default;`.
> > Strict intepretation of the LGPL would mean that a downstream user
> > should be able to recompile the whole product using libgpiodcxx.
> > Effectively, libgpiodcxx can be considered GPL (not LGPL) licensed for
> > practical purposes. You can find more background at:
> >  * https://blogs.msmvps.com/gdicanio/2016/07/11/the-lgpl-and-libraries-exposing-a-c-interface/
> >  * Eigen was initially LGPL and was converted to MPL2:
> >    https://eigen.tuxfamily.org/index.php?title=News:Relicensing_to_MPL2!
> >  * QT4 has also encountred this:
> >    https://lwn.net/Articles/315251/
> > I think that the LGPL when applied to C++ results in an unclear
> > licensing situation at best and an effective GPL at a strict
> > interpretation. Varying license interpretation rarely results in
> > anything good.
> >
> > For these reasons, I ask you to consider changing the license for
> > libgpiodcxx only (and not for libgpiod nor for the Python bindings). I
> > propose following Eigen and switching to MPL2. If however, the intention
> > is the strict reading of the non-lesser GPL, consider switching to that
> > instead. Either change improves the clarity of the licensing and makes
> > the intention visible.
> >
> 
> Hi Helmut,
> 
> thank you for this e-mail. I admit I'm not very well versed in
> software licensing. What you're saying makes sense and the links you
> posted seem to confirm it. I'll still try to get a second opinion on
> this. Anyway: my intention is to make the library available to
> non-free projects - including C++ bindings - so MPL2 makes sense.
> 
> There's only one significant contributor (new features, not bug-fixes)
> to C++ bindings other than me (Cc'ed Kent Gibson) from whom I'd need
> an ack on relicensing, so it shouldn't be very difficult to do.
> 

I agree with your intent, so feel free to relicense as you see fit.

Kent.

> While at it: LGPL is the only license used by all libgpiod components.
> Do you know if it makes sense to use regular GPL for programs that are
> part of the repo and LGPL for libraries only (except C++ bindings)?
> 
> Best regards,
> Bartosz Golaszewski

Re: [libgpiod] consider changing the license of the C++ bindings

[Bartosz Golaszewski]

śr., 12 lut 2020 o 11:00 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>
> śr., 12 lut 2020 o 08:48 Helmut Grohne <helmut.grohne@intenta.de> napisał(a):
> >
> > Hi,
> >
> > I've recently encountered libgpiod and found that its API is nice to
> > work with. Thank you for this piece of software.
> >
> > IANAL
> >
> > The library is licensed LGPL, which makes it available to non-free uses
> > in principle. For the C library, I think this is a good license. For the
> > C++ bindings, LGPL poses a little problem as code can be generated from
> > the header. For instance, libgpiodcxx is using `ctor() = default;`.
> > Strict intepretation of the LGPL would mean that a downstream user
> > should be able to recompile the whole product using libgpiodcxx.
> > Effectively, libgpiodcxx can be considered GPL (not LGPL) licensed for
> > practical purposes. You can find more background at:
> >  * https://blogs.msmvps.com/gdicanio/2016/07/11/the-lgpl-and-libraries-exposing-a-c-interface/
> >  * Eigen was initially LGPL and was converted to MPL2:
> >    https://eigen.tuxfamily.org/index.php?title=News:Relicensing_to_MPL2!
> >  * QT4 has also encountred this:
> >    https://lwn.net/Articles/315251/
> > I think that the LGPL when applied to C++ results in an unclear
> > licensing situation at best and an effective GPL at a strict
> > interpretation. Varying license interpretation rarely results in
> > anything good.
> >
> > For these reasons, I ask you to consider changing the license for
> > libgpiodcxx only (and not for libgpiod nor for the Python bindings). I
> > propose following Eigen and switching to MPL2. If however, the intention
> > is the strict reading of the non-lesser GPL, consider switching to that
> > instead. Either change improves the clarity of the licensing and makes
> > the intention visible.
> >
>
> Hi Helmut,
>
> thank you for this e-mail. I admit I'm not very well versed in
> software licensing. What you're saying makes sense and the links you
> posted seem to confirm it. I'll still try to get a second opinion on
> this. Anyway: my intention is to make the library available to
> non-free projects - including C++ bindings - so MPL2 makes sense.
>
> There's only one significant contributor (new features, not bug-fixes)
> to C++ bindings other than me (Cc'ed Kent Gibson) from whom I'd need
> an ack on relicensing, so it shouldn't be very difficult to do.
>
> While at it: LGPL is the only license used by all libgpiod components.
> Do you know if it makes sense to use regular GPL for programs that are
> part of the repo and LGPL for libraries only (except C++ bindings)?
>
> Best regards,
> Bartosz Golaszewski

Helmut,

one more thing that's unclear to me: I found this post[1] on the eigen
mailing list and started wondering: what makes MPL2 better than LGPL3?

Bart

[1] https://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2008/02/msg00003.html

Re: [libgpiod] consider changing the license of the C++ bindings

[Helmut Grohne]

On Wed, Feb 12, 2020 at 01:58:40PM +0100, Bartosz Golaszewski wrote:
> one more thing that's unclear to me: I found this post[1] on the eigen
> mailing list and started wondering: what makes MPL2 better than LGPL3?
...
> [1] https://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2008/02/msg00003.html

Thank you for pointing me to this. I mostly looked at the LGPL-2.1 and
overlooked the fact that libgpiod already uses the "later version"
language permitting use of LGPL-3. Indeed, the situation is much better
for LGPL-3 due to precisely the paragraphs referenced in that mail.

Thank you

Helmut

Re: [libgpiod] consider changing the license of the C++ bindings

[Bartosz Golaszewski]

czw., 13 lut 2020 o 11:15 Helmut Grohne <helmut.grohne@intenta.de> napisał(a):
>
> On Wed, Feb 12, 2020 at 01:58:40PM +0100, Bartosz Golaszewski wrote:
> > one more thing that's unclear to me: I found this post[1] on the eigen
> > mailing list and started wondering: what makes MPL2 better than LGPL3?
> ...
> > [1] https://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2008/02/msg00003.html
>
> Thank you for pointing me to this. I mostly looked at the LGPL-2.1 and
> overlooked the fact that libgpiod already uses the "later version"
> language permitting use of LGPL-3. Indeed, the situation is much better
> for LGPL-3 due to precisely the paragraphs referenced in that mail.
>
> Thank you
>
> Helmut

Does explicit relicensing to LGPL-3 make sense to avoid any potential confusion?

Bart

Re: [libgpiod] consider changing the license of the C++ bindings

[Helmut Grohne]

On Thu, Feb 13, 2020 at 11:17:08AM +0100, Bartosz Golaszewski wrote:
> Does explicit relicensing to LGPL-3 make sense to avoid any potential confusion?

I don't think so. Checking whether a GPL can be upgraded is a general
thing that I should quite simply have done. Most of the confusion I have
stems from reading the GPL language itself and trying to apply it
commercially.

Plus anyone encountering this issue now will quite likely have another
hit in their favourite search engine.

Helmut