Re: Possible GPL violation in package distribution
>>>> "Valdis" == Valdis Kletnieks
<Valdis.Kletnieks(a)vt.edu> writes:
Valdis> On Mon, 05 Mar 2001 14:02:03 +0900, "Stephen J. Turnbull"
Valdis> <turnbull(a)sk.tsukuba.ac.jp> said:
> The GPL _does_ require that you make any patches available for
> three years. Now, much of the code in a .elc is actually
> inline-expanded by the byte compiler. Recently there was a bug
> fix to the byte compiler which changed the inline code,
> requiring a rebuild of every package. We have no way of
> tracking that, but the letter of the GPL probably requires us
> to do so if we distribute .elcs. (This doesn't apply to GCC on
> Linux, because it's part of the system.) And it certainly
Valdis> Umm.. how is this any different than the "RedHat
Valdis> distributed a GCC 2.96 snapshot that won't compile the
Valdis> kernel correctly" problem?
System software has an explicit exception in the GPL. XEmacs doesn't
qualify.
Valdis> Does this mean that Linus has to put gcc patches into the
Valdis> kernel distro, under the theory that "you need gcc
Valdis> 2.96+patches to build it"?
No. But Red Hat must (IMO) provide a compiler capable of building the
kernels the distribute if they distribute kernels, and quite possibly
they must provide the one they actually used to produce the kernel
binaries.
Valdis> I don't see why the Linux kernel gets away with just
Valdis> saying "you need gcc such-and-such, modultils
Valdis> such-and-such, PPP such-and-such" - if that's OK, we
Valdis> certainly should be able to just say "You need XEmacs
Valdis> 21.2.<mumble> or later so you have a non-buggy byte
Valdis> compiler".
The issue is not providing the user with a non-buggy byte-compiled
.elc. It is providing the user with a buggy byte-compiler for their
amusement and documentation. Maybe they _want_ the bug. I consider
that we satisfy provision of the byte compiler via CVS and GPL clause
3. What we don't have is an accurate way to match up the .elc with
the version of the byte compiler that produced it.
Valdis> 1) XEmacs base code .elcs that went out with a buggy
Valdis> byte-compiler. Hey, we didn't know, there isn't much we
Valdis> can do about them.
We can provide the byte compiler for downstream analysis.
Valdis> 2) XEmacs base code .elcs that has the patch. It's got
Valdis> the patch in the source tree that we distribute with the
Valdis> .elcs, that patch will stay in the source that gets
Valdis> distributed for 3 years. We're done.
Wrt to the patch, if it stays that way and Martin doesn't fiddle with
it in the meantime. However, we still have an obligation to provide
the source to the buggy byte-compiler on demand for three years.
What is not clear is whether (in the extreme) the user can present us
with a .elc and say "I want the byte compiler that produced this
.elc". I think that the GPL comes close to that.
Valdis> I'm obviously not being anal-retentive enough about the
Valdis> GPL's intent. What am I missing here?
That the spirit of the GPL clearly requires that the user be able to
get the source to the binary he has in hand for three years after it
was last distributed by the modifying party.
I consider this to be an ambiguous mess. But then, this _is_ the
GPL....
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."