Path: gmd.de!xlink.net!howland.reston.ans.net!ux1.cso.uiuc.edu!sdd.hp.com!
cs.utexas.edu!geraldo.cc.utexas.edu!mccoy
From: mc...@ccwf.cc.utexas.edu (Jim McCoy)
Newsgroups: comp.os.linux
Subject: Recent GPL interpretations and Linux
Date: 5 Jul 1993 14:38:14 -0500
Organization: The University of Texas - Austin
Lines: 56
Sender: mc...@tramp.cc.utexas.edu
Distribution: world
Message-ID: <219vv6$ld9@tramp.cc.utexas.edu>
Reply-To: mc...@ccwf.cc.utexas.edu
NNTP-Posting-Host: tramp.cc.utexas.edu
If you don't read gnu.misc.discuss, there has been an interesting thread
regarding interfacing non-GPL program to GPL code/libraries. The basic
story is as follows:
-The RIPEM package uses the RSAREF package due to a very
restrictive patent by PKP on public key encryption that only
permits free use of these methods through this package. The RSAREF
package is very restrictive in distribution of the software because
of U.S. export laws (these cryptographic methods are classified as
"munitions" and may not be distributed outside the U.S. or Canada
without a liscense from the State Department). The non-RSAREF
parts of RIPEM are not subject to such restrictions, but the
package needs RSAREF to work.
-The author of RIPEM included some patches that could make the
calls in the code interface with GMP (the gnu multi precision
library) if you choose to link it in this fashion. This inclusion
of an interface to the GNU code was not required for the package,
but instructions for making this link were included in the
documentation. The patches bascially consisted of changing a few
functions to the appropriate name and format for linking the
package with libgmp. _No GPL'd code was included in this package
in any way shape or form, the patches only provided a method to
interface the GPL'd libraries if the user already had them_.
-RMS has stated that this is in violation of the GPL and cannot be
done. The author has removed the patches from the distribution and
it is no longer possible to use the GMP library with this
particular package.
I hesitate the bring the GPL issue up again, but these recent events seem
to have significant implications for the use of GPL'd libraries in Linux
with any commercial code. If this particular interpretation of what is
effectively an interface copyright to GPL libraries is the "way things will
be" I am wondering what impact this might have on people developing any
commercial applications under Linux. If this interpretation is official
then it may have a rather chilling effect upon anyone who might want to
develop a program on a system (such as most Linux systems...) that uses
GPL'd libraries. By simply providing a method for you program to link with
these libraries you may be found to be in violation of the GPL. The
previously dismissed (by myself as well as others) claim that the GPL was a
"copyright virus" may in fact have come true. While I hope this is not the
case, I strongly urge people to pay attention to what is happening on this
issue.
Check out gnu.misc.discuss for more discussion on this particular issue,
but if you are considering creating a non-GPL program under any system that
uses GPL libraries you need to definitely take a look at this.
jim
--
Jim McCoy | UT Unix Sysadmin Tiger Team
mc...@ccwf.cc.utexas.edu | #include <disclaimer.h>
pgp key available via "finger -l", on pubkey servers, or upon request
Crossposted-To: gnu.misc.discuss
From: stodghil@cs.cornell.edu (Paul Stodghill)
Subject: Re: Recent GPL interpretations and Linux (several responses)
Date: Tue, 6 Jul 1993 13:16:26 GMT
In article <9307060611.AA24791@mole.gnu.ai.mit.edu>
rms@gnu.ai.mit.edu (Richard Stallman) writes
[ Discussion of NeXT's desire to distribute the Objective-C front-end as
proprietary software, and the FSF's objection. ]
> Note that this is not a matter of copyrighting an interface. The .o
> files that NeXT planned to release would have used one of the
> (internal) interfaces of the GNU compiler, but that was *not* what the
> FSF objected to. Our objection was because the use of these .o files
> implied linking them with the GNU compiler--the program, not just an
> interface.
Make the following substitutions in the above quote,
linking -> loading
.o -> a.out
GNU compiler -> Linux
Now read it.
Clearly, I'm putting words into RMS's mouth, but I don't believe that the
conclusion that I draw (namely, that Linux specific versions of executables
cannot be distributed, except under the conditions of the GPL) is too
outrageous.
From: eoliver@ralph.cs.haverford.edu (Erik Oliver)
Crossposted-To: gnu.misc.discuss
Subject: Re: Recent GPL interpretations and Linux (several responses)
Date: 6 Jul 1993 14:36:03 GMT
In article < STODGHIL.93Jul6091626@hel.cs.cornell.edu>
stodghil@cs.cornell.edu (Paul Stodghill) writes:
>
>
> linking -> loading
> .o -> a.out
> GNU compiler -> Linux
>
>Now read it.
>
>Clearly, I'm putting words into RMS's mouth, but I don't believe that the
>conclusion that I draw (namely, that Linux specific versions of executables
>cannot be distributed, except under the conditions of the GPL) is too
>outrageous.
Um, the source code must be available.
That I think is the key point. There is nothing wrong with distributing
an executable as long as the source code can be obtained.
(Freely and I think from the same place you got the executable.)
Anyhow, that at least is my understanding of the GPL withb regard to
distributing executables.
-Erik
--
Erik Oliver Erik_Oliver@ralph.cs.haverford.edu
Crossposted-To: gnu.misc.discuss
From: stodghil@cs.cornell.edu (Paul Stodghill)
Subject: Re: Recent GPL interpretations and Linux (several responses)
Date: Tue, 6 Jul 1993 15:14:13 GMT
In article < 21c2kj$guv@venus.haverford.edu>
eoliver@ralph.cs.haverford.edu (Erik Oliver) writes:
Um, the source code must be available.
That I think is the key point. There is nothing wrong with distributing
an executable as long as the source code can be obtained.
(Freely and I think from the same place you got the executable.)
Anyhow, that at least is my understanding of the GPL withb regard to
distributing executables.
I think that you are confusing two issues,
1) If the source from which the executable was generated was GPL'ed, then
this is exactly right, and the GPL is very clear about it.
2) What are the situations and the mechanisms under which GPL'ed and
non-GPL'ed components be integrated to form a complete system?
Suppose that the source from which the executable was generated is _not_
covered by the GPL, but only runs on a GPL'ed OS. Does the GPL allow this?
I claim that the FSF's position on linking objects makes answering this
question with any certainty problematic.
From: markh@vanbc.wimsey.com (Mark C. Henderson)
Crossposted-To: gnu.misc.discuss
Subject: Re: Recent GPL interpretations and Linux (several responses)
Date: 6 Jul 1993 10:05:37 -0700
In article <STODGHIL.93Jul6111413@hel.cs.cornell.edu>
stodghil@cs.cornell.edu (Paul Stodghill) writes:
-I think that you are confusing two issues,
-
-1) If the source from which the executable was generated was GPL'ed, then
-this is exactly right, and the GPL is very clear about it.
-
-2) What are the situations and the mechanisms under which GPL'ed and
-non-GPL'ed components be integrated to form a complete system?
-
-Suppose that the source from which the executable was generated is _not_
-covered by the GPL, but only runs on a GPL'ed OS. Does the GPL allow this?
-I claim that the FSF's position on linking objects makes answering this
-question with any certainty problematic.
For example, can I run ripem/RSAREF on Linux.
Can I distribute the ripem binary for Linux?
Can a company sell Motif for Linux?
If GPL incompatible software is prohibited on Linux, what is the real future
of Linux?
Anyone from the FSF care to comment?
Mark
--
Mark Henderson
markh@wimsey.bc.ca (personal account)
RIPEM key available by key server/finger/E-mail
MD5OfPublicKey: F1F5F0C3984CBEAF3889ADAFA2437433
Crossposted-To: gnu.misc.discuss
From: stodghil@cs.cornell.edu (Paul Stodghill)
Subject: Re: Recent GPL interpretations and Linux (several responses)
Date: Tue, 6 Jul 1993 18:09:45 GMT
On 6 Jul 1993 10:05:37 -0700, markh@vanbc.wimsey.com (Mark C. Henderson) said:
> For example, can I run ripem/RSAREF on Linux.
>
> Can I distribute the ripem binary for Linux?
>
> Can a company sell Motif for Linux?
>
> If GPL incompatible software is prohibited on Linux, what is the real future
> of Linux?
>
> Anyone from the FSF care to comment?
This is _exactly_ what I am getting at.
And of course, there already _is_ a company selling Motif for Linux. I
doubt that Linus is going to sue them for GPL infringement, but I do thing
that they are vulnerable to such a suit. Whether someone could win such a
suit is a completely different issue.
As to the "real future of Linux": HURD will be in the same boat as Linux.
Between the two, I imagine that there will be a sufficiently large user
base, that enough people will write enough GPL'ed code that HURD and Linux
can function well as hacker OS's. But, I don't believe than many people
want to see Linux being limited to a hacker OS.
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: Recent GPL interpretations and Linux (
Reply-To: cflatter@nrao.edu
Date: Tue, 6 Jul 93 20:19:52 GMT
In article 93Jul6140945@hel.cs.cornell.edu,
stodghil@cs.cornell.edu (Paul Stodghill) writes:
>And of course, there already _is_ a company selling Motif for Linux. I
>doubt that Linus is going to sue them for GPL infringement, but I do thing
>that they are vulnerable to such a suit. Whether someone could win such a
>suit is a completely different issue.
There is not much of a problem here. The GLPL merely requires that applications
that use the GLPL'd libraries be shipped in a form that enables them to be used
with updated versions of the GLPL'd code. This is trivially true for the Motif
libraries and is true for the two programs shipped without source (mwm and uil)
since the Linux shared library implementation allows such a swap (if it didn't
mwm.o and uil.o would have to be included in the distribution).
The Motif development environment would only violate the GPL if it used
code covered by the GPL rather than the GLPL (eg. if bison was used to
generate uil with the GNU template or if one of the programs or
libraries required the GNU regex libraries or another of the
diminishing set of GNU library routines that is still covered by the
GPL rather than the GLPL). Even if this were still the case could ask
FSF for permission to ship the Motif developers kit without source. In
this hypothetical case they would be very likely to get it since they
are constrained by the Motif source license not to disclose source and
are making a reasonable attempt to approximate GNU licensing conditions
(and the FSF are reasonable people).
Remember in all such discussions that there are two flavours of GPL.
1 - The GNU General Public License: requires disclosure of source code;
generally used for complete programs.
2 - The GNU General Library Public License: does not require disclosure of
source code; intended not to discourage commercial use of GNU libraries.
And remember that you can ask for a specific exemption from the terms of the
GNU licenses and will probably get one if you present a reasonable argument
for it.
Chris Flatters
cflatter@nrao.edu
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Subject: Re: Recent GPL interpretations and Linux (
Date: 6 Jul 93 22:19:18 GMT
cflatter@nrao.edu (Chris Flatters) writes:
>The Motif development environment would only violate the GPL if it used
>code covered by the GPL rather than the GLPL (eg. if bison was used to
>generate uil with the GNU template or if one of the programs or
...
Unfortunately there are several things in Linux libc that are covered
by the GPL. These include gdbm, regex, termcap, and single files from
locale, misc, sbin, and time. I asked Len Tower of the FSF to clarify
the situation. He has passed it on to rms, but his preliminary
reaction is that using dynamic linking does not change the legal
status of libraries. I think this position is both harmful to the
long-term progress of free software and legally unenforceable. But
few companies are likely to use software that could potentially get
them into trouble, even if it is likely that they would win in court
in the end. And many programmers are probably not willing to use code
for purposes that the author objects to, even if they can't legally
enforce that. So whether the FSF position would actually hold up in
court is probably irrelevant.
As I understand it from looking at the comments in crt0 and __load,
and from one email exchange with hlu, it is his intent that libc be
usable for commercial software. While I don't see Linux ever becoming
an alternative to DOS, I would not be willing to commit time to a
system that prohibits ports of Motif and other major commercial
packages.
Unless we get something from the FSF that clarifies the situation, I
believe that we're going to see an effort to make libc GPL-free. I
think it's pretty stupid that after the community has worked to
produce an ATT-free alternative, we now have to produce a GPL-free
alternative as well, but that's what ideology does...
The obvious source for GPL-free code is Berkeley. However that is
going to require a judgement on how much risk there is of entanglement
in the USL suit. At least some Berkeley code was pronounced ATT-free
by ATT themselves. I believe that is safe. So is any code that
clearly originated with Berkeley. (E.g. the Berkeley networking code
has been used in many commercial products, and seems not to be a
problem. I would think dbm would fall into this category.) There may
be some new coding necessary. If so, I'm willing to help.
From: imp@boulder.parcplace.com (Warner Losh)
Subject: Re: Recent GPL interpretations and Linux (
Date: Tue, 6 Jul 1993 23:44:27 GMT
In article < Jul.6.18.19.15.1993.10722@geneva.rutgers.edu>
hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>Unfortunately there are several things in Linux libc that are covered
>by the GPL. These include gdbm, regex, termcap, and single files from
>locale, misc, sbin, and time.
What functions are affected, directly or indirectly, by these files?
Warner
--
Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
From: iiitac@swan.pyr (Alan Cox)
Subject: Re: Recent GPL interpretations and Linux (
Date: Wed, 7 Jul 1993 09:25:52 GMT
In article <C9roM3.Hn7@boulder.parcplace.com>
imp@boulder.parcplace.com (Warner Losh) writes:
>In article <Jul.6.18.19.15.1993.10722@geneva.rutgers.edu>
>hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>>Unfortunately there are several things in Linux libc that are covered
>>by the GPL. These include gdbm, regex, termcap, and single files from
>>locale, misc, sbin, and time.
>
>What functions are affected, directly or indirectly, by these files?
>
>Warner
If someone will give me a list of these functions I'll volunteer to chase down
free alternatives. From memory we can swap gdbm with sdbm, termcap with the
Fred Fish termcap (I'm sure thats not GPL -I'd have to check). I've seen
at least one circa 1984 free regex somewhere (not a superb one but fixable),
ditto for other things.
We've got berkeley yacc/lex for bison problems so an LGPL only system should
not be hard.
Once it appears done maybe someone can get an FSF bod to verify it contains
no GPL code.
Alan
iiitac@pyr.swan.ac.uk
Newsgroups: comp.os.linux
Path: gmd.de!xlink.net!howland.reston.ans.net!noc.near.net!uunet!
caen!malgudi.oar.net!news.ans.net!nynexst.com!gallifrey!baruch
From: bar...@nynexst.com (Robert Baruch)
Subject: Re: Recent GPL interpretations and Linux
Message-ID: <1993Jul8.190757.8962@nynexst.com>
Sender: n...@nynexst.com (For News purposes)
Reply-To: bar...@nynexst.com
Organization: Nynex S&T, Inc.
References: <21hie7$n4k@senator-bedfellow.MIT.EDU>
Date: Thu, 8 Jul 93 19:07:57 GMT
Lines: 80
About the recent GPL debate:
Recently on the GCC channel of the Linux activists list, it was mentioned that
Richard Stallman interpreted the GPL such that code written using libraries under
the GPL falls under the GPL.
Also, there has been talk here about whether code written using any aspect of GPL'd
code is GPL'd.
As an Objectvist, I instinctively reject anything which lays a claim without my
permission to code I wrote. To do so is theft. Here is my reply in the GCC channel.
The '>' lines were written by ty...@ATHENA.MIT.EDU (Theodore Ts'o).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Remember, so far we only have the assertions of Richard Stallmen that a
> program, which does not contain a byte of code derived from GPL sources,
> but which happens to call a shared library which contains GPL code,
> would in fact be violating the GPL. While I am not a lawyer, I have
> studied copyright law, and I don't believe this assertion would hold
> legal water.
>
> It wouldn't be hard for a commercial company to get a legal opinion on
> this matter, and quickly come to the conclusion that rms is just blowing
> smoke. I suspect that if this matter ever came to a courtroom, it would
> quickly be laughed out the door.
I agree. I'm developing something in Linux that I eventually hope to sell.
I'll be distributing the Linux kernel, libraries, and other utilities for
free, but the software *I* wrote will be sold. I have no intention of
stopping because my code calls free libraries. IMHO Stallman's opinion
is bogus.
#ifdef _FLAME
So Stallman, if you're listening, Up Yours. You can take your statement,
fold it so that it's all sharp corners, and stick it where the sun doesn't
shine.
#endif
Furthermore, as an Objectivist, I allow no-one to dictate terms for using
anything which flowed from my mind. The code that I develop
and wish to sell is *mine* to do with what I please. No-one can ever lay
claim to my code unless I give it away or sell it. To do otherwise is theft.
Claiming that my software must be free because it calls libc is like claiming
that the salary my company pays me is not really mine because I used their
computers to do work. [Also, claiming that the *work* I perform for the
company is mine and not the company's is false because I *sell* them my
work and get my salary in return].
Unfortunately, in this country, the government does not operate according
to Objectivist principles. If there is ever a conflict between an Objectivist
principle and a government law, I must give in to the government law because
my government is holding a virtual gun to my head. That's why I pay taxes!
So if a court does rule that the GPL is upheld for libc, I would have no
choice but to fold my enterprise or carry it on in the black market.
So much for economic prosperity. Sorry to rant, but I'm a very strong
supporter of the free market.
I agree with the sentiment "let the issue lie", not because of "it's only
illegal after you get caught" but because the libc issue violates my ethical
system.
---------------------------------------------------------------------
Robert Baruch e-mail: bar...@nynexst.com
PH 1+914+644-2415
I swear by my life and my love of it that I shall
never live for the sake of another man, nor ask
another man to live for mine.
"Oh, I'm sorry, this is Abuse!" "Soon and in pleasant company"
--Monty Python's Flying Circus --A very strange fortune cookie
---------------------------------------------------------------------
Path: gmd.de!xlink.net!howland.reston.ans.net!darwin.sura.net!
haven.umd.edu!uunet!mcsun!news.funet.fi!hydra!klaava!klaava!not-for-mail
From: torva...@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Recent GPL interpretations and Linux
Date: 9 Jul 1993 01:48:53 +0300
Organization: University of Helsinki
Lines: 58
Message-ID: <21i88l$fo0@klaava.Helsinki.FI>
References: <21hie7$n4k@senator-bedfellow.MIT.EDU> <1993Jul8.190757.8962@nynexst.com>
NNTP-Posting-Host: klaava.helsinki.fi
Please... This discussion is getting out of hand, and while
uninteresting, I will follow up to (hopefully) get rid of some of the
misconceptions.
In article <1993Jul8.190757.8...@nynexst.com> bar...@nynexst.com writes:
>
>Recently on the GCC channel of the Linux activists list, it was mentioned that
>Richard Stallman interpreted the GPL such that code written using libraries under
>the GPL falls under the GPL.
Actually, it's not so much a case of "linking with the linux C library
makes programs GPL'd", as "we did a minor boo-boo in the library
creation which will have to be corrected". The standard linux C library
does indeed contain some GPL'd code - we'll just have to remove it and
hopefully use other alternatives instead. If all goes well, nobody will
even notice when a non-GPL'd version gets into use.
I have actually mailed around with rms a bit now, and he isn't the rabid
monster some people seem to think he is. He didn't rant and rave, and
indeed, he didn't even start accusing me (obvious target when he knew
about some misuse of GPL'd code), but I mailed him instead. The parts
of the linux C library which are now under the GPL will just have to be
excised, either to a separate library (which would be more clearly
marked "GPL" some way so that developers would actually *know* about the
fact), or by trying to use other versions of the offending routines.
The problem with the current C library is that there is no clear way to
indicate whether a program actually uses the GPL'd parts, so even if a
program is only linked against the "normal" C library routines (which
are all either GLPL or otherwise free), it's by no means obvious. Only
the regexp, gdbm and termcap parts of libc.a seem to be GPL'd, and of
those it seems that the regexp library may actually be available in GLPL
form in the GNU libc.a sources.
Note that the linux *kernel* has never been a problem in any way: all
the system calls have always been "freely usable", and I now even added
some extra explanations to the COPYING file for those that actually read
the thing. Even rms never considered the kernel a problem - not that he
has any say in this particular matter.
>So Stallman, if you're listening, Up Yours. You can take your statement,
>fold it so that it's all sharp corners, and stick it where the sun doesn't
>shine.
I've seen more eloquent replies on the matter, but frankly, as long as
we are using code written by others, I for one will *first* listen to
their wishes, and only then start looking into legality and make general
denouncements. The fact is that the people who wrote parts of the
current linux libc.a are unhappy with how it's used, and it's not for us
to say whether they are right or wrong. I personally don't think the
GPL is suitable for standard libraries, and the linux libc.a will be
cleaned up one way or another (I won't be promising any dates right now:
I'll have time to actually look into it myself only next week). The
best solution would be to get GLPL'd versions of the currently GPL'd
routines, but that failing (probable) we'll just have to find something
else.
Linus
From: keith@ksmith.com (Keith Smith)
Subject: Re: Recent GPL interpretations and Linux
Date: Wed, 14 Jul 93 01:55:24 GMT
[ Arguments about linking in GPL'd libc stuff ... ]
So let's say one was to produce some proprietary code tested & linked
into the GPL'd libc. Yet not ship it as a full BINARY just as a
collection of .o files with a 'sh' executable install script that builds
and links the executable on the target GPL'd system? Then restrict the
distribution of *MY* .o files (Which are not guaranteed to be suitable
for any particular purpose :) ) under a licence.
Seems this would be the logical answer.
Many of the GNU arguments would not hold water in court. There are also
IMPLIED reasons for use. i.e. the sole purpose of using gcc/bison is
to produce a binary. Restricting use of this product to produce
proprietary work is ludicrous. That's like saying using a patented
copywrited lathe to produce a bearing, puts the bearing under the lathe
manufactures copyright. Or using an IBM keyboard to input my code puts
the results my code under IBM copywrites. Or even further putting a GPL
on the bearing itself and giving them away means I can't put the bearing
in a skateboard and sell it? Uh-Uh. The implied use of the tool/object
is for the EXPRESS PURPOSE of producing derivative works, and has NO
OTHER purpose. Makeing anything like that stand up in court would
involve buying a few Judges or something. Maybe in So. Cal though ...
:) :) :).
--
Keith Smith keith@ksmith.com 5719 Archer Rd.
Digital Designs BBS 1-919-423-4216 Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Recent GPL interpretations and Linux
Date: Wed, 14 Jul 1993 21:50:18 GMT
In article <1993Jul14.015524.21665@ksmith.com>
keith@ksmith.com (Keith Smith) writes:
>So let's say one was to produce some proprietary code tested & linked
>into the GPL'd libc. Yet not ship it as a full BINARY just as a
>collection of .o files with a 'sh' executable install script that builds
>and links the executable on the target GPL'd system? Then restrict the
>distribution of *MY* .o files (Which are not guaranteed to be suitable
>for any particular purpose :) ) under a licence.
FSF has already said that this violates the license. It's only a slight
variant of the situation that led to this thread (RIPEM patches to use gmp,
which died on the shoals of the required RSAREF libraries).
>Many of the GNU arguments would not hold water in court. There are also
>IMPLIED reasons for use. i.e. the sole purpose of using gcc/bison is
>to produce a binary. Restricting use of this product to produce
>proprietary work is ludicrous. That's like saying using a patented
>copywrited lathe to produce a bearing, puts the bearing under the lathe
>manufactures copyright. Or using an IBM keyboard to input my code puts
Except that the bearing don't contain pieces of the lathe. The problem with
Bison is that a GPL'ed piece of code (bison.hairy or bison.simple, the parser
skeletons) is integrated into the binary. *Not* just linked; user code
(reductions) is interpolated into the parser skeleton. ---This is RMS's
interpretation of the GPL as applied to Bison.
As for me, I simply refuse to use bison. Even if byacc weren't part of SLS, I
have the source readily to hand.
++Brandon
--
Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org
Crossposted-To: gnu.misc.discuss
From: ijackson@nyx.cs.du.edu (Ian Jackson)
Subject: Re: Recent GPL interpretations and Linux
Date: Sat, 17 Jul 1993 00:43:15 GMT
(Followups to gnu.misc.discuss, please)
In article <1993Jul14.215018.10303@kf8nh.wariat.org>
bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
>In article < 1993Jul14.015524.21665@ksmith.com>
>keith@ksmith.com (Keith Smith) writes:
>>So let's say one was to produce some proprietary code tested & linked
>>into the GPL'd libc. Yet not ship it as a full BINARY just as a
>>collection of .o files with a 'sh' executable install script that builds
>>and links the executable on the target GPL'd system? Then restrict the
>>distribution of *MY* .o files (Which are not guaranteed to be suitable
>>for any particular purpose :) ) under a licence.
>
>FSF has already said that this violates the license. It's only a slight
>variant of the situation that led to this thread (RIPEM patches to use gmp,
>which died on the shoals of the required RSAREF libraries).
However, Brandon omitted to mention that:
Firstly, the libc is likely to be GLPL rather than GPL, which even
permits distribution of the linked binary provided that the .o files
are provided as well. The Linux libc is still tainted by some GPL
rather than GLPL code, but this is being worked on. IMHO, it would be
much better if most of those parts had been GLPL in the first place,
as this is causing problems for Linux.
Secondly, the FSF's interpretation of the GPL is (a) self-servingly
inconsistent, (b) very probably incorrect as a matter of law and (c)
irrelevant.
I consider myself a strong supporter of the GPL. However the
behaviour of the FSF (and esp. rms) with regard to this issue has left
a lot (propriety, openness and clarity, for example) to be desired.
--
Ian Jackson (urgent email: iwj10@phx.cam.ac.uk)
35 Molewood Close, Cambridge, CB4 3SR, England; phone: +44 223 327029
PGP2 public key on request; fingerprint = 5906F687 BD03ACAD 0D8E602E FCF37657