How not to follow the GNU GPL
Richard Stallman
Be Inc. has made an announcement to explain carefully how it follows
the rules of the GNU GPL:
We use GPL code for malloc, termcap and crypt. This are
directly linked into the kernel, libroot, telnet, telnetd, top,
and zbeos (the BeOS Intel bootloader). We have a single
downloadable archive called gnu_x86.tar.gz that contains
makefiles, the GNU source code, and object files that allow you
to rebuild these components. We also use GPL code for our 3Com
3C905 Ethernet drivers.
There is just one problem here: the GNU GPL does not permit this. It
does not permit using GPL-covered code as part of a non-free program.
If it did, it would fail to be a copyleft, and would not achieve the
benefits of copyleft (see
http://www.gnu.org/philosophy/pragmatic.html).
It looks like Be has made an honest mistake: overlooking the
difference between the GNU GPL and the GNU Library GPL. This way of
using GNU malloc and GNU crypt is permitted, precisely because those
programs are covered by the GNU Library GPL (also called the LGPL).
However, GNU termcap and the Linux 3c509 driver are covered by the GNU
GPL, and Be will have to stop using them as part of proprietary
programs.
Jeffrey C. Dege
On Sat, 9 May 1998 19:24:54 -0600, Richard Stallman <r...@santafe.edu> wrote:
>Be Inc. has made an announcement to explain carefully how it follows
>the rules of the GNU GPL:
>It looks like Be has made an honest mistake: overlooking the
>difference between the GNU GPL and the GNU Library GPL. This way of
>using GNU malloc and GNU crypt is permitted, precisely because those
>programs are covered by the GNU Library GPL (also called the LGPL).
>
>However, GNU termcap and the Linux 3c509 driver are covered by the GNU
>GPL, and Be will have to stop using them as part of proprietary
>programs.
They won't have to do any such thing unless the actual copyright holder
convinces a court to require them to do so.
--
When a clever man was stupid, he was stupid in a way a man who was
stupid all the time could never hope to match, for the clever man's
stupidity, drawing as it did on so much more knowledge, had a breadth
and depth to it the run-of-the-mill fool found impossible to duplicate.
-- Harry Turtledove
Roger Espel Llima
In article <1998051001...@wijiji.santafe.edu>,
Richard Stallman <r...@gnu.org> wrote:
>It looks like Be has made an honest mistake: overlooking the
>difference between the GNU GPL and the GNU Library GPL. This way of
>using GNU malloc and GNU crypt is permitted, precisely because those
>programs are covered by the GNU Library GPL (also called the LGPL).
I said the same to a Be advocate about the Linux 3c509 driver, and he
replied that the driver being loaded as a module with a specified
interface, by the kernel, it does not require the whole kernel to be
GPL'd. Since the Linux kernel itself allows non-GPL code to be inserted
as modules, I suppose this makes sense.
>However, GNU termcap and the Linux 3c509 driver are covered by the GNU
>GPL, and Be will have to stop using them as part of proprietary
>programs.
That leaves GNU termcap as the remaining open problem.
--
Roger Espel Llima, es...@llaic.u-clermont1.fr
http://www.eleves.ens.fr:8080/home/espel/index.html
David Kastrup
es...@llaic.u-clermont1.fr (Roger Espel Llima) writes:
> In article <1998051001...@wijiji.santafe.edu>,
> Richard Stallman <r...@gnu.org> wrote:
> >It looks like Be has made an honest mistake: overlooking the
> >difference between the GNU GPL and the GNU Library GPL. This way of
> >using GNU malloc and GNU crypt is permitted, precisely because those
> >programs are covered by the GNU Library GPL (also called the LGPL).
>
> I said the same to a Be advocate about the Linux 3c509 driver, and he
> replied that the driver being loaded as a module with a specified
> interface, by the kernel, it does not require the whole kernel to be
> GPL'd. Since the Linux kernel itself allows non-GPL code to be inserted
> as modules, I suppose this makes sense.
Nope. With Linux we have the kernel being under GPL, not the driver.
The real difference, however, is that the Linux kernel is covered with
a modified version of the GPL allowing for non-GPLed kernel modules.
If, however, we have a generic kernel interface not specific to the
particular driver, loading in kernel modules at run-time, then the
kernel can hardly be called a derived work of the driver. Nor do both
form an inseparable entity that can be licensed only as a whole.
> >However, GNU termcap and the Linux 3c509 driver are covered by the GNU
> >GPL, and Be will have to stop using them as part of proprietary
> >programs.
>
> That leaves GNU termcap as the remaining open problem.
That's what I would think so, too.
--
David Kastrup Phone: +49-234-700-5570
Email: d...@neuroinformatik.ruhr-uni-bochum.de Fax: +49-234-709-4209
Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany
Klaus.S...@home.ivm.de
>
> From: es...@llaic.u-clermont1.fr (Roger Espel Llima)
> References:
> <1998051001...@wijiji.santafe.edu>
>In article <1998051001...@wijiji.santafe.edu>,
>Richard Stallman <r...@gnu.org> wrote:
>>However, GNU termcap and the Linux 3c509 driver are covered by the GNU
>>GPL, and Be will have to stop using them as part of proprietary
>>programs.
>
>That leaves GNU termcap as the remaining open problem.
>
Why did the beo$ people choose gnu-termcap in the first place, as there
are different termcap libraries, like att or bsd termcap, or the replacement
that comes with ncurses?
Klaus Schilling
edw...@hairnet.demon.co.uk
In article <1998051001...@wijiji.santafe.edu>,
r...@gnu.org wrote:
> However, GNU termcap and the Linux 3c509 driver are covered by the GNU
> GPL, and Be will have to stop using them as part of proprietary
> programs.
Or release Be under GPL
--
Edward Betts http://www.hairent.demon.co.uk/
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Kenneth Miller
On 10 May 1998 12:57:05 +0200, David Kastrup wrote:
> es...@llaic.u-clermont1.fr (Roger Espel Llima) writes:
> If, however, we have a generic kernel interface not specific to the
> particular driver, loading in kernel modules at run-time, then the
> kernel can hardly be called a derived work of the driver. Nor do both
> form an inseparable entity that can be licensed only as a whole.
Precisely.
> > >However, GNU termcap and the Linux 3c509 driver are covered by the GNU
> > >GPL, and Be will have to stop using them as part of proprietary
> > >programs.
> >
> > That leaves GNU termcap as the remaining open problem.
> That's what I would think so, too.
Right. Someone at Be I've been talking to claims that source is
available to registered customers and developers (legitimate cd-owners)
upon request. This puts them in compliance if a) this is true and b)
they mention this and give an address in the distribution somewhere.
I'm in freebsd right now and can't comment on part b (though if it's not
mentioned, that's very easy to fix) but have sent mail to be inquiring
about part a. I'll let all of you know what happens.
Jason Stokes
[BeOS illegally incorporates copylefted software in its kernel]
>It looks like Be has made an honest mistake: overlooking the
>difference between the GNU GPL and the GNU Library GPL. This way of
>using GNU malloc and GNU crypt is permitted, precisely because those
>programs are covered by the GNU Library GPL (also called the LGPL).
>
>However, GNU termcap and the Linux 3c509 driver are covered by the GNU
>GPL, and Be will have to stop using them as part of proprietary
>programs.
It seems strange that anyone doing commercial development of an OS,
presumably with advisers and lawyers at hand, would misunderstand the
rather basic requirements of the license, but we should probably
ascribe this to ignorance, not malice, like you said. If this
violation is ignored than it sends a clear message to commercial
software developers that the GNU license doesn't have any teeth; I hope
the licensers involved will pursue this.
--
Jason Stokes: jstok (at) bluedog.apana.org.au (I use a spam block in my
header. Use this address to mail me, replacing (at) with @)
Jason Stokes
[BeOS illegally incorporates copylefted software in its kernel]
>It looks like Be has made an honest mistake: overlooking the
>difference between the GNU GPL and the GNU Library GPL. This way of
>using GNU malloc and GNU crypt is permitted, precisely because those
>programs are covered by the GNU Library GPL (also called the LGPL).
>
>However, GNU termcap and the Linux 3c509 driver are covered by the GNU
>GPL, and Be will have to stop using them as part of proprietary
>programs.
It seems strange that anyone doing commercial development of an OS,
presumably with advisers and lawyers at hand, would misunderstand the
rather basic requirements of the license, but I guess we should
probably ascribe this to ignorance rather than malice.
This could be a real test for copylefted software though; if this
violation skips through than it sends a clear message to commercial
software developers that the GNU license doesn't have any teeth; I
presume the maintainers of the software involved will pursue this?
M Rassbach
Jason Stokes wrote:
> In article <1998051001...@wijiji.santafe.edu>, Richard Stallman
> <r...@santafe.edu> wrote:
>
> [BeOS illegally incorporates copylefted software in its kernel]
So, who has the lawyers to write the letter, make the determination of
volation/non violation and time to go after this matter? I don't, and I'd
bet that the original author doesn't either.
If this whole GPL thing is to mean more than handwaving about GPL vs, say
Berkely-style licencing, then someone has to be willing to send out the
lawyers.
> If this
> violation is ignored than it sends a clear message to commercial
> software developers that the GNU license doesn't have any teeth; I hope
> the licensers involved will pursue this.
Exactly.
He who has the best lawyers win. And on that basis, GPL is rather
toothless to begin with.
Andi Kleen
M Rassbach <ma...@milestonerdl.com> writes:
>
> > If this
> > violation is ignored than it sends a clear message to commercial
> > software developers that the GNU license doesn't have any teeth; I hope
> > the licensers involved will pursue this.
>
> Exactly.
>
> He who has the best lawyers win. And on that basis, GPL is rather
> toothless to begin with.
I think they would obey simply to avoid a PR desaster.
-Andi
Paul D. Smith
%% kemi...@hcs.harvard.edu (Kenneth Miller) writes:
>> > That leaves GNU termcap as the remaining open problem.
>> That's what I would think so, too.
km> Right. Someone at Be I've been talking to claims that source is
km> available to registered customers and developers (legitimate
km> cd-owners) upon request. This puts them in compliance if a) this
km> is true and b) they mention this and give an address in the
km> distribution somewhere.
Only if GNU termcap is completely stand-alone. If it has any libraries
(such as libtermcap) then any non-GPL'd apps linked with those libraries
cannot be distributed.
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions--Bay Networks takes no responsibility for them.
Paul D. Smith
%% M Rassbach <ma...@milestonerdl.com> writes:
mr> So, who has the lawyers to write the letter, make the
mr> determination of volation/non violation and time to go after this
mr> matter? I don't, and I'd bet that the original author doesn't
mr> either.
The FSF has lawyers, and has used them in the past (although they never
had to go all the way to court).
Barry Margolin
In article <slrn6lbjdf....@hcs.harvard.edu>,
Kenneth Miller <kemi...@hcs.harvard.edu> wrote:
>Right. Someone at Be I've been talking to claims that source is
>upon request. This puts them in compliance if a) this is true and b)
>they mention this and give an address in the distribution somewhere.
I don't think so. If they're using this clause:
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; or,
then they can't restrict the source code only to registered customers and
developers. The above clause says "any third party".
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Aaron M. Renn
M Rassbach wrote:
> If this whole GPL thing is to mean more than handwaving about GPL vs, say
> Berkely-style licencing, then someone has to be willing to send out the
> lawyers.
Yes. That is one reason for assigning copyright to the FSF. That way they
have the legal authority to pursue a copyright infringement claim against
GPL violators - something that an independent developer is unlikely to have
the resources/time/inclination to do.
--
*****************************************************
* Aaron M. Renn *
* Email: ar...@urbanophile.com *
* Homepage: <URL:http://www.urbanophile.com/arenn/> *
*****************************************************
M Rassbach
Paul D. Smith wrote:
> The FSF has lawyers, and has used them in the past (although they never
> had to go all the way to court).
And as well they souldn't have to. If you used GPLed code, you are either in
violation or not. And, if GPL code is a hassle for you, then go pick up the same
thing in a Berkely-style...or do a re-write.
Kenneth Miller
On 10 May 1998 14:02:41 -0400, Paul D. Smith wrote:
> %% kemi...@hcs.harvard.edu (Kenneth Miller) writes:
>
> >> > That leaves GNU termcap as the remaining open problem.
>
> >> That's what I would think so, too.
>
> km> Right. Someone at Be I've been talking to claims that source is
> km> available to registered customers and developers (legitimate
> km> cd-owners) upon request. This puts them in compliance if a) this
> km> is true and b) they mention this and give an address in the
> km> distribution somewhere.
>
> Only if GNU termcap is completely stand-alone. If it has any libraries
> (such as libtermcap) then any non-GPL'd apps linked with those libraries
> cannot be distributed.
Nono, I mean the source to the programs linked to it. They're already
distributing the termcap source.
Kenneth Miller
On Sun, 10 May 1998 18:10:33 GMT, Barry Margolin wrote:
> In article <slrn6lbjdf....@hcs.harvard.edu>,
> Kenneth Miller <kemi...@hcs.harvard.edu> wrote:
> >upon request. This puts them in compliance if a) this is true and b)
> >they mention this and give an address in the distribution somewhere.
>
> I don't think so. If they're using this clause:
>
> 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; or,
>
> then they can't restrict the source code only to registered customers and
> developers. The above clause says "any third party".
hmm. the individual i talked to seemed under the impression that you
only had to give source copies to those to whom you gave binary copies.
this does seem to contradict that. i will investigate.
Kenneth Miller
On 10 May 1998 16:33:34 GMT, Jason Stokes wrote:
> In article <1998051001...@wijiji.santafe.edu>, Richard Stallman
> <r...@santafe.edu> wrote:
>
> [BeOS illegally incorporates copylefted software in its kernel]
There is no GPLed software in the kernel. Period. There is LGPL'ed
code in the kernel, which is legit. There is a wholly GPLed, standalone
driver which communicates with the net_server (userland networking), for
which source has been released. No violation there. The only remaining
issue are three programs, telnet, telnetd, and top which link to the
termcap library, which, oddly enough, is GPLed. They have given out the
source to the termcap lib itself, and the object files necessary to
rebuild the applications, but this is apparently not quite enough.
This has all been said before, but you should know where the violations
are occurring. Just in the interests of clarity.
> It seems strange that anyone doing commercial development of an OS,
> presumably with advisers and lawyers at hand, would misunderstand the
> rather basic requirements of the license, but we should probably
> ascribe this to ignorance, not malice, like you said. If this
> violation is ignored than it sends a clear message to commercial
> software developers that the GNU license doesn't have any teeth; I hope
> the licensers involved will pursue this.
It is a little strange, I agree, but they're a very small company and
the GPL is an oft-misunderstood and misrepresented document, and
confusion abounds. I've been in communication with people at Be about
this, because I want them to succeed, and legal snafus with the very
community of users and developers they hope to attract is a bad way to
do so.
Kragen Javier Sitaker
In article <m290oa8...@mailhost.neuroinformatik.ruhr-uni-bochum.de>,
David Kastrup <d...@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:
>With Linux we have the kernel being under GPL, not the driver.
>The real difference, however, is that the Linux kernel is covered with
>a modified version of the GPL allowing for non-GPLed kernel modules.
This is not correct, at least for Linux 2.0.30:
kragen@gentle:/usr/src/linux> diff -u /usr/src/linux-2.0.30/COPYING /usr/doc/binutils/COPYING
--- /usr/src/linux-2.0.30/COPYING Wed Dec 1 07:44:15 1993
+++ /usr/doc/binutils/COPYING Wed Aug 12 02:24:51 1992
@@ -1,15 +1,3 @@
-
- NOTE! This copyright does *not* cover user programs that use kernel
- services by normal system calls - this is merely considered normal use
- of the kernel, and does *not* fall under the heading of "derived work".
- Also note that the GPL below is copyrighted by the Free Software
- Foundation, but the instance of code that it refers to (the linux
- kernel) is copyrighted by me and others who actually wrote it.
-
- Linus Torvalds
-
-----------------------------------------
-
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
This diff does not say *anything* about allowing for non-GPL kernel
modules.
Did you post this disinformation through carelessness or malice?
I expect I'll have to argue with people who read your post for at least
five years.
If through carelessness, please be a little more careful about checking
your facts.
The 3c509 driver is supposed to be covered by GPL. I believe that this
is not actually possible in the US, since US government works (the 3c509
driver is from NASA) aren't subject to copyright under US law.
Kragen
Eric Lemar
Kenneth Miller (kemi...@hcs.harvard.edu) wrote:
: hmm. the individual i talked to seemed under the impression that you
: only had to give source copies to those to whom you gave binary copies.
: this does seem to contradict that. i will investigate.
:
Which is true, but the people given the binary copies are free by the GPL to
give the binaries to anyone else, and the people given the binaries then have
the right to the source, so unless Be is willing to allow any binaries that
contain GPL'd code to be freely distributed along with the source to these
binaries, they are in violation(not to mention that they are required to
ship the GPL with the product, which as far as I know they haven't done)...
eric
David Schweikert
In article <slrn6lc369....@hcs.harvard.edu>, Kenneth Miller wrote:
>On 10 May 1998 16:33:34 GMT, Jason Stokes wrote:
>> In article <1998051001...@wijiji.santafe.edu>, Richard Stallman
>> <r...@santafe.edu> wrote:
>>
>> [BeOS illegally incorporates copylefted software in its kernel]
>
>There is no GPLed software in the kernel. Period. There is LGPL'ed
>code in the kernel, which is legit. There is a wholly GPLed, standalone
>driver which communicates with the net_server (userland networking), for
>which source has been released. No violation there. The only remaining
>issue are three programs, telnet, telnetd, and top which link to the
>termcap library, which, oddly enough, is GPLed. They have given out the
>source to the termcap lib itself, and the object files necessary to
>rebuild the applications, but this is apparently not quite enough.
I think that if Be needs a driver for a network device, it has to write it
alone and not steal it from the Linux kernel.
The userland argument is only marginal as I see it.
It is parhaps legal but immoral.
A legal questions remains though: the userland module is linked against
/boot/develop/lib/x86/glue-noinit.a
is this one published and GPLed?
I am really deceived of Be doing things like that.
David
jo...@dhh.gt.org
M Rassbach writes:
> So, who has the lawyers to write the letter, make the determination of
> volation/non violation and time to go after this matter? I don't, and
> I'd bet that the original author doesn't either.
The FSF can and probably will enforce the copyright on the termcap stuff.
The 3c509 driver is more interesting. The "original author" is the US
Government, which is prohibited by law from enforcing its US copyright.
Some "fixes" are attributed to Alan Cox, but as no license terms are
attaced to them, his work must be presumed to be "all rights reserved".
Thus he can sue to prevent Be (or anyone else) from copying his "fixes",
but the GPL would not be involved. Be could buy him off, or get an old
copy without his patches and fix it themselves.
> If this whole GPL thing is to mean more than handwaving about GPL vs, say
> Berkely-style licencing, then someone has to be willing to send out the
> lawyers.
One of the things the FSF is in business for.
> He who has the best lawyers win. And on that basis, GPL is rather
> toothless to begin with.
You have personal knowledge of the competence of the FSF's attorneys?
--
John Hasler This posting is in the public domain.
jo...@dhh.gt.org Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.
Kragen Javier Sitaker
In article <6j59g9$s...@dailyplanet.wam.umd.edu>,
Eric Lemar <ele...@hyperion.dorm.umd.edu> wrote:
>
>Kenneth Miller (kemi...@hcs.harvard.edu) wrote:
>: hmm. the individual i talked to seemed under the impression that you
>: only had to give source copies to those to whom you gave binary copies.
>: this does seem to contradict that. i will investigate.
>:
>Which is true,
No. The situation under discussion is Be distributing binaries and
offering source separately. The GPL permits this, but only with the
requirement that the source be available to *everyone* -- not just those
to whom you gave binary copies -- and essentially at media cost.
The GPL does permit you to give binaries packaged with source to only
those people you want, but Be is not doing that, and...
> but the people given the binary copies are free by the GPL to
>give the binaries to anyone else, and the people given the binaries then have
>the right to the source, so unless Be is willing to allow any binaries that
>contain GPL'd code to be freely distributed along with the source to these
>binaries, they are in violation(not to mention that they are required to
>ship the GPL with the product, which as far as I know they haven't done)...
... yes, they are required to tell people the binaries are under GPL :)
Kragen
r...@greenend.org.uk
kra...@gentle.best.com (Kragen Javier Sitaker) writes:
> The 3c509 driver is supposed to be covered by GPL. I believe that this
> is not actually possible in the US, since US government works (the 3c509
> driver is from NASA) aren't subject to copyright under US law.
According to 3c509.c:-
Copyright 1994-1997 by Donald Becker.
Copyright 1993 United States Government as represented by the
Director, National Security Agency. This software may be used and
distributed according to the terms of the GNU Public License,
incorporated herein by reference.
...so (assuming that Donald Becker has the right to claim copyright!)
it's not just a US Government work.
Matt Brubeck
> However, GNU termcap and the Linux 3c509 driver are covered by the GNU
> GPL, and Be will have to stop using them as part of proprietary
> programs.
As a BeOS developer, let me clear up the technical confusion over BeOS network
drivers.
First, the BeOS uses a (pseudo) microkernel, and networking is not included in
the kernel.
Networking is handled by a user-level program called the net_server. So the BeOS
kernel
definitely doesn't enter into this question; if anything, it would be the
net_server.
NIC drivers in BeOS are compiled as "add-ons" to the net_server. The concept of
an add-on
in BeOS is similar to that of a shared library in some ways; the add-on exports
certain
symbols in the same way that a shared library does. However, instead of
importing the
symbols at link time as with a shared library, programs dynamically load and
unload an add-
ons at run time and use special kernel functions to access their exported
symbols.
What this means in practice: A network driver is a compiled binary which exports
certain
symbols defined by the BeOS API. The user takes this binary file and puts it
into a
specific directory for net_server addons. Whenever the net_server is launched,
it scans
each file in this directory and loads it into memory. An important note is that
the
net_server does not need to be recompiled in order to use new add-ons; it simply
needs to
be killed and re-launched.
So the BeOS 3c509 driver is definitely a stand-alone product in terms of the GNU
GPL; it is
not linked to the kernel or the net_server, nor are the kernel or net_server
linked to the
driver. Under the language of the GPL, the kernel and net_server are clearly not
affected
by the use of the 3c509 code.
As for my perspective on the whole Be/GNU situation...
It's clear that Be violated the GNU GPL and LGPL with the initial release of
BeOS R3.
However, they appear to be honestly apologizing and fixing their mistake. All
they have yet
to do is A) release the code to any programs linked to libtermcap and B) include
notices
about the GPL with the BeOS distribution. A number of GNU people are already
talking to Be
about A and it appears Be will do so. As for B, just watch for the upcoming 3.1
release in
June; I'll bet that the CD will include all of the appropriate notices.
As for various comments about Be "taking from the free software community
without giving
back," I am confused. Be has given back the same thing that all free software
developers
do: their source code. Look at the code to the BeOS 3c509 driver: It will be of
great help
to anyone writing BeOS network card drivers, or porting ethernet drivers to and
from any
platform.
Something else which no one here seems to be aware of: Be has been using GPL'd
software in
BeOS for ages now, and they have always included all of the source code and the
license
itself on the BeOS CD. In the latest release, they managed to miss some of the
code they
needed to include, and so they made it available on their FTP server a few weeks
later.
This hardly seems malicious.
Matt Brubeck
> However, GNU termcap and the Linux 3c509 driver are covered by the GNU
> GPL, and Be will have to stop using them as part of proprietary
> programs.
As a BeOS developer, let me clear up the technical confusion over
BeOS network drivers.
First, the BeOS uses a (pseudo) microkernel, and networking is
not included in the kernel. Networking is handled by a user-level
program called the net_server. So the BeOS kernel definitely
doesn't enter into this question; if anything, it would be the
net_server.
NIC drivers in BeOS are compiled as "add-ons" to the net_server.
The concept of an add-on in BeOS is similar to that of a shared
library in some ways; the add-on exports certain symbols in the
same way that a shared library does. However, instead of importing
the symbols at link time as with a shared library, programs dy-
namically load and unload an add-ons at run time and use special
Something else which few here seem to be aware of: Be has
David Kastrup
dwsc...@stud.ee.ethz.ch (David Schweikert) writes:
> I think that if Be needs a driver for a network device, it has to write it
> alone and not steal it from the Linux kernel.
> The userland argument is only marginal as I see it.
> It is parhaps legal but immoral.
Nonsense. The GPL is written in pretty clear language. Reuse of
software as long asth efull usefulness of the software for its
purpose (source availability of the entire unit in question) is quite
ok. Talking about "stealing" here is idiocy.
If Be uses a GPLed loadable module for the network device, all users
have the advantages they expect from GPLed software: they can get and
modify the source in order to adapt the driver to do what they need
freely.
That this does not hold for the rest of Be does make it any more
desirable not to have at least the network driver GPLed.
M Rassbach
jo...@dhh.gt.org wrote:
> > He who has the best lawyers win. And on that basis, GPL is rather
> > toothless to begin with.
>
> You have personal knowledge of the competence of the FSF's attorneys?
I'm betting that any business that took FSF to court would be able to outspend
them. And, alas, in the US, justice has little to do with facts....justice is
what you can afford. :-( FSF may have the best attorneys on earth, but in my
jaded view, he who has the gold wins.
Kragen Javier Sitaker
In article <wwvg1ih...@sfere.greenend.org.uk>,
Mr. Becker has sent me email about this. He says that (1) he is not an
employee of the government, but of a contractor, and (2) the contractor
does not hold a copyright on 3c509.c either, presumably because writing
it was not part of his employment duties.
I apologize for spreading my misapprehensions.
Kragen
Kragen Javier Sitaker
In article <6j6ado$c...@edrn.newsguy.com>,
Matt Brubeck <sno...@wport.com> wrote:
>> However, GNU termcap and the Linux 3c509 driver are covered by the GNU
>> GPL, and Be will have to stop using them as part of proprietary
>> programs.
>
>The concept of an add-on in BeOS is similar to that of a shared
>library in some ways; the add-on exports certain symbols in the
>same way that a shared library does. However, instead of importing
>the symbols at link time as with a shared library, programs dy-
>namically load and unload an add-ons at run time and use special
>kernel functions to access their exported symbols.
This is exactly the same as using dlopen() and dlsym() on Linux, or
LoadLibrary() and GetProcAddress() on Win32.
>What this means in practice: A network driver is a compiled binary
>which exports certain symbols defined by the BeOS API. The user
>takes this binary file and puts it into a specific directory for
>net_server addons. Whenever the net_server is launched, it scans
>each file in this directory and loads it into memory. An important
>note is that the net_server does not need to be recompiled in
>order to use new add-ons; it simply needs to be killed and re-launched.
>
>So the BeOS 3c509 driver is definitely a stand-alone product in
>terms of the GNU GPL; it is not linked to the kernel or the
>net_server, nor are the kernel or net_server linked to the driver.
>Under the language of the GPL, the kernel and net_server are
>clearly not affected by the use of the 3c509 code.
RMS has said to me that he considers loading a GPLed Netscape plug-in
into non-GPLed Netscape "definitely" a violation of the GPL. Netscape
plug-ins are loaded by Netscape in essentially exactly the same way that
the 3c509 driver is loaded into the net_server. Perhaps this means that
RMS would still, even knowing all the technical details, conclude that
this use of the 3c509 driver was in violation of the GPL.
(This worries me a bit. Where does "mere aggregation" begin, then?
Is it a violation of the GPL to run gcc on Win32, where it must link with
non-GPLed DLLs in order to access Win32 system calls? Is it a violation
of the GPL to run less on MS-DOS, where it calls OS routines in nearly
the same way it calls its own? If not, does it become a violation if
we replace INT 21 hex with mov word ptr [42], AX, followed by setting up
an interrupt stack frame and calling the routine whose address is in AX?)
Donald Becker has said to me, in private email, "Converting one of
my GPLed device drivers to link with a non-GPLed OS is a violation of
my copyright. Do not do it."
However, he apparently has a different interpretation of the GPL than RMS.
Kragen
Jeffrey C. Dege
On 11 May 1998 08:59:06 -0400, Kragen Javier Sitaker <kra...@gentle.best.com> wrote:
>In article <6j6ado$c...@edrn.newsguy.com>,
>>
>>So the BeOS 3c509 driver is definitely a stand-alone product in
>>terms of the GNU GPL; it is not linked to the kernel or the
>>net_server, nor are the kernel or net_server linked to the driver.
>>Under the language of the GPL, the kernel and net_server are
>>clearly not affected by the use of the 3c509 code.
>
>RMS has said to me that he considers loading a GPLed Netscape plug-in
>into non-GPLed Netscape "definitely" a violation of the GPL. Netscape
>plug-ins are loaded by Netscape in essentially exactly the same way that
>the 3c509 driver is loaded into the net_server. Perhaps this means that
>RMS would still, even knowing all the technical details, conclude that
>this use of the 3c509 driver was in violation of the GPL.
What RMS believes in this case is relevent only as to whether he decides
to file suit. You may agree with his interpretation of the the GPL,
BE may disagree with is interpretation, and none of it matters squat,
because the only interpretation that is enforcable is that of a judge.
--
Personally, I think my choice in the mostest-superlative-computer wars has to
be the HP-48 series of calculators. They'll run almost anything. And if they
can't, while I'll just plug a Linux box into the serial port and load up the
HP-48 VT-100 emulator.
William C. Cheng
In article <t4m51.14$1b.8...@cam-news-reader1.bbnplanet.com>,
Barry Margolin <bar...@bbnplanet.com> wrote:
>In article <slrn6lbjdf....@hcs.harvard.edu>,
>Kenneth Miller <kemi...@hcs.harvard.edu> wrote:
>>Right. Someone at Be I've been talking to claims that source is
>>available to registered customers and developers (legitimate cd-owners)
>>upon request. This puts them in compliance if a) this is true and b)
>>they mention this and give an address in the distribution somewhere.
>
>I don't think so. If they're using this clause:
>
> 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; or,
>
>then they can't restrict the source code only to registered customers and
>developers. The above clause says "any third party".
The term ``third party'' is not defined in GPL. Unless there's a legal
definition for it, it is up to the lawyers to define and argue about it.
If there's no legal definition for it, does anyone know if this is
intensionally not defined or if this is a hole that should be plugged
up in GPL?
--
Bill Cheng // bill....@acm.org <URL:http://bourbon.cs.umd.edu:8001/william/>
Paul D. Smith
%% M Rassbach <ma...@milestonerdl.com> writes:
mr> I'm betting that any business that took FSF to court would be able
mr> to outspend them. And, alas, in the US, justice has little to do
mr> with facts....justice is what you can afford. :-( FSF may have
mr> the best attorneys on earth, but in my jaded view, he who has the
mr> gold wins.
Sometimes, but not always, to be sure. There are obviously thousands
and thousands of examples where this did not happen.
Besides, there's no surer way to get _serious_ bad press on the 'Net
than pulling a stunt like this: these days, 'Net image _does_ matter to
all but the most entrenched high-tech companies. It would by a Pyhrric
victory at best.
Anyway, the FSF's attorneys (at least some of them) are working pro
bono; there was a post here recently regarding the new Netscape MPL from
a university professor of law (IIRC) who was acting basically in that
capacity.
Kenneth Miller
On 11 May 1998 08:59:06 -0400, Kragen Javier Sitaker wrote:
> RMS has said to me that he considers loading a GPLed Netscape plug-in
> into non-GPLed Netscape "definitely" a violation of the GPL. Netscape
> plug-ins are loaded by Netscape in essentially exactly the same way that
> the 3c509 driver is loaded into the net_server. Perhaps this means that
> RMS would still, even knowing all the technical details, conclude that
> this use of the 3c509 driver was in violation of the GPL.
This seems, well, silly. Not to mention indefensible. Who, exactly, is
committing the violation in the case of netscape loading a GPLed module?
The GPLed module? That seems pretty odd. Netscape? They didn't put
the module there, the user did. The user? The GPL governs
distribution, not private use. There is nothing at all wrong with
distributing a modified copy of the driver, or the module, with source,
and with the license. Or are you saying that if I, an unoffiliated
developer, using published interfaces, rewrote the program such that it
happens to run as a netscape plug-in, or a be add-on, it would force the
Be kernel into GPL? I can distribute it however I want, and suggest
people do anything they please with it, so long as I include source and
the license. Be (or Netscape) is different because they happen to hold
the copyright to the other end of the interface? Come on.
Kris Van Hees
On 10 May at 18:29:50, Aaron M. Renn wrote <3555F21E...@urbanophile.com> which contained:
> M Rassbach wrote:
>> If this whole GPL thing is to mean more than handwaving about GPL vs, say
>> Berkely-style licencing, then someone has to be willing to send out the
>> lawyers.
>
> have the legal authority to pursue a copyright infringement claim against
> GPL violators - something that an independent developer is unlikely to have
> the resources/time/inclination to do.
I wonder how this is possible. I cannot speak for the US much, but at least
in most countries I have checked out, copyright is non-transferable, since it
lies with the author. Licensing is possible to another party, but you cannot
transfer copyright. I believe this is also true in the international copyright
agreements (please correct me if I am wrong).
An author holds the copyright on everything he or she writes, whether it is
explicitly mentioned or not. However, it can be licensed to anyone, and the
license of course can be protected by someone else.
Kris
Timothy Philip Vernum
ele...@hyperion.dorm.umd.edu (Eric Lemar) writes:
>(not to mention that they are required to
>ship the GPL with the product, which as far as I know they haven't done)...
It's all in with the source to the shell tools.
/optional/gnu/ on the CD
(or /boot/optional/gnu/ if you installed the optionals)
Not very prominent, but I think you'd have a hard time arguing that the GPL
puts restrictions on that.
>eric
Timothy Philip Vernum
kra...@gentle.best.com (Kragen Javier Sitaker) writes:
>In article <6j6ado$c...@edrn.newsguy.com>,
>>NIC drivers in BeOS are compiled as "add-ons" to the net_server.
>>The concept of an add-on in BeOS is similar to that of a shared
>>library in some ways; the add-on exports certain symbols in the
>>same way that a shared library does. However, instead of importing
>>the symbols at link time as with a shared library, programs dy-
>>namically load and unload an add-ons at run time and use special
>>kernel functions to access their exported symbols.
>This is exactly the same as using dlopen() and dlsym() on Linux, or
>LoadLibrary() and GetProcAddress() on Win32.
I don't have access to any Win32 docs ATM, but Add-Ons are technically
different to dl*() on Unix(like) systems.
Essentially it comes down to whether an add-on is a separate app to the
application calling it.
IIRC objects linked with dl*() share symbol tables with the loading
process. Add-ons do not.
For an example:
I was playing with an add-on to the tracker this evening.
I can't guarantee that the net_server add-ons operate in the same way
as the tracker's but I would strongly suspect it.
This particular add-on runs as both a stand-alone app and as an add-on.
It's not just the same source, but the same binary.
I can drop files onto it and have it process them, or I can put it into
the add-ons directory of the tracker and have the tracker load it when
I want to use it.
If this program came under the GPL, then it wouldn't force the Tracker
to become GPL.
Similarly if I decide to convert a linux driver to run on BeOS, then I
am not able to? The GPL goes out of its way to state that their is no
distinction regarding the authorship of separate components.
No matter who writes the code, the licence is the same.
But if I am not legally allowed to convert a linux driver to BeOS then I
would argue that the GPL is a sham, because in that case it doesn't offer
me the freedom that the FSF pushes. The point of making free (open-source)
software is to allow users to use it and modify it for the benefit of all.
If I want to use it under BeOS, then truly open software has to let me, or
it ceases to be "free".
Ultimately it is clear the Be has violated the GPL regarding libtermcap.
All other alleged violations regarding the current release would take some
fairly fierce court battles to prove.
Sean Eddy
ae...@fnx.com (Kris Van Hees) writes:
> I wonder how this is possible. I cannot speak for the US much, but at least
> in most countries I have checked out, copyright is non-transferable, since it
> lies with the author. Licensing is possible to another party, but you cannot
> transfer copyright. I believe this is also true in the international copyright
> agreements (please correct me if I am wrong).
IANAL, but I think you're wrong. Certainly in US and UK copyright law,
you can transfer copyright. (Very common in submitting papers to
American or British scientific journals, for example.) I believe US
copyright law is consistent (now) with the Berne Convention and
international law.
--
- Sean Eddy
- Dept. of Genetics, Washington University in St. Louis
- http://www.genetics.wustl.edu/eddy/
Tim Smith
Kragen Javier Sitaker <kra...@gentle.dyn.ml.org> wrote:
>RMS has said to me that he considers loading a GPLed Netscape plug-in
>into non-GPLed Netscape "definitely" a violation of the GPL.
1. My reading of copyright law says that the plug-in is not a derivative
work of Navigator, and Navigator is not a derivative work of the
plug-in. I thus fail to see the relevance of GPL in this case.
2. Whom does he see as violating the GPL in the case of a GPL-ed plug
in? Netscape? The author of the plug-in? The author of the web page
that has the content that causes the plug-in to be invoked? The user
who allows Navigator to load the plug-in?
--Tim Smith
jo...@dhh.gt.org
Matt Brubeck writes:
> Something else which few here seem to be aware of: Be has been using
> GPL'd software in BeOS for ages now, and they have always included all of
> the source code and the license itself on the BeOS CD. In the latest
> release, they managed to miss some of the code they needed to include,
> and so they made it available on their FTP server a few weeks later. This
> hardly seems malicious.
No it doesn't. From your description, it sounds like honest mistakes.
IMHO, commercial organizations planning to use GPL'd code could avoid many
such errors by asking the FSF for advice. They are under no legal or moral
obligation to do so, but it could save them embarrassment and expense.
Anthony Rossini
>>>>> "Kris" == Kris Van Hees <ae...@fnx.com> writes:
Kris> I wonder how this is possible. I cannot speak for the US
Kris> much, but at least in most countries I have checked out,
Kris> copyright is non-transferable, since it lies with the
Kris> author. Licensing is possible to another party, but you
Kris> cannot transfer copyright. I believe this is also true in
Kris> the international copyright agreements (please correct me if
Kris> I am wrong).
Kris> An author holds the copyright on everything he or she
Kris> writes, whether it is explicitly mentioned or not. However,
Kris> it can be licensed to anyone, and the license of course can
Kris> be protected by someone else.
Copyright is transferable -- at least if you want to publish research
papers in (the majority of) academic journals these days.
But I believe you are correct about copyright being present whether it
is explicitly mentioned.
best,
-tony
David Kastrup
kra...@gentle.best.com (Kragen Javier Sitaker) writes:
> In article <m290oa8...@mailhost.neuroinformatik.ruhr-uni-bochum.de>,
> David Kastrup <d...@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:
> >With Linux we have the kernel being under GPL, not the driver.
> >The real difference, however, is that the Linux kernel is covered with
> >a modified version of the GPL allowing for non-GPLed kernel modules.
>
> This is not correct, at least for Linux 2.0.30:
> This diff does not say *anything* about allowing for non-GPL kernel
> modules.
>
> Did you post this disinformation through carelessness or malice?
Carelessness. I have cancelled the original article by now. I am
afraid that I could have sworn having read this information somewhere
in some other post or so. One should not go around spreading by
hearsay. Sorry for that.
> I expect I'll have to argue with people who read your post for at least
> five years.
>
> If through carelessness, please be a little more careful about checking
> your facts.
I'll try.
BTW, I have now looked through all of the kernel and relevant HOWTOs
in order to find a relevant ruling. Nothing. A kernel module would
be pretty much standalone, but will have to include kernel headers
usually. The kernel headers I have looked at don't have *any*
copyright notice to them. If they were supposed to be GPLed (which
they probably are), it would have been a good idea to place the
standard copyright notice in them, as *very* much suggested by the
GPL. A lot of other files in the kernel don't bear any explicit
notice, either.
Part of the module idea has been that hardware vendors could provide
modules for their relevant hardware, I believe. I am not sure that
the intention was that those would have to be GPLed in any case.
Whatever the intention has been, it is very difficult to read anything
explicit into the rather lax placing of copyright notices. In lack of
other information, one has to assume that the inclusion of the headers
will make your stuff a derived work from GPLed code. But there have
been some court rulings IIRC that mere interfaces are not
copyrightable, and one might claim an honest mistake when confronted
with the lack of exact information in the Linux kernel.
I think it would be probably a good idea to state the intention with
regard to the necessary licensing of kernel modules more explicitly
somewhere.
James Youngman
>>>>> "se" == Sean Eddy <ed...@wrasse.wustl.edu> writes:
se> ae...@fnx.com (Kris Van Hees) writes:
>> I wonder how this is possible. I cannot speak for the US much,
>> but at least in most countries I have checked out, copyright is
>> non-transferable, since it lies with the author. Licensing is
>> possible to another party, but you cannot transfer copyright. I
>> believe this is also true in the international copyright
>> agreements (please correct me if I am wrong).
se> IANAL, but I think you're wrong. Certainly in US and UK
se> copyright law, you can transfer copyright. (Very common in
se> submitting papers to American or British scientific journals,
se> for example.) I believe US copyright law is consistent (now)
se> with the Berne Convention and international law.
I'm not quite up to date with this, since the last time I looked into
this was in about 1992, but at that time the situation in the UK was
that there were twelve or so separate copyrights (the "All" in "All
Rights Reserved"). These included the rights of broadcasting, public
performance, copying, and so on. Another of these rights was the
*right to be identified as the author of a work*. IIUC, all
copyrights are transferrable (separately or collectively) *except*
that last one.
So the author can give away or otherwise dispose of all his/her rights
with regard to a work, and can give away the right to so dispose of
all the transferrable rights, but that single right still cannot be
transferred.
Indeed, if you look in the front of some books published in the UK,
you may see words similar to:-
(C) 1832 MegaCorp Publishing Ltd. All Rights Reserved. No part of
this book .... may be reproduced or .... without the prior
written consent of MegaCorp Publishing Ltd.
The moral right of Foo Barbaz to be identifed as the author of this
book has been asserted.
James Youngman
>>>>> "dk" == David Kastrup <d...@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:
[The Linux kernel.....]
dk> Whatever the intention has been, it is very difficult to read
dk> anything explicit into the rather lax placing of copyright
dk> notices. In lack of other information, one has to assume that
dk> the inclusion of the headers will make your stuff a derived work
dk> from GPLed code. But there have been some court rulings IIRC
dk> that mere interfaces are not copyrightable, and one might claim
dk> an honest mistake when confronted with the lack of exact
dk> information in the Linux kernel.
Well, the include files don't just contain interfaces, they also
contain *implementations* of inline functions. For, example the file
linux/include/asm-i386/delay.h includes the inline functions delay()
and udelay().
Greg Stark
Anthony Rossini <ros...@stat.sc.edu> writes:
> >>>>> "Kris" == Kris Van Hees <ae...@fnx.com> writes:
>
> Kris> I wonder how this is possible. I cannot speak for the US
> Kris> much, but at least in most countries I have checked out,
> Kris> copyright is non-transferable, since it lies with the
> Kris> author. Licensing is possible to another party, but you
> Kris> cannot transfer copyright. I believe this is also true in
> Kris> the international copyright agreements (please correct me if
> Kris> I am wrong).
I believe in the US and many other countries copyright is completely
transferable. In some European countries I believe authors have
certain untransferable rights but I doubt these will survive the
current round of attempts to strip copyright law from anything that
threatens large media companies.
There are various pages about this, one is at:
http://www.connected.org/rights/wipo.html
> Kris> An author holds the copyright on everything he or she
> Kris> writes, whether it is explicitly mentioned or not. However,
> Kris> it can be licensed to anyone, and the license of course can
> Kris> be protected by someone else.
This is true under the Berne convention, though sometimes employers
and other copyright owners have claims as well.
greg
Jason Stokes
In article <6j71po$nip$1...@client2.news.psi.net>, Kris Van Hees
<ae...@fnx.com> wrote:
>I wonder how this is possible. I cannot speak for the US much, but at
>least in most countries I have checked out, copyright is
>non-transferable, since it lies with the author.
Copyright not transferrable!!! You must be joking!
--
Jason Stokes: jstok (at) bluedog.apana.org.au (I use a spam block in my
header. Use this address to mail me, replacing (at) with @)
Per Abrahamsen
Sean Eddy <ed...@wrasse.wustl.edu> writes:
> ae...@fnx.com (Kris Van Hees) writes:
> > I wonder how this is possible.
> > I cannot speak for the US much, but at least in most countries I
> > have checked out, copyright is non-transferable, since it lies
> > with the author. Licensing is possible to another party, but you
> > cannot transfer copyright. I believe this is also true in the
> > international copyright agreements (please correct me if I am
> > wrong).
>
> IANAL, but I think you're wrong. Certainly in US and UK copyright law,
> you can transfer copyright.
Danish law has no such thing as "Copyright". Instead it has "Creators
Right". This is non-transferable, but you can license your work for
specifiers perpuses. I.e. if you write a book, you can give a
publisher the exclusive right to publish it in book form. But if
someone wants to use it in a movie, he will have to contact the
author.
Of course, you can write the contract that gives the publisher the
exclusive rights for the book, movie, radio and TV version. But the
contract have to be specific, it you make the statements too broad (I
sign over *all* uses), the contract will not be legally binding.
I believe this is the situation on most of continental Europe.
robert havoc pennington
jd...@jdege.visi.com (Jeffrey C. Dege) writes:
>
> What RMS believes in this case is relevent only as to whether he decides
> to file suit. You may agree with his interpretation of the the GPL,
> BE may disagree with is interpretation, and none of it matters squat,
> because the only interpretation that is enforcable is that of a judge.
>
Except that Be is a young company without a lot of money to throw
around, and wouldn't want to risk the PR, so they're likely to just
give in if RMS threatens to sue. They aren't going to do the "Oh yeah,
make me" thing.
Havoc Pennington ==== http://pobox.com/~hp
Klaus.S...@home.ivm.de
>
> Re: How not to follow the GNU GPL
>
> From: kemi...@hcs.harvard.edu (Kenneth Miller)
> Reply to: Kenneth Miller
> Date: 10 May 1998 20:14:08 GMT
> Organization: the 24-hour church of elvis
> Newsgroups:
> gnu.misc.discuss
> Followup to: newsgroup(s)
> References:
> <1998051001...@wijiji.santafe.edu>
> <6j3qce$k8c$1...@alpha.sky.net>
> <m290oa8...@mailhost.neuroinformatik.ruhr-uni-bochum.de>
> <slrn6lbjdf....@hcs.harvard.edu>
> <t4m51.14$1b.8...@cam-news-reader1.bbnplanet.com>
>On Sun, 10 May 1998 18:10:33 GMT, Barry Margolin wrote:
>> In article <slrn6lbjdf....@hcs.harvard.edu>,
>> Kenneth Miller <kemi...@hcs.harvard.edu> wrote:
>> >Right. Someone at Be I've been talking to claims that source is
>> >available to registered customers and developers (legitimate cd-owners)
>> >upon request. This puts them in compliance if a) this is true and b)
>> >they mention this and give an address in the distribution somewhere.
>>
>> I don't think so. If they're using this clause:
>>
>> 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; or,
>>
>> then they can't restrict the source code only to registered customers and
>> developers. The above clause says "any third party".
>
>only had to give source copies to those to whom you gave binary copies.
>this does seem to contradict that. i will investigate.
I bet Be will do that under a nondisclosure agreement, which is downright immoral .
Klaus Schilling
Kris Van Hees
On 11 May at 14:26:00, Kris Van Hees wrote <6j71po$nip$1...@client2.news.psi.net> which contained:
< About transfering copyright to e.g. the FSF... >
> I wonder how this is possible. I cannot speak for the US much, but at least
> in most countries I have checked out, copyright is non-transferable, since it
> lies with the author. Licensing is possible to another party, but you cannot
> transfer copyright. I believe this is also true in the international copyright
> agreements (please correct me if I am wrong).
>
> An author holds the copyright on everything he or she writes, whether it is
> explicitly mentioned or not. However, it can be licensed to anyone, and the
> license of course can be protected by someone else.
I made a mistake here (which obviously has been noticed by several people).
What I named Copyright (for what I know it as in flemish) actual has several
aspects in its english meaning, apparantly. One of these is (as James Youngman
and Per Abrahamsen point out) the right to be identified as the author of the
work. Licensing is of course something which covers rights such as the use and
distribution (if any) of the work.
US law may work differently, but I know that at least in many european countries
I could write code as employee, and though my employer would have all rights
on the code, I would legally be the author, and anyone (including the employer)
who would claim to be the author would be in violation of my right.
My apologies for the confusing statement I made in my previous posting.
Kris
Leslie Mikesell
In article <6j6smq$k...@gentle.best.com>,
>Is it a violation of the GPL to run gcc on Win32, where it must link with
>non-GPLed DLLs in order to access Win32 system calls?
There is an exception for the standard system libraries, but if you
have installed any enhancements or third party software that replaced
the stock DLLS it would be a violation.
>Is it a violation
>of the GPL to run less on MS-DOS, where it calls OS routines in nearly
>the same way it calls its own? If not, does it become a violation if
>we replace INT 21 hex with mov word ptr [42], AX, followed by setting up
>an interrupt stack frame and calling the routine whose address is in AX?)
Depends on what you hit. If you have installed non-standard drivers
(aspi, network, etc.) then it's not the stock operating system. At
one point it was considered a violation to use any libraries under
dos since there wasn't a stock compiler to supply them. Now I think
since you have to buy some compiler the libs that come with it are
considered OK.
Les Mikesell
l...@mcs.com
Matt Brubeck
Kragen Javier Sitaker <kra...@gentle.dyn.ml.org> wrote:
>RMS has said to me that he considers loading a GPLed Netscape plug-in
>into non-GPLed Netscape "definitely" a violation of the GPL.
I hope that RMS does not seriously believe that, as I was under the
impression that he is familiar with the GNU General Public License
and its terms. If he does believe it, he is wrong, and should read
the GPL again.
The only way that releasing a Netscape Navigator plugin (or BeOS
network driver, for that matter) under GPL would violate the terms
of the license is if Navigator (or the BeOS net_server) was then
considered a derivative work based on the plugin, under Section 2
of the GPL.
Navigator is very clearly not derived in any way from the hypo-
thetical GPL'ed plugin. The authors of Navigator did not use any
code from the plugin; in fact, the plugin may not even have exis-
ted when Navigator was written, compiled, and distributed. There
is no way that the authors of Navigator (or the net_server) have
violated the GPL, because they have not incorporated any GPL code
into their products. There is no way a court, or any person, would
accuse them of doing so.
As for the authors of the plugins, they have not violated the GPL
either. The GPL does not forbid distributed code which can be
loaded and executed by other, non-GPL, programs. As long as the
author of the plugin releases the full source code to their plugin
and includes the appropriate licensing notices, no violation has
been made. No one can accuse them either of violating GPL. If you
doubt me, read the license yourself. If you disagree, please cite
which clause of the GPL has been violated.
The only other reasoning I can imagine is that the copy of Navigator
loaded into memory on a user's computer becomes a derived work of
the plugin when it loads the plugin into its memory space. In this
case, it is the user who has violated GPL by creating a new work
not released under GNU GPL but based on GPL code.
Of course, this would require that the copy of an executable re-
siding in memory be considered an original work, and that causing
a computer to load a program into its memory constitutes authorship
of this "work." Based on the information I have on US and inter-
national copyright law (as well as common sense), this is not a
legally acceptable argument.
If neither Netscape or BeOS, the plugin author, or the user has
violated the GPL, then who has? No one.
Should it be illegal to run gzip on a Macintosh because it causes
GPL code to be loaded by a non-GPL program? Don't laugh; this is
more relevant than you might think. What happens when an operating
system launches an executable is exactly the same as when Navigator
or the net_server loads a plugin. It loads the binary into memory,
scans for certain exported symbols (in this case, usually the __start
symbol exported by a main function), and executes code contained in
the binary. If it is illegal for Navigator to load GPL code, the
same should be true for running a GPL program on any operating system
not distributed under GNU GPL (that is, pretty much every operating
sytem but Linux).
Of course, the GNU GPL could be modified to forbid GPL code from
being loaded into memory and executed by a non-GPL program (though
I don't see why this would be desirable). However, the current
version of the GPL contains nothing of the sort. If you believe
that it does, please quote to me the relevant parts of the license.
As for Be: As I have said before, they are currently in violation
of the General Public License. However, they appear to be taking
all steps necessary to rectify that. I expect that the next release
will fully conform to GPL. If not, then we have reason to get angry.
Michael Kagalenko
(jo...@dhh.gt.org) wrote in article <877m3sj...@hasler.dhh>
]> Something else which few here seem to be aware of: Be has been using
]> GPL'd software in BeOS for ages now, and they have always included all of
]> the source code and the license itself on the BeOS CD. In the latest
]> release, they managed to miss some of the code they needed to include,
]> and so they made it available on their FTP server a few weeks later. This
]> hardly seems malicious.
]
]No it doesn't. From your description, it sounds like honest mistakes.
]
]IMHO, commercial organizations planning to use GPL'd code could avoid many
]such errors by asking the FSF for advice. They are under no legal or moral
]obligation to do so, but it could save them embarrassment and expense.
Even better idea is to avoid GPL code with all associated legal
aggravations, and use BSD stuff.
jo...@dhh.gt.org
Jeffrey C. Dege writes:
> What RMS believes in this case [the 3c509 driver] is relevent only as to
> whether he decides to file suit.
He can't sue. He doesn't own any of the code involved. It appears, from
the copyright notice in the source and what has been posted here, that only
Mr. Becker and possibly Mr. Cox have standing (The US Government could
theoretically sue outside the US).
Paul D. Smith
%% jd...@jdege.visi.com (Jeffrey C. Dege) writes:
jcd> Well, I generally approve of amicable resolution of problems of
jcd> this sort. But part of me would like to see a precedent on the
jcd> enforcability of the GPL established.
I'm sure that even if there was a ruling, it would be strictly targeted
and probably wouldn't do much more than give us all something new to
argue about :)
Which, I suppose, would still be a very good thing *sigh*.
Steve Peltz
In article <m2emy0n...@mailhost.neuroinformatik.ruhr-uni-bochum.de>,
David Kastrup <d...@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:
>Part of the module idea has been that hardware vendors could provide
>modules for their relevant hardware, I believe. I am not sure that
>the intention was that those would have to be GPLed in any case.
If the intention is to allow proprietary modules to be loaded into the
kernel, and that a GPL-ed module can also be loaded into that same kernel,
the conclusion would seem to be that a GPL-ed module (whether written
to the Linux interface or some other interface) would be allowed to be
loaded by a totally non-GPLed kernel.
With regard to libtermcap, if the only programs that are linked with
libtermcap are distributed under the GPL themselves, I'd think that
would be satisfactory. I don't think any of the system itself needs it,
just the various terminal-mode programs such as Bash, and as far as
I know, the source for all of those, as modified to run under BeOS,
is available. Since those tools are distributed and installed at the
same time as the kernel, the clause allowing "anything that is normally
distributed with the major components" "unless that component itself
accompanies the executable" may be a problem; not sure how that interacts
with the "mere aggregation" clause, as those tools are not vital parts
of the system interface.
Aaron M. Renn
Per Abrahamsen wrote:
> Danish law has no such thing as "Copyright". Instead it has "Creators
> Right". This is non-transferable, but you can license your work for
> specifiers perpuses. I.e. if you write a book, you can give a
> publisher the exclusive right to publish it in book form. But if
> someone wants to use it in a movie, he will have to contact the
> author.
Well, this is how it usually works in the US as well. The original author
maintains the copyright and sells the publishing rights to a publisher. All
other rights (unless stated otherwise in the contract) remain with the
author. If you look at the front of most books (at least in the US) you will
see that the copyright statement has the author's name, not the publisher's
name. In negotiating these type of arrangements, it helps to have an agent
and/or lawyer on your side.
US law rejects the notion of "natural rights" for authors. Indeed the US
law (contrary to what most large media and software companies would have you
believe) explicitly states that copyright is to promote progress in the arts
and to benefit the public - not to protect any rights of authors or to help
them get rich. European countries have a somewhat different view and many
of their laws do recognize some "natural rights", though I am unclear on
exactly what. As a result of this US legal doctrine, copyright is fully
transferrable here. Your mileage may vary in other countries, but I believe
most of them do allow copyright transferal, though the author may retain
some rights over the work.
--
*****************************************************
* Aaron M. Renn *
* Email: ar...@urbanophile.com *
* Homepage: <URL:http://www.urbanophile.com/arenn/> *
*****************************************************
Jeffrey C. Dege
On Mon, 11 May 1998 18:06:06 GMT, robert havoc pennington <h...@pobox.com> wrote:
>jd...@jdege.visi.com (Jeffrey C. Dege) writes:
>>
>> to file suit. You may agree with his interpretation of the the GPL,
>> BE may disagree with is interpretation, and none of it matters squat,
>> because the only interpretation that is enforcable is that of a judge.
>>
>
>Except that Be is a young company without a lot of money to throw
>around, and wouldn't want to risk the PR, so they're likely to just
>give in if RMS threatens to sue. They aren't going to do the "Oh yeah,
>make me" thing.
Well, I generally approve of amicable resolution of problems of this sort.
But part of me would like to see a precedent on the enforcability of
the GPL established.
--
For every problem there is one solution which is simple, neat, and wrong.
-- H. L. Mencken
Paul D. Smith
%% Matt Brubeck <sno...@wport.com> writes:
mb> I hope that RMS does not seriously believe that, as I was under the
mb> impression that he is familiar with the GNU General Public License
mb> and its terms. If he does believe it, he is wrong, and should read
mb> the GPL again.
Hmm. Where did you get _your_ law degree?
RMS has competent lawyers at his disposal and utilized them to create
the GPL so that it says what he wanted it to; I'd trust his
interpretation of the license over yours... but I'd get a real legal
opinion before basing any decisions on either.
mb> The only way that releasing a Netscape Navigator plugin (or BeOS
mb> network driver, for that matter) under GPL would violate the terms
mb> of the license is if Navigator (or the BeOS net_server) was then
mb> considered a derivative work based on the plugin, under Section 2
mb> of the GPL.
mb> Navigator is very clearly not derived in any way from the hypo-
mb> thetical GPL'ed plugin. The authors of Navigator did not use any
mb> code from the plugin; in fact, the plugin may not even have exis-
mb> ted when Navigator was written, compiled, and distributed. There
mb> is no way that the authors of Navigator (or the net_server) have
mb> violated the GPL, because they have not incorporated any GPL code
mb> into their products. There is no way a court, or any person, would
mb> accuse them of doing so.
Obviously not, but that's not the issue. The issue isn't with Netscape,
it's with the people who distributed GPL'd code--the plugin authors.
If someone incorporated the RogueWave libraries with GPL'd code, would
RogueWave be liable? Obviously not: the problem is with those who tried
to combine incompatible licensing terms.
mb> As for the authors of the plugins, they have not violated the GPL
mb> either. The GPL does not forbid distributed code which can be
mb> loaded and executed by other, non-GPL, programs. As long as the
mb> author of the plugin releases the full source code to their plugin
mb> and includes the appropriate licensing notices, no violation has
mb> been made. No one can accuse them either of violating GPL. If you
mb> doubt me, read the license yourself. If you disagree, please cite
mb> which clause of the GPL has been violated.
You haven't at all shown that the plugin isn't considered a derived
work. This is a legal term, not a "logical" one. The legal definition
may have no relationship to what _you_ "logically" think it should
mean.
IANAL, either, and furthermore I'm not familiar with Netscape's plugin
technology, but to me the most salient question is: can the plugin be
invoked and will it perform useful functions without Netscape?
If you can't run the plugin and use it without Netscape present, then
there's a good case to be made, IMO, that the plugin _is_ in fact a
derived work, in the sense that the GPL means. In this case, the plugin
is simply yet another version of the "user does the link" dodge, which
the FSF and RMS have repeatedly stated _does_ constitute a violation of
the GPL.
If you can run it, usefully, standalone, then I would think it's almost
certainly not a derived work.
mb> Should it be illegal to run gzip on a Macintosh because it causes
mb> GPL code to be loaded by a non-GPL program? Don't laugh; this is
mb> more relevant than you might think. What happens when an operating
mb> system launches an executable is exactly the same as when Navigator
mb> or the net_server loads a plugin. It loads the binary into memory,
mb> scans for certain exported symbols (in this case, usually the __start
mb> symbol exported by a main function), and executes code contained in
mb> the binary. If it is illegal for Navigator to load GPL code, the
mb> same should be true for running a GPL program on any operating system
mb> not distributed under GNU GPL (that is, pretty much every operating
mb> sytem but Linux).
Please re-read the GPL more carefully, yourself. There is an explicit
exception made in the GPL for all system components. The Macintosh
loader is a system component. Netscape is not a system component.
David Kastrup
jd...@jdege.visi.com (Jeffrey C. Dege) writes:
> On Mon, 11 May 1998 18:06:06 GMT, robert havoc pennington <h...@pobox.com> wrote:
> >jd...@jdege.visi.com (Jeffrey C. Dege) writes:
> >>
> >> What RMS believes in this case is relevent only as to whether he decides
> >> to file suit. You may agree with his interpretation of the the GPL,
> >> BE may disagree with is interpretation, and none of it matters squat,
> >> because the only interpretation that is enforcable is that of a judge.
> >>
> >
> >Except that Be is a young company without a lot of money to throw
> >around, and wouldn't want to risk the PR, so they're likely to just
> >give in if RMS threatens to sue. They aren't going to do the "Oh yeah,
> >make me" thing.
>
> Well, I generally approve of amicable resolution of problems of this sort.
> But part of me would like to see a precedent on the enforcability of
> the GPL established.
Boy, you guys are more eager for legal battles than Microsoft. If any
honest or purported mistake with the use of GPL leads to this sort of
"crucifiget" calls, you're not making a good case for businesses using
GPLed software. Even if the copyright holder itself will usually
behave more rationally and sanely, if use of GPLed software leads
potentially to massively exaggerated defamation campaigns and witch
hunts, then GPL is really almost as bad as a restrictive proprietary
license, with the difference that not your capital is immediately at
the whims of your strangeholders, but your reputation.
Stephan Boettcher
Matt Brubeck wrote:
>
> The only other reasoning I can imagine is that the copy of Navigator
> loaded into memory on a user's computer becomes a derived work of
> the plugin when it loads the plugin into its memory space. In this
> case, it is the user who has violated GPL by creating a new work
> not released under GNU GPL but based on GPL code.
> If neither Netscape or BeOS, the plugin author, or the user has
> violated the GPL, then who has? No one.
Am I wrong in my understanding of the GPL that a _user_ cannot violate
the GPL at all --- anybody is free to do what he/she wants, as long as
he/she does not distribute anything?
Shalom
Stephan
--
------------------------------------------------------------------------
Stephan B"ottcher FAX: +972-3-640-7932
School of Physics and Astronomy Tel: +972-3-640-7722
High Energy Physics Department or -6094
Tel Aviv University mailto:ste...@alzt.tau.ac.il
69978 Tel Aviv or mailto:Stephan....@cern.ch
Israel WWW: http://zufo.tau.ac.il/~stephan/home.html
------------------------------------------------------------------------
Matt Brubeck
>If you can't run the plugin and use it without Netscape present, then
>there's a good case to be made, IMO, that the plugin _is_ in fact a
>derived work, in the sense that the GPL means.
Plugins and add-ons loaded at run-time do not rely on a particular
program to function. Anyone may write a program which loads the same
plugin and imports the same symbols. In addition, if the plugin exports
a main function in addition to the ones defined by the plugin API, it
can run as an executable in its own right (this may depend on the de-
tails of your OS).
[By "main," I am using C/C++ terminology for the block of code which an
operating system jumps to when an executable is loaded. The actually
routine or label has different names in other languages.]
For example, browser plugins are usually available in a single binary
which works in most web browsers, because Navigator and Explorer and
others support common basic interfaces for plugins. Similarly, there
are image-editing tools other than Adobe Photoshop that can load and
use Photoshop plugin tools.
>IANAL, either, and furthermore I'm not familiar with Netscape's plugin
>technology, but to me the most salient question is: can the plugin be
>invoked and will it perform useful functions without Netscape?
Definitely yes. (I admit that IANAL either; on the other hand, I am
quite familiar with run-time loading and plugin architectures.) I hope
that these technical facts convince you (and would convince a court)
that plugin files are separate works from any programs which load them
into memory.
When I create a dynamically loadable plugin for a web browser or other
program, I am not creating a work derived from that program. I am cre-
ating a piece of software that exports certain known symbols, which any
program is free to import.
The process could happen in reverse: I could create a plugin and document
the exported symbols, and someone else could then write the code to load
the plugin and run it. Would my work still be considered derived from
their (later) work?
This debate is not hypothetical to me at all. I am the author of a popular
BeOS program called "Run," which functions both as an executable and an
addon to the Tracker (a part of the operating system).
The only difference between running my program as an executable and run-
ning it as a Tracker add-on is that in the latter case, a function called
process_refs() is called when the program is loaded, instead of one called
main().
I have considered using some code from bash in a future version of Run,
which would require releasing my program under the terms of the GNU GPL.
(It is currently released to the public domain. Yes, I do know what this
means legally.) Am I forbidden from releasing my Tracker add-on under GPL
because the Tracker must be considered part of my program?
No. My program and the Tracker are separate works. They can interact, but
this does not mean that one is derived from the other.
What if I also write a simple program which loads a Tracker add-on and
calls its process_refs() function, and released that under the GPL? Can I
now call Run an add-on to this program rather than to the Tracker?
This doesn't just affect authors who wish to use already-GPL'd code in
their plugins. It also affects authors who wish to release their original
work under GNU GPL. According to RMS, they may do so only if their code
does not export any symbols which might be imported by non-GPL software.
This would severely restrict the freedom of free software developers.
[What if I wrote another simple program which loaded executables as add-
ons and called their main() functions? Then, every executable binary is
an add-on to my app, and every author of GPL software is in violation of
their license.]
>Please re-read the GPL more carefully, yourself. There is an explicit
>exception made in the GPL for all system components.
I believe you are referring to the paragraph in Section 3 which deals
with defining the source code for a program. It states that source code
must include everything that the user needs to create an executable pro-
gram (headers, config scripts, etc.).
Obviously, this should include a compiler and other tools necessary for
creating the binary from its source code. The exception which you mention
merely states that the source may exclude such tools if they are normally
distributed with the operating system. This paragraph deals only with
creating object code from source, not the use of that code once created.
Jeff Read
Michael Kagalenko wrote:
> Even better idea is to avoid GPL code with all associated legal
> aggravations, and use BSD stuff.
There's a problem with the BSD license too, as pointed out on the GNU
web page. An option would be to cut and paste the license out of
programs like Wine, which is licensed under "BSD-like" terms but doesn't
use the BSD license proper.
Then again, there are legit reasons to use the GPL, particularly if you
wish to keep the software "free" throughout its incarnations. This I'm
sure is why Linux was GPLed.
--
----------------------------------------------------------------------
Jeff Read <bit...@geocities.com>/ http://genpc.home.ml.org
Unix / Linux / Windows Hacker, / Boycott Microsoft!
Anime & Sonic Fan, / Use Linux/GNU!
All Around Nice Guy / Let's keep the Net and the Land FREE!
----------------------------------------------------------------------
Kragen Javier Sitaker
William C. Cheng <wil...@cs.umd.edu> wrote:
>Barry Margolin <bar...@bbnplanet.com> wrote:
> >If they're using this clause:
> >
> > 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
> >
> >then they can't restrict the source code only to registered customers and
> >developers. The above clause says "any third party".
>
>definition for it, it is up to the lawyers to define and argue about it.
It's defined in Webster's (www.m-w.com) as `a person other than the
principals'. I imagine it's defined legally in the same way.
I would like to request that you look things up in a dictionary before
posting a message saying that they're not defined.
It would probably be clearer to say "any person", since that would avoid
the definitional problem above -- possibly not everyone knows what a
"third party" is.
Kragen
Klaus Espenlaub
Matt Brubeck wrote:
>
> >If you can't run the plugin and use it without Netscape present, then
> >there's a good case to be made, IMO, that the plugin _is_ in fact a
> >derived work, in the sense that the GPL means.
>
> Plugins and add-ons loaded at run-time do not rely on a particular
> program to function. Anyone may write a program which loads the same
> plugin and imports the same symbols. In addition, if the plugin exports
> a main function in addition to the ones defined by the plugin API, it
> can run as an executable in its own right (this may depend on the de-
> tails of your OS).
First, IANAL.
I think we all agree that plugins are some sort of dynamic library.
Some plugins make sense to be used standalone, but generally they are
linked by some means to a host application, which means that it is
incorporated into that host application. They are sharing the same
address space when run. I assume that this is the case with BeOS.
Please correct me if I'm wrong.
Paragraph 0 of the GPL states that
"
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted [...]
"
meaning that the user can do whatever he likes to do with the software,
except when it comes to distributing.
As far as I understand the paragraphs 1 and 2 of the GPL, there's no
problem with distributing the (maybe modified) Linux network driver
if it's still under GPL.
The only program that gets affected by the GPL is the net_driver program
shipped by Be. Linking a program with some library (even dynamic ones)
makes a program a derivative works of the library. If the library is under
GPL, then the program must be under GPL, too.
But there's another case possible, shown by the Mozilla browser.
Netscape wrote an application and specified a plugin interface. They did
that before the first want-to-be GPL plugin existed. Now someone reads
that spec and writes a plugin. From my viewpoint, this plugin can be
under GPL, because just implementing some specs doesn't force you to
use any particular license.
An example would be the GNU libc. It is mostly an implementation of some
spec, but no one can force a license on the authors, because e.g. they
didn't use any AT&T code. Thus GNU libc is not a derivative work. This
means that I don't share RMS' opinion about GPLed plugins for Mozilla.
I'm not writing one either, so I won't go to court about this issue.
The Be case is just the other way round. The GPL library existed first,
making the program linked to the library derived works, because that is
part of the conditions of the Linux network driver. The program was
designed to work with the library.
By itself this would be implementing some specs, but distributing the
program with the Linux driver makes the program a derivative works of
the driver. The touch question is: would the same apply to Mozilla if
some distributor ships with a GPLed plugin (possible, see above)?
The two other cases possible with a GPLed program and a proprietary
library are not problematic, because a GPLed program may never rely on
any existing or future proprietary library except the system libs.
This "GPL anomaly" shows up only for dynamic libraries, because an
arbitrary order of proprietary and GPL development is possible. The
most problematic cases
I'd better stop now, because my brain starts to go backwards thinking
about this shaky legal ground. I think there should be something in
GPL about dynamic libraries (apart from the very last paragraph, which
isn't even in the TERMS AND CONDITIONS, meaning that they are not binding).
BUT DON'T ask me what to add. The more critical uses of dynamic libraries
just got into widespread use, because dlopen/dlsym became more popular.
See the short history about the pluggable authentication modules. What
if I write a proprietary authentication module and ship it with the GPLed
stuff? BZZZZZZZT!
Klaus
, changeable during
the lifetime of either product.
Kenneth Miller
First off, add-ons -are- different from a standard dynamic library.
They do not share symbol tables, and run separately. I feel like I'm
repeating myself.
On Tue, 12 May 1998 15:07:54 +0200, Klaus Espenlaub wrote:
[snip]
> The Be case is just the other way round. The GPL library existed first,
> making the program linked to the library derived works, because that is
> part of the conditions of the Linux network driver. The program was
> designed to work with the library.
No. The driver was wrapped with a layer of code to make it work with
the pre-existing interface. The net_server and its add-on interface has
been there since the ppc version, presumably since the bebox, which used
only ne2000 cards and for which be wrote drivers themselves.
> By itself this would be implementing some specs, but distributing the
> program with the Linux driver makes the program a derivative works of
> the driver. The touch question is: would the same apply to Mozilla if
> some distributor ships with a GPLed plugin (possible, see above)?
No. Codistribution does not make things fall under the same license.
Paul D. Smith
%% Klaus Espenlaub <kesp...@hydra.informatik.uni-ulm.de> writes:
ke> This "GPL anomaly" shows up only for dynamic libraries, because an
ke> arbitrary order of proprietary and GPL development is possible.
It seems unlikely to me that a legal decision on whether two licenses
conflict with each other would be based on which was created first.
Either the licenses have a conflict, or they don't.
I could be wrong.
It may well be that determining who's liable for the license
infringement depends on which came first, but the mere fact that
the licenses are in conflict doesn't seem like it would.
Barry A. Warsaw
>>>>> "PDS" == Paul D Smith <psm...@baynetworks.com> writes:
PDS> Please re-read the GPL more carefully, yourself. There is an
PDS> explicit exception made in the GPL for all system components.
PDS> The Macintosh loader is a system component. Netscape is not
PDS> a system component.
No, but MSIE *is*. 1/2 :-)
Barry A. Warsaw
>>>>> "john" == <jo...@dhh.gt.org> writes:
john> He can't sue. He doesn't own any of the code involved.
This is exactly the reason why the FSF prefers to have copyright
assigned to them for GNU programs.
Alan Coopersmith
David Schweikert <dwsc...@stud.ee.ethz.ch> wrote:
>I think that if Be needs a driver for a network device, it has to write it
>alone and not steal it from the Linux kernel.
If everyone had this attitude, there would be no such thing as Linux.
I think that if Be is willing to use and support a GPL'ed driver,
everyone (*) benefits, as long as Be follows the rules.
* at least Be users/developers, people who might benefit from Be's
changes on other OS'es, and people who want to see the free software
movement expand all benefit
--
________________________________________________________________________
Alan Coopersmith al...@godzilla.EECS.Berkeley.EDU
Univ. of California at Berkeley http://soar.Berkeley.EDU/~alanc/
aka: alanc@{CSUA,OCF,CS,BMRC,ucsee.eecs,cory.eecs,server}.Berkeley.EDU
David Schweikert
In article <6jac9b$rd0$1...@agate.berkeley.edu>, Alan Coopersmith wrote:
>David Schweikert <dwsc...@stud.ee.ethz.ch> wrote:
>>I think that if Be needs a driver for a network device, it has to write it
>>alone and not steal it from the Linux kernel.
>
>If everyone had this attitude, there would be no such thing as Linux.
>I think that if Be is willing to use and support a GPL'ed driver,
>everyone (*) benefits, as long as Be follows the rules.
The difference is that Linux is free (or "open source") and Be OS is not.
The purprose of the GPL is to share code and is against proprietary
code like Be OS. Be wants to make profit out of
proprietary software? No problem, but not with GPL code which was written
with an opposed goal in mind.
This userland stuff is a technical trick. What is the _moral_ difference?
As for the benefit: I think mostly Be benefits because it can write on it's
hardware compatibility list that this 3com card is supported and thus have
more possible customers.
--
David Schweikert <schwe...@acm.org>
"Grandpa, tell me again about the days when there was a Microsoft."
Isaac
In article <slrn6lfglr...@jdege.visi.com>, Jeffrey C. Dege wrote:
>
>Well, I generally approve of amicable resolution of problems of this sort.
>But part of me would like to see a precedent on the enforcability of
>the GPL established.
>
Is threre a particular outcome you'd like to see?
Isaac
Steve Peltz
In article <slrn6lgs14....@hcs.harvard.edu>,
Kenneth Miller <kemi...@hcs.harvard.edu> wrote:
>First off, add-ons -are- different from a standard dynamic library.
>They do not share symbol tables, and run separately. I feel like I'm
>repeating myself.
Details are different, basic principle is the same. The add-on can call
code in the main program; the main program can call code in the add-on,
binding isn't done until run-time. If you think of it as a dynamic library
with a separate name-space, would that satisfy your objections?
Isaac
In article <p5yaw8f...@baynetworks.com>, Paul D. Smith wrote:
>IANAL, either, and furthermore I'm not familiar with Netscape's plugin
>technology, but to me the most salient question is: can the plugin be
>invoked and will it perform useful functions without Netscape?
>
>there's a good case to be made, IMO, that the plugin _is_ in fact a
>is simply yet another version of the "user does the link" dodge, which
>the FSF and RMS have repeatedly stated _does_ constitute a violation of
>the GPL.
>
This argument repeatedly comes up and probably will again because the
responses to date have been very unsatisfying.
For most plugins, it would be trivial to make them perform useful
functions without Netscape present. A plugin can be simply an
executable with extra symbols exported which give no functionality
not present when unplugged from Netscape. In the case where
the plugin is not so arranged, what value would there be in forcing
someone to make the trivial changes needed.
Secondly, if copyright law does not prevent the user from doing the
link, exactly when does the GPL license become relevant? The GPL
cannot possible be relevant unless what is being discussed are
activities restricted by copyright law. I have seen no convincing
arguments for "user linking" being an activity not permitted by
copyright law when the user owns the copy of the work. It is the
definition of derived used by copyright law that is relevant first and
not that of the GPL.
What I will agree to is that when someone makes code available for free,
their wishes as to how it should be used are relevant. I think it would
be extremely rude to take FSF code and use it in ways which RMS has
said constitute violation of the license.
Isaac
Steve Peltz
In article <slrn6lhfpt....@tardis-a2.ee.ethz.ch>,
David Schweikert <dwsc...@stud.ee.ethz.ch> wrote:
>This userland stuff is a technical trick. What is the _moral_ difference?
Not really a technical trick. Would you prohibit Linux from using a
proprietary driver that was made available? If not, then Linux, while
that proprietary driver is loaded, is non-GPL-compliant, thus by the
same argument, you shouldn't be allowed to load any GPL drivers at the
same time.
I don't see any difference between a GPL program dynamically linking
with a proprietary library or plug-in or add-on or whatever, and a GPL
add-on linking with a proprietary program, regardless of whether either is
"normally distributed with the major components of the operating system"
(and who is to say that Netscape is not such a component? On what basis?).
The following is my opinion. IANAL.
The GPL refers to copying, not usage. Although the issue was raised
with the RIPEM lunacy, it was then sidestepped. Distributing NON-GPL
source can NOT be prohibited by the GPL, regardless of whether the
source is designed to be turned into a program that links with GPL
binaries or source. Even with the "user does the link" assertion, all
that can do is possibly prevent distributing GPL code (object or source),
along with proprietary code. If I have source code that is designed to
link with both GPL and proprietary libraries, and don't include either,
the resulting binary will not be distributable, but I can certainly
create it and run it, and I can certainly distribute that source code.
IF the driver or plug-in or add-on binary itself contains both
GPL code and proprietary libraries, then I agree that it can not be
distributed. However, if everything necessary to create that binary is
available on GPL terms or less restrictive terms, I don't see how the
intended USAGE (including the use of a specific interface to another
program) can possibly be covered by the GPL, which explicitly does not
cover usage of a derived work, only distribution.
The argument used with RIPEM was that there was only one possible
library it could be linked with (remember, RIPEM could be used without
that library, using the GPL library was a configuration OPTION;
while the resulting binary would not be distributable at all, if that
option was used, creating such a binary is allowed, and a source-only
distribution should CERTAINLY be allowed). This is a very weak argument.
Either my work is a derived work, or it is not. What if, instead of a
public-domain math library, a proprietary library was created? By the
arguments that were used, RIPEM would all of a sudden have been legal -
unless, of course, the proprietary library was made unavailable again,
at which point all of a sudden RIPEM is no longer legal to distribute,
even as source code?
David Schweikert
In article <6jak2p$atn$1...@jaka.ece.uiuc.edu>, Steve Peltz wrote:
>In article <slrn6lhfpt....@tardis-a2.ee.ethz.ch>,
>David Schweikert <dwsc...@stud.ee.ethz.ch> wrote:
>>This userland stuff is a technical trick. What is the _moral_ difference?
>
>Not really a technical trick. Would you prohibit Linux from using a
>proprietary driver that was made available? If not, then Linux, while
>that proprietary driver is loaded, is non-GPL-compliant, thus by the
>same argument, you shouldn't be allowed to load any GPL drivers at the
>same time.
This is obviously a more complex problem than I initially thought :-)
If the Linux kernel distribution included a module which explicitly forbids
linking with GPL stuff, the it would be illegal...
If however a user gets a kernel proprietary module (for example from the Net)
then you can't say nothing.
>The GPL refers to copying, not usage. Although the issue was raised
>with the RIPEM lunacy, it was then sidestepped. Distributing NON-GPL
>source can NOT be prohibited by the GPL, regardless of whether the
>source is designed to be turned into a program that links with GPL
>binaries or source. Even with the "user does the link" assertion, all
>that can do is possibly prevent distributing GPL code (object or source),
>along with proprietary code. If I have source code that is designed to
>link with both GPL and proprietary libraries, and don't include either,
>the resulting binary will not be distributable, but I can certainly
>create it and run it, and I can certainly distribute that source code.
You are right: it is a distribution problem. If a third party did this
network driver, then there would be no problems. If however Be distributes
this driver with it's release of BeOS, even if it is a "userspace module",
then I think there is a problem...
>IF the driver or plug-in or add-on binary itself contains both
>GPL code and proprietary libraries, then I agree that it can not be
>distributed. However, if everything necessary to create that binary is
>available on GPL terms or less restrictive terms, I don't see how the
>intended USAGE (including the use of a specific interface to another
>program) can possibly be covered by the GPL, which explicitly does not
>cover usage of a derived work, only distribution.
What do you mean by "contains"? static-linked?
This is I think one of the big problems of the GPL: it becomes fuzzy for
dynamic linking and such.
Bye,
David
Jeffrey C. Dege
Well, I've found the GPL bothersome on occasion, particularly with
respect to the Gnu Regex library, which should, it seems to me,
have been distributed under the LGPL, but it wasn't. But all-in-all,
I am supportive of the GNU effort, even if I don't agree with RMS
all the time, and I think a decision supporting the GPL would do
a lot in legitimatizing the open source movement.
--
What? Me .sig?
Kenneth Miller
Not really. Because for a library, the application has to know, at
build time, something about what that specific library does, and depends
on that behavior to function. I.e. if my program needs strcat or
something like that, it loads the appropriate library and runs it; if
the library isn't there or the wrong one is put in its place, the
program cannot continue. With the add-ons, it looks for the specified
function in ALL of a class of programs (in this case all files in a
directory). If the file doesn't have the function, it's a non-fatal
error, and the program continues. So I can completely and wholly remove
the specified lump of code, and the loading application won't be any the
wiser.
I think what I'm saying is that it's not so much the technical details
of how exactly they communicate with each other, but the nature of the
relationship. We could be talking about traditional dlls and it
wouldn't matter. In the first situation I describe, the program is most
certainly a derived work, in that the calling program relies on
functionality in the loaded work to function at all. In the second
case, the loaded work provides data to and performs services for the
calling program, but it is merely one possible instance of a class of
performers and providers. It's not fundamentally different from, for
example, programs running on an X server. Just because the method of
communication is more intimate does not mean that there is any
derivation going on. In fact, it's almost exactly like an X server.
The X server will run just fine without clients. You won't be able to
do anything useful, but that's irrelevant. And programs which rely on
X are useless without the X server, but again, that's irrelevant. I
don't hear anyone saying that running the GIMP on a proprietary X server
is a violation.
Timothy Philip Vernum
pe...@jaka.ece.uiuc.edu (Steve Peltz) writes:
>In article <slrn6lgs14....@hcs.harvard.edu>,
>Kenneth Miller <kemi...@hcs.harvard.edu> wrote:
>>First off, add-ons -are- different from a standard dynamic library.
>>They do not share symbol tables, and run separately. I feel like I'm
>>repeating myself.
>Details are different, basic principle is the same.
>The add-on can call code in the main program;
Only if the main program exports symbols for that purpose.
> the main program can call code in the add-on,
>binding isn't done until run-time. If you think of it as a dynamic library
>with a separate name-space, would that satisfy your objections?
But then every utility is a dynamic library.
I'll caliing the __start symbol (or whatever your OS calls it)
So as someone mentioned (not sure if it was here or on SlashDot)
that makes something like
cat foo | grep "bar"
illegal if I use standard Solaris 'cat' and GNU 'grep'.
Does exporting extra symbols other than __start suddenly change the licence
for my program? I don't thinks so.
But then, IANAL
Isaac
In article <slrn6li7mr....@hcs.harvard.edu>, Kenneth Miller wrote:
>On 12 May 1998 16:51:35 -0500, Steve Peltz wrote:
>I think what I'm saying is that it's not so much the technical details
>of how exactly they communicate with each other, but the nature of the
>relationship. We could be talking about traditional dlls and it
>wouldn't matter. In the first situation I describe, the program is most
>certainly a derived work, in that the calling program relies on
If I followed your post correctly, your first example was of a program
using "strcat" from a library. You are arguing that such a program
is a derived work under copyright law? I would need permission to
distribute the source of such a program from the author of "strcat"?
>functionality in the loaded work to function at all. In the second
>case, the loaded work provides data to and performs services for the
>calling program, but it is merely one possible instance of a class of
>performers and providers. It's not fundamentally different from, for
>example, programs running on an X server. Just because the method of
I can't argue with your analysis in the second case, but I see only
artificial distinctions between the situations once the method of
communication between programs is not an issue. How is a program
that calls system ("foo -r") any more or less derivative than a
program which gets the same functionality by calling dlopen ("foo"...)
dlsym ("do_work") ? Why is it different if we leave the symbol _do_work
to be resolved dynamically at run time and let the user worry about how
to get a copy of the free foo library. How would such an argument stand up
if the offending program was distributed in source form under a restrictive
NDA?
Even though the technical arguments seem shaky, I don't see that the
FSF has any choice but to draw the line where they have. Microsoft
when in the same position can argue that you don't have all the rights
allowed under copyright law since you don't own a copy of their software
but have only licensed a copy. With GPL'd code this same line of argument
cannot be made. Only by calling an offending program derivative (or
a copy of course) do they have any say in how it is used. The alternative
is that anyone with some trivial steps could use GPL'd code in
proprietary software without distributing source and this would be bad.
Isaac
William C. Cheng
In article <6j9gb3$t...@gentle.best.com>,
Kragen Javier Sitaker <kra...@gentle.dyn.ml.org> wrote:
>William C. Cheng <wil...@cs.umd.edu> wrote:
>>Barry Margolin <bar...@bbnplanet.com> wrote:
>> >If they're using this clause:
>> >
>> > 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
>> > . . .
>> >
>> >then they can't restrict the source code only to registered customers and
>> >developers. The above clause says "any third party".
>>
>>The term ``third party'' is not defined in GPL. Unless there's a legal
>>definition for it, it is up to the lawyers to define and argue about it.
>
>It's defined in Webster's (www.m-w.com) as `a person other than the
>principals'. I imagine it's defined legally in the same way.
But I doubt that this is the only legal interpretation! My suspecision
is that it can interpreted as ``a person other than the principals that's
involed in a transaction'' when it's put in the context of a transaction.
X writes a piece of free software and put it under GPL. Y gets X's code
and agreed to the terms of GPL. The principals are X and Y. Y derives
work from X's code and sells derived work to Z. If Y uses the 2nd
interpretation of ``third party'' above, Y has to offer source to Z and
no one else.
My question is if the 2nd interpretation can also be a legal definition.
Does ``third party'' has to be interepreted without any context?
--
Bill Cheng // bill....@acm.org <URL:http://bourbon.cs.umd.edu:8001/william/>
Kenneth Miller
On 13 May 1998 10:46:04 GMT, Isaac wrote:
> In article <slrn6li7mr....@hcs.harvard.edu>, Kenneth Miller wrote:
> >On 12 May 1998 16:51:35 -0500, Steve Peltz wrote:
> >I think what I'm saying is that it's not so much the technical details
> >of how exactly they communicate with each other, but the nature of the
> >relationship. We could be talking about traditional dlls and it
> >wouldn't matter. In the first situation I describe, the program is most
> >certainly a derived work, in that the calling program relies on
> If I followed your post correctly, your first example was of a program
> using "strcat" from a library. You are arguing that such a program
> is a derived work under copyright law? I would need permission to
> distribute the source of such a program from the author of "strcat"?
Yes.
> >functionality in the loaded work to function at all. In the second
> >case, the loaded work provides data to and performs services for the
> >calling program, but it is merely one possible instance of a class of
> >performers and providers. It's not fundamentally different from, for
> >example, programs running on an X server. Just because the method of
> I can't argue with your analysis in the second case, but I see only
> artificial distinctions between the situations once the method of
> communication between programs is not an issue. How is a program
> that calls system ("foo -r") any more or less derivative than a
> program which gets the same functionality by calling dlopen ("foo"...)
> dlsym ("do_work") ? Why is it different if we leave the symbol _do_work
> to be resolved dynamically at run time and let the user worry about how
> to get a copy of the free foo library.
This is exactly my point. If the program -will- -fail- without the
presence of a (non-standard) other work, regardless of how it is
invoked, it can reasonably be considered derivative. Otherwise, no.
> How would such an argument stand up if the offending program was
> distributed in source form under a restrictive NDA?
I'm not sure how this affects anything.
> Even though the technical arguments seem shaky, I don't see that the
> FSF has any choice but to draw the line where they have. Microsoft
> when in the same position can argue that you don't have all the rights
> allowed under copyright law since you don't own a copy of their software
> but have only licensed a copy. With GPL'd code this same line of argument
> cannot be made. Only by calling an offending program derivative (or
> a copy of course) do they have any say in how it is used. The alternative
> is that anyone with some trivial steps could use GPL'd code in
> proprietary software without distributing source and this would be bad.
I don't see this. If people can reasonably make two pieces distinct,
one their code, one GNU-derived, I see no reason they should be forced
to do anything they don't want to do with the code they wrote. They
still have to distribute the source to the GNU-derived portions,
including whatever modifications they made. If the intent of the GPL is
to be a virus, sucking in people's work against their will, it's the
most reprehensible farce I've ever seen. If it's intended to be so
restrictive that GNU software can only talk to other GNU software in any
way, it's just silly.
Tim Smith
Kenneth Miller <kemi...@hcs.harvard.edu> wrote:
>> If I followed your post correctly, your first example was of a program
>> using "strcat" from a library. You are arguing that such a program
>> is a derived work under copyright law? I would need permission to
>> distribute the source of such a program from the author of "strcat"?
>
>Yes.
Uh, he asked two questions. "Yes" is the correct answer to the first
question, but not the second. The *source* to a program that uses
strcat is not a derivative work of the library, and so he needs no
permission from the library author to distribute it. The *executable*
produced by compiling that source and linking with the library is a
derivative work of the library, and needs permission of the library
copyright holder to be distributed.
>This is exactly my point. If the program -will- -fail- without the
>presence of a (non-standard) other work, regardless of how it is
>invoked, it can reasonably be considered derivative. Otherwise, no.
There is nothing in copyright law in the United States to support that
statement, and plenty of case law directly against it. For example, the
major manufacturers of video game consoles want to control who writes
games for their systems. If your view of copyright were correct, a game
cartridge for a Nintendo would be a derivative work of the software in
the console unit, and would require Nintendo's permission to distribute.
--Tim Smith
jo...@dhh.gt.org
Kenneth Miller writes:
> In the first situation I describe, the program is most certainly a
> loaded work to function at all.
No. A 'derived work' is one which contains a copy of part or all of
another work (without qualifying as 'fair use'). 'Functionality' has no
relevance to copyright law. If I write words to your music I can
distribute those lyrics without your permission. Only the *combination* of
your music and my words is a derived work.
--
John Hasler This posting is in the public domain.
jo...@dhh.gt.org Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.
Barry Margolin
Regarding the interpretation of "any third party" in clause 3(b) of the GNU
GPL....
In article <6jc83u$e...@bourbon.cs.umd.edu>,
William C. Cheng <wil...@cs.umd.edu> wrote:
>But I doubt that this is the only legal interpretation! My suspecision
>is that it can interpreted as ``a person other than the principals that's
>involed in a transaction'' when it's put in the context of a transaction.
>
>X writes a piece of free software and put it under GPL. Y gets X's code
>and agreed to the terms of GPL. The principals are X and Y. Y derives
>work from X's code and sells derived work to Z. If Y uses the 2nd
>interpretation of ``third party'' above, Y has to offer source to Z and
>no one else.
>
>My question is if the 2nd interpretation can also be a legal definition.
>Does ``third party'' has to be interepreted without any context?
I think if the GPL authors had intended such a restricted interpretation,
they should have said so. If your interpretation were intended, they could
have said "the recipient" rather than "any third party". Based on their
choice to use the word "any", as well as the context established by the
Preamble and the GNU Manifesto, I think the intent of the GNU GPL is pretty
clear, and it would be ludicrous to try to interpret that clause so
restrictively.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Kenneth Miller
On Wed, 13 May 1998 16:15:14 GMT, jo...@dhh.gt.org wrote:
> Kenneth Miller writes:
> > In the first situation I describe, the program is most certainly a
> > derived work, in that the calling program relies on functionality in the
> > loaded work to function at all.
>
> No. A 'derived work' is one which contains a copy of part or all of
> another work (without qualifying as 'fair use'). 'Functionality' has no
> relevance to copyright law. If I write words to your music I can
> distribute those lyrics without your permission. Only the *combination* of
> your music and my words is a derived work.
OK, fine. This is less restrictive than the point I was originally
arguing. I'm all for fewer restrictions. But "contains" is a pretty
bloody ambiguous term when it comes to computer programs.
Isaac
In article <slrn6ljbmk....@hcs.harvard.edu>, Kenneth Miller wrote:
>> How would such an argument stand up if the offending program was
>> distributed in source form under a restrictive NDA?
>
>I'm not sure how this affects anything.
>
My point was that even if the arguments for a program and a linked library
being one complete infringing article were valid, certainly the arguments
would be more shaky when source code was distributed. The source code
of an offending program containing a few function calls to a GPL'd
library, even one that did all of the hard work, would contain so little
text related to the library that a fair use defense would be possible.
The exact license of the offending program would be irrelevant so I picked
the most proprietary one I could come up with on short notice.
>> Even though the technical arguments seem shaky, I don't see that the
>> FSF has any choice but to draw the line where they have. Microsoft
>> when in the same position can argue that you don't have all the rights
>> allowed under copyright law since you don't own a copy of their software
>> but have only licensed a copy. With GPL'd code this same line of argument
>> cannot be made. Only by calling an offending program derivative (or
>> a copy of course) do they have any say in how it is used. The alternative
>> is that anyone with some trivial steps could use GPL'd code in
>> proprietary software without distributing source and this would be bad.
>
>I don't see this. If people can reasonably make two pieces distinct,
>one their code, one GNU-derived, I see no reason they should be forced
>to do anything they don't want to do with the code they wrote. They
>still have to distribute the source to the GNU-derived portions,
>including whatever modifications they made. If the intent of the GPL is
I think one of the goals of the GPL is to encourage people to release
more freed code. The encouragement comes in the form of a base of GPL'd
code contributed by others that makes an attractive start for new GPL'd
programs. If people can circumvent the GPL by writing trivial interface
code or using some special compiler/linker options, then the GPL fails
at one of its objectives.
Isaac
Stephen Crane
pe...@jaka.ece.uiuc.edu (Steve Peltz) writes:
> In article <slrn6lgs14....@hcs.harvard.edu>,
> Kenneth Miller <kemi...@hcs.harvard.edu> wrote:
> >First off, add-ons -are- different from a standard dynamic library.
> >They do not share symbol tables, and run separately. I feel like I'm
> >repeating myself.
>
> Details are different, basic principle is the same. The add-on can call
> code in the main program; the main program can call code in the add-on,
> binding isn't done until run-time. If you think of it as a dynamic library
> with a separate name-space, would that satisfy your objections?
OK, now what is the difference between dynamic library bindings and OS
kernel bindings? Playing the devil's advocate here for a minute, if
there is no difference (and I can't see one) *and* if linking with a
dynamic library makes a program a derivative work of that library,
then it should be contrary to the GPL to release commercial software
for a GPL'd OS, such as Linux.
Someone please point out the flaw in my reasoning here; apologies if
I've missed something obvious.
-- Steve
Ronald Cole
Barry Margolin <bar...@bbnplanet.com> writes:
> I don't think so. If they're using this clause:
>
> 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
> 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; or,
>
> then they can't restrict the source code only to registered customers and
> developers. The above clause says "any third party".
ACT claims that the written offer has to accompany the request. That
is certainly a disincentive for a registered customer or developer to
give away their one opportunity to get the source to a third party.
--
Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412
Ronald Cole <ron...@forte-intl.com> Phone: (760) 499-9142
President, CEO Fax: (760) 499-9152
My PGP fingerprint: E9 A8 E3 68 61 88 EF 43 56 2B CE 3E E9 8F 3F 2B
Ronald Cole
kra...@gentle.best.com (Kragen Javier Sitaker) writes:
> No. The situation under discussion is Be distributing binaries and
> offering source separately. The GPL permits this, but only with the
> requirement that the source be available to *everyone* -- not just those
> to whom you gave binary copies -- and essentially at media cost.
Read it again. The source is to be made available only upon
presentation of a "written offer" and for a media and copying fee.
In other words: no shoes, no service.
Kenneth Miller
On 13 May 1998 11:59:24 -0700, Tim Smith wrote:
> Kenneth Miller <kemi...@hcs.harvard.edu> wrote:
> >> If I followed your post correctly, your first example was of a program
> >> using "strcat" from a library. You are arguing that such a program
> >> is a derived work under copyright law? I would need permission to
> >> distribute the source of such a program from the author of "strcat"?
> >
> >Yes.
> Uh, he asked two questions. "Yes" is the correct answer to the first
> question, but not the second. The *source* to a program that uses
> strcat is not a derivative work of the library, and so he needs no
> permission from the library author to distribute it. The *executable*
> produced by compiling that source and linking with the library is a
> derivative work of the library, and needs permission of the library
> copyright holder to be distributed.
Right. But if you distribute the binary, assuming the GPL you'd
have to make the source available too.
> >This is exactly my point. If the program -will- -fail- without the
> >presence of a (non-standard) other work, regardless of how it is
> >invoked, it can reasonably be considered derivative. Otherwise, no.
> There is nothing in copyright law in the United States to support that
> statement, and plenty of case law directly against it. For example, the
> major manufacturers of video game consoles want to control who writes
> games for their systems. If your view of copyright were correct, a game
> cartridge for a Nintendo would be a derivative work of the software in
> the console unit, and would require Nintendo's permission to distribute.
I'm talking about the GPL's notion of separate works. I.e. cases in
which programs work together but do not infect each other with the GPL.
If I'm wrong in that case, the GPL either has no teeth at all, or is
childishly restrictive, depending on which direction.
Isaac
In article <871ztxs...@yakisoba.forte-intl.com>, Ronald Cole wrote:
>Read it again. The source is to be made available only upon
>presentation of a "written offer" and for a media and copying fee.
>In other words: no shoes, no service.
>
>--
The GPL says the binary only distribution is provided with a written offer
to give the source to anyone. I don't see anything supporting requiring the
presentation of the written order before the third party demands their source.
If you can demonstrate that a GPL'd binary was distributed without source,
you can infer a right to the source.
I can see where it might be difficult in practice to demonstrate your right
to source without some cooperation by the person receiving the original
distribution. For example if you want me to install a GPL'd program on 1000
workstations at your place, I'd probably want to give you a few copies of the
source but 1000 binaries. I might not be able to convince you to even take
the source code. A third party could never verify this arrangement
was on the up and up without some help. Try to run a business this way with
lots of customers though and I'm sure someone will complain.
Are you aware of situations where the above has happened?
Isaac
Isaac
In article <slrn6lkc7v....@hcs.harvard.edu>, Kenneth Miller wrote:
>
>Right. But if you distribute the binary, assuming the GPL you'd
>have to make the source available too.
>
You might have to distribute source to avoid distributing a derived work,
but the source would not have to be distributed under GPL. This is an
important distinction.
Isaac
Russell Senior
>>>>> "Ronald" == Ronald Cole <ron...@yakisoba.forte-intl.com> writes:
Barry> I don't think so. If they're using this clause:
Barry> b) Accompany it with a written offer, valid for at least three
Barry> years, to give any third party, for a charge no more than your
Barry> cost of physically performing source distribution, a complete
Barry> machine-readable copy of the corresponding source code, to be
Barry> distributed under the terms of Sections 1 and 2 above on a
Barry> medium customarily used for software interchange; or,
Barry> then they can't restrict the source code only to registered
Barry> customers and developers. The above clause says "any third
Barry> party".
Ronald> ACT claims that the written offer has to accompany the
Ronald> request. That is certainly a disincentive for a registered
Ronald> customer or developer to give away their one opportunity to
Ronald> get the source to a third party.
I believe that a copy of the written offer is sufficient, so the
particular disincentive you cite is absent. Yes, here is the clause
from section 3:
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
So if you received a copy of the binary from someone without source
code, they are required to give you a copy of the written offer that
they themselves received from their provider. If you are receiving
the code in a commercial distribution, then your provider is obligated
to obtain the source for themselves and, at their option, provide to
you either the source or their own written offer of source.
My understanding is that the `any third party' in clause b) is
referring only to third parties in possession of a written offer or
some nth-generation copy of a written offer. I have yet to see anyone
convincingly refute this view, but if you can then please do.
--
Russell Senior
sen...@teleport.com
Leslie Mikesell
In article <873eeds...@yakisoba.forte-intl.com>,
Ronald Cole <ron...@yakisoba.forte-intl.com> wrote:
>> customarily used for software interchange; or,
>>
>> developers. The above clause says "any third party".
>
>ACT claims that the written offer has to accompany the request. That
>is certainly a disincentive for a registered customer or developer to
>give away their one opportunity to get the source to a third party.
I thought the interpretation was that anyone with the binary should
be able to get source (i.e. they have to get a copy of the offer
with the binaries). Also, redistribution of the binaries cannot
be restricted. In a 'small circle of friends' environment it may
be the case that everyone who has a purchased a copy of the binary
may choose not to resell or give away copies but they cannot be
restricted from doing so. However, in a mass market situation you
can pretty much count on the binaries being available everywhere,
and anyone with the binary should be able to request source.
Les Mikesell
l...@mcs.com
Leslie Mikesell
In article <slrn6li7mr....@hcs.harvard.edu>,
Kenneth Miller <kemi...@hcs.harvard.edu> wrote:
>>
>> Details are different, basic principle is the same. The add-on can call
>> code in the main program; the main program can call code in the add-on,
>> binding isn't done until run-time. If you think of it as a dynamic library
>> with a separate name-space, would that satisfy your objections?
>
>build time, something about what that specific library does, and depends
>on that behavior to function. I.e. if my program needs strcat or
>something like that, it loads the appropriate library and runs it; if
>the library isn't there or the wrong one is put in its place, the
>program cannot continue.
No it doesn't. Perl is perfectly capable of dlopen()'ing and
linking in dynamic libraries at runtime that were unknown at compile
time and it can use them through script modules possibly all written
by different people unaware of the restrictions on the shared libs
on your machine. Since there are GPL/non-GPL versions of many of
the same libraries and the glue linkages are made at install time
with whatever libs are already there it is impossible to know what
combination will result. But as a test case, consider someone who
writes a perl script that uses both the readline module and DBI/DBD
for a database interface. Now when someone installs this with one
of the commercial database DBD backends you will end up with an
illegal combination linked at runtime (GPLed readline plus a
commercial lib executing in the same program). It isn't illegal
to *use* such a combination, but can the components be distributed
and who is responsible for the problem if there is one?
Les Mikesell
l...@mcs.com
Anselm Lingnau
In article <rjn2cog0qu.fsf@zuse.+dina.kvl.dk>,
Per Abrahamsen <abr...@dina.kvl.dk> wrote:
> I believe this is the situation on most of continental Europe.
As far as I am aware the situation in Germany is about the same.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
All [NT] seems to offer [compared to Unix] is the ability to run Excel and
Word, which seem to be an expensive way to do what can be done better and
cheaper with Fortran and LaTeX. --- Johann A. Hibschman
William C. Cheng
In article <H6o61.36$EA.11...@cam-news-reader1.bbnplanet.com>,
Barry Margolin <bar...@bbnplanet.com> wrote:
>Regarding the interpretation of "any third party" in clause 3(b) of the GNU
>GPL....
>
>In article <6jc83u$e...@bourbon.cs.umd.edu>,
>William C. Cheng <wil...@cs.umd.edu> wrote:
>>But I doubt that this is the only legal interpretation! My suspecision
>>is that it can interpreted as ``a person other than the principals that's
>>involed in a transaction'' when it's put in the context of a transaction.
>>
>>X writes a piece of free software and put it under GPL. Y gets X's code
>>and agreed to the terms of GPL. The principals are X and Y. Y derives
>>work from X's code and sells derived work to Z. If Y uses the 2nd
>>interpretation of ``third party'' above, Y has to offer source to Z and
>>no one else.
>>
>>My question is if the 2nd interpretation can also be a legal definition.
>>Does ``third party'' has to be interepreted without any context?
>
>I think if the GPL authors had intended such a restricted interpretation,
>they should have said so. If your interpretation were intended, they could
>have said "the recipient" rather than "any third party". Based on their
>choice to use the word "any", as well as the context established by the
>Preamble and the GNU Manifesto, I think the intent of the GNU GPL is pretty
>clear, and it would be ludicrous to try to interpret that clause so
>restrictively.
If X writes a piece of free software and put it under GPL. Y gets X's
code. Then Y would be the recipient! So using "the recipient" would
not have the correct meaning there.
I agree that the word "any" there should be interpreted without context.
If that's the case, how come some companies can get away with only
having to give source code of derived work to customers who pay for the
binaries? Don't they have to give source code of derived work to
"anybody" who asks for it?
Timothy Philip Vernum
wil...@cs.umd.edu (William C. Cheng) writes:
>If that's the case, how come some companies can get away with only
>having to give source code of derived work to customers who pay for the
>binaries? Don't they have to give source code of derived work to
>"anybody" who asks for it?
It depends upon how they do it.
It is legal to distribute your source ONLY with your binaries.
If anyone asks you for a copy of the source, you can refuse.
(3a of the GPL)
But anyone who gets copies of your binaries and source may then distribute
the source if they wish.
So no, the don't have to give the code to anyone who asks. They must either
[a] give the source code with the binary.
OR
[b] give the source code to anyone who asks
OR
[c] tell them where they can get the source ( only applicable of the
binary being re-distributed was received via point [b] )
So in the case in question, Be could restrict the source to its customers only
if it shipped it on the CD, but then it couldn't stop the recipients of the
CDs from offering the source publically.