Re: Outdated GNU config (config.{sub,guess}) and autotools-dev
On Mon, Jul 23, 2001 at 04:06:04AM +0200, Marcus Brinkmann wrote:
> No, he has a legal right in the derived work. Again, you are confusing the
> issue. All authors of parts of the software have a legal right in the
> derived work, which is the composition of the parts, and can request the
> whole source code, because this is what the GPL requires you to provide.
I think you are making the fairly common mistake of assuming that the
parts of the GPL which apply *iff* you copy and distribute "the program"
always apply, and require you to make it available.
There is no requirement (as far as I can see or that I've ever heard of)
to force you to distribute your derivative work. The authors of the
original components have no rights in it. *If* you distribute the your
work, then the terms of your license from them require you to make *all*
source, including configure scripts etc., available to whoever you distribute
the work to.
Example: I write something based on a GPL-ed program. In the environment
where it is used, it must comply with parts of the GPL (banners in interactive
programs etc.). If I do not choose to give it away to anyone, I do not have
to. Say though, that I give it to my friend John. I must then make available
to John the *complete* source - everything that he would need to build the
binary. That still doesn't mean that *I* have to make anything available
to anyone other than John. It does mean that he is now entitled to give it
away, though.
> Otherwise you could just incorporate GPL code in proprietary code, and tell
> the original author of the GPL code to go away because he has no legal
> rights in the proprietary code.
Absolutely you could.
> You would just have found a way to entirely
> circumvent the GPL ;)
No, that is the common misunderstanding; the GPL does not force you to give
your code away, it just controls the terms under which you *may* give it
away. It's not intended to force you to give your code away, just to ensure
that *if* you decide so to do, that you do it in a manner of which RMS
approves.
> All this confusion and attempts to duck the issue make me more and more
> confident we should completely avoid changing the source at binary build
> time.
You're probably right; although the GPL makes no mention of which version
of the source code you are supposed to make available - if you have
distributed 1001 different versions, are you required to keep each version's
source snapshot available for 3 years, or can you just provide them with the
latest version?
The "latest version" idea would probably enable people to dodge the GPL
by removing most of the features from version 1 in version 1.1 and then
distributing only the version 1.1 source.
The question appears to be "since we are distributing many versions of
packages, which bits are we required to be able to make available, and for
how long?"
RMS is probably the best person to answer that.
The answer to that question will then provide more insight into the best
way to handle the original question - I expect that the answer will be that
we will have to be able to provide source snapshots for any binary that
has shipped in the past 3 years, and that that will rule out making changes
to the source package at build time (otherwise the source packages would
no longer be signed by the maintainer when distributed in the modified form).
Then I would guess that the autoconf bits that started this would still
be a grey area. My guess, for what it's worth (and I'm not an autoconf whizz,
nor highly experienced in Debian packaging, nor ...), is that it would
make sense for the relevant bits to be:
1) provided in the source package (but not in the location from which they
would be used) by the maintainer in a form which works at the time;
2) copied into the package from the newer of the system's copies and the
maintainer-provided copies at build-time, *unless* the maintainer has
somehow specified that this should not happen.
(2) should probably be done by yet another bit of debhelper, to avoid
lots of people not doing it right.
Cheers,
Nick
--
Nick Phillips -- nwp@lemon-computing.com
Tomorrow, you can be anywhere.
Reply to: