[Q] GPL violation.
Paco Moya
It was about a device driver for a frame grabber which could be
dynamicaly linked with Linux or statically linked with it.
Some people, namely Linus himself, stated that it was fair use of
the GPL'd code (the kernel) because no line of code was apparently
used and the driver was independent enough.
I'm not a lawyer but I cannot accept this interpretation of code reuse.
A device driver is not in any way independent of the kernel with which
it interacts. I'm not talking about interface copyright or patents but
about logical dependance.
We're about to release a GPL'd library written in C++ using libdl for
easy expansion in runtime. The library implements a base class Filter
which provides support for making instances of derived classes loaded
in runtime. It sounds similar to the case of the proprietary driver
but we do not want proprietary Filters derived from our library.
Dynamic linking is just a special case but object oriented development
is a more general case where derived work don't actually use a single
line of code from libraries but use them. Why bother to write LGPL if
anybody may make works derived from GPL'd code without distributing
sources? If the legal interpretation of GPL allows such behaviours there
is no need for LGPL at all.
I don't know what does the GPL or Copyright law consider a derived work.
Could anyone explain wheather the GPL would allow proprietary classes
derived from a GPL'd class? Does dynamic linking make difference?
Thanx a lot,
Paco. fm...@die.upm.es
pa...@neptuno.die.upm.es
Ingemar Hulthage
Paco Moya (paco@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN) wrote:
...
> We're about to release a GPL'd library written in C++ using libdl for
> easy expansion in runtime. The library implements a base class Filter
> which provides support for making instances of derived classes loaded
> in runtime. It sounds similar to the case of the proprietary driver
> but we do not want proprietary Filters derived from our library.
Why not ? What are the goals that your are trying to accomplish by
allowing everyone to copy your code ? Are you sure that it would be
in conflict with your goals if somebody made a proprietary enhancement
to it ?
> Dynamic linking is just a special case but object oriented development
> is a more general case where derived work don't actually use a single
> line of code from libraries but use them. Why bother to write LGPL if
> anybody may make works derived from GPL'd code without distributing
> sources?
I'm not sure this answers your question, but it is legal to create
derivative work of GPL code and not distribute it at all, in any form.
This is, in my opinion, an undesirable consequence of the GPL. Since
it is impossible to retain exclusive rights to derivative works, some
such work might not be distributed at all, commercially or otherwise.
> I don't know what does the GPL or Copyright law consider a derived work.
I'm not an attorney, but I believe that a derived work is anything
that contains parts of another work in verbatim, but also paraphrased
or translated in some way.
Ingemar Hulthage
Ajit George
: paco@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Paco Moya) writes:
: >Some people, namely Linus himself, stated that it was fair use of
: >the GPL'd code (the kernel) because no line of code was apparently
: >used and the driver was independent enough.
: >I'm not a lawyer but I cannot accept this interpretation of code reuse.
: I'm not a lawyer either, but ...
: Doesn't matter. As the copyright owner Linus is free to grant extra
: permissions beyond what the GPL allows, so even if you're right, Linus's
: word goes.
That's assuming that the word in question was written into the license
distributed with the code. Linus can't make new wishes apply
retroactively.
Oh yeah, I'm not a lawyer either. Just picking nits.
Has anyone taken a case of GPL violation to court? We can speculate
all we like about technicalities of the GPL, but if some judge gets up
on his bench one day and says the whole thing is as worthless as the
paper it's printed on (or not, as the case may be), then the points
are all moot.
Ajit
Joe Buck
Check the above. -^
>Some weeks ago I posted an article on a probable violation of the GPL.
>It was about a device driver for a frame grabber which could be
>dynamicaly linked with Linux or statically linked with it.
>
>Some people, namely Linus himself, stated that it was fair use of
>the GPL'd code (the kernel) because no line of code was apparently
>used and the driver was independent enough.
>I'm not a lawyer but I cannot accept this interpretation of code reuse.
I'm not a lawyer either, but ...
Doesn't matter. As the copyright owner Linus is free to grant extra
permissions beyond what the GPL allows, so even if you're right, Linus's
word goes. (Some other person who's written a major piece of the kernel
would have standing to object, perhaps, but their case would be questionable).
>A device driver is not in any way independent of the kernel with which
>it interacts. I'm not talking about interface copyright or patents but
>about logical dependance.
How would you prove infringement when the alleged infringer is not
distributing even one line of GPL'ed code, and is using standard,
documented interfaces? This is the user-does-the-link question again,
but in the NeXT case (the Objective-C compiler) they were going to alter
gcc to fit with their piece, rather than just use a standard interface,
so I think that the law could make a distinction.
>We're about to release a GPL'd library written in C++ using libdl for
>easy expansion in runtime. The library implements a base class Filter
>which provides support for making instances of derived classes loaded
>in runtime. It sounds similar to the case of the proprietary driver
>but we do not want proprietary Filters derived from our library.
The GPL would protect you against anyone distributing a binary containing
both your code and their code, unless they put their code under the GPL.
If your header files do inline functions, they wouldn't be able to
compile their code separately and claim they aren't violating your
copyright, since it would be a derivative work of the header file.
>Could anyone explain wheather the GPL would allow proprietary classes
>derived from a GPL'd class? Does dynamic linking make difference?
They can write the source. If they compile the source, the object
file will be a derivative work of both their source and your header
file. They can't distribute the object without your permission.
They can't distribute a binary that links them both together.
They *could* distribute the *source* without your permission, it
seems, though the user-does-the-link flames will start when we
talk about this. (There was a big stink about use of the GNU MP
library with RIPEM on this subject).
Note that copyright doesn't treat derived classes in C++ any differently
from, say, a class that had your class as a member. Don't let the
term "derived class" confuse you, it has nothing to do with "derivative
work".
--
-- Joe Buck <jb...@synopsys.com> (not speaking for Synopsys, Inc)
Linus Torvalds
Paco Moya <paco@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN> wrote:
>Some weeks ago I posted an article on a probable violation of the GPL.
>It was about a device driver for a frame grabber which could be
>dynamicaly linked with Linux or statically linked with it.
>
>Some people, namely Linus himself, stated that it was fair use of
>the GPL'd code (the kernel) because no line of code was apparently
>used and the driver was independent enough.
>
>I'm not a lawyer but I cannot accept this interpretation of code reuse.
>it interacts. I'm not talking about interface copyright or patents but
>about logical dependance.
Note that there is no such thing as "dynamically link into the kernel"
in linux. Instead there are "loadable modules".
Now the above may strike some people as nit-picking, but there is one
rather important thing about loadable modules: they can _not_ link
themselves against any random kernel routine. And the routines they
_can_ link against are routines that I consider to be "logically
independent" of the kernel implementation.
Essentially, the kernel module interface is a "library" interface to the
kernel, and kernel modules are considered to be under the GNU _Library_
license. In fact, due to the way kernel modules work, you automatically
do it according to the LGPL so this isn't explicitly stated anywhere,
but that's the way you should think about this.
Another way to look at this - using the legal rather than the moral
viewpoint - is to just see module loading as "use" of the kernel, rather
than as linking against it. I prefer to explain the rationale behind it
using the _moral_ reason to do it, though.
The reason the kernel is exposed in such a LGPL'd way when using modules
is simply that there are a lot of kernel device drivers for unix
available, and they were not all written under linux. If somebody wants
to port his SVR4 driver to linux but doesn't want to GPL it, I feel that
he should have the right to do that, using modules. After all, the
driver wasn't actually derived from linux itself: it's a real driver in
its own right, so I don't feel that I have the moral right to force him
to switch copyrights.
Now, the above said, I _much_ _much_ prefer GPL'd drivers, even if they
are available only as modules. Especially if they were actually
originally written _for_ linux, I consider it a bit dodgy to not use the
GPL (they can potentially be considered derived works even if you don't
actually link them into the kernel per se). But I do not want to force
it on people that arguably are _not_ doing derived work (it would be
rather preposterous to call the Andrew FileSystem a "derived work" of
linux, for example, so I think it's perfectly ok to have a AFS module,
for example).
For several reasons a linux module also doesn't always make much sense
unless it comes with sources - if some commercial company thinks that
linux is important enough that they want to do a commercial module for
linux, they may also recognize that a binary module doesn't work for
most linux users who use experimental kernels, for example.
Final note: the linux interpretation is not a "normal" case. I wouldn't
use it as a guide-line to anything else, especially not in user mode.
Linus
Francisco Moya Fernandez
: Paco Moya (paco@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN) wrote:
: ...
: > We're about to release a GPL'd library written in C++ using libdl for
: > easy expansion in runtime. The library implements a base class Filter
: > which provides support for making instances of derived classes loaded
: > in runtime. It sounds similar to the case of the proprietary driver
: > but we do not want proprietary Filters derived from our library.
: Why not ? What are the goals that your are trying to accomplish by
: allowing everyone to copy your code ? Are you sure that it would be
: in conflict with your goals if somebody made a proprietary enhancement
: to it ?
: > Dynamic linking is just a special case but object oriented development
: > is a more general case where derived work don't actually use a single
: > line of code from libraries but use them. Why bother to write LGPL if
: > anybody may make works derived from GPL'd code without distributing
: > sources?
: I'm not sure this answers your question, but it is legal to create
: derivative work of GPL code and not distribute it at all, in any form.
: This is, in my opinion, an undesirable consequence of the GPL. Since
: it is impossible to retain exclusive rights to derivative works, some
: such work might not be distributed at all, commercially or otherwise.
: > I don't know what does the GPL or Copyright law consider a derived work.
: I'm not an attorney, but I believe that a derived work is anything
: that contains parts of another work in verbatim, but also paraphrased
: or translated in some way.
: Ingemar Hulthage
--
----------------------------- Escuela Tecnica Superior
Francisco Moya Fernandez de Ingenieros de Telecomunicacion.
pa...@neptuno.die.upm.es Universidad Politecnica de Madrid.
Francisco Moya Fernandez
Ingemar Hulthage (hult...@hollywood.cinenet.net) wrote:
> Paco Moya (pa...@neptuno.die.upm.es) wrote:
> >...
> > but we do not want proprietary Filters derived from our library.
> Why not ? What are the goals that your are trying to accomplish by
> allowing everyone to copy your code ?
I'll quote the GNU Manifesto:
I consider that the golden rule requires that if I like a program I
must share it with other people who like it. Software sellers want to
divide the users and conquer them, making each user agree not to share
with others. I refuse to break solidarity with other users in this
way. I cannot in good conscience sign a nondisclosure agreement or a
software license agreement.
At least another paragraph applies here:
All intellectual property rights are just licenses granted by
society because it was thought, rightly or wrongly, that society as a
whole would benefit by granting them. But in any particular
situation, we have to ask: are we really better off granting such
license? What kind of act are we licensing a person to do?
> Are you sure that it would be in conflict with your goals if somebody
> made a proprietary enhancement to it ?
Yes. I don't see any good reason to distribute it under a less
restrictive license (such as LGPL). If you don't care whether other
people make proprietary enhancements then you probably don't care
whether it is distributed under the GPL or not. The same benefits you
obtain from GPL'd code are retained by not allowing proprietary
enhancements.
> I'm not sure this answers your question, but it is legal to create
> derivative work of GPL code and not distribute it at all, in any form.
I can't avoid that. But I am able to avoid proprietary enhancements.
> This is, in my opinion, an undesirable consequence of the GPL. Since
> it is impossible to retain exclusive rights to derivative works, some
> such work might not be distributed at all, commercially or otherwise.
It is not undesirable for me in any way. When a program is distributed
under the GPL those consequences are just the intention of the author.
Francisco Moya Fernandez
> paco@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Paco Moya) writes:
> Check the above. -^
Sorry, I think it's already fixed :)
> Doesn't matter. As the copyright owner Linus is free to grant extra
> permissions beyond what the GPL allows, so even if you're right,
> Linus's word goes.
I don't object to Linus' words. But I think Linus' interpretation of
the GPL is exactly my interpretation of the LGPL.
> How would you prove infringement when the alleged infringer is not
> distributing even one line of GPL'ed code, and is using standard,
> documented interfaces?
I'm not a lawyer. But the need to link the library (or the kernel, or
any piece of software) to make a running binary should be enough.
> The GPL would protect you against anyone distributing a binary
> containing both your code and their code, unless they put their code
> under the GPL.
When the GPL'd code supports dynamic linking users may develop
derivatives without even recompiling original sources. Would be legal
distributing full sources for my library and their libraries in binary
form?
> If your header files do inline functions, they wouldn't be able to
> compile their code separately and claim they aren't violating your
> copyright, since it would be a derivative work of the header file.
It would be trivial to outline inlines at a small (or not so small but
affordable) performance loss.
> They can write the source. If they compile the source, the object
> file will be a derivative work of both their source and your header
> file. They can't distribute the object without your permission.
> They can't distribute a binary that links them both together.
It sounds to me like interfaces copyright. No hope :)
> Note that copyright doesn't treat derived classes in C++ any
> differently from, say, a class that had your class as a member.
> Don't let the term "derived class" confuse you, it has nothing to do
> with "derivative work".
If derived classes are not considered derivative works by the
copyright law any software system developed with good OO methods and
with reusability in mind might be used by anyone by adding a subsystem
for dynamic linking. Well, I don't actually know whether dynamic
linking cares or not but it is a way not to include original code in
the distributed binary.
In proprietary software industries there is no much difference in
making derivative works by including other people's code or by using
it because each copy of the derived software will bring money to the
original copyright holder anyway. For free software authors it means
proprietary software companies may distribute derivatives just
including the source for the original program.
Paco
Mike Stump
Paco Moya <paco@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN> wrote:
>A device driver is not in any way independent of the kernel with which
>it interacts.
What if the driver works with Linux, FreeBSD, NetBSD and Mach? What
if the driver only works with Linux today, but tomorrow it works with
another independent kernel?
>we do not want proprietary Filters derived from our library.
Put it in your licence, if you want. No one forces you to use the
GPL as is. The text of the GPL is public domain, if I recall.
>Dynamic linking is just a special case but object oriented development
>is a more general case where derived work don't actually use a single
>line of code from libraries but use them. Why bother to write LGPL if
>anybody may make works derived from GPL'd code without distributing
>sources? If the legal interpretation of GPL allows such behaviours there
>is no need for LGPL at all.
>
>I don't know what does the GPL or Copyright law consider a derived work.
What GPL or rms, or the FSF thinks is a derived work, is pretty
irrelevant. What matters is what a court has said, or what the PTO
has said. Rms has stated things in the past (RIPEM) that I do not
agree with in this respect.
>Could anyone explain wheather the GPL would allow proprietary classes
>derived from a GPL'd class? Does dynamic linking make difference?
I like the statement:
If to use something, the use of that something requires an interface,
merely using the required interface does not by itself create a
derived work.
There is some support for this in law. There is also bound to be some
non-support for this in law. It may have to be litigated to be
resolved for any particular instance of it. Sorry, welcome to the US
legal system.
Michael I. Bushnell, p/BSG
I will agree, in the general case, he cannot. For example, he cannot
now say, all people must now pay me $100 to have it, or they must
remove it. But, when considering granting extra rights to people, yes
he can. He can also put totally new terms on it, like say, you must
pay $100 for each copy you have, and enforce it, but that would not
apply to old copies, only new copies.
Let me point out, lest anyone get scared, that in the case of the FSF
this kind of thing would be impossible.
Nearly all GNU software was contributed by its authors to the FSF.
(That's why the copyright is in the name of the FSF.) They did so by
signing a contract with the FSF, which grants the FSF the copyright,
but prohibits the FSF from doing distribution under any but free
software terms.
That means that the FSF is contractually bound, to *jillions* of
people, in a way that prevents it from hoarding software in the
future.
Even if you trust the FSF board, this is still a good thing, because
if the FSF loses a lawsuit someday and its assets are seized by Big
Bad Nasty Software, Inc., then BBNS can't distribute it under non-free
software terms, so it still remains free.
Michael
Steve Dunham
: Joe Buck (jb...@synopsys.com) writes:
: > paco@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Paco Moya) writes:
: > Check the above. -^
: Sorry, I think it's already fixed :)
: > Doesn't matter. As the copyright owner Linus is free to grant extra
: > permissions beyond what the GPL allows, so even if you're right,
: > Linus's word goes.
: I don't object to Linus' words. But I think Linus' interpretation of
: the GPL is exactly my interpretation of the LGPL.
So what's the difference between loading a kernel module and loading
an executable file?
Steve
dun...@gdl.msu.edu
Mike Stump
Ajit George <ga...@cs.utexas.edu> wrote:
>Joe Buck (jb...@synopsys.com) wrote:
>: Doesn't matter. As the copyright owner Linus is free to grant extra
>: permissions beyond what the GPL allows, so even if you're right, Linus's
>: word goes.
>
>retroactively.
As copyright holder, yes he can (in this case). You fail to
understand basic copyright law.
Terry Lambert
] If derived classes are not considered derivative works by the
] copyright law any software system developed with good OO methods and
] with reusability in mind might be used by anyone by adding a subsystem
] for dynamic linking. Well, I don't actually know whether dynamic
] linking cares or not but it is a way not to include original code in
] the distributed binary.
There is, in fact, a significant difference between loading a
kernel module and dynamic linking against a shared library.
As the original author of the BSD LKM mechanism (and as the
autor of a BSD shared library mechanism in June of 93, which
was unfortunately rendered undistributable), I am *very* familiar
with the ideas involved in both.
The difference is that in a loaded kernel module, the module
symbols are all imported at load time. In the shared library
case, typically the data symbols are imported at link time,
and the text is imported at load time.
That is, the static data referenced by the library itself and
the agregate initialized data for the library are seperate.
For kernel modules, this means that proprietary driver modules
can be loaded into a GPL kernel, but that a GPL kernel can not
be distributed with them statically linked in unless you can
also distribute the driver source (this is a pain in the butt
if it happens to be your disk driver).
Similarly, it means that GPL'ed drivers can be loaded into a
non-GPL'ed kernel, but that the resulting kernel can not be
distributed if you don't also distribute the sources AND the
license is non-conflicting with the GPL (specifically, no
additional caluses, like the BSD "credit clause"). This is
also a pain in the butt if it happens to be your disk driver.
Actually, if the kernel itself was LGPL'ed, then the LGPL relink
clause would apply, and you would be fine with the commercial
driver, as long as you distributed it as a linkable .o file. I
have asked about this several times with regard to Linux, but
the overhead of changing distribution terms now that there are
so many contributors means that it's unlikely the Linux could
be shipped with commercial disk drivers without an impossible
amount of effort.
If the drivers were LGPL'ed, then the non-GPL'ed kernel could
be linked with the LGPL'ed drivers, as long as a link kit was
provided (and source for the LGPL'ed drivers, of course). This
would have the effect of making use of LGPL'ed drivers possible
under SCO, UnixWare, FreeBSD, and other OS's that have
conflicting clauses or choose a binary distribution format, and
since the drivers themselves are under LGPL, the improvement and
source provision clauses protect their "freedom" (in the GNU
sense of the word). I've asked about this several times as well,
also with no success.
Now shared libraries (dynamic linking):
The LGPL requires that the user be able to replace the library
with an updated version (this is the "relink clause" of the LGPL).
It turns out that dynamic linking, as implemented by most shared
library technologies, doesn't meet the terms of the LGPL. In
specific: it is not possible to replace a shared library with
another in certain circumstances.
Consider the library function "fooinit":
char namebuf[ 8];
void
fooinit( char *name)
{
if( namebuf[ 0])
return;
strncpy( namebuf, name, sizeof( namebuf));
namebuf[ sizeof( namebuf) - 1 ] = 0; /* maybe truncate*/
}
In the next rev of the library, this has been changed to
char namebuf[ 32];
[ ... ]
Now, using the new library with the old data (*exactly* what
happens with shared libraries, since the data is stored with
the post-link binary instead of in the library) could result
in a segmentation violation, and if it doesn't, it *will* result
in semi-random data corruption.
A program using a shared library that implements sharing this
way (the way Linux and FreeBSD and NetBSD and SunOS and SVR4
and Solaris and ... currently do) can not be said to comply with
the terms of the relink clause of the LGPL.
So if we go back to our kernel, we see that the GPL'ed kernel
fails this case with a *dynamically linked* module, but not
with a *loaded* module.
The same failure occurs in the BSD case using an LGPL'ed driver:
if it is *dynamically linked*, then like the application linked
with the LGPL'ed shared library, it can't guarantee that future
versions of the library will be usable (without a full link kit
even in the LGPL'ed case).
So Linus' "nitpick" (see his posting in this thread) is
*exactly* right, and he is *exactly* correct about where the
distinction needs to be drawn in the "GPL'ed kernel with
commercial driver" case.
Terry Lambert
te...@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Joe Buck
Ajit George <ga...@cs.utexas.edu> wrote:
>>That's assuming that the word in question was written into the license
>>distributed with the code. Linus can't make new wishes apply
>>retroactively.
m...@kithrup.com (Mike Stump) writes:
>As copyright holder, yes he can (in this case). You fail to
>understand basic copyright law.
Or rather, yes he could if he were the sole copyright owner. At present,
though, only about half the code in the Linux kernel was written by Linus
Torvalds; most of the device drivers as well as some pieces of the kernel
itself were written by others, and they did not assign copyright to Linus
(as the FSF asks its contributors to do), so the whole group of people
would have to agree before conditions on the code could change.
For a list, see the CREDITS file in the kernel distribution.
H.J. Lu
In this case, I would call it a bug. To me it is the same as you
change the API/ABI. When you do that, the old programs may fail
no matter if static or dynamic link, nor the source code is provided
or not. You have to change something to get the old programs working
again with the new library.
H.J.
Craig Milo Rogers
legal advice.]
In article <4aprrr$7...@sanson.dit.upm.es> paco@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Paco Moya) writes:
>I'm not a lawyer but I cannot accept this interpretation of code reuse.
>A device driver is not in any way independent of the kernel with which
>it interacts. I'm not talking about interface copyright or patents but
>about logical dependance.
Your furtune cookie reads: Learn to be more accepting about
those things you cannot change. :-)
Copyright infringement and "logical dependance", by which I
presume you mean runtime execution dependence, are two different
things. In analogy: copyright violation applies to compiletime macro
expansion, not runtime subroutine calls. In other words, if one
program looks like a compiletime macro translation of another, than a
Copyright infringement might have occured. If one program happens to
make runtime calls to a second program without a
macro-translation-like relationship, than there is no Copyright
infringement. In general, a "use" which isn't "source reuse"
(allowing for the ill-defined term "translation") isn't a Copyright
infringement (at present).
For the specific case of a kernel device driver, it *is*
possible to write device drivers with "OS-dependent" and
"OS-independent" parts, although it may be economically justifiable
only when you can hide critical information (eg, register definitions
or bootstrap code) inside the "OS-independent" part. If you make the
first OS-dependent part for a non-GPLed OS, then create the
OS-dependent part for your target GPLed OS, your OS-independent part
is clearly independent of the GPLed OS, per the usual interpretation
of Copywrite law. QED.
It becomes an exercise in nitpicking as to whether you can
non-infringingly distribute, say, a CDROM with: 1) a binary image of
the GPLed OS kernel with your driver linked in, 2) sources to the
GPLed OS, 3) sources to your OS-dependent driver code for this GPLed
OS, and 4) no sources to your OS-independent driver code. It would
probably require a court precedent to establish this one way or
another.
It certainly seems reasonable that you could non-infringingly
distribute a CDROM with: 1) a binary image of the GPLed OS kernel
without your driver linked in, 2) sources to the GPLed OS, 3) a binary
image of your driver as a loadable driver, 4) sources to the
OS-dependent part, and 5) no sources to the OS-independent part. The
situation becomes a little more interesting if this CDROM were to
contain a batch file to *automatically* load the partially-secret
driver into the GPLed OS kernel. Some people have claimed that this
constitutes a de-facto distribution the combined, linked image; I do
not subscribe to that interpretation, as it violates causality. :-)
Referring to Linux specifically, recent kernels have changed
the device driver initiallization process. I believe that these
changes increase the similarity between Linux device drivers and those
of other protected-mode POSIX-like OSes. This should simplify the
task of creating a device driver that is split into OS-dependent and
OS-independent parts, and developing the OS-dependent part for Linux.
Now, in terms of actual practice... if I were facing a market
choice between buying a product with a two-part driver (half of which
were secret, as described above), and buying a product with a
single-part driver (entirely available in free source code), and all
other things were equal... I'd choose the free-source-code product, of
course! If other things weren't equal... I'd still want to choose the
free-source-code product, but I'd try to estimate the economic
tradeoffs first.
In other words, my advice is: know that you can do it, but
please refrain from doing so. :-)
...
>Dynamic linking is just a special case but object oriented development
>is a more general case where derived work don't actually use a single
>line of code from libraries but use them. Why bother to write LGPL if
>anybody may make works derived from GPL'd code without distributing
>sources? If the legal interpretation of GPL allows such behaviours there
>is no need for LGPL at all.
I've argued this position (GPL implies LGPL) in the past.
Again, it is critical to remember that copyright law adresses
"inclusion" (and "translation"), but not "use" (in the non-textual
sense). And again, "conceptual derivation" and "textual derivation"
are two separate matters.
>I don't know what does the GPL or Copyright law consider a derived work.
Then this is where you should concentrate your studies, as it
is essential to have a firm concept of this distinction before
embarking upon debate.
>Could anyone explain wheather the GPL would allow proprietary classes
>derived from a GPL'd class? Does dynamic linking make difference?
Maybe, and yes. There are already court decisions that imply
that the critical content in header files which allows class
derivation to be performed is not subject to Copyright restrictions.
The essential philosophy is that you cannot copyright a verifiable
fact (such as telephone number, but presumably also an offset into a
data structure), only the creative expression in which you present the
fact. However, this is a rather subtle distinction, and court
precedents and legislative action could easily change the situation.
Dynamic linking certainly makes a difference, since static
linking incorporates textual material from multiple sources and
translates it, clearly raising grounds for Copyright infringement,
while dynamic linking attempts to limit textual inclusions to
interface definitions, which may-or-may-not create a Copyright
problem.
You cannot copywright a fact. You can't patent facts, either.
However, you can patent applications of a fact, at least, in the US.
This appears to be a legal basis for using a software patent to
protect an interface, and, hence a logical but non-textual derivation.
Craig Milo Rogers
Terry Lambert
] |> Consider the library function "fooinit":
[ ... ]
] In this case, I would call it a bug. To me it is the same as you
] change the API/ABI. When you do that, the old programs may fail
] no matter if static or dynamic link, nor the source code is provided
] or not. You have to change something to get the old programs working
] again with the new library.
No. I could relink the program objects vs. the new LGPL'ed library,
and it would continue to work.
The problem is that in the prelinked data case, the data/code
abstration for the codified interface has not changed.
We are, in fact, not discussing a library interface change at
all. Unless you are definiing the data provided by the library
and referenced only by the library as part of the interface.
In which case dynamic linking still fails the relink test in LGPL.
This is all real ancillary to the discussion of kernel modules
being loaded as a unit vs. their being dynamically loaded, since
both Linus and I have made clear that the technique in both the
Linux and BSD cases is to load it as a unit, data and all.
I'm quite content to wait for the shared library/relink issue to
be clarified by the FSF (since the LGPL never specifically
mentions data vs. code linking and takes no explicit notice of
shared library technology whatsoever).
Regards,
Michael I. Bushnell, p/BSG
Put it in your licence, if you want. No one forces you to use the
GPL as is. The text of the GPL is public domain, if I recall.
Actually, it's not. It's copyright by the FSF and can only be
distributed if you don't modify it. This is essential to the ability
to use it as a "subroutine". This is the only way to make sure there
is only one thing called the "GNU General Public License".
I think that if you modify it, but clearly call it something else,
there is no problem. But I'm not sure exactly what the rules are.
Michael
John S. Dyson
of GPL. The people that use it often don't understand it very well. This
is not meant as an insult, but this thread scares me further from GPL.
As the proprietor of a small company, this increases my legal expense/exposure.
The license itself is so complex, that the net-wisdom does not seem to converge.
I guess that I'll read it again and try not only to understand the words
said, but any second-order ramifications.
John Dyson
Jimen Ching
>In article <MIB.95De...@gnu.ai.mit.edu>,
>Michael I. Bushnell, p/BSG <m...@gnu.ai.mit.edu> wrote:
>>In article <DJrxt...@kithrup.com> m...@kithrup.com (Mike Stump) writes:
>> Put it in your licence, if you want. No one forces you to use the
>> GPL as is. The text of the GPL is public domain, if I recall.
>>there is no problem. But I'm not sure exactly what the rules are.
>It is *exactly* this kind of statement that makes me even more fearful
>of GPL. The people that use it often don't understand it very well.
Or maybe you do not understand the GPL at all? I've read almost all
permutation of this GPL debate. The only conclusion I can make is that
the people who say the GPL is against commercializing software, does not
understand what the GPL *means* at all.
You say you *read* what the GPL *says*. Fine, but do you understand
what the GPL means? Do you understand the concept of 'software as a
product' vs. 'software as a service'? This is what the GPL *means*.
Through all of the threads that I have read, not one single person
used these two concepts. You say GPL does not allow *commercial use*
of GPL'ed software. Exactly what does that mean? GPL *says* that
source code must be available! How does that affect commercial use?
Do you mean that Walnut Creek can not sell their CDROM's? Or is that
not part of your definition of *commercial use*?
If you don't know by now. What I am implying in this article is that
there is no such thing as *commercial use*. Software is not a product
to be sold or traded. Software is like the procedure for 'heart bypass
surgery'. Once you learned it, you should be able to use it for the
rest of your life. Just like it doesn't make sense to sell the procedure
for 'heart bypass surgery', it doesn't make sense to sell source code.
So what is sold then? What is sold is the skills of the surgeon. Just
like what Cygnus is selling is not software, but the skills of its
software engineers.
This is what the GPL is all about. If you do not believe in this, then
GPL is not for you. But anyone who believe in this philosophy, doesn't
need to understand what the GPL *says*. All they need to know is that
the GPL is what they need to make the above work!
--jc
P.S. Maybe people should stop reading the GPL. They should instead
read the Manifesto. If they believe in the concepts in the Manifesto,
then they should use the GPL. But under no circumstance should anyone
read the GPL. Especially if they're not a lawyer.
--
Jimen Ching (WH6BRR) jch...@aloha.com wh6...@uhm.ampr.org
John S. Dyson
>John S. Dyson (ro...@dyson.iquest.net) wrote:
>>In article <MIB.95De...@gnu.ai.mit.edu>,
>>Michael I. Bushnell, p/BSG <m...@gnu.ai.mit.edu> wrote:
>>>In article <DJrxt...@kithrup.com> m...@kithrup.com (Mike Stump) writes:
>>> Put it in your licence, if you want. No one forces you to use the
>>> GPL as is. The text of the GPL is public domain, if I recall.
>>>I think that if you modify it, but clearly call it something else,
>>>there is no problem. But I'm not sure exactly what the rules are.
>>It is *exactly* this kind of statement that makes me even more fearful
>>of GPL. The people that use it often don't understand it very well.
>
>Or maybe you do not understand the GPL at all? I've read almost all
>permutation of this GPL debate. The only conclusion I can make is that
>the people who say the GPL is against commercializing software, does not
>understand what the GPL *means* at all.
>
(The users of the software, as I DO NOT DEVELOP GPL'ed software) have
the right to use it.
>
>of GPL'ed software. Exactly what does that mean? GPL *says* that
>source code must be available! How does that affect commercial use?
>Do you mean that Walnut Creek can not sell their CDROM's? Or is that
>not part of your definition of *commercial use*?
>
You obviously misunderstand -- you are taking one example of commercial
use and inferring that all other types of use are valid according to the license
and they are not. Your example is simply fallacious.
>
>This is what the GPL is all about. If you do not believe in this, then
>GPL is not for you. But anyone who believe in this philosophy, doesn't
>need to understand what the GPL *says*. All they need to know is that
>the GPL is what they need to make the above work!
>
>P.S. Maybe people should stop reading the GPL. They should instead
>read the Manifesto. If they believe in the concepts in the Manifesto,
>then they should use the GPL. But under no circumstance should anyone
>read the GPL. Especially if they're not a lawyer.
>
Oh my gosh!!! REMEMBER, the GPL is the license that YOU MUST OBEY to
use the software. Very little outside of the license is important (as you risk
legal action if you do not abide by what the GPL says.) I for one am
not willing to be dependent on the whims of some software developer
somewhere when he *thinks* that I have violated his license, even though
I *feel* that I understand other supporting documents.
I guess I just won't read the license and be all touchy feely and trust
that I am one with the one true GPL god :-). That is NOT the way to
do business... It is apparent to me that there is a community of people
out there who do not understand the risks taken by not reading contracts
carefully. And after reading them, I am convinced that these people
COULD not understand the side-effects of the agreements that they are taking
on. It is a sorry state of affairs...
The only valid discussion that I can see on this subject is to discuss the
terms and requirements of the GPL. It is also valid to compare GPL vs. BSD
vs. Artistic, ad nauseum... Other supporting documents are interesting
BUT NOT THE AGREEMENT(S) THAT YOU MUST ADHERE TO...
John Dyson
Paul D. Smith
%% ro...@dyson.iquest.net (John S. Dyson) writes:
jsd> In article <MIB.95De...@gnu.ai.mit.edu>,
jsd> Michael I. Bushnell, p/BSG <m...@gnu.ai.mit.edu> wrote:
>> Actually, it's not. It's copyright by the FSF and can only be
>> distributed if you don't modify it. This is essential to the
>> ability to use it as a "subroutine". This is the only way to
>> make sure there is only one thing called the "GNU General Public
>> License".
>>
>> I think that if you modify it, but clearly call it something
>> else, there is no problem. But I'm not sure exactly what the
>> rules are.
jsd> It is *exactly* this kind of statement that makes me even more
jsd> fearful of GPL. The people that use it often don't understand
jsd> it very well. This is not meant as an insult, but this thread
jsd> scares me further from GPL. As the proprietor of a small
jsd> company, this increases my legal expense/exposure.
Again, I don't understand this position. Suppose you took the licensing
scheme from your Microsoft program, labelled "Microsoft's License",
modified it slightly, then used it with your program still calling it
"Microsoft's License". That's obviously not a good idea, right? So why
the amazement that the GPL is the same way? Where's the extra exposure
there?
As for people using the license not understanding it, again, where's the
big difference between the GPL and commercial software licenses? I bet
if you asked 100 net denizens detailed questions about the licensing
that came with their last piece of commercial software at least 50 would
get significant portions wrong, and advise you incorrectly.
Heck, from what I can see on many newsgroups, more than 50% of the
people posting don't have any idea what they're talking about on _any_
given subject :)
jsd> The license itself is so complex, that the net-wisdom does not
jsd> seem to converge.
I maintain that it's not the _license_, at *all*, that's complex. It's
the obscure situations that people come up with on this newsgroup (and
elsewhere), either to exercise the boundaries of the license for their
own intellectual edification, or because they're trying to find a way to
"cheat" the license. If this newsgroup spent as much time trying to
examine the details of commercial licenses, I daresay you'd be even more
nervous about them than the GPL! :)
If you use the GPL in a straightforward manner, there's no mystery
there. If you think there is, or are worried, describe the specific
situation and I'm sure people will point you to the parts of the GPL
they feel relate to your situation.
Then, as with any license, it's up to you to read and comprehend, and
finally to decide to take the risk or not. The risk may be real, but I
can't see that it's greater with the GPL than any other license. I
personally feel it's less.
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
Senior Software Engineer Bay Networks, Inc.
-----------------------------------------------==<http://www.baynetworks.com/>-
"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.
John S. Dyson
Paul D. Smith <psm...@baynetworks.com> wrote:
>%% Regarding Re: [Q] GPL violation.;
>%% ro...@dyson.iquest.net (John S. Dyson) writes:
>
> jsd> It is *exactly* this kind of statement that makes me even more
> jsd> fearful of GPL. The people that use it often don't understand
> jsd> it very well. This is not meant as an insult, but this thread
> jsd> scares me further from GPL. As the proprietor of a small
> jsd> company, this increases my legal expense/exposure.
>
>Again, I don't understand this position. Suppose you took the licensing
>scheme from your Microsoft program, labelled "Microsoft's License",
>modified it slightly, then used it with your program still calling it
>"Microsoft's License". That's obviously not a good idea, right? So why
>the amazement that the GPL is the same way? Where's the extra exposure
>there?
>
been trying to read something into the GPL that isn't there I guess...
>
>As for people using the license not understanding it, again, where's the
>big difference between the GPL and commercial software licenses?
>
If there is no difference to me, then what makes GPL so good???
There are so many interpretations of what GPL means, and a person in a
previous posting made a very constructive point... It would be good to
find a lawyer that is not connected with FSF at all to analyze the GPL
and write an unbiased laymans' version of it.
My view of it is that GPLed code isn't alot better than Microsoft's code
when it comes to me making money. I mean -- I can make money supporting
Microsoft OSes, Compilers, etc... We have such a support organization where
I work for example. So can I supporting GPLed code... But if I try to resell
portions of Microsoft code, I can get in trouble, and likewise GPLed code...
In fact, it is apparently fairly easy to violate the GPL, as it is to violate
the license for Microsoft C.
John Dyson
Mike Stump
>The people that use it often don't understand it very well.
I always thought the central concept of the GPL was rather simple
myself.
>This is not meant as an insult, but this thread scares me further
>from GPL. As the proprietor of a small company, this increases my
>legal expense/exposure.
One can dump as much money as they care into legal. If you are GPLing
your own code, the expense/exposure can be low, very low.
If you are using other's GPLed code, you can always run the use by
them, and see if they balk. If they don't, then you fairly ok from a
pratical perspective (if you trust them). If they do, then it doesn't
matter what your lawyer thinks as they will want to take you to court
anyway.
There is a cost to using GPLed code, yes. For most uses, the cost is
kept down to a reasonable level. The higher the value of the use of
the GPLed code, the more cost is in using it. This isn't unreasonable.
For example, to use emacs to edit files, it is a pretty good no
brainer. But, if you want to edit it up, and sell it as the basis for
your own C++ code browser, better dump some money into it.
>The license itself is so complex,
It just seems that way. :-)
>that the net-wisdom does not seem to converge.
I disagree. I have only ever seen one unresolved disagreement before.
And for that case, one should consult his lawyer, and measure the
risk/benefit.
If you feel there are any unresolved points, state them here, and then
just sit back, and watch the discussion. In the end, I think it
should be clear.
Mike Stump
>the Manifesto.
I disagree.
For the newcomers to this list, please don't read the Manifesto,
decide you disagree in part, or in all with it, and then assume that
the GPL isn't for you.
I disagree, in part at least, with the Manifesto, but I don't hold
that against the GPL, nor rms, nor the FSF, nor emacs.
John S. Dyson
>In article <4bgt6i$j...@dyson.iquest.net>,
>John S. Dyson <ro...@dyson.iquest.net> wrote:
>
>One can dump as much money as they care into legal. If you are GPLing
>your own code, the expense/exposure can be low, very low.
>
of GPL is interesting from the standpoint of the original author loosing
ownership of his/her software as mods and enhancements are added by the
net at large. Eventually, ownership can become so diffuse, that licensing
for commercial use can be tricky. There are licenses that totally eliminate
that problem. (I can take code that I originally wrote, but others have
enhanced, and perhaps put it into an embedded controller that I just do not
want to deal with source redistribution on, for example.) There is
no sinister (sorry, lefties) plan here...
>
>There is a cost to using GPLed code, yes. For most uses, the cost is
>kept down to a reasonable level. The higher the value of the use of
>the GPLed code, the more cost is in using it. This isn't unreasonable.
>
I am pretty much forbidden from using GPLed code at work (in product), but
of course can use it in development tools as I would purchased software
from Microsoft. I almost definitely would have to license the GPLed
work seperately, and that is not even practical in some cases. We are
NOT about to redistribute source code -- sorry, just doesn't/will not
happen.
>
>If you feel there are any unresolved points, state them here, and then
>just sit back, and watch the discussion. In the end, I think it
>should be clear.
>
Actually, my questions have been an attempt at leading the discussion
into whether GPLed software is as encumbered as to redistribution as it
appears that it is. This IS NOT MEANT TO BE FLAMEBAIT, but as an example,
the Berkeley Networking Code is used as a seed for many TCP/IP suites
(for better or worse.) This would not be practical under GPL without
getting seperate agreement from the authors. The notion of GPLed software
as being a community resource is diminished by this.
Tell me where I am wrong...
(These are a few of my worries, more to come.)
John Dyson
Russ Allbery
> Since I am a substantial contributor to a free software project, the issue
> of GPL is interesting from the standpoint of the original author loosing
> ownership of his/her software as mods and enhancements are added by the
> net at large. Eventually, ownership can become so diffuse, that licensing
> for commercial use can be tricky. There are licenses that totally
> eliminate that problem. (I can take code that I originally wrote, but
> others have enhanced, and perhaps put it into an embedded controller that
> I just do not want to deal with source redistribution on, for example.)
> There is no sinister (sorry, lefties) plan here...
Let me get this straight...your objection to the GPL is that it doesn't
automatically give you the right to distribute code someone else wrote? Of
course it doesn't. I'd be interested to see the license that does, and
whether it would hold up in court.
Your *original* code, along with any modifications you write yourself, is
your possession. You can release it under any license you care to use. You
do not automatically get the right to release other people's improvements
under a different license without making additional arrangements with them.
If you think this is a problem unique to the GPL, I believe you're wrong.
I'm sure Sun (for example) needs to be just as meticulous about maintaining
ownership (or ensuring that the license agreements are compatible with their
use) of all the code that goes into Solaris. They're undoubtably aided by
employee contracts with the people working on the code.
If they were to open Solaris up to modification by the Net at large, I'm
sure they would have to make legal arrangements with the authors of
improvements before they could incorporate them into Solaris under the
standard licensing agreement.
(The example of Solaris is used solely because it was the first thing that
came to mind. If I am mistaken about Sun's licensing scheme, please
substitute some other commercially licensed, non-GPL product (Windows '95,
for instance).)
> I am pretty much forbidden from using GPLed code at work (in product), but
> of course can use it in development tools as I would purchased software
> from Microsoft. I almost definitely would have to license the GPLed work
> seperately, and that is not even practical in some cases. We are NOT
> about to redistribute source code -- sorry, just doesn't/will not happen.
Yes, in that case, you're not going to be able to use GPL code in your
product without making additional arrangements with the copyright
holder(s). I'm not sure why you consider this a criticism of the GPL.
There *is* a political agenda behind the GPL -- it's stated in the
Manifesto. I would imagine that most of us who release code under GPL agree
with that political agenda, at least to some extent (if only to the extent
that we feel the user of the software should have the freedom to modify it
as they wish). By not releasing the source code of your product, you are
acting directly contrary to that political agenda, and therefore the GPL is
going to make matters difficult for you.
But note that the GPL only applies to code that you have received *under
that license*. It doesn't apply to code you wrote yourself, since you have
ownership of that code and can ignore any licensing agreement. It doesn't
apply to code released under the GPL but also released under another
licensing agreement, which you are using under that other licensing
agreement (Perl under the Artistic License, for instance). It only applies
to code that you would not have been able to use were it not under GPL.
In no way can the GPL cause the owner of the code to lose possession of it.
> This IS NOT MEANT TO BE FLAMEBAIT, but as an example, the Berkeley
> Networking Code is used as a seed for many TCP/IP suites (for better or
> worse.) This would not be practical under GPL without getting seperate
> agreement from the authors. The notion of GPLed software as being a
> community resource is diminished by this.
It may be in your opinion. It isn't in mine, because I believe in source
code distribution and *want* to have the source code for software packages
that I use and *want* to distribute the source code of products I write.
The community of people who are benefited by GPLed software are those who
release their source code. There are some benefits to those who do not, but
I personally believe those benefits are mainly nice side effects, not the
main purpose of the license.
I'm sure that I'll be corrected by others here who know more of the
specifics of the situation than I....
--
Russ Allbery (r...@cs.stanford.edu) http://www-leland.stanford.edu/~rra/
Russ Allbery
>> Let me get this straight...your objection to the GPL is that it doesn't
>> automatically give you the right to distribute code someone else wrote?
>> Of course it doesn't. I'd be interested to see the license that does,
>> and whether it would hold up in court.
> The BSD license does. With a very simple set if stipulations... Even
> USL dealt with it unhappily (existance proof.)
I'd appreciate more details on this, because it certainly doesn't look like
it does. All the BSD license does is list provisions under which your
program can be distributed. Nowhere does it say "any modifications to this
program become the property of the original author" or "any modifications to
this program can be distributed under the BSD license."
I could take your BSD licensed program, make my own modifications to it, and
then distribute my modifications (in some encapsulated form not containing
the original source) under a commerical license and you wouldn't be able to
use them in your product without working it out with me.
>> Your *original* code, along with any modifications you write yourself, is
>> your possession. You can release it under any license you care to use.
>> You do not automatically get the right to release other people's
>> improvements under a different license without making additional
>> arrangements with them.
> Sorry, then it does not get the advantage of enhancements made over time
> on the net... Bzzzt... (Sort-of a trade for free-use on the net for bug
> fixes and enhancements that can be used as opposed to encumbered with
> GPL.)
This has nothing to do with the GPL. You're *always* going to have to make
arrangements with the people who produced the code modifications you want to
use if you want to incorporate them in a commerical product unless they
explicitly made them public domain or put them under a license that allowed
you to do what you want. This is going to be true regardless of whether you
distribute your code under the GPL or not.
> The notion of GPLed software being freeware appears to be double speak
> that is clearly and blatently set forth in the GNU Manifesto...
Where on earth did you get the impression that GPLed software was freeware?
Didn't you ever read the Manifesto? To quote:
GNU is not in the public domain. Everyone will be permitted to
modify and redistribute GNU, but no distributor will be allowed to
restrict its further redistribution. That is to say, proprietary
modifications will not be allowed. I want to make sure that all
versions of GNU remain free.
GPLed software is *free*. It is not freeware.
> Ok, but how does that relate to true freeware???... Certain copyrights
> only require attribution.
If you prefer that, use it. I'm not particularly interested in what you
call "true freeware."
> I guess I don't subscribe to that agenda, and I think that people should
> read it VERY CAREFULLY with understanding of it's side effects before
> signing up... :-). The agenda is not only political but has the effect of
> converting "ownership" from the original author to the net at large or
> large support entities. This conversion process takes time and appears to
> be insidious. (Defining "ownership" as the ability to profit in one way
> or another.)
What a bizarre definition of ownership. If by profit, you mean make money,
then apparently I don't own my couch. If by profit, you mean derive
benefts from, then everyone owns GPLed software.
I have to say I don't find your definition of ownership particularly useful.
John S. Dyson
Russ Allbery <r...@cs.stanford.edu> wrote:
>John S Dyson <ro...@dyson.iquest.net> writes:
>
>> Since I am a substantial contributor to a free software project, the issue
>> of GPL is interesting from the standpoint of the original author loosing
>> ownership of his/her software as mods and enhancements are added by the
>> net at large. Eventually, ownership can become so diffuse, that licensing
>> for commercial use can be tricky. There are licenses that totally
>> eliminate that problem. (I can take code that I originally wrote, but
>> others have enhanced, and perhaps put it into an embedded controller that
>> I just do not want to deal with source redistribution on, for example.)
>> There is no sinister (sorry, lefties) plan here...
>
>Let me get this straight...your objection to the GPL is that it doesn't
>automatically give you the right to distribute code someone else wrote? Of
>course it doesn't. I'd be interested to see the license that does, and
>whether it would hold up in court.
>
USL dealt with it unhappily (existance proof.)
>
>Your *original* code, along with any modifications you write yourself, is
>your possession. You can release it under any license you care to use. You
>do not automatically get the right to release other people's improvements
>under a different license without making additional arrangements with them.
>
Sorry, then it does not get the advantage of enhancements made over time
on the net... Bzzzt... (Sort-of a trade for free-use on the net for bug
fixes and enhancements that can be used as opposed to encumbered with GPL.)
>
>If you think this is a problem unique to the GPL, I believe you're wrong.
>I'm sure Sun (for example) needs to be just as meticulous about maintaining
>ownership (or ensuring that the license agreements are compatible with their
>use) of all the code that goes into Solaris. They're undoubtably aided by
>employee contracts with the people working on the code.
>
Sure, and Sun does not purport to give away it's freeware (SunOS/Solaris) :-).
The notion of GPLed software being freeware appears to be double speak that
is clearly and blatently set forth in the GNU Manifesto...
>
>If they were to open Solaris up to modification by the Net at large, I'm
>sure they would have to make legal arrangements with the authors of
>improvements before they could incorporate them into Solaris under the
>standard licensing agreement.
>
Ok, but how does that relate to true freeware???... Certain copyrights
only require attribution.
>
>There *is* a political agenda behind the GPL -- it's stated in the
>Manifesto. I would imagine that most of us who release code under GPL agree
>with that political agenda, at least to some extent (if only to the extent
>that we feel the user of the software should have the freedom to modify it
>as they wish). By not releasing the source code of your product, you are
>acting directly contrary to that political agenda, and therefore the GPL is
>going to make matters difficult for you.
>
I guess I don't subscribe to that agenda, and I think that people should
read it VERY CAREFULLY with understanding of it's side effects before
signing up... :-). The agenda is not only political but has the effect of
converting "ownership" from the original author to the net at large or
large support entities. This conversion process takes time and appears
to be insidious. (Defining "ownership" as the ability to profit in one
way or another.)
John Dyson
Jimen Ching
>For the newcomers to this list, please don't read the Manifesto,
>decide you disagree in part, or in all with it, and then assume that
>the GPL isn't for you.
I read both the Manifesto and the GPL. I've always thought the Manifesto
is the 'why' and the GPL is the 'how' of free[dom] software. If you
understand the 'why', then the 'how' isn't that important, especially if
you are not into the legal details.
>I disagree, in part at least, with the Manifesto, but I don't hold
>that against the GPL, nor rms, nor the FSF, nor emacs.
I might be able to get a better understanding of your point of view
if you can provide passages in the Manifesto which would direct people
against the GPL.
--jc
Jimen Ching
>large support entities. This conversion process takes time and appears
>to be insidious. (Defining "ownership" as the ability to profit in one
>way or another.)
I do not understand this. In practically every article you posted, you
say in one way or another, that GPL prevents the author from making a
profit. You mean by selling the source code? No one prevents you from
selling source code. Walnut Creek sell multiple CDROM's of GPL code.
You can do the same with GPL code. What other profit do you have in
mind? The following are some other ways to earn a profit from giving
source code away.
Crynwyr drivers
Cygnus Support
Remember, the point of the GPL is to provide source code. So if you
suggest selling 'software as a product' like Netscape, you've already
misunderstood the purpose of GPL. The GPL is specifically designed to
fight against this. Are you criticizing GPL for doing what it was
designed to do?
Russ Allbery
>> I could take your BSD licensed program, make my own modifications to it, and
>> then distribute my modifications (in some encapsulated form not containing
>> the original source) under a commerical license and you wouldn't be able to
>> use them in your product without working it out with me.
> Cool... That is the purpose of my gift... There is no commercial intent,
> but any free versions are still fair game. At least in the BSD community
> the free versions are keeping up with the commercial versions... I am not
> afraid of the commercial stuff. I am more afraid of encumbered code in
> the public where I can see the code and I have to clean-room reimplement
> it.
Then I definitely didn't understand your original point. You don't seem to
be concerned with what license you yourself use, but rather what license the
people making modifications to your programs use.
Maybe I can explain how this sounds to me. You want to maintain your right
to release commercial versions of your software, but you want all
modifications to your software to be released under a license that lets you
make money off of them.
This immediately turns me off.
Now I'm not sure you actually feel that way, since you've said that you're
part of major free software products. I'm not sure where you stand on
this. But to me, this feels liking asking for Christmas gifts so that you
can sell them. My instinctive response to the offering of free software is
to respond in kind and release my own free software, not to say "hey, thanks
for the software" and then going off to sell it.
Now don't get me wrong; you should certainly be able to sell your
programming experience and the products of your labors. What I highly
dislike is the idea of selling *other people's* labors without paying them
for it. I realize that the GPL also allows this, but it at least requires
that source code also be developed so that others can distribute the work
for free.
> All I want is a little bit of credit if someone uses my code -- that is
> all.
Then perhaps you should use the BSD license. The reason why *I* would use
the GPL is because it encourages the development of more free software,
whereas the BSD license does not.
>> GPLed software is *free*. It is not freeware.
> The old double-speak again. GPL software is NOT free software to me.
The users of GPL software are free to modify it and improve it. They are
free to distribute their versions for other people to use. They are free to
use the code in their own packages provided that their packages are also
free.
This is free software to me. Apparently you have a different definition,
and that's fine. Most words have different definitions depending on who you
ask. But accusing someone of doublespeak because you disagree with their
definitions is dishonest.
> Cygnus and other support companies are free to make money from it -- so
> therefore it is free. :-). But since I write code for companies that
> believe that proprietary is the way to go (which in my commercial work --
> I believe also), I am not free to use it...
Yes, your *company* is not free to use it in any way they please because
your company is not part of the free software community.
> I CAN use it in development -- and I do, up to the limits of the GPL. But
> the GPL limits me -- sorry, it is just broken for me in much of my work.
It's not broken; it's doing precisely what it was designed to do. (Be aware
that my political opinions are not necessarily those of other people who use
the GPL.)
>> If you prefer that, use it. I'm not particularly interested in what you
>> call "true freeware."
> My interests are apparently not the same as yours... I hope that is what
> you mean, and are not just blowing me off -- that is impolite...
No, you have the intention correct. I would be perfectly happy to see the
commerical software market shrivel up and largely die. Writing software
that is free to be used in commerical software packages without source
distribution is not high on my priority list.
I'm paid for *writing* software, not for *having written* software. Other
users of the GPL probably have different perspectives.
John S. Dyson
>
>>> Let me get this straight...your objection to the GPL is that it doesn't
>>> automatically give you the right to distribute code someone else wrote?
>>> Of course it doesn't. I'd be interested to see the license that does,
>>> and whether it would hold up in court.
>
>> USL dealt with it unhappily (existance proof.)
>
>it does. All the BSD license does is list provisions under which your
>program can be distributed. Nowhere does it say "any modifications to this
>program become the property of the original author" or "any modifications to
>this program can be distributed under the BSD license."
>
>then distribute my modifications (in some encapsulated form not containing
>the original source) under a commerical license and you wouldn't be able to
>use them in your product without working it out with me.
>
Cool... That is the purpose of my gift... There is no commercial intent, but
any free versions are still fair game. At least in the BSD community the
free versions are keeping up with the commercial versions... I am not
afraid of the commercial stuff. I am more afraid of encumbered code in the
my area of work on free software, there aren't many organizations that can do
much better -- certainly not afraid of them. I AM afraid of tainted code in
the public. All I want is a little bit of credit if someone uses my code --
that is all.
>
>This has nothing to do with the GPL. You're *always* going to have to make
>arrangements with the people who produced the code modifications you want to
>use if you want to incorporate them in a commerical product unless they
>explicitly made them public domain or put them under a license that allowed
>you to do what you want. This is going to be true regardless of whether you
>distribute your code under the GPL or not.
>
That is why I like the BSD license. Again, I find that the free software
projects tend to lead the commercial entries. -- I am NOT afraid of them.
In fact, I aplaud the ability of a small start-up being able to adopt code
and make money from it. They don't even have to give the results of their
work to their competition!!!
>
>Where on earth did you get the impression that GPLed software was freeware?
>Didn't you ever read the Manifesto? To quote:
>
> GNU is not in the public domain. Everyone will be permitted to
> modify and redistribute GNU, but no distributor will be allowed to
> restrict its further redistribution. That is to say, proprietary
> modifications will not be allowed. I want to make sure that all
> versions of GNU remain free.
>
>GPLed software is *free*. It is not freeware.
>
The old double-speak again. GPL software is NOT free software to me. Cygnus
and other support companies are free to make money from it -- so therefore it
is free. :-). But since I write code for companies that believe that
proprietary is the way to go (which in my commercial work -- I believe also),
I am not free to use it... I CAN use it in development -- and I do, up
to the limits of the GPL. But the GPL limits me -- sorry, it is just
broken for me in much of my work.
>
>If you prefer that, use it. I'm not particularly interested in what you
>call "true freeware."
>
My interests are apparently not the same as yours... I hope that is what
you mean, and are not just blowing me off -- that is impolite...
>
>I have to say I don't find your definition of ownership particularly useful.
>
I meant in the sense as a tool in my work. If I don't have free use of
it I cannot profit from it. Sorry for your misunderstanding of what
I have been trying to say. I have been answering lots of email privately
on this subject also -- just tired, sorry ...
For example:
Cygnus is in a interesting postion of being able to profit from GPLed software
that is perhaps written by other people. I can see where GPL is good for it,
but not me... I could be convinced that GPL is good for me if I can
benefit from it -- it is obvious that Cygnus is convinced that GPL is good
for it.
John Dyson
Gasparovski / Daniel (ISE)
>
> Put it in your licence, if you want. No one forces you to use the
> GPL as is. The text of the GPL is public domain, if I recall.
>
>distributed if you don't modify it. This is essential to the ability
>to use it as a "subroutine". This is the only way to make sure there
>is only one thing called the "GNU General Public License".
>
>I think that if you modify it, but clearly call it something else,
>there is no problem. But I'm not sure exactly what the rules are.
Maybe the FSF should release the GNU General Public License under a
BSD-like license. You know, you can copy it and what not but if you
change it don't call it the official GNU GPL (as per clause 4). :)
Dan ...
--
[ Danny Gasparovski | Mortified by the lack of conscience ]
[ u92...@student.canberra.edu.au | Our sanctity bears no relevance ]
[ University of Canberra, Australia | Insignificant is our existence ]
[ Bolt Thrower, "The IVth Crusade" -> | Hear the litany of life's persistence ]
Ingemar Hulthage
Russ Allbery <r...@cs.stanford.edu> first wrote:
> How am I imposing my will on anyone? If you don't like my terms,
> don't use my code. That's no different than any other licensing
> arrangement. The BSD license is forcing you to publicize the names
> of the original authors whether you like it or not.
later he writes:
> The reason why *I* would use the GPL is because it encourages the
> development of more free software, whereas the BSD license does not.
Where does the line between 'imposing' and 'encouraging' go ? If
there is no coercing going on, why not make GPL voluntary also for
derivative work ?
Also there are important differences between the GPL and 'other
licensing arrangements'. For example, when a copyright holder
reserves the rights, associated with copyright, in order to get
economical compensation or acknowledgement, he is seeking legitimate
interests. But when the GPL coerces people to use the GPL for
derivative work, no legitimate interest of the copyright holder is
protected. The copyright is only used as a leverage to make other
people conform to certain values. A copyright holder may have the
right to use the GPL license for his code, but it smacks of
intolerance and extremism.
Merry Christmas,
Ingemar Hulthage
(This message is my copyright and may not be quoted unless the phrase
'Merry Christmas' is included 8-^)
William S. Gribble
> Also there are important differences between the GPL and 'other
> licensing arrangements'. For example, when a copyright holder
> reserves the rights, associated with copyright, in order to get
> economical compensation or acknowledgement, he is seeking legitimate
> interests. But when the GPL coerces people to use the GPL for
> derivative work, no legitimate interest of the copyright holder is
> protected.
I would say that your definition of ``legitimate interest'' is far too
narrow. The GPL serves the interest of the copyright holder by making
the world of free software just a little bit richer, by making software
in general just a little bit easier to get, use, and improve, and
by fractionally reducing the stranglehold that proprietary software
has on the marketplace. I'd say tht's definitely a legitimate interest
of a programmer.
> A copyright holder may have the right to use the GPL license for his
> code, but it smacks of intolerance and extremism.
.. and that statement smacks of hyperbole and bombast.
> Merry Christmas,
> (This message is my copyright and may not be quoted unless the phrase
> 'Merry Christmas' is included 8-^)
Actually, that's not enforceable.. quoting is fair use. Not to mention
that I hate Christmas, and it's already over :) But in the interest
of altruism I'll reproduce your message.
Bill Gribble
Barry Margolin
Ingemar Hulthage <hult...@hollywood.cinenet.net> wrote:
>Russ Allbery <r...@cs.stanford.edu> first wrote:
>> development of more free software, whereas the BSD license does not.
>Where does the line between 'imposing' and 'encouraging' go ? If
>there is no coercing going on, why not make GPL voluntary also for
>derivative work ?
The difference between "imposing" and "encouraging" is that you aren't
forced to write derivative works of GPLed code. You have a choice: you can
write proprietary code, or you can build upon the existing GPLed code
base. The existence of a high-quality base of free code is used as an
incentive to get you to create more code like it.
--
Barry Margolin
BBN PlaNET Corporation, Cambridge, MA
bar...@bbnplanet.com
Phone (617) 873-3126 - Fax (617) 873-6351
Russ Allbery
> Russ Allbery <r...@cs.stanford.edu> first wrote:
>> How am I imposing my will on anyone? If you don't like my terms,
>> don't use my code. That's no different than any other licensing
>> arrangement.
This is misphrased, because it implies that I'm denying that I'm imposing my
will. I'm not; I'm saying that I'm imposing my will only on my code and
through a licensing agreement, and that the BSD license is doing the same
thing.
> Where does the line between 'imposing' and 'encouraging' go? If there is
> no coercing going on, why not make GPL voluntary also for derivative work?
All licenses coerce.
> Also there are important differences between the GPL and 'other licensing
> arrangements'. For example, when a copyright holder reserves the rights,
> associated with copyright, in order to get economical compensation or
> acknowledgement, he is seeking legitimate interests. But when the GPL
> coerces people to use the GPL for derivative work, no legitimate interest
> of the copyright holder is protected.
I find it convenient how you define legitimate to suit your argument.
Let's just say that I do not accept your definition of legitimate.
> A copyright holder may have the right to use the GPL license for his code,
> but it smacks of intolerance and extremism.
More so than a commerical license? I'd have to say that you're extremely
confused. Someone is intolerant and extreme because they release their code
for the public to modify and use?
Marcus Daniels
In article <HULTHAGE.95...@hollywood.cinenet.net> hult...@hollywood.cinenet.net (Ingemar Hulthage) writes:
Ingemar> The copyright is only used as a leverage to make
Ingemar> other people conform to certain values.
Hey, you're catching on!
Ingemar> A copyright holder
Ingemar> may have the right to use the GPL license for his code, but
Ingemar> it smacks of intolerance and extremism.
Hoarding the code of derived work smacks of exploitation. Go figure.
[and here's hoping that "Merry Christmas" resulted in big bucks all around!]
John S. Dyson
Barry Margolin <bar...@tools.bbnplanet.com> wrote:
>In article <HULTHAGE.95...@hollywood.cinenet.net>,
>Ingemar Hulthage <hult...@hollywood.cinenet.net> wrote:
>>> development of more free software, whereas the BSD license does not.
>
>>there is no coercing going on, why not make GPL voluntary also for
>
>The difference between "imposing" and "encouraging" is that you aren't
>forced to write derivative works of GPLed code. You have a choice: you can
>write proprietary code, or you can build upon the existing GPLed code
>base. The existence of a high-quality base of free code is used as an
>incentive to get you to create more code like it.
Third choice -- you can build upon the BSDed code base... It works also.
There are glitches in the system, but there are in GPL also, they are just
less visible, because there are companies and individuals that
stay away from the GPL license a priori.
John Dyson
John S. Dyson
Marcus Daniels <mar...@sysc.pdx.edu> wrote:
>>>>>> "Ingemar" == Ingemar Hulthage <hult...@hollywood.cinenet.net> writes:
>In article <HULTHAGE.95...@hollywood.cinenet.net> hult...@hollywood.cinenet.net (Ingemar Hulthage) writes:
>
>Ingemar> The copyright is only used as a leverage to make
>Ingemar> other people conform to certain values.
>
>Hey, you're catching on!
>
>Ingemar> A copyright holder
>Ingemar> may have the right to use the GPL license for his code, but
>Ingemar> it smacks of intolerance and extremism.
>
>Hoarding the code of derived work smacks of exploitation. Go figure.
>
I DO NOT feel exploited when someone makes money from what I do. Since R+D
budgets might be about 5% of gross revenues, and I get perhaps 1-10% of the R+D
budget (if I am lucky), am I being exploited? -- NO. I agreed to those
terms and it is reality in the marketplace -- and so the BSD license allows
people to agree to share code if they want to -- but it does not compel them
to. Why should I worry if someone is ingenuous(sp) enough to find a way to make
money on software that is public??? They must have done *significant* work
on the code for the free sector to not be able to reproduce it.
John Dyson
Marcus Daniels
In article <4c3hnp$3...@dyson.iquest.net> ro...@dyson.iquest.net (John S. Dyson) writes:
Ingemar> A copyright holder may have the right to use the GPL license
Ingemar> for his code, but it smacks of intolerance and extremism.
me> Hoarding the code of derived work smacks of exploitation. Go
me> figure.
John> I DO NOT feel exploited when someone makes money from what I do.
Who said anything about money? Hoarding is the activity of taking
something that was *intended* for the public commons and making it
a product for private profit. GNU developers *intend* this, hence
they select the GPL. I don't think you will find many GNU
developers who would categorically object to the notion of their
work resulting in the production of wealth for others.
Arthur Kreitman
> My view of it is that GPLed code isn't alot better than Microsoft's code
> when it comes to me making money. I mean -- I can make money supporting
> Microsoft OSes, Compilers, etc... We have such a support organization where
> I work for example. So can I supporting GPLed code... But if I try to resell
> portions of Microsoft code, I can get in trouble, and likewise GPLed code...
> In fact, it is apparently fairly easy to violate the GPL, as it is to violate
> the license for Microsoft C.
since there have to be hundreds of time more people using microsoft code
then gpl'ed code, you can probably make more money supporting microsoft code.
--
----
Art Kreitman Congruent Corporation
ar...@congruent.com 110 Greene Street
212-431-5100 New York, New York 10012
fax 219-1532
John S. Dyson
>In article <qumd99a...@cyclone.Stanford.EDU>,
>Russ Allbery <r...@cs.stanford.edu> wrote:
>>John S Dyson <ro...@dyson.iquest.net> writes:
>>
>>Let me get this straight...your objection to the GPL is that it doesn't
>>automatically give you the right to distribute code someone else wrote? Of
>>course it doesn't. I'd be interested to see the license that does, and
>>whether it would hold up in court.
>
>to distribute code someone else wrote. In fact, this is one of it's
>central objectives.
>
But, I cannot make proprietary mods to gain competitive advantage in a
free market, and to me that breaks GPL.
John Dyson
Mike Stump
>of GPL is interesting from the standpoint of the original author loosing
>ownership of his/her software as mods and enhancements are added by the
>net at large. Eventually, ownership can become so diffuse, that licensing
>for commercial use can be tricky.
This is a well founded reason for not using GPL, if you want to use
license other people's work, as if you had written it. Use the BSD
style copyright, instead. It permits this type of use.
>I am pretty much forbidden from using GPLed code at work (in product),
Funny, at work, I am required to use it. :-) Work on changing your
companies views... :-)
Mike Stump
>
>Let me get this straight...your objection to the GPL is that it doesn't
>automatically give you the right to distribute code someone else wrote? Of
>course it doesn't. I'd be interested to see the license that does, and
>whether it would hold up in court.
I think you mis-stated this. The GPL is fact does give one the right
to distribute code someone else wrote. In fact, this is one of it's
central objectives.
What he was asking for is a license that allows him to sell/license
code that other people wrote, as if he wrote it, without some of the
restrictions that GPL places on him.
I think you did know this, but didn't express it well in the paragraph
above. Hum, I wonder if this is as bad as correcting people's
spelling? Let me know if you think it was. I mainly correct it, so
that users new to the GPL are not confused by a literal reading of
what you wrote.
John S. Dyson
but not in the business of selling services for GPLed software. In fact,
the company that I work for primarily isn't even in the software business,
except as a side-effect. Since the company that you work for is in the
business of selling the service of supporting GPLed software -- it makes
sense for them to compel you to GPL encumber your software...
John Dyson
Mike Stump
>free market, and to me that breaks GPL.
I disagree to some degree. Please see my other posting in this
thread, and refute my points, if you care.
Piercarlo Grandi
>>> S. Dyson) said:
>> The GPL is fact does give one the right to distribute code someone
>> else wrote. In fact, this is one of it's central objectives.
Dyson> But, I cannot make proprietary mods to gain competitive advantage
Dyson> in a free market, and to me that breaks GPL.
But, the _goal_ of the GPL is precisely to prevent proprietary mods, as
its aim is to promote the widest sharing of sw. You seem to be arguing
that the the GPL was not designed to serve *your* aims.
If so, you are probably right: it was designed to promote the aims of
the Free Software Foundation, chiefly the building up of a body of
unrestrictedly sharable, non-proprietary, sw, and it seems to be working
fairly well as to that.
I can also easily believe that the aims of the FSF do not coincide with
yours; but this is a rather boring observation: different people have
rather different goals, and that goes without saying.
So what's this discussion really about?
John S. Dyson
Piercarlo Grandi <pier...@sabi.demon.co.uk> wrote:
>>>> On Tue, 2 Jan 1996 09:00:32 GMT, ro...@dyson.iquest.net (John
>>>> S. Dyson) said:
>
>>> The GPL is fact does give one the right to distribute code someone
>>> else wrote. In fact, this is one of it's central objectives.
>
>Dyson> But, I cannot make proprietary mods to gain competitive advantage
>Dyson> in a free market, and to me that breaks GPL.
>
>that the the GPL was not designed to serve *your* aims.
>
>
on arguing with me. See, the original author has a choice as to which
license to use. BSD is best for people who want or expect their code
to be used in applications (the authors or others) -- free OR proprietary.
GPL apparently is best for people who want or expect their code to be used in
applications (the author's can be proprietary if using code fully is written
by the author), or others with full code disclosure, potentially giving
away trade secrets. So AGAIN, GPL cannot work for me.
John Dyson
John S. Dyson
>
>The thread started out with Mr. Dyson saying GPL doesn't meet his needs.
>Unfortunately, he went on to spread lies about GPL to backup his point.
>Here are some of the of lies Mr. Dyson tried to spread. And this thread
>is about correcting those lies.
>
>Lies about GPL:
>
>1. GPL source code can not be commercialized.
Not by me... Not a lie... I guess if I want to do something that
is not in my interest, I could commercialize it.
>2. GPL takes away the rights of the author of the source code.
Yes it does, when modifications are under GPL.
>3. Modifications of GPL source code MUST go under the GPL.
I did not know that. Where does it say that in the GPL?? I work in
the commercial realm where my work IN redistributed.
>4. GPL has *MORE* restrictions (than BSD? Commercial licenses?).
It does (than BSD.) It is possible to construct a commercial license
freer than GPL, but it would contrived.
>5. GPL is not really *FREE*.
Depending on what you define to be free.
I See that Mr Ching is defining what I say to be a lie. He is redefining
the circumstances.
>
>Truths about GPL:
>
>1. Depending on how you want to commercialize GPL source code, many
>companies have done so. See www.cygnus.com or www.crynwr.com for
>some examples.
I guess that you CAN jump off a building, but it is not in your interest.
It is NOT in the interest of many companies to give away your modifications.
Since those companies ARE in the business of redistribution, GPLed code
is not appropriate. BTW, those companies used as examples are SUPPORT
companies. Cygnus is very small in the scheme of things, $10M???
>2. No license can ever do this. The only way authors can lose rights
>to source code they have written is if they released the code to the
>public domain. If you do not believe this, print out a copy of the GPL
>and take it to your lawyer.
But the author can gain no advantages due to proprietary modifications
if they are redistributed.
>3. GPL can not force authors of modifications to do anything they do
>not want to do. What the GPL *says* is that IF AND ONLY IF you want
>to distribute that modification, THEN it MUST go under the GPL. Note:
>the word 'modification' has a special meaning, please read the GPL for
>further details.
Hmmm... Most of what I do is used externally, or is targeted for real
customer use -- I would expect that the majority of the community is
in the same position as I. Since the GPL terms are inappropriate for
most companies that redistribute proprietary code -- it is just broken
for them.
>4.
>GPL says:
> "You can not take away the rights of others which you, yourself were
> given."
>
But if I add modifications, and want to redistribute the object code, I also
have to redistribute the source. Trade secrets are important to many real
companies.
>BSD License says:
> "You must include our name."
>
Really costly. :-).
>Commercial license says:
> "You've been screwed. We already have your money."
>
You have been dealing with the wrong companies -- cynical attitude.
>5.
>GPL says:
> "This source code has been liberated."
>
And all code that is redistributed requires release of trade secrets, thereby
making GPLed code undesirable for most applications. But boy is it great
for development tools, especially since I dont generally write such code.
BTW, any of that neat GPL code that you see has to be carefully linked with your
own, if at all, because it will encumber yours with a source redistribution
requirement.
>BSD says:
> "This source code has been liberated, until someone else comes along
> and enslaves it again. Then you're screwed."
>
Define enslave??? Once it has been released, it is free. If someone spends
lots of time designing a proprietary mod, and they want to make money, they
can. They have not lost any intellectual property freedoms if they want
to sell the code. Most enhancements can be replicated by the free community.
In essence, software that is out in the open is relatively unencumbered
(compared to GPL.) And intellectual property rights are not signed away...
>Commercial license says:
> "You've been screwed. We already have your money."
>
>What was the definition of 'free' again?
Definitely not what GPL says :-).
Who is lying??? This silly argument is taking valuable time for some
major performance updates on FreeBSD -- but I'll tell you that it is obvious
that the GPL crew is interested in perpetuating the myth... I really
don't care what license terms that someone uses -- just so that they
understand the risks. It is obvious that there is a sales job going on
here FOR GPL... This is *very* interesting indeed.
John Dyson
Per Abrahamsen
>>>>> "MS" == Mike Stump <m...@kithrup.com> writes:
MS> This is a well founded reason for not using GPL, if you want to use
MS> license other people's work, as if you had written it. Use the BSD
MS> style copyright, instead. It permits this type of use.
How does it permit that?
Is a modification of an original work automatically covered by the
same license as the original work, if you do not state otherwise?
Paul D. Smith
%% dy...@inuxs.inh.att.com (John S. Dyson) writes:
jsd> In article <4cdano$4...@news.aloha.com>, Jimen Ching
jsd> <jch...@aloha.com> wrote:
>> 1. GPL source code can not be commercialized.
jsd> Not by me... Not a lie... I guess if I want to do something that
jsd> is not in my interest, I could commercialize it.
When you speak in absolutes, what you say must be absolutely true.
Otherwise you're giving disinformation.
Until we define "commercialize" this can't be rationally discussed.
Let's try some definitions of commercialized and see what the GPL says
about them:
* Taking code you own and selling it for money, under the terms of the
GPL (freely redistributable, source code included).
This is fine, no problem. GPL allows this.
* Taking code you own and selling it for money, under licensing terms
other than the GPL.
This is also fine: you own the code, you can do what you want with
it.
* Taking GPL'd code you don't own and selling it for money, under the
terms of the GPL (freely redistributable, source code included).
This is also fine, nothing in the GPL that prevents it.
* Taking GPL'd code you don't own and selling it for money, under
licensing terms other than the GPL, after contacting the owner and
getting permission.
This is _also_ fine: the owner can release you from the terms of his
license if he pleases.
* Taking GPL'd code you don't own and selling it for money, under
licensing terms other than the GPL, without the owner's permission.
Aha! Here we go. This is not allowed by the GPL.
So, if you define "commercialized" as the last one, then you're right,
GPL source code cannot be commercialized in that way. However, I doubt
if you asked 100 people what "commercializing" software means that more
than a couple, if any, would give that last definition.
So if you want to say "GPL source code can't be commercialized", please
also state what you mean by commercialized, since it's not the "normal"
definition.
>> 2. GPL takes away the rights of the author of the source code.
jsd> Yes it does, when modifications are under GPL.
Argh! NO! The _AUTHOR_ of the source code maintains _ALL_ of his
rights! If you're talking about "modifications" (that you didn't make),
then you're _NOT_ the author of those modifications! Someone else is!
_THEY_ maintain the rights to the modifications, not you. What is so
complex about this?
>> 5. GPL is not really *FREE*.
jsd> Depending on what you define to be free.
No, it depends on what _you_ define to be free. If you make statements
like "GPL'd software isn't really free", then it's your responsibility
to define what you mean by "free".
What the GPL means by free is clearly stated in the GPL itself and in
parts of the GNU manifesto.
If you feel that there is an inaccuracy there such that GPL'd software
_isn't_ free by the definition provided, then that's a valid statement
and certainly worthy of discussion.
If your definition of free doesn't jibe with that one, then you can also
say "I don't believe GPL'd software is free, because I define free to be
xxx instead". That is also a valid statement, although somewhat
useless, since it's obvious: if you use a different definition of the
term then you obviously get a different result.
>> 4. GPL says: "You can not take away the rights of others which
>> you, yourself were given."
jsd> But if I add modifications, and want to redistribute the object
jsd> code, I also have to redistribute the source. Trade secrets
jsd> are important to many real companies.
Look, if you want to have "trade secrets", then don't build your code on
GPL'd code. No great mystery. No big conspiracy.
>> Commercial license says:
>> "You've been screwed. We already have your money."
jsd> You have been dealing with the wrong companies -- cynical attitude.
It is a fact that companies have to prioritize changes to their
software. If their priorities don't dovetail with yours, and they often
don't, you're screwed (in the sense that your needs aren't being met and
there's nothing you can do about it). This is _every_ company, not just
the "wrong" ones.
Sure, they'll fix big problems. Some even do so in a timely fashion,
although rarely as fast as you need them :). But smaller problems,
enhancements you may want, etc. are all much lower on the list. And
you're screwed because there's nothing you can do about it, short of
coming up with a _lot_ of money to convince them to change their
priorities.
With GPL software you _always_ have another option: do it yourself.
Send back the changes, and hopefully they'll be incorporated. If
they're not, you can just re-patch new versions yourself (see my VPATH+
patch to GNU make).
>> What was the definition of 'free' again?
jsd> Definitely not what GPL says :-).
The GPL and GNU Manifesto define what they mean by "free". Are you
saying that, based on their definition, GPL'd software isn't free?
Or are you saying that you don't agree with their definition of "free"?
You need to state your definition so we can tell what you mean by it.
jsd> Who is lying??? This silly argument is taking valuable time
jsd> for some major performance updates on FreeBSD -- but I'll tell
jsd> you that it is obvious that the GPL crew is interested in
jsd> perpetuating the myth... I really don't care what license
jsd> terms that someone uses -- just so that they understand the
jsd> risks. It is obvious that there is a sales job going on here
jsd> FOR GPL... This is *very* interesting indeed.
Again, the implication that something slimy or underhanded is going on.
*Sigh*.
All we are trying to do is make sure people understand the risks as
well. But the "risks" you claim are largely inaccurate, and continue to
be so after many explanations.
It's no big secret, no great myth, no lies being expounded on this side.
It's very simple and straightforward.
If you write code, and place it under the GPL, then it ensures that
anyone who distributes _your_ code cannot restrict it from being freely
redistributed, and must provide the source. If you like, you can still
take _your_ code, and relicense it differently, and do something else
with it.
If you want to use someone _else's_ code, even if it consists of
additions to your code, you still have to obey the terms of the license
they provide the addition to you under. They own it, it's their terms.
The same is true of BSD code: just because your original code was under
BSD is _no_ gaurantee that someone won't put their modifications under a
different license, so you couldn't use them anyway.
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
Senior Software Engineer Bay Networks, Inc.
-----------------------------------------------==<http://www.baynetworks.com/>-
"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.
Jimen Ching
>Dyson> But, I cannot make proprietary mods to gain competitive advantage
>Dyson> in a free market, and to me that breaks GPL.
>that the the GPL was not designed to serve *your* aims.
>So what's this discussion really about?
The thread started out with Mr. Dyson saying GPL doesn't meet his needs.
Unfortunately, he went on to spread lies about GPL to backup his point.
Here are some of the of lies Mr. Dyson tried to spread. And this thread
is about correcting those lies.
Lies about GPL:
1. GPL source code can not be commercialized.
2. GPL takes away the rights of the author of the source code.
3. Modifications of GPL source code MUST go under the GPL.
4. GPL has *MORE* restrictions (than BSD? Commercial licenses?).
5. GPL is not really *FREE*.
Truths about GPL:
1. Depending on how you want to commercialize GPL source code, many
companies have done so. See www.cygnus.com or www.crynwr.com for
some examples.
2. No license can ever do this. The only way authors can lose rights
to source code they have written is if they released the code to the
public domain. If you do not believe this, print out a copy of the GPL
and take it to your lawyer.
3. GPL can not force authors of modifications to do anything they do
not want to do. What the GPL *says* is that IF AND ONLY IF you want
to distribute that modification, THEN it MUST go under the GPL. Note:
the word 'modification' has a special meaning, please read the GPL for
further details.
4.
GPL says:
"You can not take away the rights of others which you, yourself were
given."
BSD License says:
"You must include our name."
Commercial license says:
"You've been screwed. We already have your money."
5.
GPL says:
"This source code has been liberated."
BSD says:
"This source code has been liberated, until someone else comes along
and enslaves it again. Then you're screwed."
Commercial license says:
"You've been screwed. We already have your money."
What was the definition of 'free' again?
--jc
Daniel Reish
John S. Dyson <dy...@inuxs.inh.att.com> wrote:
>Jimen Ching <jch...@aloha.com> wrote:
[...]
>>2. GPL takes away the rights of the author of the source code.
>Yes it does, when modifications are under GPL.
In which case, the author of the modifications owns the copyright to
those modifications. Work out something with that author if you want
to sell his code.
You seem to be asking for something to be granted to you automatically
(the right to sell other people's modifications to your code). The
polite way to handle this is to _ask_ first.
We've gone over this several times already, haven't we?
[...]
>>Truths about GPL:
>>
>>1. Depending on how you want to commercialize GPL source code, many
>>companies have done so. See www.cygnus.com or www.crynwr.com for
>>some examples.
>I guess that you CAN jump off a building, but it is not in your interest.
Oops!
*plonk*
--
Dan
John S. Dyson
> So, if you define "commercialized" as the last one, then you're right,
> GPL source code cannot be commercialized in that way. However, I doubt
> if you asked 100 people what "commercializing" software means that more
> than a couple, if any, would give that last definition.
>
>
> No, it depends on what _you_ define to be free. If you make statements
> like "GPL'd software isn't really free", then it's your responsibility
> to define what you mean by "free".
>
>
> Look, if you want to have "trade secrets", then don't build your code on
> GPL'd code. No great mystery. No big conspiracy.
>
Right... That and the above is the reason that the GPL license is not
generally applicable to commercial use.
>
> Sure, they'll fix big problems. Some even do so in a timely fashion,
> although rarely as fast as you need them :). But smaller problems,
> enhancements you may want, etc. are all much lower on the list. And
> you're screwed because there's nothing you can do about it, short of
> coming up with a _lot_ of money to convince them to change their
> priorities.
>
So... I usually haven't had a problem. In the case of having serious
bugs, workarounds have usually been developed.
>
> With GPL software you _always_ have another option: do it yourself.
> Send back the changes, and hopefully they'll be incorporated. If
> they're not, you can just re-patch new versions yourself (see my VPATH+
> patch to GNU make).
>
How long has the X86 strength reduce bug been in GCC???
>
> The GPL and GNU Manifesto define what they mean by "free". Are you
> saying that, based on their definition, GPL'd software isn't free?
>
> Or are you saying that you don't agree with their definition of "free"?
> You need to state your definition so we can tell what you mean by it.
>
Yep, my definition of free is closer to the BSD license, except I agree
that attribution is an encumberance -- although minor. The problem with
GPL is that the term "free" is so ambiguous and is used in public without
qualification.
>
> Again, the implication that something slimy or underhanded is going on.
> *Sigh*.
^^^^^^ Condesending...
>
How do you know what I am thinking??? I did not bring that up, but
if you think that independently -- convince yourself. Are you worried
that other people might think that??? If they do, then you have a sales
job... Putting me down in public isn't going to help the cause of GPL.
GPL is an enigma, with subtile consequences. The way that Cygnus
does business and how it can be profitable was a total mystery to me.
>
> It's no big secret, no great myth, no lies being expounded on this side.
> It's very simple and straightforward.
>
No it hasn't been, and with the latest revelations, I now understand
how it works. It is in no way "free" software for the masses. The
use of the word free obscures what it really is.
>
> If you write code, and place it under the GPL, then it ensures that
> anyone who distributes _your_ code cannot restrict it from being freely
> redistributed, and must provide the source. If you like, you can still
> take _your_ code, and relicense it differently, and do something else
> with it.
>
Hmmm, so Cygnus does not restrict the distribution of other's code by
denying a request for it??? I have not found FTP sites that have the code
that they allege that they provide to customers. I wonder why the customers
don't put the code up for ftp... There probably is no agreement between
Cygnus and the customers -- but their code is not available to me.... Hmmm...
If I had been an author of such code, I would not even be able to see the
results of my work (in a practical sense.) Sounds alot like BSD to me...
See, I have been trying to find out how the use of GPL can be profitable,
and as I said, it is my belief that small companies need some kind of
"edge"... One of the things that give Cygnus the edge is that people
"dont" redistribute their code even though they can... It actually is
probably not in Cygnus' customers best interest.
>
> The same is true of BSD code: just because your original code was under
> BSD is _no_ gaurantee that someone won't put their modifications under a
> different license, so you couldn't use them anyway.
>
Sure, but BSD code "allows" freedom of choice by people who posess it. GPLed
code puts such serious limitations on that by forcing disclosure of trade
secrets -- if the code with the trade secrets is derived from the GPLed
code. Note that technically, you are free to jump off of a building, but
practically not -- GPL puts a similar kind of restriction on software.
John Dyson
John S. Dyson
as evidenced by the bogus header. It WAS NOT meant to be public, but
a private (personal) reply... Why do people send email like this with the
autopost "trick" reply???
From dy...@inuxs.INh.ATt.COM Thu Jan 4 13:05:08 EST 1996
Article: 12788 of gnu.misc.discuss
Path: nntphub.cb.att.com!gw2.att.com!pacbell.com!ihnp4.ucsd.edu!swrinde!cs.utexas.edu!howland.reston.ans.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!inuxs.INh.ATt.COM!dyson
From: dy...@inuxs.INh.ATt.COM (John S. Dyson)
Newsgroups: gnu.misc.discuss
Subject: Re: [Q] GPL violation.
Date: 4 Jan 1996 10:23:04 -0500
Organization: GNUs Not Usenet
Lines: 105
Sender: dae...@cis.ohio-state.edu
Distribution: gnu
Message-ID: <960104152...@inuxs.inh.att.com>
References: <960103214...@lemming.engeast>
>
> So, if you define "commercialized" as the last one, then you're right,
> GPL source code cannot be commercialized in that way. However, I doubt
> if you asked 100 people what "commercializing" software means that more
> than a couple, if any, would give that last definition.
>
But that is the way that most people sell software...
etc...
John Dyson
Per Abrahamsen
JSD> I guess if I want to do something that
JSD> is not in my interest, I could commercialize it.
This is not a lie, but the formulation is misleading. It would be
true of I said the same for software under the BSD license.
> 2. GPL takes away the rights of the author of the source code.
JSD> Yes it does, when modifications are under GPL.
Again not a lie as stated, but misleading since you don't loose any
right which you wouldn't also loose by distributing the software under
a BSD license.
> 3. Modifications of GPL source code MUST go under the GPL.
JSD> I did not know that. Where does it say that in the GPL?
Nowhere, since it is a lie.
> 4. GPL has *MORE* restrictions (than BSD? Commercial licenses?).
JSD> It does (than BSD.)
True.
> 5. GPL is not really *FREE*.
JSD> Depending on what you define to be free.
True. The "freedom" in the GPL is the kind of freedom that doesn't
include the right to restrict the freedom of other people.
Paul D. Smith
%% dy...@inuxs.inh.att.com (John S. Dyson) writes:
me> * Taking GPL'd code you don't own and selling it for money, under
me> licensing terms other than the GPL, without the owner's permission.
>> So, if you define "commercialized" as the last one, then you're
>> right, GPL source code cannot be commercialized in that way.
jsd> But that is the way that most people sell software...
Eh? I feel like I'm in a carnival fun house :-/ :)
You said GPL code cannot be commercialized. Jimen said that wasn't
true. You reiterated it couldn't be commercialized by you. I provided
a list of 5 definitions of "commercialize" that _were_ legal under the
GPL, and one definition that wasn't.
Do you now claim that that one definition (taking code you didn't write,
changing the licensing terms without permission, then selling it) is
actually how most people sell software? Seriously?
>> Look, if you want to have "trade secrets", then don't build your
>> code on GPL'd code. No great mystery. No big conspiracy.
jsd> Right... That and the above is the reason that the GPL license
jsd> is not generally applicable to commercial use.
Again, you have failed to define "commercial", so it's impossible to
tell if that statement is true. Certainly many people here have posted
many instances where "commercial use", if you use a definition of
"making money from it", of GPL'd software is perfectly applicable.
If you define "commercial use" to mean restricting the rights of your
customers so they can't redistribute your code or product, then yes, the
GPL isn't generally applicable to commercial use. I can't recall a
single person on this thread denying that.
jsd> The problem with GPL is that the term "free" is so ambiguous
jsd> and is used in public without qualification.
Not true. It is very rarely used without reference to the GPL and/or
the GNU manifesto, both of which define what "free" means in that
context quite clearly.
jsd> GPL is an enigma, with subtile consequences. The way that
jsd> Cygnus does business and how it can be profitable was a total
jsd> mystery to me.
Then say "hey, how does Cygnus do business and how can it be profitable,
since it uses the GPL?", and it will be explained. There's no need to
imply that there's something sneaky about how it works, and that because
Cygnus makes money they are all of a sudden not truly dealing in free
software and hiding behind a "twist" of the GPL. I quote the relevant
paragraph below, since it was actually on another thread:
jsd> Since I don't have much money to spend on the software (because
jsd> of the marginal differences between the freely available
jsd> versions and the "commercial" not-available free versions
jsd> (interesting combination of words) :-)), the "commercial"
jsd> version is not free to me. Where is the "freedom-of-software"
jsd> notion here... I am so confused... Another twist to GPL...
>> It's no big secret, no great myth, no lies being expounded on
>> this side. It's very simple and straightforward.
jsd> No it hasn't been, and with the latest revelations, I now
jsd> understand how it works. It is in no way "free" software for
jsd> the masses. The use of the word free obscures what it really
jsd> is.
Why isn't it free software for the masses? You can use the software,
personally, however you like. You get the source code. You can use the
software on as many systems as you like (even all at the same time :).
You can give the software to as many friends and neighbors as you like,
or email it out, or put it up for anonymous ftp.
Sounds free to me.
What you can't do is restrict others' rights to use it (unless you wrote
it yourself). But it's still free. Where's the mystery?
>> If you write code, and place it under the GPL, then it ensures
>> that anyone who distributes _your_ code cannot restrict it from
>> being freely redistributed, and must provide the source. If you
>> like, you can still take _your_ code, and relicense it
>> differently, and do something else with it.
jsd> Hmmm, so Cygnus does not restrict the distribution of other's
jsd> code by denying a request for it??? I have not found FTP sites
jsd> that have the code that they allege that they provide to
jsd> customers.
"Allege"? Now you're implying that they're liars? Why do you insist on
this rhetoric? My company has a contract with Cygnus. They have done
real work for us, and good work too. They aren't "alleging" anything.
You say you have found no FTP sites with the code. Have you asked on
gnu.gcc.help to see if anyone has it and is willing to share it with
you?
jsd> I wonder why the customers don't put the code up for ftp...
Maybe they have, and you just don't know about it. Maybe they don't
have the internet bandwidth to be willing to do so. Maybe they just
never thought of it.
jsd> There probably is no agreement between Cygnus and the customers
There definitely is not, that would be illegal.
jsd> and as I said, it is my belief that small companies need some
jsd> kind of "edge"... One of the things that give Cygnus the edge
jsd> is that people "dont" redistribute their code even though they
jsd> can... It actually is probably not in Cygnus' customers best
jsd> interest.
_What_?!? That's ridiculous. You're implying that there's some kind of
silent "conspiracy of hoarding" between Cygnus and its customers?
You have to expand your vision a little bit: there are many ways to make
a profit other than keeping everything secret!
What gives Cygnus an "edge" is that they have extremely good technical
people, they have competitive pricing, they have excellent customer
support (you can get 24- and 48-*HOUR* turnaround on bug fixes, for
example, something no commercial vendor provides), and they have great
products that people want, and want to have supported.
Paul D. Smith
%% dy...@inuxs.inh.att.com (John S. Dyson) writes:
jsd> The last article posted was not posted by me, but an automated
jsd> system as evidenced by the bogus header. It WAS NOT meant to
jsd> be public, but a private (personal) reply... Why do people
jsd> send email like this with the autopost "trick" reply???
It's not a "trick". Some people don't read or have access to
gnu.misc.discuss as a newsgroup, and instead use the mailing list
gnu-misc...@cis.ohio-state.edu.
The newsgroup and the mailing list are gatewayed together so that people
on the mailing list aren't left out of newsgroup discussions, and vice
versa. See the MAILINGLISTS file, either in your Emacs distribution or
via anonymous ftp from wherever you get GNU software.
If you want to reply privately, use the "Reply" functionality of your
mailer; that will reply only to the person the message is from. If you
want to reply to all the people who got the original message, use the
"Followup" functionality of your mailer, which will reply to the
originator and all the CC'd people as well.
If your mailer doesn't make a distinction between them, you need a
better mailer :)
Stan Shebs
Hmmm, so Cygnus does not restrict the distribution of other's code by
denying a request for it??? I have not found FTP sites that have the code
that they allege that they provide to customers. I wonder why the customers
don't put the code up for ftp... There probably is no agreement between
Cygnus and the customers -- but their code is not available to me....
Off the top of my head, I know that AMD, IDT, Lynx, Hitachi, and
Fujitsu redistribute Cygnus' releases more-or-less verbatim, typically
along with chip eval kits and the like. Hundreds or maybe even thousands
of these are out there somewhere, and any one of those could easily be
put up for ftp (and probably have been).
We also make snapshots available to developers, although we don't
announce those everywhere, so that naive users don't try to use them
(they don't always work). If you haven't found those snapshots
available for ftp, then you can't have been looking very hard!
Stan Shebs
Cygnus Support
sh...@cygnus.com
Greg Stark
The last article posted was not posted by me, but an automated system
as evidenced by the bogus header. It WAS NOT meant to be public, but
a private (personal) reply... Why do people send email like this with the
autopost "trick" reply???
Sigh, you must be using Pine. It wasn't any ``automated system'' just your
newsreader/mailer. Its non-intuitive handling of the newsgroups header has
given a lot of people grief. Of course you should always check the headers
before you send mail anyways.
Back on topic, you have to ask yourself one question:
Why do you write free software.
The GPL was written because the authors believed hoarding software is wrong.
Your indictment of the GPL seems to be essentially, that you want to be able
to hoard if it gives you a competitive advantage. Obviously you don't agree
with the basic tenets the GPL was written to support, so why _do_ you write
free software?
If you don't care about people hoarding you software, then of course the
license designed to prevent that isn't going to be helpful to. If all you
care about is fame then the BSD license will serve. The FSF programmers and
the other programmers that release GPL'd free software really are concerned
about ensuring their software remains free.
--
greg
Tim Smith
>The thread started out with Mr. Dyson saying GPL doesn't meet his needs.
>Unfortunately, he went on to spread lies about GPL to backup his point.
>BSD says:
> "This source code has been liberated, until someone else comes along
> and enslaves it again. Then you're screwed."
If you are going to accuse others of lying, you should try to avoid making
up your own blatant lies, like that one.
--Tim Smith
Erik Corry
: The argument that an author may distribute under several licenses
: does not satisfy the claim that the GPL'ed code can in fact be
: commercialized. Since the distribution under the secondary
: license is a distribution of pre-GPL'ed code, it can not in fact
: be said to be commercialization.
No, it can be post-GPL'ed code, as long as all copyright-holders
agree. See Aladdin Ghostscript, which is based on GNU Ghostscript.
Of course in this case you have to compete against the old GPL version
of the software.
: In addition, the author explicitly cedes the right to make
: derivative works from the published sources, except in compliance
: with the terms of the license under which the sources were
: published (in this case, GPL: the same is true of the UCB license).
See above. The author can make a derivative work without complying
with the GPL.
: The author implicitly cedes the right of sublicense. That is,
: modifications by him to the GPL release must be in accordance
: with the license.
No.
: Many people find this insidious and damaging to commercialization
: (statements #1), since this effectively prevents the author from
: making derivative works of the derivatives of his original work
: under any but GPL terms. Thus he has lost the right of attaching
: conditions to sublicense.
Yes, he cannot make derivatives of the derivatives of his original
work without the permission of those that made the improvements
to his original work. That's only reasonable, since many people
would not have bothered to make and release the changes if the
software had not been under the GPL.
: | 3. Modifications of GPL source code MUST go under the GPL
: | if they are to be used to obtain commercial advantage
: | directly.
The notable exceptions to this rule are modifications made by the
copyright holder himself.
: These seem a bit more onerous than the "encumberance" on your
: licensees than simply witholding your endorsement for the code
: or its derivatives.
I would agree that the GPL is more restrictive than the BSD license,
and this is what the authors like about it. Linux was initially
distributed with a non-commercial license: the switch to GPL was
a removal of restrictions. I can well understand that Linus did
not want to go to the BSD license: the risk of losing control of
Linux altogether would have been much greater in this case.
--
You couldn't deny that, even if you tried with both hands. -- The Red Queen
--
Erik Corry ehc...@inet.uni-c.dk
Terry Lambert
] The thread started out with Mr. Dyson saying GPL doesn't meet his needs.
] Unfortunately, he went on to spread lies about GPL to backup his point.
] is about correcting those lies.
]
] Lies about GPL:
]
] 1. GPL source code can not be commercialized.
] 3. Modifications of GPL source code MUST go under the GPL.
] 4. GPL has *MORE* restrictions (than BSD? Commercial licenses?).
] 5. GPL is not really *FREE*.
]
] Truths about GPL:
]
] 1. Depending on how you want to commercialize GPL source code, many
] companies have done so. See www.cygnus.com or www.crynwr.com for
] some examples.
These companies operate by restricting their distribution channel
in order to create an artificial scarcit (see Mike Stump's postings
on defining "proprietary").
In all cases, profit is tangential. That is, the code itself is
not commercialized. Distribution is, support is, creation of
additional code. But not the code itself.
The argument that an author may distribute under several licenses
does not satisfy the claim that the GPL'ed code can in fact be
commercialized. Since the distribution under the secondary
license is a distribution of pre-GPL'ed code, it can not in fact
be said to be commercialization.
Thus we have a specious argument by both parties: the statement
#1 in the "lies" list implies that releasing under GPL prevents
commercialization of code so distributed. This falsely supports
statement #2 in the "lies" list. But statement #1 in the "truths"
list relies on an atypical usage of the word "commercialize".
] 2. No license can ever do this. The only way authors can lose rights
] to source code they have written is if they released the code to the
] public domain. If you do not believe this, print out a copy of the GPL
] and take it to your lawyer.
The strong initial sentence in statement #2 of "truths" is, in
fact, incorrect. A license which can take away an authors rights
is called an "assign".
Since corporations, as fictional legal entities, can not submit
patent claims, an assign is the typical mechanism a corporation
would use, generally using part of an employment or other civil
contract as an instrument, to obtain rights.
Nevertheless, the rest of the statement is more or less correct:
an author ma not be deprived of rights unless he assigns them.
Assignment to the "Publio Domain" isone mechanism.
However, the author does explicitly and implicitly assign some
rigts under GPL. As long as the GPL conditions are obeyed, the
author may not void the license. He trades these rights as a
"valuable consideration" for an obligation on the part of the
licensee. Without this "valuable consideration", GPL would be
legally unenforcible.
The Author explicitly cedes joint publication rights to the
original sources. This allows publication without his permission
without diminishing his ability to publish the sources himself.
In addition, the author explicitly cedes the right to make
derivative works from the published sources, except in compliance
with the terms of the license under which the sources were
published (in this case, GPL: the same is true of the UCB license).
The author implicitly cedes the right of sublicense. That is,
modifications by him to the GPL release must be in accordance
with the license.
Many people find this insidious and damaging to commercialization
(statements #1), since this effectively prevents the author from
making derivative works of the derivatives of his original work
under any but GPL terms. Thus he has lost the right of attaching
conditions to sublicense.
] 3. GPL can not force authors of modifications to do anything
] they do not want to do. What the GPL *says* is that IF AND
] ONLY IF you want to distribute that modification, THEN it
] MUST go under the GPL. Note: the word 'modification' has a
] special meaning, please read the GPL for further details.
Statement #3 in "lies" is false IFF the intent of the modifying
author is to distribute the resulting combined binaries without
source.
Since the purpose of such a distribution would be to provide the
author of the modifications with commercial advantage (note: NOT
necessarily "competitive advantage"), the net effect is to make
the statement require the following addendum to be true:
| 3. Modifications of GPL source code MUST go under the GPL
| if they are to be used to obtain commercial advantage
| directly.
This is a defnsible statement, since, for instance, modification
of the GCC compiler to produce faster code, then using the
modified compiler to compile the unmodified GCC sources and then
distributing the binaries for the unmodified compiler (but compiled
with the modified compiler), and the sources to the unmodified
compiler, would comply with the terms of the GPL.
Thus it is possible to commercially advantage yourself using
GPL'ed code for which source is not distributed: if the end
user compiles the GCC sources with the GGC compiler, he will
not obtain an identical binary to that provided: he will get
a binary that, in fact, compiles code slower.
So it is a difficult stretch to make the ammended statement #3
in the "lies" list actually false.
] 4.
] GPL says:
] "You can not take away the rights of others which you, yourself were
] given."
]
] BSD License says:
] "You must include our name."
]
] Commercial license says:
] "You've been screwed. We already have your money."
This response does not address the veracity of statement #4
in the "lies" list. It is not a refutation, and therefore
not a defense of your characterization of that statement as
a "lie".
] 5.
] GPL says:
] "This source code has been liberated."
]
] BSD says:
] "This source code has been liberated, until someone else comes along
] and enslaves it again. Then you're screwed."
]
] Commercial license says:
] "You've been screwed. We already have your money."
]
] What was the definition of 'free' again?
"Without encumberances".
The BSD license has encumberances:
1) Hold harmless
2) No assignation of endorsement, even without
subsequent code modification
3) A claim credit clause
The GPL has similar encumberances, though does not prevent
implied assignment of endorsement to the code or derivatives
(number 2 in the BSD encumberance list).
In addition, it has the following encumberances:
1) If you wish to distribute modified GPL'ed code,
you must distribute your modifications under
the same terms. That is, you must assign some
of your rights.
2) If you wish to distribute without sources to
allow yourself a market window in which your
competition does not have immediate access to
leverage your effort and destroy your value
proposition, you must agree to become a GPL
source distributor for the modified sources
for a period of two years.
These seem a bit more onerous than the "encumberance" on your
licensees than simply witholding your endorsement for the code
or its derivatives.
Regards,
Terry Lambert
te...@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Terry Lambert
] >>> On Tue, 2 Jan 1996 09:00:32 GMT, ro...@dyson.iquest.net (John
] >>> S. Dyson) said:
] Dyson> in a free market, and to me that breaks GPL.
]
] But, the _goal_ of the GPL is precisely to prevent proprietary mods, as
] its aim is to promote the widest sharing of sw. You seem to be arguing
] that the the GPL was not designed to serve *your* aims.
The goal and the aim are contradictory. As is the implied goal
of promoting the GPL.
To wit: John does not share his software, the aim of the GPL,
because of the baggage carried with the GPL in its attempt
to achieve its _goal_ would cause John to violate his own
self interest.
Thus the _goal_ of the GPL thwarts its aim.
The aim is subservient to the goal.
John agrees with the aim.
John S. Dyson
Stan Shebs <sh...@cygnus.com> wrote:
>
>We also make snapshots available to developers, although we don't
>announce those everywhere, so that naive users don't try to use them
>(they don't always work). If you haven't found those snapshots
>available for ftp, then you can't have been looking very hard!
>
even announce pre-releases with the appropriate caveats... It might help
you debug your code better. There are alot of people on the periphery of
FreeBSD development that help find bugs... We do pretty openly announce
such info...
John Dyson
Marcus Daniels
>>>>> "Tim" == Tim Smith <t...@coho.halcyon.com> writes:
Jimen> "This source code has been liberated, until someone else comes along
Jimen> and enslaves it again. Then you're screwed."
Tim> If you are going to accuse others of lying, you should try to
Tim> avoid making up your own blatant lies, like that one.
A lie merely because the BSD license doesn't say that literally?
It is a fact that someone can come along and hoard BSD licensed source
code.
Marcus Daniels
>>>>> "Terry" == Terry Lambert <te...@lambert.org> writes:
Terry> The goal and the aim are contradictory. As is the implied goal
Terry> of promoting the GPL.
Often, it seems, they aim and the goal are at odds, but they are not
contradictory.
Terry> To wit: John does not share his software, the aim of the GPL,
Terry> because of the baggage carried with the GPL in its attempt to
Terry> achieve its _goal_ would cause John to violate his own self
Terry> interest.
Terry> Thus the _goal_ of the GPL thwarts its aim.
Terry> The aim is subservient to the goal.
There are examples, like bison, where the goal becomes subservient to the
aim. Another example is the tolerance for the proprietary
idiosyncrasies of Unix OS's (GNU autoconf).
Terry> John agrees with the aim.
Maybe someday John will be sufficiently motivated by a GPLed program,
to accept the GPL terms in particular cases. Maybe not.
But come to find out (ahem) John was not even aware of the goal, only the aim.
Terry Lambert
]
] In article <4ce6c5$8...@nntpb.cb.att.com>,] >>2. GPL takes away the rights of the author of the source code.
] >
] >Yes it does, when modifications are under GPL.
] In which case, the author of the modifications owns the copyright to
] those modifications. Work out something with that author if you want
] to sell his code.
]
] You seem to be asking for something to be granted to you
] automatically (the right to sell other people's modifications
] to your code). The polite way to handle this is to _ask_ first.
]
] We've gone over this several times already, haven't we?
I don't think so.
John is making a distinction between the original author wanting
to make a derivation of a derivative work of the original code.
GPL wants to prevent proprietary derivation by third parties.
It is unclear whether the original author is included in "third
parties" intentionally or by omission.
The FSF itself avoids this issue by incorporting code for which
the copyright has been assigned to the FSF.
John would like to do the same, it seems, without the assignment
of the copyright, rather using a mutual colicensing.
John needs a legal instrument other than the GPL to do what
he wants.
Russ Allbery
> GPL wants to prevent proprietary derivation by third parties.
> It is unclear whether the original author is included in "third
> parties" intentionally or by omission.
Neither. The original author isn't included in "third parties" at all.
--
Russ Allbery (r...@cs.stanford.edu) http://www-leland.stanford.edu/~rra/
Erik Bennett
Terry Lambert <te...@lambert.org> wrote:
>pier...@sabi.demon.co.uk (Piercarlo Grandi) wrote:
>] >>> On Tue, 2 Jan 1996 09:00:32 GMT, ro...@dyson.iquest.net (John
>] >>> S. Dyson) said:
>] Dyson> But, I cannot make proprietary mods to gain competitive advantage
>] Dyson> in a free market, and to me that breaks GPL.
>]
>] But, the _goal_ of the GPL is precisely to prevent proprietary mods, as
>] its aim is to promote the widest sharing of sw. You seem to be arguing
>] that the the GPL was not designed to serve *your* aims.
>
>
>To wit: John does not share his software, the aim of the GPL,
>self interest.
>
>Thus the _goal_ of the GPL thwarts its aim.
>
>
>
>
> te...@cs.weber.edu
Indeed. While working for the USDA, I developed an entire,
independent application, but a I made the unfortunate choice of using
gdbm. I read, and followed to the letter, the terms and conditions of
the GPL. I didn't change it. I didn't distribute it, and I didn't say it
was mine. I was told, that even though I in no way distributed gdbm, that
my ENTIRE application now fell under the GPL because it was a
"Phantom Distribution", and the application was a derived work. Funny
that these people who speak so often about freedom were trying to
scoop the rights to the software.
I agreed in spirit with the GPL, but its implementation is a little
bit like a viral infection. I agree that it would be swell to have a
nice base of free (there's that word again) code, but it really isn't
a whole lot of good if the price for using it is so high.
p.s. I have a question for anyone in the know:
If I write a shell script that uses features specific to GNU find, does
that shell script fall under the terms of the GPL?
Suppose those features turn up in BSD find later? Does that affect anything?
Thanks.
-Erik
--
-Erik
----------------------------------------------------------------------------
Erik Bennett ben...@corp.oneworld.com
One World Internetworking, Inc. Ph: 503-758-1112
1763 NW Kings Blvd.
Corvallis, Oregon 97330
Sakari Jalovaara
> eb> application, but a I made the unfortunate choice of using gdbm.
> [...and was told that his code would fall under the GPL]
> Eh? That doesn't make any sense.
> Since no actual GPL'd code is included, it cannot come under GPL.
I agree with you; I don't think it makes any sense either.
As not a sincle byte of GPL'd code is copied, the GPL does not apply.
Unfortunately, it appears Richard Stallman disagrees with both of us.
If a piece of code calls a GPL'd function, and no implementation of
that function exists under any other copyright, the calling code
supposedly falls under the GPL if distributed. Whether the author
wants that or not.
A program ("RIPEM") was distributed in source form some months ago.
That program could, with suitable compilation options, compiled to use
a GPL'd mathematics library. Mr. Stallman told the authors they can't
do that. The matter was resolved (for that program) by writing
a non-GPL-encumbered library with a similar programming interface.
I don't think US copyright law or intenational agreements can be that
silly. I'm not 100% certain, though; it sure prevented me from giving
away a port of a free program that used system services implemented by
only one UNIX vendor.
++sja
John S. Dyson
Nope, once the code has been released, it can't be practically revoked... Now
if someone decides that they need to keep their own intellectual property
secret (which is morally and legally within their rights using BSD licensed
code, with few restrictions) they can do that. In essence, a third party
cannot take others rights to BSD licensed source code away.... How can they???
It is absurd...
In essence:
John produces BSD licensed software.
Mary uses the BSD licensed software and redistributes it.
Sam uses the BSD licensed software, adds to it, and redistributes it.
Sam cannot take Mary's license away from her...
John Dyson
Per Abrahamsen
>>>>> "Tim" == Tim Smith <t...@coho.halcyon.com> writes:
Jimen> "This source code has been liberated, until someone else comes along
Jimen> and enslaves it again. Then you're screwed."
Tim> If you are going to accuse others of lying, you should try to
Tim> avoid making up your own blatant lies, like that one.
>>>>> "MD" == Marcus Daniels <mar...@sysc.pdx.edu> writes:
MD> It is a fact that someone can come along and hoard BSD licensed source
MD> code.
The original copy will still be free. I agree with Tim here.
Mr. Ching's statement is just as unacceptable as those of Mr. Dyson.
Paul D. Smith
%% dy...@inuxs.inh.att.com (John S. Dyson) writes:
>> The last article posted was not posted by me, but an automated
>> system as evidenced by the bogus header. It WAS NOT meant to be
>> public, but a private (personal) reply... Why do people send
>> email like this with the autopost "trick" reply???
> Sigh, you must be using Pine.
jsd> Elm, and I just trusted the sender... Shouldn't do that
jsd> though...
I'm not completely sure, but (as the original sender of the message John
is complaining about) I think I should be offended here: are you
implying that I can't be trusted, or that I was guilty of some kind of
improper netiquette?
I've already explained the situation. There's a mailing list for this
newsgroup for people who can't or don't want to read it via news. The
only way people on this mailing list can put public articles out is to
CC them to the mailing list, since they don't use the newsgroup. I did
this. John followed up to my message, instead of replying, which means
that his reply went to the mailing list as well, and was subsequently
posted here.
There is no trickery or anything involved: it's not a matter of
"trusting the sender". John, you just messed up. No big deal, could
happen to anyone, but please don't try to make it sound like it's anyone
else's fault or someone else was the cause of the problem.
Tim Smith
>Jimen> "This source code has been liberated, until someone else comes along
>Jimen> and enslaves it again. Then you're screwed."
>
>Tim> If you are going to accuse others of lying, you should try to
>Tim> avoid making up your own blatant lies, like that one.
>
>
Oh, really? OK, lets say Microsoft decides to come and hoard FreeBSD.
How is Microsoft going to make Walnut Creek stop distributing it? You can
only "enslave" BSD licensed code if you have an organization sufficiently
powerful to track down all existing copies and eradicate them, so that you
become the sole source of the code.
--Tim Smith
Marcus Daniels
Tim> If you are going to accuse others of lying, you should try to
Tim> avoid making up your own blatant lies, like that one.
me> A lie merely because the BSD license doesn't say that literally?
me> It is a fact that someone can come along and hoard BSD licensed
me> source code.
Tim> Oh, really? OK, lets say Microsoft decides to come and hoard
Tim> FreeBSD. How is Microsoft going to make Walnut Creek stop
Tim> distributing it? You can only "enslave" BSD licensed code if you
Tim> have an organization sufficiently powerful to track down all
Tim> existing copies and eradicate them, so that you become the sole
Tim> source of the code.
You aren't looking at this from the users' point of view.
Jimen's post was about how users gets screwed.
Should Microsoft come along and slurp up FreeBSD, as soon as they make
one change that isn't cleanly insulated from the mainline code, the
MicrosoftBSD owner is screwed because there is no way to fix bugs or
rebuild the package and still maintain compatability. [Note if changes
are cleanly insulated and follow common APIs, a GPLed OS can be
exploited just as easily]
MicrosoftBSD has rendered the FreeBSD sources useless for users who'd
like to fix or extend their copy of MicrosoftBSD.
Irclark
>
> eb> While working for the USDA, I developed an entire, independent
> eb> application, but a I made the unfortunate choice of using gdbm.
> eb> the GPL. I didn't change it. I didn't distribute it, and I
> eb> didn't say it was mine. I was told, that even though I in no
> eb> way distributed gdbm, that my ENTIRE application now fell under
> eb> the GPL because it was a "Phantom Distribution", and the
> eb> application was a derived work.
>
>Eh? That doesn't make any sense. Either the person who told you that
>(who was it? My luck it was probably RMS himself :) didn't know what
>they were talking about, or there're details that are missing above.
>What's a "Phantom Distribution"? I don't see anything about that in the
>GPL so my gut instinct is that it's (legally) meaningless.
>
I believe you will find that the FSF does indeed support this interpretation of
the GPL. This particular point was the subject of a quite heated discussion a
few months back when someone released a program based on a GPL'd math
library. To quiet the FSF's objections, the author of the package wrote a
library with the same programming interface as the FSF library which was
released into the public domain.
The argument used by the FSF was that without the existence of an alternate
library, the author's program required the FSF's library and thus distribution
of the program even without the GPL'ed library was in fact an infringing
distribution. This interpretation did not seem right to me. It seems
particularly weak if there are reasons to assume that the user already
has the library present (for example, what if the needed GPL library were part
of a popular distribution of Linux). However, I do understand why the FSF
insists on this interpretation. Without it the GPL is trivially easy to
bypass. Just compile the required FSF code as a library after writing some
trivial interfacing code, and call the GPL'd code as necessary. You then
distribute only binaries plus the trivial interfacing code. I don't like
this outcome as it is completely at odds with the owner's intentions.
The major disadvantage that I see for this interpretation is that it
discourages the use of FSF extensions to existing libraries. I think gdbm
is largely compatible with other libraries under easier to hoard liscenses.
Is the use of the GNU extensions really worth the pain? Bison had the same
problems before the liscensing terms were relaxed. Was it worth the trouble
to keep track of the GPL restrictions when you could just use yacc?
Isaac
Marcus Daniels
>>>>> "Sakari" == Sakari Jalovaara <s...@beta.hut.fi> writes:
Sakari> If a piece of code calls a GPL'd function, and no
Sakari> implementation of that function exists under any other
Sakari> copyright, the calling code supposedly falls under the GPL if
Sakari> distributed. Whether the author wants that or not.
And why not? If it is code crucial to a popular configuration of the
program, and it just doesn't happen to be included in the
distribution, it is still a crucial piece of code (e.g. GNU mp).
In this situation, the purpose of an interface is to mix and max
implementations, if there is only one implementation, it implies
that the work is derived.
Inclusion is a trivial and incidental matter of configuration.
It is a superficial condition not equivalent to derivation.
John S. Dyson
Greg Stark <gss...@mit.edu> wrote:
>
> The last article posted was not posted by me, but an automated system
> as evidenced by the bogus header. It WAS NOT meant to be public, but
> a private (personal) reply... Why do people send email like this with the
> autopost "trick" reply???
>
>newsreader/mailer. Its non-intuitive handling of the newsgroups header has
>given a lot of people grief. Of course you should always check the headers
>before you send mail anyways.
>
>
>Back on topic, you have to ask yourself one question:
> Why do you write free software.
>
>The GPL was written because the authors believed hoarding software is wrong.
>
I don't thing that hoarding software is wrong, I believe that you have
the right to free your own intellectual property.
>
>If you don't care about people hoarding you software, then of course the
>license designed to prevent that isn't going to be helpful to. If all you
>care about is fame then the BSD license will serve. The FSF programmers and
>the other programmers that release GPL'd free software really are concerned
>about ensuring their software remains free.
>
I don't care about fame, but I sure hope that others apply the BSD copyright
(or equiv non-GPL) to their modifications of my code so that I can use it
in my work. Since I was generous enough to donate my work originally, it
would be a slap in my face if I could not used derived works just because
someone thought that GPL was better than BSD. If someone actually added
value significantly enough to make the code proprietary, it is likely that
the enhancements were non-obvious. I believe that the person who added
the work has a right to his intellectual property. And in all actuality,
if the person thought that the BSD copyright was somehow WRONG, he
could GPL it -- but that would be very unkind to me, the original author.
John Dyson
Marcus Daniels
me> It is a fact that someone can come along and hoard BSD licensed
me> source code.
Per> The original copy will still be free. I agree with Tim here.
Per> Mr. Ching's statement is just as unacceptable as those of
Per> Mr. Dyson.
The original source code will be of little if any practical value.
Even just for gaining insight into how the application works, the
original source code won't necessarily say enough.
Although it seems likely the user could find the original source
code, whether or not the vendor made them aware of it, the point
is: _what is it good for_?
If a commercial GPL distributor can make a clean interface to the
GPL'ed code, then the distributor won't be required to release their
extensions. If the distibutor can't do this then the user is screwed
because the original source code isn't what they have.
Paul D. Smith
%% ben...@fix.oneworld.com (Erik Bennett) writes:
eb> While working for the USDA, I developed an entire, independent
eb> application, but a I made the unfortunate choice of using gdbm.
eb> I read, and followed to the letter, the terms and conditions of
eb> the GPL. I didn't change it. I didn't distribute it, and I
eb> didn't say it was mine. I was told, that even though I in no
eb> way distributed gdbm, that my ENTIRE application now fell under
eb> the GPL because it was a "Phantom Distribution", and the
eb> application was a derived work.
Eh? That doesn't make any sense. Either the person who told you that
(who was it? My luck it was probably RMS himself :) didn't know what
they were talking about, or there're details that are missing above.
What's a "Phantom Distribution"? I don't see anything about that in the
GPL so my gut instinct is that it's (legally) meaningless.
If you didn't give the binary to anyone but only used it yourself, then
you have no obligations to provide anyone with anything (binary or
sources).
If more than just you used it (e.g. USDA), then "distribution" may come
into play--I've never really been 100% clear on that point: does it
count as "distribution" if the company uses it, but doesn't give it to
anyone? What about if you developed it for the company, so the company
owns the copyright?
However, even that point may be rendered uninteresting as long as
everyone who *used* it had the capability to get the sources as per the
GPL... that is, if all of the USDA used the binary, as long as any of
those people who wanted to could obtain the sources, you're not in
violation.
Of course, technically I guess any of those people would have the
_right_ (under the GPL anyway) to then give away that code if they were
viewed as recipients of a distribution... but I doubt they would :), and
they certainly don't have to.
eb> p.s. I have a question for anyone in the know:
eb> If I write a shell script that uses features specific to GNU
eb> find, does that shell script fall under the terms of the GPL?
Of course not.
No more than using GCC extensions in a C file places it under the GPL,
or elisp packages automatically fall under the GPL because they use
Emacs Lisp.
Since no actual GPL'd code is included, it cannot come under GPL.
-------------------------------------------------------------------------------
Tim Smith
> eb> application, but a I made the unfortunate choice of using gdbm.
> eb> I read, and followed to the letter, the terms and conditions of
> eb> the GPL. I didn't change it. I didn't distribute it, and I
> eb> didn't say it was mine. I was told, that even though I in no
> eb> way distributed gdbm, that my ENTIRE application now fell under
> eb> the GPL because it was a "Phantom Distribution", and the
> eb> application was a derived work.
>
>Eh? That doesn't make any sense. Either the person who told you that
>(who was it? My luck it was probably RMS himself :) didn't know what
>they were talking about, or there're details that are missing above.
>What's a "Phantom Distribution"? I don't see anything about that in the
>GPL so my gut instinct is that it's (legally) meaningless.
FSF believes that if your code calls GPL'ed code, your code is a derivative
work of that GPL'ed code, unless there is also non-GPL'ed code in existence
with the exact same interface as the GPL'ed code.
For example, if you were to write a program that needed to use arbitrary
precision arithmetic, and were to include in your code a compile-time
option to select between using a GPL'ed mp library and some public domain
mp library with a different interface, then FSF would claim that your code
can only be distributed under GPL, unless there was a non-GPL'ed clone of
the GPL'ed library available.
Your suspicions that this is wrong are correct. The last time FSF
did this, the person whose code FSF was trying to appropriate ended
the matter by writing a clone of the GPL'ed library before anyone
sued, so we didn't get to get a court ruling.
--Tim Smith
Darin Johnson
> The original source code will be of little if any practical value.
>
> Even just for gaining insight into how the application works, the
> original source code won't necessarily say enough.
>
> Although it seems likely the user could find the original source
> code, whether or not the vendor made them aware of it, the point
> is: _what is it good for_?
Answer: to recreate the original program without the proprietary
extensions. That ability has never been taken away. What has
been taken away is the ability to recreate the *extended* product.
The original author hasn't been screwed over, the authors of the
extension haven't been screwed over, and the user can choose between
two versions.
The only thing that has been lost, which is what RMS thinks is
important from what I've heard from him, is the ability to keep the
extensions while making your own extensions. Ie, the end user of the
proprietary product can no longer make their own bug fixes; but isn't
that the case with proprietary software anyway? If the users want
that ability, they need to come up with the extensions themselves.
Sure, if you want to ensure that this never happens to your code,
then make it GPL'd. I'm all for that. (restricting the use of
the work, as is the case with the GPL's libraries, bison, etc,
is another thing altogether) But if the author doesn't care,
then the FSF crowd shouldn't get all hot and bothered because
the GPL wasn't used.
Sometimes the ability to be incorporated in proprietary commercial
code is important. I was happy when a company wanted to get rights to
a program I wrote, since it meant that there would be a wider group of
people who could hear of it and make use of it. Prior to that, you
had to know how to get it (internet wasn't big, and I had a big demand
from overseas where it was cheaper to get a decus tape than use a
modem, and also demand from people who hadn't heard of or could even
use usenet). The program is still in use, even though I personally
can not maintain it, not having the necessary machine and software.
The program would just have been a minor thing that few had heard
about if it had been GPL'd. Of course, back then people didn't
get all rabid on this subject, and just making free software was
encouraged, even if you didn't stick on a GPL.
--
Darin Johnson
djoh...@ucsd.edu -- Strange things are afoot at the circle-K...
Michael I. Bushnell, p/BSG
%% Regarding Re: [Q] GPL violation.;
%% t...@coho.halcyon.com (Tim Smith) writes:
ts> FSF believes that if your code calls GPL'ed code, your code is a
ts> derivative work of that GPL'ed code, unless there is also
ts> non-GPL'ed code in existence with the exact same interface as
ts> the GPL'ed code.
It is without doubt the case that ELisp code can be placed under non-GPL
licensing terms and distributed: it has been done and no one from the
FSF has cared. And yet no one would argue that there is an alternative,
non-GPL'd ELisp language (Lisp, yes, of course, but not ELisp). Isn't
ELisp code using the ELisp interface? Or is there a special
dispensation somewhere in the Emacs license I don't know about?
Tim Smith was using a shorthand in language. The point is "are they
the same program or not?" If they are the same program (which is what
Tim meant by "calls GPL'd code") then the GPL applies to the complete
aggregate. Normal use of libraries is an example of two things being
in "the same program".
In the case you are mentioning, Elisp is a language, not a library.
There is no simplistic technical distinction here. It's a *legal* and
*human* distinction, about intent, purpose, and the like, not about
the technical details of the process.
So there is no problem with writing non-GPL'd elisp programs which use
the normal features of elisp. Similar comments apply to shell scripts
which use GPL'd shell commands (and bash itself).
If you're really intent on working around the GPL, I suppose you might
write the code without referring to the GPL'd code at all, then provide
a patch file that was GPL'd which users could apply that would add the
GPL references. Sort of annoying to all concerned. And it would only
work if you distributed sources, since that's all that could be patched.
Not good enough at all. The GPL applies to PROGRAMS not lines of
code, files, or the like. If the complete entity of original code,
patch files, and GPL'd library, constitutes a complete program, then
the subterfuge you describe doesn't work. In fact, this kind of trick
was exactly what was going on in the RIPEM case.
Michael
Barak Pearlmutter
odd to me. Perhaps to programmers it makes sense that there should be
hard and fast rules about the GPL, which can be applied by merely
examining source code and following some cookbook instructions to
determine whether something is a violation.
But this is not how the law works. The law frequently depends on
*intent*. In other words, a particular act could be or not be a
violation of the GPL depending on the *intent* of whoever did it.
For an analogy: let's say I pick up a gun and shoot a man dead. Did I
commit murder? Well, it depends. To large measure, it depends on
whether I *intended* to kill him.
Similarly, certain distributions (eg perhaps the RIPEM/gmp program)
might be violations of the GPL because the authors *intended* to
distribute encumbered programs that contained GPL code, but used
tricks to make it seem like they weren't.
It is to the FSF's credit that they found a way to help the authors of
RIPEM/gmp find a way to modify their program so that it was clearly
not infringing, and clearly did not set a precedent that would be bad
news for the cause of free software --- while still allowing the
public to get its hands on a version of RIPEM that uses gmp
internally.
There are nightmare scenarios in which the GPL is weakened to nothing
by workarounds and subterfuges. It is part of the job of the FSF to
see that the GPL maintains its integrity in practice, by making sure
that unfortunate precedents do not get set. For that reason, as an
author of GPLed software, I am very satisfied with the job the FSF has
been doing to make sure that dodging around the GPL won't work.
Occasionally this can be an inconvenience to us "good guys", who end
up having to dot our i's and cross our t's more than we might prefer.
But consider the alternative, in which new optimizations and back ends
for GCC are kept proprietary because, after all, they're just talking
to well documented GCC internal interfaces.
Paul D. Smith
%% t...@coho.halcyon.com (Tim Smith) writes:
ts> FSF believes that if your code calls GPL'ed code, your code is a
ts> derivative work of that GPL'ed code, unless there is also
ts> non-GPL'ed code in existence with the exact same interface as
ts> the GPL'ed code.
This is interesting... I guess I can follow their logic, sort of; how
does this sound? Note I just made it all up, so it could be completely
off-base:
It is without doubt the case that ELisp code can be placed under non-GPL
licensing terms and distributed: it has been done and no one from the
FSF has cared. And yet no one would argue that there is an alternative,
non-GPL'd ELisp language (Lisp, yes, of course, but not ELisp). Isn't
ELisp code using the ELisp interface? Or is there a special
dispensation somewhere in the Emacs license I don't know about?
I can envision the distinction the FSF wants to make between libraries
and public interfaces like find or ELisp... for example, with a library
you cannot easily use the library without including in your code at
least the header file, which is GPL'd, and at best shared library stubs
which are also presumably GPL'd. So a binary-only distribution would be
pretty definitely illegal.
I guess I could _kind_ of see their extension of that to even a
source-based distribution; even if the code didn't have to be compiled
with GPL'd code in it, it could be, which means that it kind of includes
GPL'd code... even if it can be compiled to not use it. If there's an
alternate library then it's not 100% clear that the code references
GPL'd code: in that case the GPL library just becomes an option (like
using GNU libc on your Sun instead of Sun libc).
If you're really intent on working around the GPL, I suppose you might
write the code without referring to the GPL'd code at all, then provide
a patch file that was GPL'd which users could apply that would add the
GPL references. Sort of annoying to all concerned. And it would only
work if you distributed sources, since that's all that could be patched.
Odd.
--
Terry Lambert
]
] Terry Lambert (te...@lambert.org) wrote:
] : The argument that an author may distribute under several licenses
] : does not satisfy the claim that the GPL'ed code can in fact be
] : commercialized. Since the distribution under the secondary
] : license is a distribution of pre-GPL'ed code, it can not in fact
] : be said to be commercialization.
] No, it can be post-GPL'ed code, as long as all copyright-holders
] agree. See Aladdin Ghostscript, which is based on GNU Ghostscript.
] Of course in this case you have to compete against the old GPL version
] of the software.
Then it is no longer GPL'ed code, since each modification was
pulled before distribution under GPL to arrive at this scenario.
This *is* one possible scenario, but it is less interesting,
since as more people hack the code, it become more and more
improbable to achieve.
Alladin Ghostscript is an exception. One would have a difficult
time of this with GCC or Linux (the first because of assignment
and the second from the sheer number of authors involved).
] : In addition, the author explicitly cedes the right to make
] : derivative works from the published sources, except in compliance
] : with the terms of the license under which the sources were
] : published (in this case, GPL: the same is true of the UCB license).
]
] See above. The author can make a derivative work without complying
] with the GPL.
Using sources other than those published under GPL. A GPL release
is bound by the terms of the GPL. This is a paper distinction
that exists only on the authors machine until the author integrates
code from deltas to the GPL'ed code, as provided by other programmers.
] : The author implicitly cedes the right of sublicense. That is,
] : modifications by him to the GPL release must be in accordance
] : with the license.
]
] No.
Yes. You are once again confusing the distinction between the
licensed and unlicensed code.
] Yes, he cannot make derivatives of the derivatives of his original
] work without the permission of those that made the improvements
] to his original work. That's only reasonable, since many people
] would not have bothered to make and release the changes if the
] software had not been under the GPL.
This assumes that their motivation was their support of the
GNU manifesto.
I freely admit that some contributions will occur this way, I
simply claim that that is not the majority case.
] : | 3. Modifications of GPL source code MUST go under the GPL
] : | if they are to be used to obtain commercial advantage
] : | directly.
]
] The notable exceptions to this rule are modifications made by the
] copyright holder himself.
To the code base seperate from its release licensing.
That is, to code under other license, or to code under no license
which is circumstantially *also* licensed under GPL.
I know this is a fine distinction; iut's based on the concepts
of "release" and "assignment of publication rights": both the
BSD and the GPL licenses assign publication rights.
The point is, that modifications that take place take place on
code such that the occurance is prior to the assignment of the
publication rights. This is the basis of implied copyright
protection for works not registered with a copyright office,
but extends beyond just the idea of "protection of works in
progress".
Irclark
Marcus Daniels <mar...@sysc.pdx.edu> wrote:
>
>>>>>> "Sakari" == Sakari Jalovaara <s...@beta.hut.fi> writes:
>
>Sakari> If a piece of code calls a GPL'd function, and no
>Sakari> implementation of that function exists under any other
>Sakari> copyright, the calling code supposedly falls under the GPL if
>Sakari> distributed. Whether the author wants that or not.
>
>And why not? If it is code crucial to a popular configuration of the
>program, and it just doesn't happen to be included in the
>distribution, it is still a crucial piece of code (e.g. GNU mp).
The weakness of this position is shown in the ease with which it is
circumvented. In the mp case, apparently the existence of another
library with the same interface as GNU mp, however slow, was
enough to make FSF's objections moot. In the case of the math library
and of the RIPEM code calling it, the speed of the math library was
the crucial point that made GNU mp desirable. Apparently now
everyone can claim to be writting code for the public domain mp even
while recommending the use of GNU mp.
Also note that the new library was written after the RIPEM code was
written. In what sense could the new library change the derivative
nature of already written code?
Isaac
Marcus Daniels
In article <4ctosq$1...@parsifal.nando.net> irc...@nando.net (Irclark) writes:
me> If it is code crucial to a popular configuration of
me> the program, and it just doesn't happen to be included in the
me> distribution, it is still a crucial piece of code (e.g. GNU mp).
Irclark> The weakness of this position is shown in the ease with which
Irclark> it is circumvented. In the mp case, apparently the existence
Irclark> of another library with the same interface as GNU mp, however
Irclark> slow, was enough to make FSF's objections moot. In the case
Irclark> of the math library and of the RIPEM code calling it, the
Irclark> speed of the math library was the crucial point that made GNU
Irclark> mp desirable. Apparently now everyone can claim to be
Irclark> writting code for the public domain mp even while
Irclark> recommending the use of GNU mp.
Yes, I think that's the point. I even suspect the FSF intends it this way.
I think the test is a simple one: how does the distribution's configuration
effect users. If the users have more-or-less the same flexibility
they have with the original source package (in reference to itself),
then the FSF will be happy. Otherwise, if the user is hurt
by the distribution conditions, then they will not be happy.
Irclark
Paul D. Smith <psm...@wellfleet.com> wrote:
>Unfortunately I'm not familiar with the details of the RIPEM case, but
>the situation I was thinking of was something like this:
>
> a) The program is complete and works without any GPL'd code, and is
> released under some non-GPL license. You can build it and use it
> productively in this mode.
>
> b) However, some GPL'd code might give you added features or benefits.
> In that case, a patch (GPL'd) could be applied which modified the
> program to use the GPL'd code. Obviously the package would have to
> be distributed in source form for this to work.
>
>In this case, the complete entity of original code does _not_ utilize
>any GPL'd code... but it can be modified to do so. Obviously if the
>package cannot work without GPL'd code then there's no issue. What's
The scenarios you have postulated are very similar to the
RIPEM case. I don't believe anyone can predict how a real case would
be decided in court. The most convincing arguments would be by
those who can cite case law supporting their position. During the
last round of heated discussions, I don't recall that anyone was able
to do this.
Above and beyond what you can get away with, it's important to remember
that in all of these situations were talking about the use of someone
else's work. If your intent is truly to take advantage of special
features of someone else's library, ethics would indicate not taking
advantage of that person.
Isaac
John S. Dyson
Barak Pearlmutter <Barak.Pe...@scr.siemens.com> wrote:
>
>Occasionally this can be an inconvenience to us "good guys", who end
>up having to dot our i's and cross our t's more than we might prefer.
>But consider the alternative, in which new optimizations and back ends
>for GCC are kept proprietary because, after all, they're just talking
>to well documented GCC internal interfaces.
>
working on GCC. The FSF/Cygnus would have competition -- and that seems
to be what they are trying to avoid.
If someone did produce a "wonderful" code generator, why couldn't the
GCC developers do the same or better??? -- if they were confident in their
skills, I would expect that they would allow such competition.
John Dyson
Russ Allbery
> Once a third party has made modifications, then the author is
> per force a third party for the modifications
Yup. Exactly the same as under every other license on the face of the
Earth.
> -- and thus, by omission (or intent), a third party for his own code as
> well.
Huh?
Irclark
>RIPEM/gmp find a way to modify their program so that it was clearly
>not infringing, and clearly did not set a precedent that would be bad
>news for the cause of free software --- while still allowing the
>public to get its hands on a version of RIPEM that uses gmp
>internally.
>
find a solution? My recollection is that FSF reluctantly agreed
that they had no case after the author pursued his own solution.
I agree that it is indeed better that no GPL busting precedent was
established. I would have been equally displeased had a solution
not been worked out that allowed the RIPEM authors to distribute
their own code.
Tim Smith
>There is no simplistic technical distinction here. It's a *legal* and
>*human* distinction, about intent, purpose, and the like, not about
>the technical details of the process.
In copyright law, intent and purpose only matter in determining remedies
for infringement, not whether or not infringement has occurred (except
possibly they may influence what the jury thinks of the various witnesses).
For something I write to fall under GPL, without my having explicitly put
it there, you've got to be able to either point to what I am distributing
and show actual copying of GPL'ed, copyrighted, code, *OR* you have to
be able to show that a person I distribute to is infringing, and try to
nail me as a contributory infringer.
You can't get the first (direct infringement) in these cases, because there
is no GPL'ed code in the actual distribution, *unless* you are going to
claim that the interface itself is copyrighted.
For the second (contributory infringement), you've got to show that the
end user has done something to infringe. Unless you are claiming that it
is against GPL for an end user to obtain GPL'ed code and link it with
non-GPL'ed code for his own use, you won't get very far down this path.
>the subterfuge you describe doesn't work. In fact, this kind of trick
>was exactly what was going on in the RIPEM case.
So, how about this scenario? I write an article for Byte or Dr. Dobbs,
called "A Comparision of C Arithmetic Libraries". My article includes
code that looks like this:
typedef struct { ... } tzsBigInt;
...
tzsBigInt * mult( tzsBigInt * X, tzsBigInt * Y )
{
#if GNU_MP
...code to use GNU library to do the multiply...
#elif BERKELEY_MP
...code to use Berkeley library to do the multiply...
#elif
...code to use some other library to do the multiply...
#endif
}
That was essentially how RIPEM code was implemented. Your claim is that my
source code from the article is now under GPL because someone might decide
to use the GNU library with it?
--Tim Smith
Terry Lambert
] >>>>> "Tim" == Tim Smith <t...@coho.halcyon.com> writes:
]
] Jimen> "This source code has been liberated, until someone else comes along
] Jimen> and enslaves it again. Then you're screwed."
] Tim> If you are going to accuse others of lying, you should try to
] Tim> avoid making up your own blatant lies, like that one.
] A lie merely because the BSD license doesn't say that literally?
]
] It is a fact that someone can come along and hoard BSD licensed source
] code.
Only by erasing it from every FTP archive, disk, printout, and
CDROM, and killing everyone who can recreate it from memory.
8-).
Probably you mean that they can hold private *modified* versions
of the code, which I agree is true.
I have a real problem with the word "hard" in this context. If
I come up with an idea for a method of thermal pumping free
electron lasers that's 600 or more times more efficient than
the current methods, but I don't tell anyone, am I "hoarding"
it?
What if I modify GCC and use it to compile products that I sell,
but I don't give out the modifications? Is that "hoarding"?
The GCC example is perfectly permissable under the terms of GPL,
the effect of which is to guarantee source availability using
some method other than source escrow. GPL is not, in itself,
a preventor of "hoarding".
Marcus Daniels
In article <p5lonh9...@lemming.wellfleet.com> psm...@lemming.wellfleet.com (Paul D. Smith) writes:
mib> In the case you are mentioning, Elisp is a language, not a
mib> library. There is no simplistic technical distinction here.
mib> It's a *legal* and *human* distinction, about intent, purpose,
mib> and the like, not about the technical details of the process.
Paul> Interesting. As in "I can't define pornography, but I know it
Paul> when I see it". :)
Things are contextual, that's all he is saying.
A language is for communicating -- to specify what can be said would
be counterproductive to the goal. On the other hand, if you are, say,
the President, the things you say may carry with them a great amount
of responsibility, and so certain things you could say would not be
appropriate. Like: "I'll blow up the world today".
So it is conceivable that certain words and phrases might be
subject to control, but not typically.
Terry Lambert
] You aren't looking at this from the users' point of view.
] Jimen's post was about how users gets screwed.
]
] Should Microsoft come along and slurp up FreeBSD, as soon as they make
] one change that isn't cleanly insulated from the mainline code, the
] MicrosoftBSD owner is screwed because there is no way to fix bugs or
] rebuild the package and still maintain compatability. [Note if changes
] are cleanly insulated and follow common APIs, a GPLed OS can be
] exploited just as easily]
]
] MicrosoftBSD has rendered the FreeBSD sources useless for users who'd
] like to fix or extend their copy of MicrosoftBSD.
This sounds self-limiting, as long as you don't find self
selection against stupid users to be abhorrent for some
reason.
In which case, you must be against any dangerous situation
in general, since dangerous situations have a tendency to
eliminate stupidity through self selection. Rather forcefully
in some cases, such as explosive decompression for stupidly
going out an airlock without chacking the helmet seals on your
spacesuit.
Marcus Daniels
In article <4cukop$s...@park.uvsc.edu> Terry Lambert <te...@lambert.org> writes:
me> It is a fact that someone can come along and
me> hoard BSD licensed source code.
Terry> Only by erasing it from every FTP archive, disk, printout, and
Terry> CDROM, and killing everyone who can recreate it from memory.
Terry> Probably you mean that they can hold private *modified*
Terry> versions of the code, which I agree is true.
Yes -- distributing binaries for which the base source code will not be of
utility. Whether or not the base source code exists is of no
practical significance to the user. Argh. Legal weaseling. Precisely
why the GPL must exist.
Terry> I have a real problem with the word "hard" in this context. If
Terry> I come up with an idea for a method of thermal pumping free
Terry> electron lasers that's 600 or more times more efficient than
Terry> the current methods, but I don't tell anyone, am I "hoarding"
Terry> it?
Ideas are dime a dozen. At some point you will probably want to tell
somebody, test, and then make it usable.
Hoarding in a broad sense is keeping secrets so as have a competitive
advantage. However, the word `hoarding' is usually not invoked unless
the `secret' is NOT a result of the hoarder's efforts.
[Neither the product and service model of software provide much
reassurance that you will be paid for developing the idea. ]
Terry> What if I modify GCC and use it to compile products that I
Terry> sell, but I don't give out the modifications? Is that
Terry> "hoarding"?
It isn't really observable. No.
Terry> The GCC example is perfectly permissable under the terms of
Terry> GPL, the effect of which is to guarantee source availability
Terry> using some method other than source escrow. GPL is not, in
Terry> itself, a preventor of "hoarding".
I agree.