Re: System libraries and the GPLv2

[Adam Borowski]

On Wed, Mar 29, 2017 at 11:28:46PM -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.

We're all coders here, so here's a code example:
==
void main()
{
printf("meow\n");
}
==

Hey, it works!  It might lack that #include  thus might not compile
in some setups, and produces a bogus exit code (5 on amd64, armhf and arm64
on current unstable), but it produces the right output, and those who run
scripts with "set -e" are only bringing problems upon themselves, right?

The approach of commercial companies to both code and law is "it compiles? 
Ship it!".  They have sizeable legal departments, so the question they ask
themselves is not "is this legal?" but "are costs of possible litigation
smaller or greater than the cost of doing it correctly?".  On the other
hand, individuals who'd be sued in Debian's case (the SPI has no deep
pockets thus is an unlikely target) have no legal clout so being fully in
the clean is our only defense.

(And yeah, in the current legal practice, even being 100% clean has
surprisingly low impact on whether you win in court.  A "win" where you pay
tens of thousands of dollars doesn't count as a win.)

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Re: System libraries and the GPLv2

[Florian Weimer]

* Josh Triplett:

> The intention of the system library exception is to allow third
> parties to ship Free Software on proprietary platforms, while
> pointedly *disallowing* the vendor of the proprietary platform from
> doing so.  As historical precedent, note that some vendors explicitly
> provided entirely separate media containing GNU applications, in order
> to satisfy that requirement.

But those vendors have since stopped doing that, and the GNU tools are
shipped along with the rest of the operating system (Solaris, Macos),
or at least together with the libc they are linked against (Interix).

Re: System libraries and the GPLv2

[Lars Wirzenius]

On Thu, Mar 30, 2017 at 08:14:25AM +0200, Vincent Bernat wrote:
> As Carlos, it's hard for me to believe anyone will object to OpenSSL
> linking, all the more when they implemented the support for it.

A compication in this is that even though the developers of a program
would be happy with linking to OpenSSL, people who've written other
libraries the program uses, or other code included in the program, may
not be. I'm such a person. If some code I've released some code under
GPL2 (only), and you link use it in a way that causes it to be linked
with OpenSSL without asking me, you'll make me unhappy. I'm unlikely
to sue you (life is too short), but I might grumble lengthily into my
cup of tea.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: System libraries and the GPLv2

[Florian Weimer]

* Adam Borowski:

> The approach of commercial companies to both code and law is "it compiles? 
> Ship it!".  They have sizeable legal departments, so the question they ask
> themselves is not "is this legal?" but "are costs of possible litigation
> smaller or greater than the cost of doing it correctly?".  On the other
> hand, individuals who'd be sued in Debian's case (the SPI has no deep
> pockets thus is an unlikely target) have no legal clout so being fully in
> the clean is our only defense.

But we make similar risk assessments all the time.  Some of us even
strongly defend the right to anonymous contributions, that is, they
argue against keeping exact copyright records, which could otherwise
be used to identify the party who added code for which they did not
have permission (so that Debian or a liable Debian contributor could
recover their costs from them).

Re: System libraries and the GPLv2

[Vincent Bernat]

 ❦ 30 mars 2017 10:46 +0300, Lars Wirzenius  :

>> As Carlos, it's hard for me to believe anyone will object to OpenSSL
>> linking, all the more when they implemented the support for it.
>
> A compication in this is that even though the developers of a program
> would be happy with linking to OpenSSL, people who've written other
> libraries the program uses, or other code included in the program, may
> not be. I'm such a person. If some code I've released some code under
> GPL2 (only), and you link use it in a way that causes it to be linked
> with OpenSSL without asking me, you'll make me unhappy. I'm unlikely
> to sue you (life is too short), but I might grumble lengthily into my
> cup of tea.

Well, that's really new to me. Why would you object to link to OpenSSL?
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: System libraries and the GPLv2

[Lars Wirzenius]

On Thu, Mar 30, 2017 at 10:09:20AM +0200, Vincent Bernat wrote:
> Well, that's really new to me. Why would you object to link to OpenSSL?

I'm not sure how to respond to this.

I don't understand why it is new to you. The conflict between the
OpenSSL and GPL licences is well known, at least within Debian. I
don't like weakening the GPL for my own code.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: System libraries and the GPLv2

[Florian Weimer]

* Richard Fontana:

> 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.

But it's not clear that applies when at the time the software was
released by upstream, the libraries were GPLv2-compatible, and we
started linking against GPLv2-incompatible versions only later.  This
has already happened with readline (GPLv3 and later), and libgcc
(GPLv3 and later with GCC exception).  It was avoided for GMP, which
used to be LGPLv2+, briefly LGPLv3+, and finally GPLv2 or LGPLv3+.

You could argue that if upstream continues to make compatibility fixes
for later readline versions, or enable compiling with later GCC
versions, they give implied permission to link with those
GPLv2-incompatible library versions.  But I think this argument breaks
down, at least formally, when there are many copyright holders, and
not everyone contributes to the changes that enable this kind of
forward compatibility (first technically, and then implicitly
license-wise).  On the other hand, when a larger upstream project
granted us a linking exception for OpenSSL, they probably did not
obtain consent from all the copyright holders, either.

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?

Re: System libraries and the GPLv2

[Florian Weimer]

* Lars Wirzenius:

> A compication in this is that even though the developers of a program
> would be happy with linking to OpenSSL, people who've written other
> libraries the program uses, or other code included in the program, may
> not be. I'm such a person. If some code I've released some code under
> GPL2 (only), and you link use it in a way that causes it to be linked
> with OpenSSL without asking me, you'll make me unhappy. I'm unlikely
> to sue you (life is too short), but I might grumble lengthily into my
> cup of tea.

This is interesting.

Do you hold the same position regarding newer versions of GCC (which
have changed the libgcc license to GPLv3+ (plus exceptions), which is
probably as GPLv2-compatible as the OpenSSL license)?

On some architectures, libgcc is required for full “long long”
support, so it's not really optional even for C.

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

Re: System libraries and the GPLv2

[Philip Hands]

Carlos Alberto Lopez Perez  writes:

> 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:
>>> On 30/03/17 00:24, Philipp Kern wrote:
 On 03/29/2017 11:10 PM, Carlos Alberto Lopez Perez wrote:
> So, the best case situation (IMHO) would be that a lawyer tell us that
> Apache 2.0 is also compatible with GPLv2-only, and that we stop playing
> the game of being amateur lawyers instead of software developers.

 But that's not how the law works in the US. Without actual litigation
 and precedent, the most you'll get is a risk assessment of getting sued
 and your likelihood of winning if so. :)

 Kind regards and IANAL
 Philipp Kern


>>>
>>> Right. That is how it also works in Spain, and I suspect that in many
>>> other countries work the same way.
>>>
>>> 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?

Sorry, but people's intent is not sufficient.

Let's we decide that we're going to ignore a license, because the
author's a jolly nice person who obviously wasn't concentrating when
they chose the license.

We thus inflict this license violation on our users, our downstreams,
and their users.

Some of those users might then build their infrastructure upon that
software, meaning that changing it could be very costly, and those users
might be wealthy enough to be interesting to copyright trolls.

Then the copyright holder dies and their estate passes on to someone
that wants to maximise its value, so they sell the copyright to a
copyright troll, who then goes around threatening to sue for the GPL
violation, offering an explicit exception ... for a fee.

I think our users expect us not to put them in that situation.

What is the huge upside that makes it worth forcing our users to take
this risk without their explicit consent?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#859095: ITP: node-combine-source-map -- Add source maps of multiple files and combine

[Bastien ROUCARIES]

Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-combine-source-map
  Version : 0.8.0
  Upstream Author : Thorsten Lorenz  (http://thlorenz.com)
* URL : https://github.com/thlorenz/combine-source-map
* License : Expat
  Programming Lang: JavaScript
  Description : Add source maps of multiple files and combine
Add source maps of multiple files, offset them and then combine
them into one source map.
.
Source map provides way of mapping code within a compressed file back to
it’s original position in a source file, hence improving debugging.
.
 Node.js is an event-based server-side JavaScript engine.

Re: System libraries and the GPLv2

[Lars Wirzenius]

On Thu, Mar 30, 2017 at 10:30:44AM +0200, Florian Weimer wrote:
> * Lars Wirzenius:
> 
> > A compication in this is that even though the developers of a program
> > would be happy with linking to OpenSSL, people who've written other
> > libraries the program uses, or other code included in the program, may
> > not be. I'm such a person. If some code I've released some code under
> > GPL2 (only), and you link use it in a way that causes it to be linked
> > with OpenSSL without asking me, you'll make me unhappy. I'm unlikely
> > to sue you (life is too short), but I might grumble lengthily into my
> > cup of tea.
> 
> This is interesting.
> 
> Do you hold the same position regarding newer versions of GCC (which
> have changed the libgcc license to GPLv3+ (plus exceptions), which is
> probably as GPLv2-compatible as the OpenSSL license)?
> 
> On some architectures, libgcc is required for full “long long”
> support, so it's not really optional even for C.

I say I want people to ask before they do something that my licence
doesn't allow. You want me to have an opinion on another licencing
situation. I don't want to play this game. It'll just end in me asking
probing questions about other people's tea preferences.

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.

I don't like convoluted, controversial re-interpretations of legalese
to achieve Nirvana.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#859106: ITP: node-object-key -- Object key helpers

[Bastien ROUCARIES]

Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-object-key
  Version : 0.2.0
  Upstream Author : Fabrício Tavares
* URL : https://github.com/fabriciotav/object-key
* License : Expat
  Programming Lang: JavaScript
  Description : Object key helpers

This module simplify assigning value to an object property by using
path string separated by dots.
This module support also lookup values using the same dot separated
string paths.
.
 Node.js is an event-based server-side JavaScript engine.

This is needed for falafel that is build dep of umd (indirect)

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.

Bug#859112: ITP: node-quote-stream -- transform a stream into a quoted string

[Bastien ROUCARIES]

Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-quote-stream
  Version : 1.0.2
  Upstream Author : James Halliday  (http://substack.net)
* URL : https://github.com/substack/quote-stream
* License : Expat
  Programming Lang: JavaScript
  Description : transform a stream into a quoted string

 This module transform a buffer to a quoted string thus escaping special
character in a safe way.
 .
 Node.js is an event-based server-side JavaScript engine.


This is needed for brfs that is needed for umr that is needed for browserify

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

NetApp customers email list

[anne . bryant]

Hi There,


Hope you are doing well!

This is Kendall from pre-sales team.

I am writing this email to inform you that we have *NetApp customers **email
list* for your marketing battles. Please let me know if you are interested
in acquiring NetApp email list.

We also have other technology users like:

· Microsoft Azure Customers

· Openstack Customers

· Google Apps Customers

· NetBackup Customers

· Linux Customers & many more…

*Data Fields we provide*: Name, Company's Name, Phone Number, Fax Number,
Job Title, Email address, Complete Mailing Address, SIC code, Company
revenue, size, Web address etc

.

The leads can also be further customized as per requirements. We can
provide contact list from any country/industry/title.


Please confirm the above and I shall get back to you with list details and
counts. If your criteria is different from the above mentioned applications
let me know we have close to 7000+ technology installations

Warm regards,

Anne Bryant

*Demand Generation- Technology Database*



“To opt out please response Remove”

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

TAG: lina -- iso-compliant Forth interpreter and compiler

[Albert van der Horst]

Package: wntpp
Severity: wishlist

Information:
Homepage: https://github.com/albertvanderhorst/ciforth
lina is a 32 bit classic Forth system, (mostly) compliant to the
ISO Forth94 standard, with a library in source form.
It is small, yet allows to generate elf-executables that can be
shipped to and run by non-Forth-aware users. This is unique among
Forth's available to linux.
It has no dependancies, so it can be used instead of a
c-compilation system or Python scripter, where size matters.
Also simplicity engenders reliability.

Architecture: This package is (for now) limited to i386 and
amd86 architectures.

Background: The system is in use since 2000. It has an extensive
regressiontest and comprehensive documentation. It is part of the
ciforth family with compatible systems for MS-windows, OSX and
MS-DOS (and similar compilers for Dec Alpha, 6809, Renesas 16, ARM)
It has been used to build an assembler/disassembler (ciasdis)
that has some notoriety.

The license is GPL2 for the compiler itself. LPGPL applies to all
library elements, including those contained within the compiler
executable.

Releases:
https://github.com/albertvanderhorst/ciforth/release
contains current releases. Binary releases are at 5.3.0 for
Linux, MS-windows and OSX.

Packaging:
  release/lina_5.3.0_i386.deb
is generated by a script debian.sh from a lina_#.tar.gz release.
A binary release contains the one(!) source file, so a binary release
can serve as an upstream source package.
This should help a prospective sponsor to swiftly go towards RFP.

Maintenance:
I'm the developer and maintainer since 2000 and
I'm planning on continuing to develop and maintain it. Also
I'm willing to adapt the package in order to smoothen the
cooperation with Debian.

Greetings, Albert
--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

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

[Russ Allbery]

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.

-- 
Russ Allbery (r...@debian.org)   

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

[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

[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 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

A quick follow up to Pivotal users list

[mary . hughes]

Hi,

A Quick Follow up to you that if you are interested in *Pivotal  users list*
 which can help you to grow up your business campaigns?

* Specialties*: big data, cloud computing, hadoop, analytics, software,
open source software, containerization, private cloud, data science, cloud
foundry, mobile software development, platform-as-a-service, hybrid cloud,
microservices, pair programming, and agile development

*Information Data Fields *– Name, Title, Email, Phone Numbers, Company
Name, and Company Details like, Physical Address, Web Address, Revenue
Size, Employee Size and industry.

We also have other technology users like: aws, tripod seat, Jira,
openshift, docker and many more….

Please let me know your thoughts and your criteria we will provide you with
more information. And if you aren’t the right person to discuss this mail
you can freely forward this mail to right person in your organization.

Thanks,

Mary Hughes
Senior Marketing Analytics

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


pgpr_GUmMdhPF.pgp
Description: PGP signature

Work-needing packages report for Mar 31, 2017

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1068 (new: 13)
Total number of packages offered up for adoption: 159 (new: 0)
Total number of packages requested help for: 42 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   chase (#858604), orphaned 6 days ago
 Description: Follow a symlink and print out its target file
 Installations reported by Popcon: 208
 Bug Report URL: http://bugs.debian.org/858604

   dfc (#858664), orphaned 6 days ago
 Description: display file system usage using graph and colors
 Reverse Depends: design-desktop
 Installations reported by Popcon: 337
 Bug Report URL: http://bugs.debian.org/858664

   docx2txt (#858666), orphaned 6 days ago
 Description: Convert Microsoft OOXML files to plain text
 Installations reported by Popcon: 381
 Bug Report URL: http://bugs.debian.org/858666

   flow-tools (#858691), orphaned 5 days ago
 Description: collects and processes NetFlow data
 Reverse Depends: flow-tools-dev flowscan nfdump-flow-tools
 Installations reported by Popcon: 320
 Bug Report URL: http://bugs.debian.org/858691

   fprobe (#858688), orphaned 5 days ago
 Description: export captured traffic to remote NetFlow Collector
 Reverse Depends: fprobe-ng
 Installations reported by Popcon: 129
 Bug Report URL: http://bugs.debian.org/858688

   fprobe-ulog (#858687), orphaned 5 days ago
 Description: export captured traffic to remote NetFlow Collector
   (ULOG version)
 Installations reported by Popcon: 39
 Bug Report URL: http://bugs.debian.org/858687

   httpcode (#858665), orphaned 6 days ago
 Description: Explains the meaning of an HTTP status code on the
   command line
 Installations reported by Popcon: 45
 Bug Report URL: http://bugs.debian.org/858665

   keepnote (#858667), orphaned 6 days ago
 Description: cross-platform note-taking and organization application
 Installations reported by Popcon: 302
 Bug Report URL: http://bugs.debian.org/858667

   libropkg-perl (#858686), orphaned 5 days ago
 Description: general purpose classes for simba
 Reverse Depends: simba
 Installations reported by Popcon: 19
 Bug Report URL: http://bugs.debian.org/858686

   pyp (#858659), orphaned 6 days ago
 Description: sed/awk-like tool with Python language
 Installations reported by Popcon: 61
 Bug Report URL: http://bugs.debian.org/858659

   simba (#858685), orphaned 5 days ago
 Description: next generation mirroring tool
 Reverse Depends: websimba
 Installations reported by Popcon: 8
 Bug Report URL: http://bugs.debian.org/858685

   usermode (#858661), orphaned 6 days ago
 Description: Graphical tools for certain user account management
   tasks
 Reverse Depends: mock ovirt-guest-agent
 Installations reported by Popcon: 10909
 Bug Report URL: http://bugs.debian.org/858661

   wfrench (#858663), orphaned 6 days ago
 Description: French dictionary words for /usr/share/dict
 Reverse Depends: forensics-extra parl-desktop-eu parl-desktop-world
 Installations reported by Popcon: 22391
 Bug Report URL: http://bugs.debian.org/858663

1055 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 159 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   autopkgtest (#846328), requested 120 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker openstack-pkg-tools
 Installations reported by Popcon: 764
 Bug Report URL: http://bugs.debian.org/846328

   balsa (#642906), requested 2013 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 695
 Bug Report URL: http://bugs.debian.org/642906

   busybox (#854181), requested 54 days ago
 Description: Tiny utilities for small and embedded systems
 Reverse Depends: bootcd busybox-syslogd dropbear-initramfs
   live-boot-initramfs-tools open-infrastructure-system-boot udhcpc
   udhcpd wicd-daemon zfs-initramfs
 Installations reported by Popcon: 195047
 Bug Report URL: http://bugs.debian.org/854181

   cups (#532097), requested 2854 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnam

Re: System libraries and the GPLv2

[Philip Hands]

Carlos Alberto Lopez Perez  writes:

> 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.

Perhaps they have decided to ignore the bit of the license that says:

  "unless that component itself accompanies the executable."

but I think it is more likely that they've had their lawyers look at
each particular case that they wanted to include in their distro, in
order to assess how realistic it is for there to be a problem with the
result, and how painful it will be to fix if there is a problem.

If we were to do a similar assessment, then we'd be asking the lawyers
different questions, because we also care about how likely it to cause a
problem for any of our downstreams (and their downstreams, etc.) or any
of the users.

RedHat are also in a position to offer indemnity against legal problems
caused by using their distribution, if they want to, whereas we can only
try to avoid the problem.

So, pointing at the fact that RedHat has on occasion decided to violate
the license in this way does nothing to prove that the violation does
not exist.

Nor does it make the exception to the exception go away, and we clearly
are causing the "component" and the "executable" to "accompany" one
another if installing a binary by whatever means causes OpenSSL to
automatically be installed because of the dependency.

I really doubt that any court of law will be particularly interested in
the mechanisms that achieve that effect, so it's not just a case of
making sure that the two things are not on the same DVD.

Cheers, Phil.

P.S. I am not a lawyer

P.P.S. Does anyone really expect a consensus to emerge where we decide
to ignore the exception to the exception across the board without
consulting lawyers?  I think there are several people in this thread
(myself included) that have demonstrated that they're going to argue
against such a consensus.  That being the case, it's not going to
happen, so repeating the same justifications for why there is no problem
does not seem even slightly productive to me.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature