[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Cryptographic software in main archive



On Sun, Mar 24, 2002 at 11:51:10AM +1000, Anthony Towns wrote:
> On Sat, Mar 23, 2002 at 07:41:55PM -0600, Steve Langasek wrote:
> > > Sorry, this isn't precisely accurate on the OpenBSD folks part. The GPL
> > > allows you to use this exception "unless [the library] accompanies the
> > > executable" which it would if the executable were allowed into main. It's
> > > the exact same situation we had with KDE/Qt.
> > With this reasoning, the only other way it's legal to distribute 
> > GPL binaries linked against glibc and other LGPLed libraries (which 
> > are also distributed in main) 

> No, the LGPL (and other compatible libraries) are "GPL compatible",
> which means that doing everything the GPL requires (and nothing more)
> also happens to satisfy the licenses they have, and aren't a problem at
> all because of this. OpenSSL isn't GPL compatible, though, so it is.
> The "distributed as a core part of the operating system" exception is
> only needed for libraries that aren't GPL compatible, like Solaris'
> or Windows' libc.

My understanding of the phrase "GPL compatible" is that source code
released under one of these licenses can also be distributed under the 
terms of the GPL (that is, sublicensed) without the need for a further 
license to be granted.

GPL section 3:

 You may copy and distribute the Program (or a work based on it,
 under Section 2) in object code or executable form under the terms of
 Sections 1 and 2 above provided that you also do one of the following:

    a) Accompany it with the complete corresponding machine-readable
    source code, which must be distributed under the terms of Sections
    1 and 2 above on a medium customarily used for software interchange; or,

    b) Accompany it with a written offer, valid for at least three
    years, to give any third party, for a charge no more than your
    cost of physically performing source distribution, a complete
    machine-readable copy of the corresponding source code, to be
    distributed under the terms of Sections 1 and 2 above on a medium
    customarily used for software interchange

<snip>

A GPL binary linked against glibc is certainly covered by this section; 
and options a) and b) both refer to "the complete corresponding 
machine-readable source code", and to distributing it "under the terms 
of Sections 1 and 2 above".  Source code is further defined as

 The source code for a work means the preferred form of the work for
 making modifications to it.  For an executable work, complete source
 code means all the source code for all modules it contains, plus any
 associated interface definition files, plus the scripts used to
 control compilation and installation of the executable.  However, as a
 special exception, the source code distributed need not include
 anything that is normally distributed (in either source or binary
 form) with the major components (compiler, kernel, and so on) of the
 operating system on which the executable runs, unless that component
 itself accompanies the executable.

You have asserted that any libraries that the application links to, 
because they are also part of Debian, are considered to be components 
that "[accompany] the executable" and are therefore part of the source 
code; and under GPL section 3, all of this source code must be 
distributed in compliance with sections 1 and 2 of the GPL.

As licensees, I assume that only section 2 is relevant to us; I don't 
believe Debian distributes verbatim copies of glibc (or verbatim copies 
of much of anything, really), but rather modified copies.  Section 1 of 
the GPL is identical to section 1 of the LGPL in any case, so I don't 
believe this is an obstacle.

However, section 2 of the GPL imposes a different set of restrictions 
than the LGPL does, and this is the problem.  If the GPL requires us to
distribute glibc under the terms of section 2 of the GPL, then we are no
longer distributing it under the terms of the LGPL, and cannot do so;
for the LGPL says:

   3. You may opt to apply the terms of the ordinary GNU General Public
 License instead of this License to a given copy of the Library.  To do
 this, you must alter all the notices that refer to this License, so
 that they refer to the ordinary GNU General Public License, version 2,
 instead of to this License.  (If a newer version than version 2 of the
 ordinary GNU General Public License has appeared, then you can specify
 that version instead if you wish.)  Do not make any other change in
 these notices.

   Once this change is made in a given copy, it is irreversible for
 that copy, so the ordinary GNU General Public License applies to all
 subsequent copies and derivative works made from that copy.

In other words, we can distribute glibc under the terms of the GPL, with 
the different set of restrictions that entails; but doing so means we 
can no longer distribute it under the LGPL (short of distributing two 
parallel copies). It's a one-way trap. If we're distributing glibc under
the GPL and not under the LGPL, then we can't distribute binaries linked
against glibc if their licenses are not GPL-compatible.

I had always been under the impression that Linux distributors were 
making use of the "normally distributed with the major components of the 
operating system" exemption.  It comes as a bit of a surprise to me that 
people think we can link GPL programs against non-GPL libraries and 
distribute the composite without either making use of this exemption, or 
distributing the libraries under the GPL.  Corrections to my layman's 
understanding of these licenses would be greatly appreciated.

Steve Langasek
postmodern programmer

Attachment: pgpx_NfsnCWuU.pgp
Description: PGP signature


Reply to: