Re: [PROPOSAL] Full text of GPL must be included
On Tue, 5 Dec 2000, John Galt wrote:
> On Tue, 5 Dec 2000, Raul Miller wrote:
> > On Sat, Dec 02, 2000 at 12:49:52PM -0600, Manoj Srivastava wrote:
> > > Doesn't the fact that we are totally geared towards a target
> > > system that is Debian matter?
> > Actually, it does make a difference -- we're not in violation of the
> > GPL for any instance where we're distributing .debs to users of debian
> > systems.
> Yeah, but wouldn't that be in violation of DFSG 8:
> The rights attached to the program must not depend on the
> program's being part of a Debian system.
Good point. It would be just so sad to see the GPL fail the DFSG. ;)
> Basically, if the license only is satisfied by a part of Debian, said part
> not being transferred with the individual files, it looks as if the rights
> attached to the individual files DO depend on being part of a Debian
> system. Like it or not, this reading is exactly where RMS's head is at on
> this issue. Can we really expect others to follow the DFSG when we do so
> only when convenient? DFSG 8 later goes on to talk about distribution IAW
> the license, so we're covered, but I'm not so sure that splitting hairs of
> our own definitions is such a good idea.
> (if I keep repeating this, I'll either add a few killfiles to my
> collection, or somebody might actually see it... :)
> > However, note that we're working on generalizing debian -- there's stuff
> > like LSB, and various sorts of ports going on that potentially broadens
> > the audience for our packages.
> > > Are you, perchance, advocating we keep several (potentially several
> > > thousand) copies of the GPL on every Debian machine out there on the
> > > off chance that the end user (despite pointers in the copyright file)
> > > is unable to get a copy of the GPL? Would it really matter, given
> > > this end users isolation from the network?
> > What, you're worried about a measly 18M? That's peanuts on a machine
> > with several thousand GPLed packages installed. [Ok, maybe that's not
> > very funny...]
> There was a proposal to hack gzip to tokenize the entirety of the GPL to a
> few data words... Make the total impact compressed OTO 30K--19K in the
> gzip code and 21K for the 3K packages at about 7 bytes/package.
An ugly hack that has nothing to do with the functionality of gzip, plus
would require either a fork (which would not be effective; we'd be in
effect making Debian proprietary) or an upstream change (which I doubt
GNU would do because it doesn't address gzip's primary function at all and
is contrary to the "UNIX spirit of being a 'collection of tools that focus
on doing one thing well'.")
The technically better solution would be to place the license/copying
files into a copying.tar.gz file contained in the .deb ar archive. Debian
systems (those with dpkg AND required packages installed) could just
ignore it. People extracting by hand would have the licenses right there
But is this even necessary? ... (see below)
; I do wish to fork this particular point off for archival and/or debate,
; as it is a technical implimentation orthoganal to the legal arguments.
> > Anyways, optimization should come after correctness, not before.
> > On Sat, Dec 02, 2000 at 01:19:10PM -0500, Raul Miller wrote:
> > > > Debian advertises a freely redistributable system, with no special need
> > > > to read copyrights before redistributing all or part of it.
> > On Sat, Dec 02, 2000 at 12:24:35PM -0800, Chris Waters wrote:
> > > Not exactly. If I upload /bin/ls from my system to a BBS without
> > > providing source, I am violating the GPL. If I start distributing
> > > GPL'd .debs without source (whether or not the .debs have a copy of
> > > the GPL), I am violating the GPL.
> > Different issue. The GPL appears to claim that you must distribute
> > a copy of the license with the binaries, even when you ship the source
> > separately.
> WITH or WITHIN? If it's WITH, wouldn't a copy of COPYING in each
> directory (except non-free :) and a dependency on
> /usr/share/common-licenses/GPL cover us? If it's WITHIN, we have the can
> of worms that's open ATM. This is the real question. What will satisfy
> the FSF? Not what does the FSF want, but what will they walk away from
> this mess thinking that they got all that they could from it and falling
> under my definition of fair: "a fair solution is one that pisses everyone
> off equally".
A strict lingistical analysis (as I mentioned earlier; different from a
legal analysis) does not show an explicit requirement to distribute a copy
of the license with executable code. This 'requirement' is implicit in a
two-part chain of events: executable code must be distruted either WITH
source code or WITH an offer to get the source code when asked within
three years, and source code MUST be distributed with the license.
As Chris Waters <firstname.lastname@example.org> mentioned on 2000-12-02, and I paraphrase
here, a Debian package "really" (as opposed to what policy documents, et
al. might have to say, as I am not THAT imtimately familliar with them)
consists of four parts: A bundle of executable code per supported
archetecture (.deb), the FULL UPSTREAM source code (.orig.tar.gz) a brief
textual description of the package (.dsc) and an optional source patch to
add Debian-specific package management and Debian policy compliance/
compatibility (.diff.gz). According to the above paragraph (and I am not
YET an enrolled Cog Sci student) the license (GPL) must accompany the
source code. Our packages are distributed WITH the source code, so that
section of the GPL is fulfilled.
Please notice also that the GPL does NOT require that the recipient
download the source code OR the license, only that both are made plainly
available to her. It is our duty as Debian to make both available with the
executable code, but it is within the recepient's rights to NOT TO
download either. Rather, we must assume, that having made a good faith
effort to give the recipient the source and license, that if she chooses
to NOT TO download them she is fully aware of what they are, why they are
available to her, and has made an informed decision to not download them.
(Yes, I'm aware I'm emulating a verb form that has been depreciated in
modern English; I use it for added emphasis)
> > > > If we now claim that our .debs are not redistributable without first
> > > > reading the copyright file, we should post this new claim prominently
> > > > (for example, as part of our home page).
> > >
> > > Well, perhaps we *should* point out that a *lot* of the software we
> > > provide *cannot* be redistributed *unless* you also provide the
> > > source. That is, after all, the terms of the GPL, and it clearly
> > > doesn't match what you seem to think.
> > Good idea. [There's a good chance we already do this, but I've
> > not taken time to look.]
> How about another RMS induced setup window (HHOS)?
> > On Sat, Dec 02, 2000 at 02:55:25PM -0700, John Galt wrote:
> > > The doctrine you're citing could have been that the moon was made
> > > of green cheese for all of the citation you'd done in the past.
> > > Furthermore, there is still 17USC507b: The FSF may be denied relief
> > > at all in the case of Debian. It hardly seems right that where a
> > > statutory limit has been reached, you are prevented relief against
> > > others. Basically, Debian is now "grandfathered in" because of a
> > > snafu: EvilCorp is not. Go bother EvilCorp.
> > That only works if we stopped distributing such things at least three
> > years ago.
> I think that good faith falls in here somewhere. Basically if we
> distributed things in good faith for three years, despite the fact that we
> violated the GPL UNKNOWINGLY, we'd be allowed by law to continue, but we
> couldn't transfer the rights. Think of it as squatters rights for
; indirectly relevant to the technical (opposed to legal) isses, and
; anyway outside my scope.
Basically, unless the lawyers say otherwise (and have taken this or
similar argument into due consideration) I believe we have nothing to
worry about save possible technical considerations on providing good faith
in our distribution methods. Apt has no consideration that I'm aware of;
posting .deb URLs for security updates might need to be looked into. I'm
not very familliar with those posts.