Re: System libraries and the GPLv2

[Francesco Poli]

On Wed, 29 Mar 2017 23:28:46 -0400 Richard Fontana wrote:

> On Thu, Mar 30, 2017 at 05:08:24AM +0200, Carlos Alberto Lopez Perez wrote:
> 
> > Do you (or anyone else) _really_ think the copyright holders of the GPL
> > program in question had any intention ever of not allowing their program
> > to be used along with OpenSSL, when they where the ones implementing
> > support for using it on the first place?
> 
> This, I would say, encapsulates the real Fedora/Red Hat position on
> this issue to the extent there is one. It assumes that the intent of
> the copyright holders can be determined from their actions.

What about programs that link both with OpenSSL and with a
third party purely-GPL-licensed library?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpNVc2q2CpDS.pgp
Description: PGP signature

Re: System libraries and the GPLv2

[Don Armstrong]

On Thu, 30 Mar 2017, Carlos Alberto Lopez Perez wrote:
> On 30/03/17 21:29, Don Armstrong wrote:
> > Precisely. It only has bearing on whether the system library
> > exception to derivative works applies.
> 
> It should apply.

Why should it apply? GPLv2 is written to make the system library
exception not apply to distributors of the system library.

> Fedora and RHEL ship also DVD images, and they do use this system
> exception clause of the GPL for linking with OpenSSL.

How do you know this? They could have made a judgement that copyright
holders who have written code which links against OpenSSL have given an
implicit license grant, or that the likelihood of litigation is
outweighed by the issue with distributing such software.

Or they may have just not bothered doing either, and hoped for the best.

> If you are still not sure, lets consult this with a lawyer instead of
> trying to argue about the wording of a license.

I don't think that's necessary, but by all means, write up a specific
set of questions that you propose to have the project ask its legal
representation. Note as well, that the legal advice will necessarily be
jurisdiction and project specific.

-- 
Don Armstrong  https://www.donarmstrong.com

This can't be happening to me. I've got tenure.
 -- James Hynes _Publish and Perish_

Re: System libraries and the GPLv2

[Carlos Alberto Lopez Perez]

On 30/03/17 08:05, Andrey Rahmatullin wrote:
> On Wed, Mar 29, 2017 at 11:10:01PM +0200, Carlos Alberto Lopez Perez wrote:
>> Apache 2.0 is compatible with GPLv3 [1] (therefore also with GPLv2+).
> It's more complicated than "therefore also".
> Imagine a GPL2+ program library linked with a GPL2 library. Now also link
> this program with an Apache 2.0 library. What happens?
> 
I agree its more complicated. But usually what happens is this:

For several Linux distributions: nothing happens because they have
already declared OpenSSL a system library.

For Debian: the maintainer reports a bug to the author of the GPLv2
library so they add an exception to link with the OpenSSL. The upstream
maintainer either can't do that because its unable to contact every
author of the software or doesn't care and thinks this is a Debian
specific issue. The Debian maintainer either abandons here or takes into
the task of implementing a patch that uses libgcrypt or similar instead
of OpenSSL. It can happen that the Debian maintainer simply disables the
feature that uses OpenSSL (if that is an option)




signature.asc
Description: OpenPGP digital signature

Re: System libraries and the GPLv2

[Carlos Alberto Lopez Perez]

On 30/03/17 21:29, Don Armstrong wrote:
> On Thu, 30 Mar 2017, Carlos Alberto Lopez Perez wrote:
>> * License Must Not Contaminate _Other_ Software
> 
> A work which is a derivative work of another piece of software isn't
> merely distributed alongside.
> 
>> Shipping a collection of software on a DVD doesn't make any of this
>> pieces of software a derivative works one of the other.
> 
> Precisely. It only has bearing on whether the system library exception
> to derivative works applies.
> 

It should apply.

Fedora and RHEL ship also DVD images, and they do use this system
exception clause of the GPL for linking with OpenSSL.

If you are still not sure, lets consult this with a lawyer instead of
trying to argue about the wording of a license.



signature.asc
Description: OpenPGP digital signature

Re: System libraries and the GPLv2

[Carlos Alberto Lopez Perez]

On 30/03/17 21:09, Russ Allbery wrote:
> Lars Wirzenius  writes:
> 
>> Instead, I'll repeat that licenses shouldn't be violated. One way of
>> achieving that is to ask copyright holders for additional permissions
>> that are needed to avoid a violation.
> 
> The problem with this approach, though, is that many of us have tried this
> with GPL software that links against OpenSSL and have been told that we're
> being pedantic, wasting the maintainer's time, and they aren't going to
> include any such specific license grant because they're not lawyers,
> aren't going to mess with licenses, no one else has this problem, and
> Debian needs to pull the stick out of its ass.
> 
> Now one can just say "well, we don't want to package software from
> maintainers like that anyway," but often those people are perfectly
> reasonable on many other topics and quite good upstreams.  We are widely
> viewed as out of step with the community on this specific point, whether
> reasonably or unreasonably.
> 
> I'm not saying we're wrong, necessarily, but the way that Debian interacts
> with software licenses is truly not the way that nearly everyone else
> interacts with software licenses.  We have non-lawyers with no legal
> training read them carefully and attempt to apply their rules as if they
> were written in normal English, very precisely.  (In other words, we treat
> them like they're computer programs.)  Very, very few people outside of
> Debian do this.  Elsewhere, people largely divide into two camps: a quick
> skim looking for obvious issues followed by "meh, good enough," or review
> by an actual lawyer who is making a legal decision based on legal
> interpretation, case law, and a risk analysis.
> 
> I think we normally arrive at reasonable conclusions, but sometimes we do
> arrive at conclusions that neither of those other two camps reach, and
> then we can look oddly out of touch.
> 

Couldn't agree more with you.

Programmers shouldn't try to interpret corner cases on licenses,
or judge about license compatibility.

What the text of a license says is never interpreted word by word by a
lawyer or a tribunal. The intention is also very important.

And when you release a software that uses OpenSSL, there is a clear
intention in that fact that you allow to use OpenSSL. After all, you
have implemented support for it.

I think we should try to consult more with lawyers when we have doubts,
or when there is a disagreement about licenses in general.

It worked for the ZFSOnLinux case.
I think it can work also for this system library exception issue.

My 2 cents.



signature.asc
Description: OpenPGP digital signature

Re: System libraries and the GPLv2

[Don Armstrong]

On Thu, 30 Mar 2017, Carlos Alberto Lopez Perez wrote:
> * License Must Not Contaminate _Other_ Software

A work which is a derivative work of another piece of software isn't
merely distributed alongside.

> Shipping a collection of software on a DVD doesn't make any of this
> pieces of software a derivative works one of the other.

Precisely. It only has bearing on whether the system library exception
to derivative works applies.

-- 
Don Armstrong  https://www.donarmstrong.com

The computer allows you to make mistakes faster than any other
invention, with the possible exception of handguns and tequila
 -- Mitch Ratcliffe

Re: System libraries and the GPLv2

[Carlos Alberto Lopez Perez]

On 30/03/17 14:31, Ian Jackson wrote:
> Carlos Alberto Lopez Perez writes ("Re: System libraries and the GPLv2"):
>> However, I still don't understand why we don't just declare OpenSSL a
>> system library; or at least define a clear policy for when a package is
>> considered part of the base system (so the GPL system exception applies
>> to it).
> 
> I think the GPL system library exception does not apply for the
> benefit of anything on a DVD image.  Since we want downstreams to be
> able to make arbitrary DVD( image)s containing whatever bits (of main)
> that they like, and distribute them, we cannot rely on the system
> library exception for anything in Debian.
> 
> Ian.
> 

Let me you remember DFSG number 9 [1]:

* License Must Not Contaminate _Other_ Software

The license must not place restrictions on other software that is
distributed along with the licensed software. For example, the
license must not insist that all other programs distributed on the
same medium must be free software.

And also point you to my previous answer to Dmitry:

 https://lists.debian.org/debian-legal/2017/03/msg00042.html


Shipping a collection of software on a DVD doesn't make any of this
pieces of software a derivative works one of the other.


[1] https://www.debian.org/social_contract




signature.asc
Description: OpenPGP digital signature

Re: System libraries and the GPLv2

[Don Armstrong]

On Thu, 30 Mar 2017, Holger Levsen wrote:
> It's also a major fuckup for some GPLv2-only users (as you just
> described), which as a result made *me* like+trust the FSF and the GPL
> less.

The FSF has always suggested that everyone license their works with the
current revision of the GPL at the time of starting the project, or any
later version, at your option. The only way the FSF could have
accommodated v2 only people was to include an explicit v2 reversion
clause, which makes many of the nice v3 features useless. [Like patents,
warranty disclaimers, non-source conveyance, DMCA bits, etc.]

> (And which then also resulted in me choosing GPLv2-only over GPLv2 or
> GPLv3 more often.)

Why not just license your work GPLv2+, then? You get compatibility with
v3, you can still work with anything which is v2 only, and you have
compatibility with a newer revision of the GPL if one ever happens. Or
at least appoint a proxy who can decide whether later license revisions
meet your standards.


-- 
Don Armstrong  https://www.donarmstrong.com

Do not handicap your children by making their lives easy.
 -- Robert Heinlein _Time Enough For Love_ p251

Re: System libraries and the GPLv2

[Jonas Smedegaard]

Quoting Carlos Alberto Lopez Perez (2017-03-30 19:12:53)
> On 30/03/17 10:44, Jonas Smedegaard wrote:
> > Quoting Carlos Alberto Lopez Perez (2017-03-30 05:08:24)
> >> On 30/03/17 03:11, Clint Byrum wrote:
> >>> Excerpts from Carlos Alberto Lopez Perez's message of 2017-03-30 02:49:04 
> >>> +0200:
>  I understand that Debian wants to take a position of zero (or 
>  minimal) risk, and I also understand the desire to respect the 
>  interpretation of the FSF about the GPL (they don't think this two 
>  licenses are compatibles).
> 
> >>>
> >>> I believe that this is a fundamental difference between RedHat and 
> >>> Debian.
> >>>
> >>> RedHat is going to do everything within the law and inside their 
> >>> values for a profit. Their values don't include a strict adherence 
> >>> to the wishes of copyright holders, but strict adherence to the law.
> >>>
> >>> But our values do include respect for copyright holder rights. So 
> >>> while we can probably get away with this legally, it's been decided 
> >>> (a few times?) that without the GPL licensor's consent, we can't in 
> >>> good faith produce a combination of OpenSSL and a GPL program.
> >>>
> >>
> >> Just a simple question:
> >>
> >> Do you (or anyone else) _really_ think the copyright holders of the 
> >> GPL program in question had any intention ever of not allowing their 
> >> program to be used along with OpenSSL, when they where the ones 
> >> implementing support for using it on the first place?
> > 
> > Yes, I believe so.
> > 
> > As a concrete example, the Netatalk project has for many years released 
> > code with plugins linking to OpenSSL, but has not added an exception.  
> > Authors of Netatalk try to make a living out of commercial support for 
> > their product, and I genuinely think it is in their interest to make it 
> > possible to use strong crypto - for personal use - but not allow 
> > redistribution of binaries with strong crypto.

> Do you have any link or resource that can back what you say here?

You asked what I _think_ and I shared that with you.

I do not speak on behalf of Netatalk, just brought it up as an example 
of what inspires my thinking.  More specifically what makes me think 
they care about differentiated use cases is their blogging at some point 
about a NAS company using their code unfairly.  but again, I mention 
this not as a piece of fact but as inspiration on how more generally 
some may deal differently with licensing.

You may judge my input unreliable due to not being proven by fact, or 
you may judge my thinking "far out".


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: System libraries and the GPLv2

[Carlos Alberto Lopez Perez]

On 30/03/17 10:44, Jonas Smedegaard wrote:
> Quoting Carlos Alberto Lopez Perez (2017-03-30 05:08:24)
>> On 30/03/17 03:11, Clint Byrum wrote:
>>> Excerpts from Carlos Alberto Lopez Perez's message of 2017-03-30 02:49:04 
>>> +0200:
 I understand that Debian wants to take a position of zero (or 
 minimal) risk, and I also understand the desire to respect the 
 interpretation of the FSF about the GPL (they don't think this two 
 licenses are compatibles).

>>>
>>> I believe that this is a fundamental difference between RedHat and 
>>> Debian.
>>>
>>> RedHat is going to do everything within the law and inside their 
>>> values for a profit. Their values don't include a strict adherence 
>>> to the wishes of copyright holders, but strict adherence to the law.
>>>
>>> But our values do include respect for copyright holder rights. So 
>>> while we can probably get away with this legally, it's been decided 
>>> (a few times?) that without the GPL licensor's consent, we can't in 
>>> good faith produce a combination of OpenSSL and a GPL program.
>>>
>>
>> Just a simple question:
>>
>> Do you (or anyone else) _really_ think the copyright holders of the 
>> GPL program in question had any intention ever of not allowing their 
>> program to be used along with OpenSSL, when they where the ones 
>> implementing support for using it on the first place?
> 
> Yes, I believe so.
> 
> As a concrete example, the Netatalk project has for many years released 
> code with plugins linking to OpenSSL, but has not added an exception.  
> Authors of Netatalk try to make a living out of commercial support for 
> their product, and I genuinely think it is in their interest to make it 
> possible to use strong crypto - for personal use - but not allow 
> redistribution of binaries with strong crypto.
> 
> 
>  - Jonas
> 

Do you have any link or resource that can back what you say here?

I didn't knew about the Netatalk project, but after Googling about this
issue I only see an upstream frustrated because they are unable to
re-license [1], as they are unable to contact all the contributors the
project has.

As you can imagine, any successfully open source project will accumulate
hundreds of contributors along the years (at least 17 years [2] in this
case). Contacting them may be simple just impossible (people change of
email address all the time, people also pass away, and people can just
simply ignore the mail because they are busy with some other stuff).

On top of that, the incentive to take into doing this hard work is not
very big, as either not all downstreams take this issue with the GPL and
OpenSSL as far as Debian, or they include OpenSSL as a system library.

I also see Netatalk was shipped until Fedora 23 with OpenSSL support!
[3], until it was retired because nobody cared to keep maintaining it [4].

IMHO: if your business model is to sell pre-built binaries with some
feature, its better that you keep this feature with the right license
that prohibits distributing it and forces everyone to build from
sources, rather than relying on some incompatibility between the GPL and
OpenSSL that is not going to stop anyone but Debian and its derivatives
from shipping it.


Regards
---

[1]
https://lists.debian.org/debian-legal/2004/08/msg00184.html
https://sourceforge.net/p/netatalk/feature-requests/33/
[2]
https://github.com/Netatalk/Netatalk/commit/31843674b7bd32eabcce3a1ad6159b4f94921f79#diff-cf45edbe4d45d61b0f0ce5e9eaeb38bcR82
[3]
http://pkgs.fedoraproject.org/cgit/rpms/netatalk.git/tree/netatalk.spec?h=f23#n84
[4]
http://pkgs.fedoraproject.org/cgit/rpms/netatalk.git/commit/?id=81611ededd7b668145715779723c60d84ef74003



signature.asc
Description: OpenPGP digital signature

Re: System libraries and the GPLv2

[Holger Levsen]

On Thu, Mar 30, 2017 at 10:27:46AM +0200, Florian Weimer wrote:
> What really annoys me about this whole situation is this: I think no
> one presently argues that the GPLv2 prevents people from distributing
> pre-built binaries for proprietary operating systems.  I can take
> Hotspot (a component of OpenJDK which is GPLv2-only), compile it with
> Microsoft Visual Studio, and distribute the result.  But I suddenly
> can't ship pre-built binaries, as a free software distribution,
> because I happen to have upgraded the system compiler past GCC 4.2,
> thus got the new GPLv3+ license for libgcc, and can't link GPLv2-only
> Hotspot against that anymore.  This can't be right, can it?

well, yes and no. By design GPLv3 is incompatible with GPLv2-only,
so this is "right" in the sense that it works as intended. It's also a
major fuckup for some GPLv2-only users (as you just described), which
as a result made *me* like+trust the FSF and the GPL less.

(And which then also resulted in me choosing GPLv2-only over GPLv2 or GPLv3
more often.)

By now I also think these "or any future version" clauses are… brave.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: System libraries and the GPLv2

[Ian Jackson]

Carlos Alberto Lopez Perez writes ("Re: System libraries and the GPLv2"):
> However, I still don't understand why we don't just declare OpenSSL a
> system library; or at least define a clear policy for when a package is
> considered part of the base system (so the GPL system exception applies
> to it).

I think the GPL system library exception does not apply for the
benefit of anything on a DVD image.  Since we want downstreams to be
able to make arbitrary DVD( image)s containing whatever bits (of main)
that they like, and distribute them, we cannot rely on the system
library exception for anything in Debian.

Ian.

Re: System libraries and the GPLv2

[Jonas Smedegaard]

Quoting Carlos Alberto Lopez Perez (2017-03-30 05:08:24)
> On 30/03/17 03:11, Clint Byrum wrote:
> > Excerpts from Carlos Alberto Lopez Perez's message of 2017-03-30 02:49:04 
> > +0200:
> >> I understand that Debian wants to take a position of zero (or 
> >> minimal) risk, and I also understand the desire to respect the 
> >> interpretation of the FSF about the GPL (they don't think this two 
> >> licenses are compatibles).
> >>
> > 
> > I believe that this is a fundamental difference between RedHat and 
> > Debian.
> > 
> > RedHat is going to do everything within the law and inside their 
> > values for a profit. Their values don't include a strict adherence 
> > to the wishes of copyright holders, but strict adherence to the law.
> > 
> > But our values do include respect for copyright holder rights. So 
> > while we can probably get away with this legally, it's been decided 
> > (a few times?) that without the GPL licensor's consent, we can't in 
> > good faith produce a combination of OpenSSL and a GPL program.
> > 
> 
> Just a simple question:
> 
> Do you (or anyone else) _really_ think the copyright holders of the 
> GPL program in question had any intention ever of not allowing their 
> program to be used along with OpenSSL, when they where the ones 
> implementing support for using it on the first place?

Yes, I believe so.

As a concrete example, the Netatalk project has for many years released 
code with plugins linking to OpenSSL, but has not added an exception.  
Authors of Netatalk try to make a living out of commercial support for 
their product, and I genuinely think it is in their interest to make it 
possible to use strong crypto - for personal use - but not allow 
redistribution of binaries with strong crypto.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature