Rebuttal to Rebuttal in GNU Manifesto
Jacob Gore
> But, they then must make these extensions---that they paid big $$$
> to create---available to their competitors! Companies won't want
> to do this!
And they don't have to. Instead, they can pay even bigger $$,$$$,$$$ to
write their own system.
> The net effect would be that _your_ company is paying _your_ programmers to
> write productivity enhancing software for _your_ competitors!
Yes. And if the management of _your_ company can see past their noses,
they'd realize that it still makes sense, because other people (and
companies) enhanced software for _your_ company.
> What if they just sit back and use your enhancements, without
> doing any themselves?
Then they lag behind you in product introduction.
I don't think competitive companies will sit and wait for somebody else to
port or custom-improve GNU for their iron. If anything, the problem will
be merging the improvements that will be coming in from all directions.
Jacob
--
Jacob Gore Ja...@Gore.Com boulder!gore!jacob
Ronald BODKIN
>/ gnu.misc.discuss / ba...@mesquite.math.ucla.edu / Mar 26, 1990 /
>> But, they then must make these extensions---that they paid big $$$
>> to create---available to their competitors! Companies won't want
>> to do this!
>
>And they don't have to. Instead, they can pay even bigger $$,$$$,$$$ to
>write their own system.
income.
>Yes. And if the management of _your_ company can see past their noses,
>they'd realize that it still makes sense, because other people (and
>companies) enhanced software for _your_ company.
This is "highly illogical". Perhaps a large conglomeration of
corporations could get together and say "we think OS's are too important
to have standardized to be proprietary" and proceed to use contract law
to force each other into making certain levels of enhancement, more
likely by funding FSF or some other group. But you can't break a
prisoner's dilemna by arbitrarily cooperating. I can tell you, I would
not be impressed by the management of a company that gave software or
enhancements to competitors.
>I don't think competitive companies will sit and wait for somebody else to
>port or custom-improve GNU for their iron. If anything, the problem will
>be merging the improvements that will be coming in from all directions.
For some, small and localized, enhancements sure. But no one in
their right mind would make an enormous enhancement if the investment
didn't work.
I must admit that I find FSF's philosophy to be essentially
flawed, in its opposition to property rights. The basic fact is that
creation of software is expensive and the assumption that one should
"share" software is no different than the assumption that one should
share any other kind of property. Property doesn't derive its value
merely from basic resource inputs -- the predominant aspect is the
labour (including entreprenneurship) that is invested. As far as the
FSF are concerned, I don't have a problem with their own desire to
create shared software (so long as they don't try to strip property
rights from those who do not wish to share their own software) and I
agree that there is a role for making certain software extremely
inexpensive and standardized. Given antitrust laws, FSF may be the
only way to do this. However, if GNU is to become a standard, it
will need to have plenty of flexibility.
Ron
Russ Nelson
FSF asserts that any program linked with libg++ is covered by the
copyleft. Morally and legally speaking, this is almost certainly wrong:
libg++ continues to be covered by the copyleft, and must be distributed
with source, but the other code comprising the package remains the
author's property, and they can decide whether or not to offer source
code. Forcing a waiver of property rights, as the copyleft sometimes
tries to do, is about as ethically upright as if the car companies were
to say "any money you make from using our car (sales gained through
travel, salary from a job you drove to, etc) belongs to us. You choose
to drive the car...".
One way to look at the copyleft is that it requires royalties equal to
any profit you may have gained if you could have restricted
redistribution of their code. Apparently you think this is too high a
royalty to pay. That does not make it "morally and legally wrong".
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems
Clarkson will be featured on PBS's Computer Chronicles next week. I'm the dude
with the camcorder taking digital portraits.
John Coolidge
>In article <1990Mar27.1...@brutus.cs.uiuc.edu> cool...@casca.cs.uiuc.edu (John Coolidge) writes:
> FSF asserts that any program linked with libg++ is covered by the
> copyleft. Morally and legally speaking, this is almost certainly wrong:
> libg++ continues to be covered by the copyleft, and must be distributed
> with source, but the other code comprising the package remains the
> author's property, and they can decide whether or not to offer source
> code. Forcing a waiver of property rights, as the copyleft sometimes
> tries to do, is about as ethically upright as if the car companies were
> to say "any money you make from using our car (sales gained through
> travel, salary from a job you drove to, etc) belongs to us. You choose
> to drive the car...".
>One way to look at the copyleft is that it requires royalties equal to
>any profit you may have gained if you could have restricted
>redistribution of their code. Apparently you think this is too high a
>royalty to pay. That does not make it "morally and legally wrong".
The first obvious problem with this view is, of course, that I have
_in no way_ restricted redistribution of _their code_. I have merely
restricted redistribution of _my code_, which happens to be linked
to their code. There is a major difference. What people seem to be
forgetting here is that it's _my code_ I'm concerned with, not the
FSF's. If I hand someone some object files, and they link with FSF
libraries, I can't be required to give out source code. If I hand
someone a binary file already linked with FSF code, my argument is
that the situation is exactly the same: they can require source to
the FSF code, which is covered by the copyleft, but they _cannot_
require source to my code, because it is not covered by the copyleft.
My contention is that the state of affairs (both ethically and legally)
is governed by the following clause in the copyleft:
>Mere aggregation of another independent work with the Program (or its
>derivative) on a volume of a storage or distribution medium does not bring
>the other work under the scope of these terms.
Linking together my program "another independent work" with a piece
of FSF code, IMHO, constitutes "mere aggregation". This is obviously
not the _intent_ of the copyleft, but it is (IMHO, again) both
ethically and legally the correct interpretation of the copyleft.
The difference between GNUware and proprietary libraries which charge
for use is simple: the library is not freely redistributable. I _can't_
give it to someone else without paying for it. That's what library
use fees are: payments for me giving the library to someone else.
On the other hand, GNUware _is_ redistributable for free. Thus, I can
hand someone the library, since the FSF's copyright allows my to copy
the program. On the other hand, in either case (commercial library or
FSFware code) I still hold my copyright to my code. I don't have to give
it to someone else. The copyleft (or the vendor's copyright) doesn't have
the legal force to make me give it to someone else, because it's just
their copyright on their code. Copyright law _cannot_ legally be used
to force someone to abrogate their rights under copyright. Licenses
can be used to this purpose, but there's no legal license between me
and the FSF, and no vendor I've ever heard of has been willing to
put such a clause (affecting author's copyright) into a license. It
might or might not hold up; in any case, no author would sign.
Thus, I reiterate my position. The idea that a program linked with
libg++ (or any piece of FSF code) is bound by the copyleft is legally
wrongheaded. Only the FSF code is covered by the copyleft. Furthurmore,
such a binding, if it _were_ to be legally enforcable, would constitute
an unethical intrusion into the rights under copyright of those it
affects.
--John
--------------------------------------------------------------------------
John L. Coolidge Internet:cool...@cs.uiuc.edu UUCP:uiucdcs!coolidge
Of course I don't speak for the U of I (or anyone else except myself)
Copyright 1990 John L. Coolidge. Copying allowed if (and only if) attributed.
You may redistribute this article if and only if your recipients may as well.
Jacob Gore
/gnu.misc.discuss/ uti...@quiche.cs.mcgill.ca (Ronald BODKIN) /Mar 26 1990/
unless otherwise attributed.]
Me>And they don't have to [make expensive extensions available to competitors].
Me>Instead, they can pay even bigger $$,$$$,$$$ to
Me>write their own system.
> And they might, given that competitors can use the gift to erode income.
That is why having GNU-based code is more appealing to hardware-producing
companies than to those who only make software.
Me>Yes. And if the management of _your_ company can see past their noses,
Me>they'd realize that it still makes sense, because other people (and
Me>companies) enhanced software for _your_ company.
> This is "highly illogical".
Notation:
<upper case letter> :== variable bound to the statement
<lower case letter> :== constant throughout the proof
d(X) :== changes to X
c(X) :== cost of developing X
t(X) :== time required to bring X to market
<< :== much less than
Symbols:
s :== software needed
g :== GNU software available
f :== a factor relating cost to development time
Axioms:
1. c(X) = f * t(X) + o [cost proportional to time]
2. f >= 1
3. f is finite
4. o = 0 [overhead insignificant]
5. c(X + d(X)) = c(X) + c(d(X))
6. s = g + d(g)
7. t(g) = 0
8. t(d(g)) << t(s)
Theorem:
9. c(g+d(g)) << c(s)
Proof:
10. c(X) = f * t(X) [1,4]
11. c(s) = f * t(s) [10]
12. c(g+d(g)) = c(g) + c(d(g)) [5]
13. c(g) = 0 [10,3,7]
14. c(g+d(g)) = c(d(g)) [12,13]
15. c(g+d(g)) = f * t(d(g)) [14,10]
16. f * t(d(g)) << f * t(s) [8,2,3]
17. c(g+d(g)) << c(s) [16,15,11]
QED
> [...] you can't break a prisoner's dilemna by arbitrarily cooperating.
My point is that there may not be a dilemma in the first place.
> I can tell you, I would
> not be impressed by the management of a company that gave software or
> enhancements to competitors.
I am aware of two companies that use the GNU C compiler as a basis for
their own: NeXT and Data General. This meant NeXT releasing their
enhancement that made an Objective-C compiler out of the C compiler (a
major enhancement), and DG releasing the first back end for the Motorola
88000 CPU. Granted, neither company has its financial future assured at
this point, but somehow I doubt it's because of this decision.
> [...] no one in
> their right mind would make an enormous enhancement if the investment
> didn't work.
That's begging the question.
> if GNU is to become a standard, it
> will need to have plenty of flexibility.
Certainly.
David Vinayak Wallace
Date: 27 Mar 90 06:37:31 GMT
From: uti...@quiche.cs.mcgill.ca (Ronald BODKIN)
In article <970...@gore.com> ja...@gore.com (Jacob Gore) writes:
>Yes. And if the management of _your_ company can see past their noses,
>they'd realize that it still makes sense, because other people (and
>companies) enhanced software for _your_ company.
This is "highly illogical".[...] I can tell you, I would
not be impressed by the management of a company that gave software or
enhancements to competitors.
I guess you don't think too highly of companies like Intel, NeXT,
Motorola, IBM, Sun, DEC, and DG who ship free software as system
utilities (some of them even as the standard compiler or debugger).
Fortunately Apple is still refusing to share anything, so we can
determine empirically which works better...
>I don't think competitive companies will sit and wait for somebody else to
>port or custom-improve GNU for their iron. If anything, the problem will
>be merging the improvements that will be coming in from all directions.
For some, small and localized, enhancements sure. But no one in
their right mind would make an enormous enhancement if the investment
didn't work.
By your argument then, since companies are making such investments
perhaps they are deciding that such a strategy can work?
I must admit that I find FSF's philosophy to be essentially
flawed, in its opposition to property rights. [description of Labor
theory of value deleted]
You presume all rights to property belong to the producer.
Essentially, when I obtain a piece of software I am enjoined from
using it in various ways by its creator, unless it's totally PD.
However car producers have been repeatedly denied the ability to
prevent customers from servicing cars themselves, or to require that
customers go to particular service providers. Why should software
consumers be required to do what the car consumers can?
As far as the
FSF are concerned, I don't have a problem with their own desire to
create shared software (so long as they don't try to strip property
rights from those who do not wish to share their own software)...
They make no effort to do this. You can use their code under their
license conditions, or not at all. What could be fairer, by your own
definitions?
However, if GNU is to become a standard, it
will need to have plenty of flexibility.
What could be more flexible than supplying the source code?
Seems to me the market is making a determination, regardless of
ANYONE'S ideology. So where's the beef?
John Coolidge
>I guess you don't think too highly of companies like Intel, NeXT,
>Motorola, IBM, Sun, DEC, and DG who ship free software as system
>utilities (some of them even as the standard compiler or debugger).
>Fortunately Apple is still refusing to share anything, so we can
>determine empirically which works better...
Hmm. Seems to me that Apple (or, rather, the individuals who have ported
Gnu tools to Apple hardware), has been more than willing to share their
changes. My impression was that the FSF was playing politics with the
changes and refusing to use the shared information. I strongly suspect
that, given the opportunity, the Apple-related patches for Gnu software
would be happily handed over to the FSF. After all, the patches are
distributed under the terms of the copyleft anyway...
> I must admit that I find FSF's philosophy to be essentially
> flawed, in its opposition to property rights. [description of Labor
> theory of value deleted]
>You presume all rights to property belong to the producer.
>Essentially, when I obtain a piece of software I am enjoined from
>using it in various ways by its creator, unless it's totally PD.
>However car producers have been repeatedly denied the ability to
>prevent customers from servicing cars themselves, or to require that
>customers go to particular service providers. Why should software
>consumers be required to do what the car consumers can?
The car companies, of course, have given up this ability as part of
the process of selling the car. Rental car companies are perfectly
free to prohibit user servicing. Rights to property _do_ belong to
the producer until the producer gives up the rights (by explicit
waiver, by selling the product, by failing to protect the rights,
or several other legal means). Most software (including, although
probably not legally, GnuWare) is not sold, but it is rather licensed,
which allows the producer to control the use of the product. Your
argument above --- that obtaining a piece of software should waive
license restrictions --- would render the copyleft's license provisions
(the most important, since copyright law is nowhere near strong enough
to do what the copyleft attempts) void.
> As far as the
> FSF are concerned, I don't have a problem with their own desire to
> create shared software (so long as they don't try to strip property
> rights from those who do not wish to share their own software)...
>They make no effort to do this. You can use their code under their
>license conditions, or not at all. What could be fairer, by your own
>definitions?
Because some of their license conditions have the effect of stripping
property rights of those who don't want to share. For instance, the
FSF asserts that any program linked with libg++ is covered by the
copyleft. Morally and legally speaking, this is almost certainly wrong:
libg++ continues to be covered by the copyleft, and must be distributed
with source, but the other code comprising the package remains the
author's property, and they can decide whether or not to offer source
code. Forcing a waiver of property rights, as the copyleft sometimes
tries to do, is about as ethically upright as if the car companies were
to say "any money you make from using our car (sales gained through
travel, salary from a job you drove to, etc) belongs to us. You choose
to drive the car...".
--John
Michael I. Bushnell
Thus, I reiterate my position. The idea that a program linked with
libg++ (or any piece of FSF code) is bound by the copyleft is legally
wrongheaded. Only the FSF code is covered by the copyleft. Furthurmore,
such a binding, if it _were_ to be legally enforcable, would constitute
an unethical intrusion into the rights under copyright of those it
affects.
Actually, this is not the case at all. Consider that what the GPL is
is a "limited license to copy". You are allowed to copy their
software, under *their* conditions...same as any other copyrighted
work. The conditions the FSF has set up are such that you can't
distribute a linked object with the libraries in cases where those
libraries are non-trivial (libg++, for example). FSF has the right to
limit your ability to copy their code *any way they want to*. They
take the position that it is wrong to sell software by the normal
copyright and license techniques, and seek to end the hoarding of
software that results. If I use a library supplied by hoarding
company XXX, and they refuse to let me sell products linked with it
(use fee or no), then I'm stuck. I don't get to complain that their
copyright limits the ability to sell my product.
Finally, note that this is really academic. All you have to do is
distribute a bunch of .o's and aggregate them with the library.
Distribute the source to the library and not your .o's, and supply
instructions to link the result.
--
Michael I. Bushnell \ This above all; to thine own self be true
LIBERTE, EGALITE, FRATERNITE \ And it must follow, as the night the day,
mi...@unmvax.cs.unm.edu /\ Thou canst not be false to any man.
CARPE DIEM / \ Farewell: my blessing season this in thee!
Kurt Baudendistel
> ... [In order to get around the copyleft on libg++] ...
>Finally, note that this is really academic. All you have to do is
>distribute a bunch of .o's and aggregate them with the library.
>Distribute the source to the library and not your .o's, and supply
>instructions to link the result.
Watch out! The problem here is that you need the header files for libg++ to
compile your code. Since these header files are source code, compiling your
C programs and including them forces your code under the copyleft! Thus,
source for your .o's must be distributed.
I hope we can get around this some day, since the libraries are as
intrinsic to the use of g++ as the compiler itself. If you don't modify
the libraries but just use them as is, why is this any different (from
the point of view of the FSF) than using the compiler as is?
kurt
--
Kurt Baudendistel --- GRA
Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332
internet: ba...@eedsp.gatech.edu uucp: gatech!gt-eedsp!baud
Sean Fagan
>distribute a bunch of .o's and aggregate them with the library.
>Distribute the source to the library and not your .o's, and supply
>instructions to link the result.
Not so, camel breath! (Sorry; too much Carnac the Magnificent, I guess
8-).)
Stallman et al have taken the stance that the above method still requires
you to distribute your source code. Since your code was designed to work
with the GNU code, and *only* the GNU code, then it must fall under the
copyleft.
Also, rms has stated that a program which mereley includes a *header file*
from the libg++ stuff falls under the copyleft.
Legally, the FSF may have something to stand upon. Morally, they are
leaches.
--
-----------------+
Sean Eric Fagan | "It's a pity the universe doesn't use [a] segmented
se...@sco.COM | architecture with a protected mode."
uunet!sco!seanf | -- Rich Cook, _Wizard's Bane_
(408) 458-1422 | Any opinions expressed are my own, not my employers'.
Lyle Seaman
>FSF's. If I hand someone some object files, and they link with FSF
>libraries, I can't be required to give out source code. If I hand
>someone a binary file already linked with FSF code, my argument is
>that the situation is exactly the same: they can require source to
>the FSF code, which is covered by the copyleft, but they _cannot_
>require source to my code, because it is not covered by the copyleft.
Ok, so suppose you convert the FSF library to a dynamically linked
library, which is linked at runtime (not widespread now, but a few
Unix releases down the road). Then you release your code, and you
ship it with the dynamically linked FSF library. Then what you sell
somebody is your code, and you give them the FSF library and the
sources. If they run the program, well, then it links them together,
but that's not the way you sold it.
Or, you sell the object code, and you give them the FSF library.
You write an installation procedure for your software that does
a link-edit as part of the process...
What does the copyleft say about this kind of thing?
--
Lyle Wang l...@comm.wang.com
508 967 2322 Lowell, MA, USA uunet!comm.wang.com!lws
John Coolidge
>In mi...@unmvax.cs.unm.edu writes:
>>Finally, note that this is really academic. All you have to do is
>>distribute a bunch of .o's and aggregate them with the library.
>>Distribute the source to the library and not your .o's, and supply
>>instructions to link the result.
>Stallman et al have taken the stance that the above method still requires
>you to distribute your source code. Since your code was designed to work
>with the GNU code, and *only* the GNU code, then it must fall under the
>copyleft.
What's the difference, ethically speaking, between this and proprietary
user interfaces? Seems to me that "designed to work with the GNU code"
is a lot like "designed to work with code with the look and feel of
the GNU code". Isn't it entirely possible for someone to come up with
libg++ (for instance) compatible libraries which are Truly Free
Software (or, on the other hand, proprietary software)? If so, that
would tend to deflate these particular sails quite a bit.
>Also, rms has stated that a program which mereley includes a *header file*
>from the libg++ stuff falls under the copyleft.
This is much more problematic, because header files are, indeed, source
code (at least in C++) because they contain inlines. On the other hand,
header files are _also_ interface specifications, which are currently
in a nebulous area of copyright. I really can't believe that either the
FSF or the LPF (League for Programming Freedom) would argue in _favor_
of the copyrightability of software interface specifications, or of
programming language descriptions, or of any such thing, any more than
they'd agree with the copyrightability of user interface specifications.
Major
| Your
| argument above --- that obtaining a piece of software should waive
| license restrictions --- would render the copyleft's license provisions
| (the most important, since copyright law is nowhere near strong enough
| to do what the copyleft attempts) void.
If obtaining a piece of software would waive license restrictions it would
render the copyleft (and in fact the whole FSF) unnecessary. The copyleft
is only a mechanism built on top of the copyright law to emulate the
situation as it would be if there was no copyright law.
| Forcing a waiver of property rights, as the copyleft sometimes
| tries to do, is about as ethically upright as if the car companies were
| to say "any money you make from using our car (sales gained through
| travel, salary from a job you drove to, etc) belongs to us. You choose
| to drive the car...".
I see no ethical problems with this as long as you do not hide the fact
that your are doing it. FSF shout their policy from the rooftops. Don't
like the car deal? Buy your cars elsewhere! Don't like the copyleft? Go
get software elsewhere! The problem is that you seem to WANT to buy the
cars in that particular car yard and they won't give it to you under the
particular terms that you want.
--
Happy hacking! | Everything should be made as simple as possible ...
| and no simpler
Major | - Albert Einstein
ma...@pta.oz.au |
Major
> Copyright law _cannot_ legally be used
>to force someone to abrogate their rights under copyright.
[ Without prejudice. I don't actualy think that that is whats happening
but for the sake of argument ... ]
Why not? If the law can be used to force me to pay money why can't it be
used to force me to pay software.
Jacob Gore
> >Stallman et al have taken the stance that the above method still requires
> >you to distribute your source code. Since your code was designed to work
> >with the GNU code, and *only* the GNU code, then it must fall under the
> >copyleft.
>
> What's the difference, ethically speaking, between this and proprietary
> user interfaces? Seems to me that "designed to work with the GNU code"
> is a lot like "designed to work with code with the look and feel of
> the GNU code". Isn't it entirely possible for someone to come up with
> libg++ (for instance) compatible libraries which are Truly Free
> Software (or, on the other hand, proprietary software)?
The difference is precisely that if you create (or obtain) a library that
is plug-compatible with libg++, you can link with it instead of libg++, and
your program will be a derivative of that library and subject to the
licensing terms of that library and not libg++. You are NOT prevented from
writing software that duplicates the interface of GNU software. That is
the difference.
In other words, if you ship a partial product that needs GNU *CODE* to be
complete, you are not fooling anybody, and the GNU license applies. On the
other hand, if the GNU code is just one of the options to complete the
product, then the product is subject to the GNU license only if you use the
GNU code.
Disclaimer: I am not a lawyer and am not presenting this as legal advice.
Preston Briggs
>In article <MIKE.90Ma...@turing.cs.unm.edu> mi...@unmvax.cs.unm.edu
and several other have posted wondering how they can distribute
object compiled under gcc without distributing the source.
How much sympathy do you expect?
You seem to be content to use tools given to you by
the FSF, but you are unhappy with the goals of the FSF.
You use and modify gcc, which represents a huge effort
in design, programming, distribution, and support;
but you connive to avoid publishing your own source.
Doesn't everyone sneer at lawyers for similar conniving?
The spirit of the FSF is clear: no object without source.
--
Preston Briggs looking for the great leap forward
pre...@titan.rice.edu
David Detlefs
that if one believes GNU libraries, such as G++, should be usable
without legal encumbrance, then one is just a wrong-headed software
hoarder. I think this is perhaps too strong a stance. In my own
view, the the libg++ policy sacrifices long-term goals of the FSF in
favor of a short-term moralistic stance. I believe that the long term
goals of the FSF are best served by targeting specific
well-understoood software tools, and producing extremely high-quality
free replacements. This tools will be at least equal with commercial
competition in terms of quality, and immeasurably superior in terms of
price. Thus, the targetted products will be removed from the arena of
competition, allowing software producers to get on to the serious
business of actually advancing the state of the art. I think this
strategy has is working marvelously for editors, and may yet work well
for C compilers. I think the libg++ policy will prevent this strategy
from working with C++ compilers. Though it is of course technically
possible to use G++ without libg++, in practical terms you can't have
one without the other. Given the existence of competition from, for
example, AT&T, the benefits of libg++ aren't going to convince any
commercial enterprise to chuck the concept of software ownership.
Instead, they're going to by AT&T 2.0. Thus, the libg++ policy helps
to keep commercial enterprises selling proprietary versions of software
available from the FSF in business. Is this worth the moral purity of
the policy?
Well, I am not a free software zealot, or a zealot of any kind -- in
fact, I kind of think Bush is doing the right thing regarding
Lithuania. Maybe I should get some more zeal about some things. My
point here, though, is that the point is nowhere as cut-and-dried as
poeple are making it out to be. In fact, in private communciations
Doug Lea has admitted to some mixed feelings about the current policy.
For what it's worth...
--
Dave Detlefs Any correlation between my employer's opinion
Carnegie-Mellon CS and my own is statistical rather than causal,
d...@cs.cmu.edu except in those cases where I have helped to
form my employer's opinion. (Null disclaimer.)
Dave Sill
cool...@casca.cs.uiuc.edu (John Coolidge) writes:
> se...@sco.COM (Sean Fagan) writes:
> >
> >Also, rms has stated that a program which mereley includes a *header file*
> >from the libg++ stuff falls under the copyleft.
>
> This is much more problematic, because header files are, indeed, source
> code (at least in C++) because they contain inlines.
No, they're source code because they're source code. Code needn't
generate executable commands to qualify as source code.
> On the other hand, header files are _also_ interface specifications...
It doesn't matter what else they are, they're source code.
Copyrighted, licensed, source code subject to the GNU GPL.
----
Dave Sill (ds...@relay.nswc.navy.mil)
"The average American spends 8 full months of his or her life just
opening junk mail."
John Coolidge
>In article <1990Mar30.0...@brutus.cs.uiuc.edu>,
>cool...@casca.cs.uiuc.edu (John Coolidge) writes:
>> code (at least in C++) because they contain inlines.
>No, they're source code because they're source code. Code needn't
>generate executable commands to qualify as source code.
This is true, as far is it goes. But it doesn't go very far.
>> On the other hand, header files are _also_ interface specifications...
>It doesn't matter what else they are, they're source code.
>Copyrighted, licensed, source code subject to the GNU GPL.
I think this matters a great deal. _Are_ the header files for libg++
interface specifications? Are they source code? Are they both? As
interface spcifications --- which I hope that the FSF wouldn't
dream of copyrighting --- they can be quickly (_very_ quickly)
reproduced. Someone with a day or two could produce copyleft-free
versions of the interface-specification parts of the headers.
On the other hand, the inline code parts of the headers are more
difficult. They're _not_ interface specifications, and they _can't_
be mechanically rebuilt from the interface specifications. On the
other hand, most inlines, by the very nature of C++, are very short
code blocks. It's also possible to tell compilers to generate calls
rather than inlines. In this way, it's possible to build most of
the inlines and produce calls for the rest, all using copyleft-
free header files. And this, in turn, makes the argument that, by
using libg++ or the header files, without linking with libg++
oneself, one somehow runs afoul of the copyleft rather silly.
John Coolidge
>You seem to be content to use tools given to you by
>the FSF, but you are unhappy with the goals of the FSF.
>You use and modify gcc, which represents a huge effort
>in design, programming, distribution, and support;
>but you connive to avoid publishing your own source.
David Detlefs (d...@F.GP.CS.CMU.EDU) has written a good response to
this that I pretty much agree with. The problem with responses like
this (which are all too common, and on both sides of the discussion)
is that they argue that, if one disagrees with one part of the FSF,
one must surely disagree with the entirety of the FSF's goals.
This is hardly the case. I agree with the goals of the FSF, even more
than they seem to themselves. I'm working on building free software.
I've modified Gnu programs, and I distribute them with full source. In
short, I'm a model user of Gnu software. I follow both the spirit and
the letter of the GPL, even though I think it's a flawed document,
because that seems to be the right thing to do right now.
However, I _do_ think the GPL is flawed, and I'm not afraid to say it,
even though it may cost me something (the enmity of some elements in
the FSF). I think free software is a good enough idea that it doesn't
need complicated, and legally problematical, licenses to protect it.
I think that the number of people who will abuse free software by
building un-free products with it will do less harm than the GPL does
now by scaring off some people and offending others. I think that
some of the arguments about libg++, and header files, and linking
in general, lead uncomfortably far down the path of software interface
copyrights (or look and feel copyrights on code). I think the FSF
shows a disturbing tendancy to forgo long-term goals and ignore ethics
in order to pursue their short-term goals. I'd like to see this
changed, and so I argue. My dedication is to the goals of free
software, not to the FSF or any other entity.
Edward Vielmetti
In my mind there's a big difference between the need to keep
g++ free and the need to keep gcc free. There are a lot
compilers in the world, and the art is well enough known that
if all copies of gcc were to suddenly and mysteriously vanish
tomorrow, there would still be the possibility of creating a
new free C compiler. (Indeed there exist other C compilers for
which source is available, though they are not free.)
If all copies of g++ were to suddenly and mysteriously vanish,
the world would be left with no free C++ compiler, and no reasonable
expectation of seeing one any time soon. AT&T owns cfront, and
it is emphatically not free, not in any sense. Lose g++ and you've
lost it all. Given that libg++ is an integral part of g++, and
that is not available free from any other source, I think it
is reasonable for people to accept restrictions on its use in order
that g++ may keep its momentum in development vis-a-vis AT&T.
When in the distant future someone comes up with a public domain
libg++ that is unencumbered by the GPL, then it is perhaps time
for GNU to re-think their policy. Until then it is in their
best interests to ensure that g++ development efforts are kept
tightly bound to GNU. Don't like those restrictions? You
know who to write the check to for the competition....
--Ed
Edward Vielmetti, U of Michigan math dept.
e...@math.lsa.umich.edu
John Coolidge
>/ gnu.misc.discuss / cool...@casca.cs.uiuc.edu (John Coolidge) / Mar 29 1990 /
>> libg++ (for instance) compatible libraries which are Truly Free
>> Software (or, on the other hand, proprietary software)?
>The difference is precisely that if you create (or obtain) a library that
>is plug-compatible with libg++, you can link with it instead of libg++, and
>your program will be a derivative of that library and subject to the
>licensing terms of that library and not libg++. You are NOT prevented from
>writing software that duplicates the interface of GNU software. That is
>the difference.
That's true. So, if someone was to sell object code to their program,
and say "link this with libg++, or any other compatible library, or
write a compatible library with this interface, and you'll have a
working program", that wouldn't violate the copyleft, right? That seems
to be the implication. In any case, the linker and not the publisher
will be the one creating the derivative work, and they're allowed to
do so for their own use.
>In other words, if you ship a partial product that needs GNU *CODE* to be
>complete, you are not fooling anybody, and the GNU license applies. On the
>other hand, if the GNU code is just one of the options to complete the
>product, then the product is subject to the GNU license only if you use the
>GNU code.
How can the GPL apply to any code that doesn't include GPL-covered
code, even if it requires GPL-covered code to function? The GPL-
covered code will be added by a third party. You're right --- the
vendor wouldn't be fooling anyone, that's true --- but "not fooling
anyone" is a public-opinion statement. Legally, there's not much you
could accuse them of. They haven't used _any_ GPL-covered code. How,
legally, could the GPL somehow become attached to their code, unless
the GPL-covered code's _interface_ was covered by the GPL? There's no
GPL-code inclusion --- the interface _has_ to be the part that ties
the protected code to the GPL. There's no other handle to grab onto.
Alexander Dupuy
... Though it is of course technically
possible to use G++ without libg++, in practical terms you can't have
one without the other.
Not so. The InterViews C++ library, for one, is distributed in a form which
allows it to be built with g++ but not libg++. Admittedly, without libg++
you'll probably want some alternative library of functions, but the InterViews
stream classes and the NIH C++ (OOPS) library are both in the public domain,
and get you pretty far. And if you want to fork over the $$ to AT&T for a C++
source license, you could try compiling the AT&T libraries with g++.
@alex
--
--
inet: du...@cs.columbia.edu
uucp: ...!rutgers!cs.columbia.edu!dupuy
Sean Fagan
>is plug-compatible with libg++, you can link with it instead of libg++, and
>your program will be a derivative of that library and subject to the
>licensing terms of that library and not libg++. You are NOT prevented from
>writing software that duplicates the interface of GNU software. That is
>the difference.
Sorry. People have quoted rms as saying that even that makes your code
fall under the copyleft. I haven't seen it, so it's hearsay, but it's
something I can imagine him doing. Even if, of course, it would not stand
up in court (unless, of course, apple wins their lawsuit 8-)).
Jacob Gore
> if someone was to sell object code to their program,
> and say "link this with libg++, or any other compatible library, or
> write a compatible library with this interface, and you'll have a
> working program", that wouldn't violate the copyleft, right?
Unless the seller can point to at least one such "other compatible library".
> How can the GPL apply to any code that doesn't include GPL-covered
> code, even if it requires GPL-covered code to function?
I don't know. I was simply stating FSF's position as I understand it: if
something needs GPL-covered code to function, it is a derivative of that
GPL-covered code.
Kevin Paul Herbert
Why is so much bandwidth being used to talk about how to get around the
copyleft, and so little about the ethics of the situation?
Kevin
Larry Wall
: something needs GPL-covered code to function, it is a derivative of that
: GPL-covered code.
I think it's a ludicrous position. By that argument, all perl scripts
fall under the GPL until someone else writes a perl interpreter.
The problem is that word "until". If I consider the perl language (as
an interface, not as a program) as proprietary (I don't), then it's
proprietary whether or not someone has made something else to use that
interface. If someone else makes one, they're in trouble with me, but it's
still proprietary interface.
Now if I don't consider it proprietary, then it's not proprietary already.
It doesn't become non-proprietary when someone "borrows" the idea. If
I considered it proprietary, but someone borrows it and the courts tell
me they can, then it wasn't all that proprietary in the first place, unless
I actually gave it to them somehow, on purpose or accidentally.
If you want to make re-implementability a test of whether a particular
interface implies derivation or mere dependency, I suppose you could,
but what we have here is not the test of re-implementability, but the
test of re-implementedness. If an interface is re-implemented, it
implies a reduction in dependency, but it says nothing about derivation.
In particular, I have difficulty seeing how an object which is MEANT
to provide a set of services, such as an interpreter, or a library,
can have anything derived from it by mere use of those services.
Another problem with using re-implementedness as a test is that it
works the other way around: someone can say, "Since many GPL-covered
routines are re-implementations of code available elsewhere, my code
isn't REALLY dependent on that code, even though I've agregated into
the same text file."
"Mere agregation" is also a very fuzzy concept. Does this mean that
Berkeley can include perl in 4.4 as long as they don't include any
perl scripts? But if they include perl scripts, then their distribution
is dependent on perl. (Or so the argument would go. I wish to go on
record once more as saying that no perl script falls under perl's copyright.
That's my interpretation of the GPL, and that's what counts, in this case.)
Pretending some interface is proprietary until someone else comes out
with one strikes me the same way as those businessmen who charge what the
the market will bear until a competitor comes along. That is, I can hardly
blame them, but I know they're not really interested in my happiness...
...and they don't realize that the high price is mostly helping the
competition. Short-term profits over long-term market share. Yet again.
Sigh. Giving away Free Software shouldn't be like selling tickets to
a concert that nobody wants to go to. Sigh, sigh, sigh.
Larry Wall
lw...@jpl-devvax.jpl.nasa.gov
Piercarlo Grandi
writes:
This is much more problematic, because header files are, indeed, source
code (at least in C++) because they contain inlines.
Header files are source code even if they contain only declarations; an
interface is an abstract shape, which can be realized in potentially many
different declarations. Where a (free) interface can only be realized in a
specific way as a source file, this is not copyrightable, because if an idea
can be expressed in only one way, that way cannot be copyrighted under
most countries' legislation.
On the other hand, header files are _also_ interface specifications, which
are currently in a nebulous area of copyright. I really can't believe that
either the FSF or the LPF (League for Programming Freedom) would argue in
_favor_ of the copyrightability of software interface specifications, or of
programming language descriptions, or of any such thing, any more than
they'd agree with the copyrightability of user interface specifications.
Incidentally, FSF supporters may be amused to learn the the EEC is planning
to enact "legislation" that grants companies the *copyrightability*, not just
patentability, of any and whatever interface they want, instructions sets,
APIs, languages, anything. You'd have to pay copyright fees to *use* them
(it also incidentally makes a copyright breach the *possession* of software
that could be used to circumvent copy protection schemes, which has already
led to the withdrawal from the market of some disk sector editors and backup
software).
Apart from being a legal monstrosity, that subverts all well understood
principles of intellectual property law, this is regarded as a suicidal move
by many, because since virtually all existing popular interfaces would
belong to USA companies, the entire European software industry would become
chained to USA interests.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.abe...@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: p...@cs.aber.ac.uk
Nate Hess
>
>In article <970...@gore.com> ja...@gore.com (Jacob Gore) writes:
>>You are NOT prevented from writing software that duplicates the
>>interface of GNU software. That is the difference.
>Sorry. People have quoted rms as saying that even that makes your code
>fall under the copyleft. I haven't seen it, so it's hearsay, but it's
>something I can imagine him doing. Even if, of course, it would not stand
>up in court (unless, of course, apple wins their lawsuit 8-)).
I, too, have never heard that statement out of rms's mouth or virtual
fingers. I, on the other hand, can't imagine him saying anything that
even vaguely resembles that sentiment. He's firmly engaged in a project
to duplicate (and enhance) the interface of Unix(tm). He is interested
in doing this without getting sued.
So, what makes *you* think that he would say something like that?
--woodstock
--
"What I like is when you're looking and thinking and looking
and thinking...and suddenly you wake up." - Hobbes
nh...@oracle.com or ...!uunet!oracle!nhess or (415) 598-3046
Ronald BODKIN
>
>That is why having GNU-based code is more appealing to hardware-producing
>companies than to those who only make software.
>Me>Yes. And if the management of _your_ company can see past their noses,
>Me>they'd realize that it still makes sense, because other people (and
>Me>companies) enhanced software for _your_ company.
>> This is "highly illogical".
The above argument for use of Gnu software is illogical -- it
isn't claiming that there's no dilemna, it attempts to say that because
someone else benefitted you, its to your advantage to benefit them.
This is a claim that, faced with a prisoner's dilemna, it makes sense
to cooperate. I reject this claim as illogical.
...
>Axioms:
>... 4. o = 0 [overhead insignificant]
> 5. c(X + d(X)) = c(X) + c(d(X))
(minor quibble -- its easier to develop a system as a whole than to develop
one and then modify it -- c(X+d(X)) < c(X) + c(d(X)) but not by much)
> 6. s = g + d(g)
> 7. t(g) = 0
> 8. t(d(g)) << t(s)
Assuming that there are no alternative sources of software than
GNU (e.g. competiting operating systems).
>Theorem:
> 9. c(g+d(g)) << c(s)
[proof omitted]
This still doesn't answer the real question -- is it profitable.
The cost is less, but there may be less revenue derived from the use of
this software. Also, one can sell s, but not g+d(g)...
>My point is that there may not be a dilemma in the first place.
As I say, that's a different question. In some cases there is
not a dilemna (as I imply with my point about small modifications) but
if one is making "major" revisions, then d(g) becomes quite significant
in time and cost factors (reducing to c(g+d(g)) < c(s)) -- also, the
5th axiom becomes dubious -- with major revisions, it is far easier to
develop as a single unit (also the resulting software will generally
be "better" -- in one or several of: smaller, faster, less buggy, etc.)
Ron
Major
| Why is so much bandwidth being used to talk about how to get around the
| copyleft, and so little about the ethics of the situation?
People who want to get around the copyleft have very little ethics
to discuss.
William A. Turnbow
>> doing any themselves?
>
>Then they lag behind you in product introduction.
------
No -- if the other company develops non-free products, then not
only do they not lag behind, but they also get profits from the software
they were working on, while the other company spent time & effort in
developing 'free', non-profit software. To compound matters, the
proprietary company gets the free use of all of 'good' company's
developed freeware.
-wat-
--- An it harm none, do what you will.
*** America vs. developed country rankings: chemistry 11/13, physics 9/13
biology 13/13, infant mortality 1/13, teen pregnancy 1/13
John Kozma
provision in the GPL requiring one to make available source code for one's
own programs is unenforceable.
The theory that you can't avoid the GPL by having your distributee do the
linking is absolutely unsupportable. If a lawyer really came up with that
idea, he or she ought to be disciplined, IMHO.
The knee-jerk response of "The GPL doesn't force you to give away your
code-- just don't use GNU software" is not responsive to my argument that
the GPL is unenforceable. The copyright statutes do impose some limitations
on what can and what can't go in a license, and the simple existence of a
quid pro quo isn't dispositive of the issue. GPL proponents, I think, will
readily admit that the GPL can't legally force anyone to give up his own
copyright, and that the FSF doesn't acquire ownership of the copyright to
anyone's source code by operation of the GPL. I have concluded that these
people don't understand what it means to own a copyright. (No sarcasm
intended-- intellectual property law is highly esoteric, and not well
understood by most lawyers.)
I'm sure the motivation behind the GPL is to undo some of the bad effects
of an overprotective copyright law, but I find it ironic that the GPL
actually goes beyond the copyright law to do so.
John P. Kozma
ko...@comus.cs.tulane.edu
Ted Lemon
>If there is enough interest, I will repost details of my argument why the
>provision in the GPL requiring one to make available source code for one's
>own programs is unenforceable.
I would guess that there is much a much larger portion of the user
community that would vote against you posting such information (I'm
assuming that you're a professional expert in Intellectual Property
law; otherwise, it would be speculation) than would vote for it. I
suggest that you respond by private mail to all those people who ask
you for the information, and allow the rest of us to live in blissful
ignorance.
_MelloN_
Karl Denninger
>
>>If there is enough interest, I will repost details of my argument why the
>>provision in the GPL requiring one to make available source code for one's
>>own programs is unenforceable.
>
>community that would vote against you posting such information (I'm
>assuming that you're a professional expert in Intellectual Property
>law; otherwise, it would be speculation) than would vote for it.
PROVIDING the original poster is willing to state his/her credentials, I
would like to hear this argument.
I would hope the original poster is a legal-type well-versed in this
area of law.
--
Karl Denninger (ka...@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910]
Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
Jacob Gore
(I'm no lawyer.)
I agree that GPL is not an exclusive license.
> A non-exclusive license is a license
> to distribute (etc) without an accompanying promise by the licensor not to
> grant further licenses: in this case it is the licensor who retains the
> exclusive right, ie the right to grant or deny further licenses.
This means that it is necessary for SOMEBODY in the world to have an
exclusive right to the work. Is it? Why?
> It is
> possible to grant a public license, but if such a license is not a dedication
> (placing the work in the public domain), it must be freely revocable by the
> copyright owner (for any reason, or for no reason).
That doesn't sound right. What a great way to sell code: place it in the
public domain, and when there are a million copies of it embedded in other
code, revoke the public license and demand royalties! Are you sure about
this?
> The GPL purports to
> require its licensees to, under certain conditions, to grant a license
> (...) in the GPL licensee's
> copyrighted (source) code. This is fine, but I maintain that such a license
> is freely revocable by the grantor, even with respect to his distributee,
> because it is unsupported (as required by the GPL) by consideration.
Are saying that it would not be revokable if the distributee paid $1 for
it? If so, does the distributee have to be the one that provides something
in consideration? What if FSF paid $1 for it? What if FSF paid for it
with at least $1 worth of code (which it does)?
> If
> the GPL licensee somehow owes a duty to FSF (the GPL licensor) not to revoke
> the public license he granted his distributee in his (the GPL licensee's)
> code, then he (the GPL licensee) effectively shares the right to exclude
> others from distributing (etc) his (the GPL licensee's) code, which means
> the FSF has obtained part ownership of his (the GPL licensee's) copyright.
OK. So, what's the problem? I don't see why one can't consider "part
ownership" of one's code by FSF (or the GPL licensor in general) part of
the price of the license for GPL'ed code. In fact, you are paying for the
GPL'ed code with, probably, at least $1 worth of ownership. Consideration,
right?
Piercarlo Grandi
[ the GPL requires the copyright holder of any work
that includes GPL work to grant the right to copy the whole
work which terms equivalent to the GPL's ]
[ Somebody objects that this is not a valid contract because
such contract does not include consideration ]
The granting of rights to copy can be the effect of a contract, but the
granting of rights does not necessarily require a contract. In
particular the GPL itself is not a contract, as far as I can understand
the issue.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.abe...@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Piercarlo Grandi
The granting of rights to copy can be the effect of a contract, but the
granting of rights does not necessarily require a contract.
Whatever the legal nature of the GPL, let's look at it the other way round,
on the issue of its enforceability:
By default, nobody can copy except the copyright holder. The copyright holder
may grant permission to copy, e.g. as the result of a contract, or by any
other suitable means.
The GPL is an instrument giving permission to copy; this is its main effect,
not the conditions it imposes on people that want to distribute (not
include!) copies of GPL software along with theirs.
Note: let me repeat that the conditions for distributing copies of
GPL software apply only if *distribution* with other software takes
place; you can always take GPL software and include it in your own
software, and keep yours secret and proprietary, as long as you don't
distribute it to third parties. The GPL imposes *no* conditions on
_use_ of GPL software, making copies for third parties, or making
copies for oneself to be incorporated in own software; only the
redistribution along with other software is subject to conditions.
If the GPL is null and void, then the software covered cannot be copied by
anybody (it may be argued that only the conditions imposed on redistribution
of copies are null and void, but in this thread we are arguing whether the
GPL itself is a valid legal instrument), whether alongside other software or
on its own.
brn...@stealth.acf.nyu.edu
unknowing programmers were adequately informed of what they'd have to do
if they distributed GPL-covered code, then opposition to it would almost
vanish.
In article <PCG.90Ap...@rupert.cs.aber.ac.uk> p...@cs.aber.ac.uk (Piercarlo Grandi) writes:
> In article <970...@gore.com> ja...@gore.com (Jacob Gore) writes:
> [ the GPL requires the copyright holder of any work
> that includes GPL work to grant the right to copy the whole
> work which terms equivalent to the GPL's ]
> [ Somebody objects that this is not a valid contract because
> such contract does not include consideration ]
Whether contracts require consideration is (at least here) decided by
the states. In New York the GPL is prima facie unenforceable. It appears
that as an contract of adhesion the GPL must be interpreted against the
restricted party; there's a strong argument that all the limitations of
the author's rights can be upheld, without any of the ambiguous or
unenforceable restrictions upon those limitations. I wish someone would
test this in court.
A more specific applicable decision is the Federal decision in Louisiana
a few years back that shrink-wrap licenses are unenforceable. This is
really a question of warning: if people using GPL-covered code were
adequately informed of the real extent of their rights under the GPL
before they received copies of the code, then it probably wouldn't
qualify as a shrink-wrap license.
A much more general principle making the same point extremely clear
appears in a section of the United States copyright statutes: an author
can never be unwillingly deprived of his exclusive copyrights. It's a
real shame NeXT didn't try this tack when they were bulldozed into
distributing their compiler for free because they hadn't realized the
effects of the GPL. If you're an author, and you've been selling a
product derived from GNU code without realizing the effects of the GPL,
and now the FSF is trying to steal your profits: Read 17 USC!
> In
> particular the GPL itself is not a contract, as far as I can understand
> the issue.
All licenses are contracts.
---Dan
brn...@stealth.acf.nyu.edu
> If the GPL is null and void, then the software covered cannot be copied by
> anybody
That just isn't how United States contract law works. A contract of
adhesion is resolved against the adhesing party. In most cases that
means that all ambiguities and unenforceable portions of the contract
are interpreted the way the other party interprets them.
For example: Foo Inc. hires you. Part of your Foo Inc. contract says
``Piercarlo is permitted to use our equipment as long as he behaves.''
You can apply any reasonable interpretation to ``behaves''; just because
the restriction is ambiguous doesn't mean the permission is lost.
A real example, names changed to protect the guilty: Project Minerva's
lawyers draw up a ``volunteer contract'' for outside programmers to sign
before contributing any code to, ummm, Berkeros. The volunteer contract
gives absolutely nothing to the volunteers and hence is unenforceable
(at least to a volunteer, Jan, who signed the contract in New York).
Part of the contract stipulates that any Project Minerva trade secrets
observed during the volunteer work be respected. If Jan had in the
course of his ``contracted'' work happened to come across such secrets,
he could have ignored the restrictions and made them public. (Of course,
Jan would never do that, 'cause he's a really nice guy. :-) )
---Dan
David Vinayak Wallace
Date: 29 Apr 90 09:03:38 GMT
From: brn...@stealth.acf.nyu.edu
A much more general principle making the same point extremely clear
appears in a section of the United States copyright statutes: an author
can never be unwillingly deprived of his exclusive copyrights. It's a
real shame NeXT didn't try this tack when they were bulldozed into
distributing their compiler for free because they hadn't realized the
effects of the GPL.
Time out for reality check: NeXT was not ``bulldozed'' into anything.
The only holdup was that the release was shunted to the bottom of the
NeXT lawyers' stack. I confirmed this on Friday wih the person who
ought to know: the guy at NeXT who did the work.
I can't understand what all this ``unwilling'' and ``unknowing''
business is about. You can't modify the source code without seeing a
copyright notice which either includes or points you at the license
terms. And if you modify sources without reading them well, you have
more problems than just worrying about selling the code.
Seems to me that once you've been informed of the licensing
conditions, if you go ahead you implicitly agree to them.
Richard Murphey
A much more general principle making the same point extremely clear
appears in a section of the United States copyright statutes: an author
can never be unwillingly deprived of his exclusive copyrights. It's a
real shame NeXT didn't try this tack when they were bulldozed into
distributing their compiler for free because they hadn't realized the
effects of the GPL.
Was NeXT was unwillingly bulldozed into giving away their compiler
sources? Who bulldozed them?
--
Ri...@Rice.edu
Ted Dunning
recent postings here have missed the real reason that the gnu license
is unenforceable: the free software foundation does not have the
resources to enforce it. if their pockets had the depth that apple's
do, then there might be some point to worrying about the technical
merits of the license.
on the other hand, the license has already succeeded in its true
intent of encouraging source distribution of software. the reasons for
this success have not been the legal merits of the license, but rather
the goodwill of the programming populace.
Joe Buck
>A more specific applicable decision is the Federal decision in Louisiana
>a few years back that shrink-wrap licenses are unenforceable. This is
>really a question of warning: if people using GPL-covered code were
>adequately informed of the real extent of their rights under the GPL
>before they received copies of the code, then it probably wouldn't
>qualify as a shrink-wrap license.
With shrink-wrap licensing, you pay money before seeing the license.
Gnu software is free; if you read the license and don't like the terms,
you're free to delete the code. If you paid for a tape, you've paid
a fee for distribution (the labor of making the tape, the cost of the
tape, and the cost of shipping). Your precedent doesn't seem to apply.
>A much more general principle making the same point extremely clear
>appears in a section of the United States copyright statutes: an author
>can never be unwillingly deprived of his exclusive copyrights. It's a
>real shame NeXT didn't try this tack when they were bulldozed into
>distributing their compiler for free because they hadn't realized the
>effects of the GPL.
Anyone at Next who thought otherwise must believe in free lunches.
I'll bet 80% of lines of source code in Next's compiler were written
by Richard Stallman. Why should NeXT get to use this work for free?
The license is really very simple -- if you want to keep your source
private, you can. You can even use Gnu Emacs to edit it and GCC to
compile it. But everything you ship must be your own product.
>If you're an author, and you've been selling a
>product derived from GNU code without realizing the effects of the GPL,
>and now the FSF is trying to steal your profits: Read 17 USC!
Give it up. If the above applies to you, you're either incredibly stupid
or a thief. Every module of every GNU program is clearly labeled. You've
been informed that you can't sell GNU software as your own.
The only case where a software vendor could be confused is if he doesn't
realize that some GNU code has been linked in as part of a library,
and according to Michael Tiemann (author of G++) the FSF is planning
some loosening up in this area, which is the only one where people
have legitimate problems.
The GNU Public License doesn't force you to give your code away; you
have several options:
1) Distribute your code with the GNU code according to the
GNU License.
2) Develop with Gnu tools, but make sure that everything you
ship is your own.
3) Use your combined software within your own organization,
but don't distribute it to anyone else.
--
--
Joe Buck
jb...@ohm.berkeley.edu {uunet,ucbvax}!ohm.berkeley.edu!jbuck
Joe Buck
>on the other hand, the license has already succeeded in its true
>intent of encouraging source distribution of software. the reasons for
>this success have not been the legal merits of the license, but rather
>the goodwill of the programming populace.
But this is what was intended in the first place, and I would prefer
that FSF concentrate on this (and they are really doing it anyway):
compete on the basis of features and price (where price = $0.00).
But without the license, vendors could take all of GNU, add a few
useful features, charge big bucks for the lot, and give nothing back.
David Vinayak Wallace
Date: 29 Apr 90 17:12:45 GMT
From: t...@nmsu.edu (Ted Dunning)
recent postings here have missed the real reason that the gnu license
is unenforceable: the free software foundation does not have the
resources to enforce it. if their pockets had the depth that apple's
do, then there might be some point to worrying about the technical
merits of the license.
The foundation does have a sugar daddy who will cover court costs of
defending their copyright. Although he doesn't have the resources of
Apple, true, I know he would come through to get things going and I
think the adverse publicity would cause others to come forwad to help.
If this were true there would be no need to assign the copyright on
new programs to the Foundation -- you could just do it yourself. Just
like sharing sources lets you just write the new part of your program,
assigning the copyright lets you just do the hacking, and not the
legal bull.
on the other hand, the license has already succeeded in its true
intent of encouraging source distribution of software. the reasons for
this success have not been the legal merits of the license, but rather
the goodwill of the programming populace.
I find this refreshing and reassuring. I am glad that there are still
American companies which plan for the long term and realize how much
better off they are with full source distribution and true open
computing.
brn...@stealth.acf.nyu.edu
> I can't understand what all this ``unwilling'' and ``unknowing''
> business is about. You can't modify the source code without seeing a
> copyright notice which either includes or points you at the license
> terms.
I agree fully that someone who looks at GNU code and sees the copyright
notice is responsible for respecting that copyright.
However, a huge portion of code use and reuse under UNIX doesn't involve
source code at all. A GNU program installs a library; someone sees the
library and uses it or, in the worst case, doesn't even know he's using
the library at all. When you install gcc, does it send mail to all your
users warning them that, unlike most UNIX compilers, it doesn't produce
freely redistributable output? No.
> Seems to me that once you've been informed of the licensing
> conditions, if you go ahead you implicitly agree to them.
This isn't true when the license is unenforceable.
---Dan
brn...@stealth.acf.nyu.edu
> intent of encouraging source distribution of software.
The extent of this encouragement has been negligible.
> the reasons for
> this success have not been the legal merits of the license, but rather
> the goodwill of the programming populace.
Wunderbar. Why is the FSF so opposed to using clear, easy-to-understand,
legally sound licenses? When corporate lawyers review the GPL and say it
has problems, why doesn't the FSF get the message and rewrite the GPL to
avoid those problems? What does the FSF gain by failing to do this?
---Dan
brn...@stealth.acf.nyu.edu
program that uses the g++ libraries. He sells the source to the program,
for a hefty $150 per tape. To install the program, the recipients need
only compile it---under g++, of course.
This is the ``GPL Library Scenario.'' Notice that someone could get into
the scenario without ever seeing any g++ source, or even the GPL.
The FSF has repeatedly claimed that such a program must fall under the
GPL, by section 2(b). I find this virus effect an outrageous expression
of a morally corrupt attempt to trap people into accepting a philosophy
that should be a matter of individual choice, but I'll stick to the
legal reasons why the FSF's position is untenable. The GPL has many
other problems, but this is by far the most important, as well as the
most clear-cut.
In article <35...@ucbvax.BERKELEY.EDU> jb...@galileo.berkeley.edu.UUCP (Joe Buck) writes:
> In article <976:Apr2909:03:38...@stealth.acf.nyu.edu> brn...@stealth.acf.nyu.edu (Dan Bernstein) writes:
[ I point out that shrink-wrap license enforcement has been struck down ]
> With shrink-wrap licensing, you pay money before seeing the license.
No. A shrink-wrap license is (literally) a license that you supposedly
agree to by breaking the plastic---even after you've legally obtained
the product. Whether ``legally'' refers to buying or to something else
is irrelevant. The principle that shrink-wrap licenses are invalid
extends to any license that purports to apply conditions not stated
until after receipt.
Maybe you don't understand the point of licenses. For the distributor of
a work, selling a copy means giving away ownership of that copy; and
then the owner has certain permanent rights, such as the right to keep
the copy forever and the rights under the First Sale doctrine. Licenses
can remove these ``disadvantages'': if the distributor can get the buyer
to agree that ownership of the copy remains with the distributor, then
he can restrict the buyer's rights much more effectively.
Say you walk into ComputerLand, see a program on a shelf, and buy it.
That copy is now yours. You leave the store, open the box, and see a
shrink-wrapped package with a license showing through the shrink-wrap.
The license says, basically, ``We retain ownership of this product. You
don't get ownership rights. If you disobey these terms, you must destroy
all copies. We do allow you to use the product or make one backup copy.
By breaking the plastic you agree to this license.''
Now it's patently obvious that the license is unenforceable: you didn't
agree to those terms when you paid. Software companies tried to get
around this with several arguments, most importantly that since you
could return the unopened package for a full refund, your payment really
occurred the moment you opened the package. Fortunately, common sense
triumphed in Federal court: only your legal ownership of the package
mattered, not the distributors' concept of where money went when. Now
we're seeing things like Borland's quite straightforward ``you can use
this just like a book.''
Why is the GPL unenforceable? If I anonymous ftp to MIT and pick up
Emacs, I don't (can't!) see the license until after I've received the
entire package. But at that point the copy is mine, and I don't have to
pay attention to section 2(b). In the GPL Library Scenario, John is
doing nothing outside his normal ownership rights: he's neither
modifying g++, nor distributing it, nor using it in public. So the FSF's
position here is completely unfounded.
> if you read the license and don't like the terms,
> you're free to delete the code.
That's exactly the argument they struck down in Louisiana. It doesn't
make the license enforceable.
> If you paid for a tape, you've paid
> a fee for distribution (the labor of making the tape, the cost of the
> tape, and the cost of shipping).
And once I've received the tape, it's mine, unless I agreed otherwise
beforehand. Get that straight.
> >If you're an author, and you've been selling a
> >product derived from GNU code without realizing the effects of the GPL,
> >and now the FSF is trying to steal your profits: Read 17 USC!
>
> Give it up. If the above applies to you, you're either incredibly stupid
> or a thief.
I've always been very careful to keep GNU stuff separate from the rest
of the system, and I distribute my UNIX software for free anyway, so I
have no personal problems with the GPL. I'm mainly worried about poor
John in the GPL Library Scenario, as well as the morals that let you
think you can call him a thief.
> Every module of every GNU program is clearly labeled.
Bullshit. I can use g++ without seeing even a mutter of the GPL. Nothing
in the g++ installation instructions even gives a hint that there's a
potential problem.
> The only case where a software vendor could be confused is if he doesn't
> realize that some GNU code has been linked in as part of a library,
I'm glad you recognize that the FSF has no rights here, but I don't
think it's John who's confused.
> The GNU Public License doesn't force you to give your code away; you
> have several options:
> 1) Distribute your code with the GNU code according to the
> GNU License.
To some people, that's giving your code away.
> 2) Develop with Gnu tools, but make sure that everything you
> ship is your own.
I'll believe that the FSF understands this when I see it.
> 3) Use your combined software within your own organization,
> but don't distribute it to anyone else.
That's a very bad idea. A disgruntled employee could then force you to
make the source code free, and your whimpered ``sorry, Your Honor, I
didn't understand what distribution meant'' wouldn't go over too well.
---Dan
David Vinayak Wallace
Date: 30 Apr 90 04:21:30 GMT
From: brn...@stealth.acf.nyu.edu
In article <GUMBY.90A...@Cygnus.COM> gu...@Cygnus.COM (David Vinayak Wallace) writes:
> I can't understand what all this ``unwilling'' and ``unknowing''
> business is about. You can't modify the source code without seeing a
> copyright notice which either includes or points you at the license
> terms.
[brnstnd agrees, but...]
However, a huge portion of code use and reuse under UNIX doesn't involve
source code at all. A GNU program installs a library; someone sees the
library and uses it or, in the worst case, doesn't even know he's using
the library at all.
I'm not sure what this means. All I can imagine:
1> User sees the new "foo" library. She/he checks the documentation
or header files to learn the calling conventions. Said docs/headers
point to the licensing terms. User makes and informed choice.
2> User links with libc.a. But this libc happens to to be copylefted
by the FSF. It acts just like any other libc; it may have some
extensions but the user doesn't know this. I agree the copyleft
could use a clarification here: the intent is that this doesn't
affect the caller since the user isn't using any special feature of
the copylefted code; you could replace it with another behind the
user's back and he/she wouldn't notice.
When you install gcc, does it send mail to all your
users warning them that, unlike most UNIX compilers, it doesn't produce
freely redistributable output? No.
No and why should it? You may do whatever you want with its output.
The licence covers the compiler's source code and binary, not your
code which you transform with it. Likewise modifications to the
editor are covered, but not programs you edit WITH the editor.
The licence discusses the program's source and modifications thereto.
It says nothing about what you may or may not use it for. In addition
the foundation has stated publically that this does not apply to
programs run through the compiler.
What's the use of putting up a straw man?
David Vinayak Wallace
Date: 30 Apr 90 05:37:22 GMT
From: brn...@stealth.acf.nyu.edu
Let me restrict attention to just one scenario: John Shmoe writes a
program that uses the g++ libraries. He sells the source to the program,
for a hefty $150 per tape. To install the program, the recipients need
only compile it---under g++, of course.
This is the ``GPL Library Scenario.'' Notice that someone could get into
the scenario without ever seeing any g++ source, or even the GPL.
I don't understand. The end user could do so without seeing the
source, but so what? And for reasons outlined in my previous message,
it would be hard to use the libraries without being pointed at the GNU GPL.
The FSF has repeatedly claimed that such a program must fall under the
GPL, by section 2(b). I find this virus effect an outrageous expression
of a morally corrupt attempt to trap people into accepting a philosophy
that should be a matter of individual choice...
If this is a moral, rather than technical argument, then where's the
beef? Positing for the moment that there might be no opportunity for
the user to escape seeing the GPL, then this is entirely a free-choice
transaction. The FSF is hardly a monopoly software provider, so if
you choose to use their code you also must choose to agree to their
terms. The choice is the individual's.
Positing that there may be a notification problem, make a suggestion.
Or are you saying there's no valid way to distribute the software
without charging for it (so that you can verify that each user has read
and signed an agreement?)
In article <35...@ucbvax.BERKELEY.EDU> jb...@galileo.berkeley.edu.UUCP (Joe Buck) writes:
> Every module of every GNU program is clearly labeled.
Bullshit. I can use g++ without seeing even a mutter of the GPL. Nothing
in the g++ installation instructions even gives a hint that there's a
potential problem.
It turns out that the README file lacks a GPL pointer, and that
someone who is lucky enough to be able to install it with no problems
and without reading the Makefile (step 3 says "Read carefully the
comments at the top of the Makefile" -- which contains at the top a
pointer to the GPL) could just possibly avoid learning that there is a
public license. This will be rectified in the next distribution.
> The GNU Public License doesn't force you to give your code away; you
> have several options:
> 1) Distribute your code with the GNU code according to the
> GNU License.
To some people, that's giving your code away.
Get a grip! To some people taxation is theft. To some people
anything is bad. YOU DON`T HAVE TO USE GNU CODE! THERE IS NO GUN
POINTED TO YOUR HEAD. THEY HAVE NO MONOPOLY.
> 2) Develop with Gnu tools, but make sure that everything you
> ship is your own.
I'll believe that the FSF understands this when I see it.
Gee, it's pretty hard to miss. Think of all the companies which used
GCC or G++ to develop and distribute proprietary code: Sun, NeXT, DG,
Thinking Machines, Intel, Motorola, just to name a few off the top of
my head. Their lawyers apparently didn't see any harm with it.
Neither has the FSF.
> 3) Use your combined software within your own organization,
> but don't distribute it to anyone else.
That's a very bad idea. A disgruntled employee could then force you to
make the source code free, and your whimpered ``sorry, Your Honor, I
didn't understand what distribution meant'' wouldn't go over too well.
Oh foo. There's nothing special about this. A disgruntled or
unthinking employee could reveal the source to ANY company's special
product (even the coke formula; there's nothing special about software
in this regard) or could make 200 copies of Lotus 1-2-3.
1> Most of us have signed agreements as to how the company treats
this. Non-disclosure of company secrets or enforcement of company
licenses. The copyleft is irrelevent to this.
2> I doubt that the foundation would enforce the copyleft in this case
(come on, they're human!) but in any case the company would have
more important things to worry about that that. If some
disgruntled employee were revealing company secrets, the company
would have to deal with the secrets' becoming public knowledge.
The degree of resistance to closing the barn door would be irrelevent.
David Vinayak Wallace
Date: 30 Apr 90 04:29:24 GMT
From: brn...@stealth.acf.nyu.edu
Wunderbar. Why is the FSF so opposed to using clear, easy-to-understand,
legally sound licenses? When corporate lawyers review the GPL and say it
has problems, why doesn't the FSF get the message and rewrite the GPL to
avoid those problems? What does the FSF gain by failing to do this?
What makes you say that they are opposed to clear or sound licenses?
It is very hard to write one. I have written one; I know it's hard.
If you have better lanuagge which achieves the same effect, plase send
it to the FSF. Their plan is not to be obscurantists (then again,
they're not lawyers, and their role is not just to write contracts,
but code).
Also, don't forget that corporate lawyers, and most lawyers in
general, are trained to look for tricky boundary cases. Any lawyer
can find a problem with ANY contract. After all, the practice of law
is the practice of ontology, not of theorem proving! For any
corporate lawyer you find who has problems with the GPL I can find one
who represents a company which is happy with it. But what would this
prove?
Russ Nelson
When you install gcc, does it send mail to all your users warning
them that, unlike most UNIX compilers, it doesn't produce freely
redistributable output? No.
Ignorance of the law is no excuse. If you distribute software without
first checking the copyright, you lose.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems
Ted Dunning
> Seems to me that once you've been informed of the licensing
> conditions, if you go ahead you implicitly agree to them.
This isn't true when the license is unenforceable.
just because an agreement is unenforceable does not mean that you
can't agree with it. if i agree to have lunch with somebody, or if
somebody pledges money to a public radio station, or tithes to their
church, the unenforceable nature of these agreements does not prevent
agreement or compliance with the agreement.
if there is a better form that the gpl can take, then please suggest
it.
Joe Buck
>However, a huge portion of code use and reuse under UNIX doesn't involve
>source code at all. A GNU program installs a library; someone sees the
>library and uses it or, in the worst case, doesn't even know he's using
>the library at all. When you install gcc, does it send mail to all your
>users warning them that, unlike most UNIX compilers, it doesn't produce
>freely redistributable output? No.
gcc does produce freely distributable output; even if you can find some
lawyer who disagrees with this, it doesn't matter because Richard Stallman
believes it (he's said so on the record) so he won't come after you. It's
only if you link with gnu libraries that you have a problem. Right now
there isn't any gcc library to worry about. The only thing that gets you
here is bison licensing.
This is more of a problem with g++. To avoid any confusion, since version
1.36 you have to say -lg++ on the command line now to get the libg++ library.
If you don't say "-lg++" and everything you link in is your own, the code
is all yours.
If anyone doesn't like this, they can produce replacement libraries that
are freely redistributable. I might even contribute to such an effort,
since I have no problems with people selling software. But when I use
Gnu software I don't think it's an evil thing to follow the conditions.
>> Seems to me that once you've been informed of the licensing
>> conditions, if you go ahead you implicitly agree to them.
>This isn't true when the license is unenforceable.
But if you believe the license is unenforceable, your attempt to license
the code you steal may be unenforceable as well -- you sell a binary, and
everyone happily gives your binary code away, refusing to pay you except
for the first copy. What are you going to do? The onus would then be
on you to prove a violation, and you've already shown your own disrespect
for licensing.
A little old lady's rights to personal safety in a very bad neighborhood
may be unenforceable, because there isn't enough police presence to stop
the thieves. But if you violate the Gnu license on the theory that it's
unenforceable, you're just another thief -- willing to steal from someone
because you believe they are helpless.
Even in the absence of a legal document you think is up to snuff, if you
were a gentleman you would honor the wishes of someone who has given you,
for free, valuable software, not to use it in a way that violates the
author's principles, even if you disagree with them.
Ronald Cole
This is more of a problem with g++. To avoid any confusion, since version
1.36 you have to say -lg++ on the command line now to get the libg++ library.
If you don't say "-lg++" and everything you link in is your own, the code
is all yours.
look at the source to gcc.c in the g++ distribution! The hints file says this,
but it isn't true. As of 1.37.2, g++ still loads -lg++ for you (to bring in
__main).
--
Ronald Cole | uucp: unify!rjc voice: +1 916 920 9092 x734
Software Engineer II | internet: csusac!unify!r...@ucdavis.edu
Unify Corporation +----------------------------------------------------
"Bo knows OOP"
Ted Dunning
In article <TED.90Ap...@kythera.nmsu.edu> t...@nmsu.edu (Ted Dunning) writes:
> on the other hand, the license has already succeeded in its true
> intent of encouraging source distribution of software.
The extent of this encouragement has been negligible.
is the freeing of the mach kernel negligible?
how about bash, gawk, bison, flex, sbprolog and many other programs
which have been written and are now covered by copyleft?
i agree that the proportion of all software delivered that is either
covered by some variant of the gpl or which is public domain is still
small, but the amount is growing at least partly due to the efforts of
the free software foundation.
David Vinayak Wallace
Date: 1 May 90 02:51:50 GMT
From: will...@athena1.Eng.Sun.COM (William A. Turnbow)
In article <GUMBY.90A...@Cygnus.COM> gu...@Cygnus.COM (David Vinayak Wallace) writes:
>I can't understand what all this ``unwilling'' and ``unknowing''
>business is about. You can't modify the source code without seeing a
>copyright notice which either includes or points you at the license
>terms. And if you modify sources without reading them well, you have
>more problems than just worrying about selling the code.
>
>Seems to me that once you've been informed of the licensing
>conditions, if you go ahead you implicitly agree to them.
Perhaps if you work with the source code, maybe, but suppose you
are an end user of g++ and link with the standard stream libraries.
I already answered this:
1> If you link with the gnu stream library in a way indistinguishable
from the standard stream library there is no effect.
2> If you use some libG++-specific feature you must have read the
documentation or header file to figure out how to use it, and hence
been pointed at the conditions.
An end user of this compiler/library can NEVER look at source
code or the agreement.
Are you saying he is covered too?
Huh? Sure. The license says clearly in section 3 that when you
distribute a derivative work or the work itself that you must offer or
distribute the sources to that the recipient may redistribute too at
his/her option.
Also most GNU programs have to start up with an annoying blurb which
explains your rights.
Even someone who installs the g++ from scratch may only type
make and copy the resultant files off somewhere -- he also may
never read the GNU license agreement.
It never works this well. But I discovered that the G++ installation
instructions only indirectly point to the copyleft -- but that is
fixed in the next release.
Using source is one thing, but using the binary libraries it seems
is something else entirely.
It's hardly only the FSF who licenses binary libraries. That's de
rigeur, except in certain parts of the unix and PC world. What's
unusual is that the FSF requires source distribution too.
Free software is truly open software! Most vendors use the phrase
just to obscure the nature their proprietary work. How can software
consumers put up with this?
William A. Turnbow
>I can't understand what all this ``unwilling'' and ``unknowing''
>business is about. You can't modify the source code without seeing a
>copyright notice which either includes or points you at the license
>terms. And if you modify sources without reading them well, you have
>more problems than just worrying about selling the code.
>
>Seems to me that once you've been informed of the licensing
>conditions, if you go ahead you implicitly agree to them.
Perhaps if you work with the source code, maybe, but suppose you
are an end user of g++ and link with the standard stream libraries.
Are you going to tell me that the GNU license agreement is
displayed each time a user does a link?
An end user of this compiler/library can NEVER look at source
code or the agreement.
Are you saying he is covered too?
Even someone who installs the g++ from scratch may only type
make and copy the resultant files off somewhere -- he also may
never read the GNU license agreement.
Using source is one thing, but using the binary libraries it seems
is something else entirely.
-wat-
--
***
We felt the effects of herb were so dangerous that it was better
to lie to the american public to save them rather than tell them
the truth -- Partnership for a Drug Free America
Joe Buck
(William A. Turnbow) writes:
> Even someone who installs the g++ from scratch may only type
> make and copy the resultant files off somewhere -- he also may
> never read the GNU license agreement.
This would be difficult; the installation procedure for g++ is quite complex
and you have to do a lot of work to make it fly. It's not like typing "make".
Vincent Manis
extremely amusing (much as I found funny Ashton-Tate's argument that it
could copyright a language: how exactly would one place an infinite set
of strings into the Library of Congress).
Surely the assignment of rights does not require something of value to
be exchanged. Can I go into my local library, take a look at the
contents and then publish them as my own? (Imagine: `Bright Lights, Big
City', by Vincent Manis. `Slaves of New York', by Vincent Manis. `The
Shining', by Vincent Manis. `The World According To Garp', by Vincent
Manis. I could retire!)
My understanding of copyright, at least under the Berne Convention, is
that the author retains all rights to the work, save those s/he
*explicitly* relinquishes. If somebody sends me letters, I can't publish
them, without getting an explicit release. You don't even have to put a
little C in a circle to get that protection.
The GPL simply consists of a set of conditions under which the author
permits the software to be used. This constitutes a declaration that
certain rights which the author retains by default can be transferred to
other people, provided that other conditions are met. Any copyright
notice which states that a book's contents may not be entered into an
information retrieval system represents exactly the same sort of
situation. The fact that you picked up a book off the sidewalk doesn't
release you from the copyright restrictions.
Copyright isn't a contract. A licence is not a contract. Software
licences actually comprise two parts: an assignment of rights of
copyrighted material, and specific statements regarding warranty,
delivery, and the like. That does bring up the validity of the Limited
Warranty attached to the GPL. However, either no contract exists, in
which case FSF is not liable, or a contract does exist (say if you buy a
copy directly from them), in which case the Warranty applies. But none
of this has anything to do with the rights to use the materials.
--
\ Vincent Manis <ma...@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
Gordon Joly
>This would be difficult; the installation procedure for g++ is quite complex
>and you have to do a lot of work to make it fly. It's not like typing "make".
>Joe Buck
>jb...@ohm.berkeley.edu {uunet,ucbvax}!ohm.berkeley.edu!jbuck
I strongly disagree. For a sun3 with SunOS 4.x, config sun3-os4 and
typing "make install" (these days ;-), is all you need for G++; libg++
may be a little more involved. If you are running on a ToasTer with
ToasTOS 5.88 under VM (tm?) then you may have some work to do.
Gordon.
JANET:g...@uk.ac.ucl.sm.psych UUCP:g...@ucl-psych.UUCP ARPA:gj...@nsf.ac.uk
Dept. of Psychiatry, University College & Middlesex School of Medicine,
Middlesex Hospital, Mortimer Street, LONDON W1N 8AA.
Tel +44 71 380 9472 FAX 323 1459
Joe Buck
the copyleft)
> >This would be difficult; the installation procedure for g++ is quite complex
> >and you have to do a lot of work to make it fly. It's not like typing
"make".
> >Joe Buck
> >jb...@ohm.berkeley.edu {uunet,ucbvax}!ohm.berkeley.edu!jbuck
Gordon Joly replies:
> I strongly disagree. For a sun3 with SunOS 4.x, config sun3-os4 and
> typing "make install" (these days ;-), is all you need for G++; libg++
> may be a little more involved. If you are running on a ToasTer with
> ToasTOS 5.88 under VM (tm?) then you may have some work to do.
You've skipped a few steps, Gordon. Like the fact that you have to build
gcc first, have to have the gcc directory in a certain position with
respect to the g++ directory, etc. Also, if you've used the gcc option
to build in a different directory (as I did) the installation procedure
won't work.
There are quite a few people who ftp'd g++ and only then found out they'd
need to get gcc as well, as well as libg++. It takes a bit of time.
Once you've done it once it gets a lot simpler.
And even if all I had to do was say "config sun3-os4" and "make install",
I'd still need to read the file telling me to do that, which points
indirectly to the copyleft.
Is there anyone out there who managed to install g++ successfully on their
system without ever reading the Gnu copyright? (That is, you never saw
it in your whole life, and managed to install gcc, maybe Gnu Emacs, etc
and STILL didn't know there was a specific set of rules?)
Piercarlo Grandi
In article <1119:Apr2909:36:46...@stealth.acf.nyu.edu>
brn...@stealth.acf.nyu.edu writes:
In article <17...@aber-cs.UUCP> p...@cs.aber.ac.uk (Piercarlo Grandi) writes:
> If the GPL is null and void, then the software covered cannot be copied by
> anybody
That just isn't how United States contract law works. A contract of
adhesion is resolved against the adhesing party. In most cases that
means that all ambiguities and unenforceable portions of the contract
are interpreted the way the other party interprets them.
But I reckon that the GPL *isn't* a contract. It has almost nothing of a
contract. It is certainly not a shrinkwrap license, or anything similar;
there are no conditions, consieration, or whatever else for you to get
and use a copy of GPL software; anybody can get a copy for free, and the
copy you get is yours 100%, not licensed or leased to you. You have full
ownership of the copy, just as for a book.
The GPL only imposes conditions on *distribution*, i.e. where you make
further copies from your copy in order to give them away. It gives you
unconditional permission to make further copies for your own use. If
the GPL did not exist, you could get copies to free software, but you
could not make further copies either for your use or for giving them
away.
The GPL is not an agreement between you and the copyright holder; there
is no meeting of wills in the GPL. It is a purely unilateral concession
from the copyright holder. You cannot copy copyrighted work not because
there is contract between you and the author by which you agree not to
make copies, but because the author is given by the law an "absolute"
property right to make copies, and he may dispose of such right in any
legal way, including, but not limited to, contract.
Under the GPL the copyright holder simply notifies you that you have
permission to make copies yourself under no or some conditions. If you
do not respect the conditions, the copyright holder does not grant you
the permission to make copies, and that's all.
A note: it might be debated whether the GPL does transfer you
some limited nonexclusive portion of the copyright, in which
case the question of whether it is a valid instrument for doing
so arises (the instrument must be "in writing"; the GPL surely
does even bear a signature).
A further note: this might imply that you can do what you want
with your copy, as the GPL does not restrict that, but only
*copying*. Well, this could mean that you could give away your
own copy, even for money, and under any conditions whatsoever.
This could open a (large) loophole in the GPL. It could only be
closed by actually giving copies out with a proper contract, and
thus asking the recipient to explicitly agree to restrictions on
the *use* of the copy. This cannot be done using copyright law
only; there is an established principle that copyright holders
cannot restrict the *use* of a copy legally obtained by a third
party using copyright law alone.
All this means that, if copies are made outside the scope of the
permissions contained in the GPL, I reckon that the appropriate legal
action would be based on copyright infringement, not breach of contract,
because I think that there is no contract.
Instead of worrying whether the GPL's conditions could be enforced by
the copyright holder, I would seriously worry on whether the GPL's
_permissions_ could be enforced by the user, i.e. whether the
*copyright holder* is legally bound by the GPL. E.g., would it be
possible for such permissions to be retracted? (I think not, and the FSF
will surely not, they even give you permission to choose the release of
GPL you want to apply to your case).
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.abe...@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: p...@cs.aber.ac.uk
David Vinayak Wallace
Date: 2 May 90 09:31:28 GMT
From: gj%psychiatry....@NSFNET-RELAY.AC.UK (Gordon Joly)
>This would be difficult; the installation procedure for g++ is
>quite complex and you have to do a lot of work to make it fly.
>It's not like typing "make".
>Joe Buck
>jb...@ohm.berkeley.edu {uunet,ucbvax}!ohm.berkeley.edu!jbuck
I strongly disagree. For a sun3 with SunOS 4.x, config sun3-os4 and
typing "make install" (these days ;-), is all you need for G++; libg++
may be a little more involved. If you are running on a ToasTer with
ToasTOS 5.88 under VM (tm?) then you may have some work to do.
But to know that that's all you have to do you will have to read the
instructions which do point you at the copyleft. You can't install
the software without being exposed to the copyleft.
David Vinayak Wallace
Date: 30 Apr 90 22:06:30 GMT
From: r...@dbrus.unify.uucp (Ronald Cole)
In article <35...@ucbvax.BERKELEY.EDU> jb...@galileo.berkeley.edu (Joe Buck) writes:
This is more of a problem with g++. To avoid any confusion,
since version 1.36 you have to say -lg++ on the command line now
to get the libg++ library. If you don't say "-lg++" and
everything you link in is your own, the code is all yours.
look at the source to gcc.c in the g++ distribution! The hints
file says this, but it isn't true. As of 1.37.2, g++ still loads
-lg++ for you (to bring in __main).
Well you need an __main if you use static objects. If you you't have
libg++ you can use gnulib3.a, which contains the little amount of
runtime support required, and which bears no copyright notice at all.
That file is poorly documented, but what do you want? It's free
software. Feel free to add a comment to the top or to the
documentation telling people what it does.
Lots of libraries define their own __main
Robert Rubinoff
a court case could decide that for certain.
But I do wonder: suppose the GPL is enforceable; what would that mean? I can
see three possibilities (assuming a situation where someone refuses to
distribute source to a program that incorporates code covered by the GPL)
1) FSF could force the distribution of the program source.
2) FSF could obtain appropriate monetary compensation for damages
3) FSF could prevent further distribution of the executable program
(More than one may be correct, of course.)
What the FSF would want, presumably, is (1). I suspect, though, that they
could only get (3). That is, FSF's copyright would allow them to block
distribution of the program, since it depends on code covered by that
copyright. (2) is sort of moot, since it would be very difficult to show any
specific damages, although there might be some sort of case. But (1) is
clearly not part of the copyright itself. It must derive from the considering
the GPL as an agreement that the program author is aware of and has agreed to.
There are two problems here: first, FSF has no proof that the author(s) ever
actually saw the GPL and agreed to its terms. FSF could argure that they must
have seen it because of the way the software was distributed, but in general
it would be hard to prove this. Second, and more important, the author could
simply say "okay, I hereby terminate the agreement", leading to result (3).
There's nothing in the GPL that says you have to provide source forever, and I
doubt such a provision would hold up in court.
Of course, if the author can't distribute the program, then he/she/it/they
has/have lost whatever advantage they got from the GPL-covered code, so FSF is
in a strong position to bargain. So in a sense this whole discussion is
theoretical. Nevertheless, a particularly stubborn could simply stop
distributing the program in any form, and thus not have to provide the source.
Disclaimer: my knowledge of the law is largely derived from such reliable
sources as LA Law and Perry Mason, so I basically don't know beans about it.
Also, despite my misgivings about the validity of the GPL strategy, and indeed
about FSF's goals in general, I think that FSF has a moral right to establish
conditions on the use of their software, and it seems to me that if you don't
want to abide by the GPL you just shouldn't use the software. But that's much
too simple an approach for this newsgroup :-)
Robert
Kenneth Arromdee
>But I do wonder: suppose the GPL is enforceable; what would that mean? I can
>see three possibilities (assuming a situation where someone refuses to
>distribute source to a program that incorporates code covered by the GPL)
> 1) FSF could force the distribution of the program source.
> 2) FSF could obtain appropriate monetary compensation for damages
> 3) FSF could prevent further distribution of the executable program
There's another possibility:
4) A third party (say a former employee or whatever) obtains the source.
The FSF license makes it impossible for the company to sue the third party,
and thus the license has had an effect even though the FSF has done nothing.
--
"And they shall be cast out where there is no outlet for their evil doings..."
-- the Book of Ubizmo, on sinful uses of electricity
Kenneth Arromdee (UUCP: ....!jhunix!arromdee; BITNET: arromdee@jhuvm;
INTERNET: arro...@crabcake.cs.jhu.edu)
Gordon Joly
jb> You've skipped a few steps, Gordon. Like the fact that you have
jb> to build gcc first, have to have the gcc directory in a certain
jb> position with respect to the g++ directory, etc. Also, if you've used
jb> the gcc option to build in a different directory (as I did) the
jb> installation procedure won't work.
Yes, I fully agree that you need to have gcc (particluary gnu-cpp)
installed. But there again, I cannot recall a time when I did
not!
Scott E. Preece
| Surely the assignment of rights does not require something of value to
| be exchanged. Can I go into my local library, take a look at the
| contents and then publish them as my own?
---
What possible connection is there between the first sentence and the second?
---
| My understanding of copyright, at least under the Berne Convention, is
| that the author retains all rights to the work, save those s/he
| *explicitly* relinquishes.
---
Yes, but there are reasonable questions about what rights you have to begin
with with respect to a particular possible infringer. If, for instance, I
quote this posting (as I have) am I infringing your rights or making fair
use of them in responding?
---
| The GPL simply consists of a set of conditions under which the author
| permits the software to be used. This constitutes a declaration that
| certain rights which the author retains by default can be transferred to
| other people, provided that other conditions are met. Any copyright
| notice which states that a book's contents may not be entered into an
| information retrieval system represents exactly the same sort of
| situation. The fact that you picked up a book off the sidewalk doesn't
| release you from the copyright restrictions.
---
I don't think anyone would claim that she has the right to redistribute the
GNU cource code, as source code, without their permission or the
permission granted by the GPL. However, the question of header files,
which are NOT redistributed as source files but are used to determine
the object representation of a user's source file, I think the legal
issues are totally unresolved.
Imagine, for a moment, that I write something; my own words, undeniably
my right to redistribute. Now suppose I transform them in some
arbitrary way. I believe the copyright law definition of a derivative
work would still protect my right to the result.
Now suppose I transform my words by applying to them a mathematical
function of the text of some other book, the function so chosen that I
can recover my original text (but not the text of the other book) by
applying another function based on that same text (the "one-time pad"
approach to encrypting text). Soes the result text infringe the
copyright on the other book? I suspect it doesn't, but I'd be
interested in a legal opinion.
I believe compiling a program using copyrighted header files would be
analogous. The resulting object program does not contain the copyrighted
representation and the copyrighted material cannot be retrieved from the
object program, but I think that a claim that it is a derivative
work be the basis for a good fight.
---
| Copyright isn't a contract. A licence is not a contract.
---
I think you'd have a little trouble selling that statement to a lawyer.
My own opinion is that it is every bit as unethical for the FSF to hoard
its rights for political reasons as it would be for money, BUT that
civility demands that one respect their intent regardless, whether they
got the legal quibbles right or not. Nobody is forcing you to use their
product, so use it under the conditions they set or don't use it.
--
scott preece
motorola/mcd urbana design center 1101 e. university, urbana, il 61801
uucp: uunet!uiucuxc!udc!preece, arpa: pre...@urbana.mcd.mot.com
Robert Rubinoff
>In article <24...@netnews.upenn.edu> rubi...@linc.cis.upenn.edu (Robert Rubinoff) writes:
>>But I do wonder: suppose the GPL is enforceable; what would that mean? I can
>>see three possibilities (assuming a situation where someone refuses to
>>distribute source to a program that incorporates code covered by the GPL)
>
>4) A third party (say a former employee or whatever) obtains the source.
>The FSF license makes it impossible for the company to sue the third party,
>and thus the license has had an effect even though the FSF has done nothing.
Maybe. I'm not sure, though. After all, the third party doesn't have any
license from anyone to do anything with the source. The GPL might prevent the
company from getting damages (if the court rules that the GPL's requirements
mean that there were no damages), but it doesn't give the third party the right
to distribute the code. In fact, if the company hadn't explicitly given the
object code to the third party, then the GPL wouldn't apply at all here.
Robert
David J. Camp
>It turns out that the README file lacks a GPL pointer, and that
>someone who is lucky enough to be able to install it with no problems
>and without reading the Makefile (step 3 says "Read carefully the
>comments at the top of the Makefile" -- which contains at the top a
>pointer to the GPL) could just possibly avoid learning that there is a
>public license. This will be rectified in the next distribution.
>
I believe that in the absence of the GPL, the user has NO RIGHTS
WHATSOEVER to distribute copies. -David-
david%wub...@wugate.wustl.edu ^ David J. Camp
...!uunet!wugate!wubios!david < * > 314-382-0584
v
"Concentration impedes Inspiration." --- "Depend on God, who has dominion."
David Vinayak Wallace
Date: 19 Aug 90 07:30:37 GMT
From: da...@WUBIOS.WUSTL.EDU (David J. Camp)
References: <GUMBY.90A...@Cygnus.COM>
>It turns out that the README file lacks a GPL pointer, and that
>someone who is lucky enough to be able to install it with no problems
>and without reading the Makefile (step 3 says "Read carefully the
>comments at the top of the Makefile" -- which contains at the top a
>pointer to the GPL) could just possibly avoid learning that there is a
>public license. This will be rectified in the next distribution.
I believe that in the absence of the GPL, the user has NO RIGHTS
WHATSOEVER to distribute copies.
This is very odd -- a reply in August to a message I sent in April.
I was replying to a complaint that it was possible to install the
software without being pointed at the GPL. The GPL was in the
distribution; there was just no line in the README file telling the
user to look at it. Hence there was an infinitesimal chance that
someone could get the software running without seeing the GPL, or a
pointer to it.