subject:"Re\: Linux and GPLv2"

On Wed, Mar 30, 2005 at 05:41:10AM +0200, Måns Rullgård wrote:
> > I'd question whether that'd apply to a *free* system, anyway.  I havn't
> > looked at these cases (since I don't know which they are), but I recall
> > a case that sounds just like it: an author of a work created (under
> > contract) for a movie claimed that no license to actually use that material
> > was granted, but as the paid-for work was useless without a license to use
> > it, a license was implied.  That doesn't seem relevant where the work
> > is being given out entirely for free; the creator has no obligation to
> > anyone else to grant a license to make the library's release useful.
> > (For a commercial SDK, this would seem to apply to header files.)
> 
> So now the degree of protection by copyright depends on how much you
> charge for it?  What if someone gets paid to develop open source?

Then, I'd imagine--which is the best I can do; this is over my layman's
head--that the person that paid him would receive such an implicit license
for the header files.  That is, if I pay you to write a library for use
in my work, you can't say after the fact: "here's the library, you can
use it all you want, but you can't copy the material in the headers",
since the work I paid for only has value if I can actually distribute
programs that use it.  (Just as special effects created for a movie
only have value if the movie producer can actually put it in the movie.)

I don't see that this affects open source as such: it's between the
creator of the work and the person that paid him to do so.  The license
other parties receive is unrelated, and the creator can--other contracts
so on permitting, of course--license or not license to other people
however he pleases.

(Maybe I'm miles off; I'm open to informed corrections.)

-- 
Glenn Maynard

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-29 Thread MÃ¥ns RullgÃ¥rd

Glenn Maynard <[EMAIL PROTECTED]> writes:

> On Tue, Mar 29, 2005 at 08:53:52PM -0500, Raul Miller wrote:
>> On Mon, Mar 28, 2005 at 11:25:39AM -0300, Humberto Massa wrote:
>> > >>My claim was: "*Basically*, bits in .h files are not
>> > >>copyrightable". Which I now solemnly amend to "The kind of bits you
>> > >>normally (>99% of the times) find in .h files in c-language based
>> > >>projects, and often (>50% of the times) find in .h files in c++ based
>> > >>projects, are those defining interfaces, deeming them uncopyrightable
>> > >>by current USofAn and Brazilian law". Better?
>> 
>> > Raul Miller wrote:
>> > >However, for U.S. law, this isn't necessarily the case.
>> 
>> On Mon, Mar 28, 2005 at 04:14:47PM -0300, Humberto Massa wrote:
>> > I was referring to the fact that there is some case law in the USofA 
>> > that deemed interface definitions, as present normally in .h files, 
>> > uncopyrightable.
>> > 
>> > HTH
>> 
>> Those .h files were held to be not protected by copyright because no
>> viable alternatives were available to interface with the system.
>
> I'd question whether that'd apply to a *free* system, anyway.  I havn't
> looked at these cases (since I don't know which they are), but I recall
> a case that sounds just like it: an author of a work created (under
> contract) for a movie claimed that no license to actually use that material
> was granted, but as the paid-for work was useless without a license to use
> it, a license was implied.  That doesn't seem relevant where the work
> is being given out entirely for free; the creator has no obligation to
> anyone else to grant a license to make the library's release useful.
> (For a commercial SDK, this would seem to apply to header files.)

So now the degree of protection by copyright depends on how much you
charge for it?  What if someone gets paid to develop open source?

-- 
Måns Rullgård
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

On Tue, Mar 29, 2005 at 08:53:52PM -0500, Raul Miller wrote:
> On Mon, Mar 28, 2005 at 11:25:39AM -0300, Humberto Massa wrote:
> > >>My claim was: "*Basically*, bits in .h files are not
> > >>copyrightable". Which I now solemnly amend to "The kind of bits you
> > >>normally (>99% of the times) find in .h files in c-language based
> > >>projects, and often (>50% of the times) find in .h files in c++ based
> > >>projects, are those defining interfaces, deeming them uncopyrightable
> > >>by current USofAn and Brazilian law". Better?
> 
> > Raul Miller wrote:
> > >However, for U.S. law, this isn't necessarily the case.
> 
> On Mon, Mar 28, 2005 at 04:14:47PM -0300, Humberto Massa wrote:
> > I was referring to the fact that there is some case law in the USofA 
> > that deemed interface definitions, as present normally in .h files, 
> > uncopyrightable.
> > 
> > HTH
> 
> Those .h files were held to be not protected by copyright because no
> viable alternatives were available to interface with the system.

I'd question whether that'd apply to a *free* system, anyway.  I havn't
looked at these cases (since I don't know which they are), but I recall
a case that sounds just like it: an author of a work created (under
contract) for a movie claimed that no license to actually use that material
was granted, but as the paid-for work was useless without a license to use
it, a license was implied.  That doesn't seem relevant where the work
is being given out entirely for free; the creator has no obligation to
anyone else to grant a license to make the library's release useful.
(For a commercial SDK, this would seem to apply to header files.)

-- 
Glenn Maynard

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-29 Thread MÃ¥ns RullgÃ¥rd

Raul Miller <[EMAIL PROTECTED]> writes:

> On Mon, Mar 28, 2005 at 11:25:39AM -0300, Humberto Massa wrote:
>> >>My claim was: "*Basically*, bits in .h files are not
>> >>copyrightable". Which I now solemnly amend to "The kind of bits you
>> >>normally (>99% of the times) find in .h files in c-language based
>> >>projects, and often (>50% of the times) find in .h files in c++ based
>> >>projects, are those defining interfaces, deeming them uncopyrightable
>> >>by current USofAn and Brazilian law". Better?
>
>> Raul Miller wrote:
>> >However, for U.S. law, this isn't necessarily the case.
>
> On Mon, Mar 28, 2005 at 04:14:47PM -0300, Humberto Massa wrote:
>> I was referring to the fact that there is some case law in the USofA 
>> that deemed interface definitions, as present normally in .h files, 
>> uncopyrightable.
>> 
>> HTH
>
> Those .h files were held to be not protected by copyright because no
> viable alternatives were available to interface with the system.
>
> It's hard to see how this reasoning would apply in a context where there
> is some viable alternative available to interface with the system.

Alternative to what?  There can be no alternative to the full set of
interfaces to the system.  Are you trying to argue, that several
interfaces exist, use of each one is protected due to the existence of
the others?

Suppose there is only one interface, such that it, per your reasoning,
is not protected.  Now add another.  Does this addition suddenly make
the first interface protected?  What if they were created in the
opposite order?

-- 
Måns Rullgård
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-29 Thread Raul Miller

On Mon, Mar 28, 2005 at 11:25:39AM -0300, Humberto Massa wrote:
> >>My claim was: "*Basically*, bits in .h files are not
> >>copyrightable". Which I now solemnly amend to "The kind of bits you
> >>normally (>99% of the times) find in .h files in c-language based
> >>projects, and often (>50% of the times) find in .h files in c++ based
> >>projects, are those defining interfaces, deeming them uncopyrightable
> >>by current USofAn and Brazilian law". Better?

> Raul Miller wrote:
> >However, for U.S. law, this isn't necessarily the case.

On Mon, Mar 28, 2005 at 04:14:47PM -0300, Humberto Massa wrote:
> I was referring to the fact that there is some case law in the USofA 
> that deemed interface definitions, as present normally in .h files, 
> uncopyrightable.
> 
> HTH

Those .h files were held to be not protected by copyright because no
viable alternatives were available to interface with the system.

It's hard to see how this reasoning would apply in a context where there
is some viable alternative available to interface with the system.

-- 
Raul


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2#

2005-03-29 Thread Andrew Suffield

http://dilbert.com/comics/dilbert/archive/dilbert-20050324.html

I am continually entertained by the way that Adams manages to be right
all the time.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Linux and GPLv2#

On Tue, Mar 29, 2005 at 01:28:57PM -0800, Adam McKenna wrote:
> Maybe he was using the word in a facetious/stylistic manner, rather than a
> literal one, and didn't feel it needed justification.

That's fine--in which case he could simply have said so, I'd have said
"okay", and we'd have moved on already.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2#

On Tue, Mar 29, 2005 at 09:34:42PM +0100, Anthony W. Youngman wrote:
> In message <[EMAIL PROTECTED]>, Glenn Maynard 
> <[EMAIL PROTECTED]> writes
> >On Mon, Mar 28, 2005 at 01:30:16PM -0500, Raul Miller wrote:
> >>Andrew seems to avoid Red Herring arguments more than I.
> >
> >I asked for the rationale behind his calling fair use a "perversion",
> >and he refused to supply one.  It's that simple.  (The only reason
> >I can find is that he had no reason; he just attacks things--people
> >and laws alike--out of sheer habit, not for any particular reason.)
> 
> I thought he gave a simple answer - if he tried (or I tried) to claim 
> "fair use" in court, the judge would simply reply "what's that?" and 
> then convict us of copyright "theft".

I didn't ask why fair use isn't useful for Debian.  I knew the answer to
that long before this thread.  I asked him why he considers fair use itself
to be a bad thing.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2#

2005-03-29 Thread Adam McKenna

On Mon, Mar 28, 2005 at 01:43:53PM -0500, Glenn Maynard wrote:
> On Mon, Mar 28, 2005 at 01:30:16PM -0500, Raul Miller wrote:
> > Andrew seems to avoid Red Herring arguments more than I.
> 
> I asked for the rationale behind his calling fair use a "perversion",
> and he refused to supply one.  It's that simple.

Maybe he was using the word in a facetious/stylistic manner, rather than a
literal one, and didn't feel it needed justification.

--Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2#

2005-03-29 Thread Anthony W. Youngman

In message <[EMAIL PROTECTED]>, Glenn Maynard 
<[EMAIL PROTECTED]> writes
On Mon, Mar 28, 2005 at 01:30:16PM -0500, Raul Miller wrote:
Andrew seems to avoid Red Herring arguments more than I.
I asked for the rationale behind his calling fair use a "perversion",
and he refused to supply one.  It's that simple.  (The only reason
I can find is that he had no reason; he just attacks things--people
and laws alike--out of sheer habit, not for any particular reason.)
I thought he gave a simple answer - if he tried (or I tried) to claim 
"fair use" in court, the judge would simply reply "what's that?" and 
then convict us of copyright "theft".

Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-28 Thread Henning Makholm

Scripsit Humberto Massa <[EMAIL PROTECTED]>

> No, but I have already explained why I firmly believe that the "merely
> aggregates" language in GPL#2§3 refers to all aggregate works, as
> opposed to the "works based on the Program" from GPL#0.

If you believe that a compiled program that contains code from both
sources combined into a monolithic executable object is merely an
aggregation, then I can only conclude that you have no idea whatsoever
what the word "merely" means.

-- 
Henning Makholm "Al lykken er i ét ord: Overvægtig!"

Re: Linux and GPLv2

Henning Makholm wrote:
 Scripsit Humberto Massa <[EMAIL PROTECTED]>
> 2. That said plugin, when in its compiled form, if it contains at
> all any inlined functions or macros from the GPL'd
> plugin-interfaces.h file, is merely a volume of storage or
> distribution in accordance to the disposition on the GPL, section
> 2, paragraph 3.
 You have a really strange and untenable understanding of "merely",
 then.
No, but I have already explained why I firmly believe that the "merely 
aggregates" language in GPL#2§3 refers to all aggregate works, as 
opposed to the "works based on the Program" from GPL#0.

> 3. That the plugin's licensing is completely independent of the "I
> can load plugins" program's one, and that it can be licensed as the
> author sees fit.
 Yes, but not of the license for the inlined functions that get
 compiled in, providing that those are sufficiently nontrivial to
 enjoy copyright protection at all.
We'll have to agree in disagreeing :-)
Friendly -- /Really/,
Massa

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

Raul Miller wrote:
On Mon, Mar 28, 2005 at 11:25:39AM -0300, Humberto Massa wrote:
 

Troll editing. My claim was: "*Basically*, bits in .h files are not copyrightable". Which I now solemnly amend to "The kind of bits you normally (>99% of the times) find in .h files in c-language based projects, and often (>50% of the times) find in .h files in c++ based projects, are those defining interfaces, deeming them uncopyrightable by current USofAn and Brazilian law". Better?
   

I don't know about Brazilian law.
However, for U.S. law, this isn't necessarily the case.
 

I was referring to the fact that there is some case law in the USofA 
that deemed interface definitions, as present normally in .h files, 
uncopyrightable.

HTH
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2#

2005-03-28 Thread Glenn Maynard

On Mon, Mar 28, 2005 at 01:30:16PM -0500, Raul Miller wrote:
> Andrew seems to avoid Red Herring arguments more than I.

I asked for the rationale behind his calling fair use a "perversion",
and he refused to supply one.  It's that simple.  (The only reason
I can find is that he had no reason; he just attacks things--people
and laws alike--out of sheer habit, not for any particular reason.)

It's fairly disappointing that a simple request for rationale--an
honest attempt to understand someone's opinion--results in such a
waste of time as this thread, and no rationale.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-28 Thread Henning Makholm

Scripsit Humberto Massa <[EMAIL PROTECTED]>

> 2. That said plugin, when in its compiled form, if it contains at all
> any inlined functions or macros from the GPL'd plugin-interfaces.h
> file, is merely a volume of storage or distribution in accordance to
> the disposition on the GPL, section 2, paragraph 3.

You have a really strange and untenable understanding of "merely", then.

> 3. That the plugin's licensing is completely independent of the "I can
> load plugins" program's one, and that it can be licensed as the author
> sees fit.

Yes, but not of the license for the inlined functions that get
compiled in, providing that those are sufficiently nontrivial to enjoy
copyright protection at all.

-- 
Henning Makholm  "It will be useful even at this
  early stage to review briefly the main
  features of the universe as they are known today."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2#

2005-03-28 Thread Raul Miller

> On Sat, Mar 26, 2005 at 11:16:29AM -0500, Raul Miller wrote:
> > This seems to imply that there's some single perspective which can be
> > easily described to clarify this issue.

On Sat, Mar 26, 2005 at 12:08:08PM -0500, Glenn Maynard wrote:
> I was asking for Andrew's perspective, not The Perspective.

Now you seem to be implying that Andrew has only one perspective on
this issue.

> I don't even feel strongly about this, and wasn't particularly
> expecting to argue about the answer; I was just curious why he dislikes
> fair use so much as to use such a strongly negative word, and found
> it strange that a simple "why do you think that?" inquiry resulted
> in evasive maneuvers.

Andrew seems to avoid Red Herring arguments more than I.

-- 
Raul


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-28 Thread Raul Miller

On Mon, Mar 28, 2005 at 11:25:39AM -0300, Humberto Massa wrote:
> Troll editing. My claim was: "*Basically*, bits in .h files are not 
> copyrightable". Which I now solemnly amend to "The kind of bits you 
> normally (>99% of the times) find in .h files in c-language based 
> projects, and often (>50% of the times) find in .h files in c++ based 
> projects, are those defining interfaces, deeming them uncopyrightable by 
> current USofAn and Brazilian law". Better?

I don't know about Brazilian law.

However, for U.S. law, this isn't necessarily the case.

A key feature of U.S. copyright law is that it's creative expression
which is being protected -- not form or function.

In other words, if the software in question provides some other
interface then U.S. law overriding copyright for interface purposes
probably wouldn't apply.  [A strong legal case could be made here,
though I don't think anyone has actually taken this particular
issue to court.]  On the other hand, in a case where this mattered,
the .h files would not probably not be considered in isolation.

You could say that copyright law does not factor issues on functional
boundaries, except as a notational convenience.  Instead, in the
context of copyright, issues are factored on creative boundaries.

-- 
Raul

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

Henning Makholm wrote:
If it is wrong to begin with, then it is also basically wrong.
 

It seems that my bad English got me: I used the word "basically" in the 
same sense that its cognate can be used in Portuguese, "in the 
basic/normal cases...". I apologize for the confusion.

Which I now solemnly amend to "The kind of bits you normally (>99%
of the times) find in .h files in c-language based projects, and
often (>50% of the times) find in .h files in c++ based projects,
are those defining interfaces, deeming them uncopyrightable by
current USofAn and Brazilian law". Better?
   

Well, yes. And which conclusion do you draw from that observation?
 

It is my most humble, but firm opinion:
1. That a plugin (written in C or C++) that includes an GPL'd 
plugin-interfaces.h file, and uses the interfaces described there for 
its normal chores, is not a derivative work of the GPL'd "I can load 
plugins" program.

2. That said plugin, when in its compiled form, if it contains at all 
any inlined functions or macros from the GPL'd plugin-interfaces.h file, 
is merely a volume of storage or distribution in accordance to the 
disposition on the GPL, section 2, paragraph 3.

2.a. That is, as long as it does not mess with implementation details of 
the plugin-loading mechanism, attaining to the use of published 
interfaces -- if it doesn't, pieces of the implementation will "leak" 
past the Filtration phase and it can be deemed a derivative work on the 
plugin loader.

3. That the plugin's licensing is completely independent of the "I can 
load plugins" program's one, and that it can be licensed as the author 
sees fit. Which, of course, includes the QPL.

4. That, reinforcing, no dispostion in the GPL would stop the user from 
linking dynamically at run-time said plugin, to make possible its use.

HTH,
Massa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-28 Thread Henning Makholm

Scripsit Humberto Massa <[EMAIL PROTECTED]>
> Henning Makholm wrote:

>>  Your claim was: "Bits in .h files are not copyrightable".

> Troll editing. My claim was: "*Basically*, bits in .h files are not
> copyrightable".

If it is wrong to begin with, then it is also basically wrong.

> Which I now solemnly amend to "The kind of bits you normally (>99%
> of the times) find in .h files in c-language based projects, and
> often (>50% of the times) find in .h files in c++ based projects,
> are those defining interfaces, deeming them uncopyrightable by
> current USofAn and Brazilian law". Better?

Well, yes. And which conclusion do you draw from that observation?

-- 
Henning Makholm  "So? We're adaptable. We'll *switch missions*!"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

Henning Makholm wrote:
 Your claim was: "Bits in .h files are not copyrightable".
Troll editing. My claim was: "*Basically*, bits in .h files are not 
copyrightable". Which I now solemnly amend to "The kind of bits you 
normally (>99% of the times) find in .h files in c-language based 
projects, and often (>50% of the times) find in .h files in c++ based 
projects, are those defining interfaces, deeming them uncopyrightable by 
current USofAn and Brazilian law". Better?

> It's the fact that you do not transform it, so you do not create a
> derivative work.
 Derivative work, anthology: Does the difference matter? To copy
 either you need the permission of the original author.
Yes, but (1) the GPL exempts anthology works, in the "mere aggregation" 
clause; and (2) the rules are slightly different on the distribution of 
anthology works.

 So if I buy a book that has been produced in an offset press, you
 assert that the book is not *per se* copyrightable. Hence I can
 freely create as many reprints as I like and sell them?
You are disappointing me. By now, I would have expected you to understand:
> The copyright does not apply to the printed book /per-se/... it's
> applied to the intellectual content (the original creation of
> spirit). Imagine I make a program that prints random words. The
> result is not copyrightable, even if it makes any sense at all.
But you came up with:
 That has nothing to do with whether an offset press has been produced
 to print the words.
The *words* are copyrighted, not the book. That is the part I wanted you 
to understand:

>> No, it's a processed work. Which is still coverved by the
>> copyright of the original work.
You are missing the difference:
> Not derived. Never. To derive you need inteligence (in Brazilian
> letter-of-law, "spirit").
 Says who? Again, the offset press is not intelligent, but the books
 that it spits out are still covered by the author's copyright.
Not the book. The words. Ok, so you are saying that: oh, well, there are 
some "words" in the .o file that came from the .h file. And I am 
counterargumenting: were those "words" the interface definition? If so, 
then the law explicitly exempted those from copyright protection.

 Why do you distinguish between those to cases?
Repeating: (1) they are distinguished by GPL and (2) they are 
distinguished by copyright law.

> The rules for anthology works and derivative works are different.
 How so? Your examples seem to try to explain how you choose to apply
 different words to slightly different situations, but the end result
 about which rights you need to have to copy the result is the same.
Let's see if I can get to the right point here:
1. The GPL has two different disposition about derivative works versus 
anthology works. At first (clause 0) it tries do redefine what it will 
call "works based on the Program", and does a lousy job at that, because 
it ends with two different definitions (square parentheses are mine:

 The "Program", below, refers to any such program or work, and a "work
 based on the Program" means either the Program or any derivative work
 under copyright law [definition A]: that is to say, a work containing
 the Program or a portion of it [redefinition B], either verbatim or
 with modifications and/or translated into another language.
Ok, everybody can claim almost any one of the two definitions as the 
"right" one, ie, that one that will apply to the scope of the GPL, 
except that in clause 2, paragraph 3, the GPL separates what would cover 
anthology works:

 mere aggregation of another work not based on the Program with the
 Program (or with a work based on the Program) on a volume of a
 storage or distribution medium does not bring the other work under
 the scope of this License.
Notice that the FSF used the "work based on the Program" again. It's 
pretty clear to me that many if not all Brazilian judges facing this 
would consider these two dispositions as separating derivative works 
from aggregate works.

Now, if the library license was a proprietary license, that did not even 
permit aggregate works, I would give in, but in the case of a GPL'd 
library, what you *do* have when you #include a file is a reference to 
an interface, and in the case where copyrightable bits end up in the 
final .o or a.out/elf file, they are redistributable anyway.

Massa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

Andrew Suffield wrote:
Fair use is an American perversion. It does not exist in most of the
rest of the world in anything like the same form. Anything that relies
on the American notion of "fair use" is non-free, because in the UK
that means "Non-commercial use only".
 

Just to be clear: "fair use" means in USC 17 and in Brazilian "Author's 
rights act", that copying any copyrighted work for: academic 
quotation/commentary/study, parody and some others (I'll look it up 
later) is granted, and without copyright protection. "First sale 
doctrine" means that if you have some license, you can pass it along to 
another party (losing your license, of course).

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-27 Thread Andrew Suffield

On Sat, Mar 26, 2005 at 11:25:29PM +0100, Francesco Poli wrote:
> > c) If the modified program normally reads commands interactively
> > when run, you must cause it, when started running for such
> > interactive use in the most ordinary way, to print or display an
> > announcement including an appropriate copyright notice and a
> > notice that there is no warranty (or else, saying that you provide
> > a warranty) and that users may redistribute the program under
> > these conditions, and telling the user how to view a copy of this
> > License.  (Exception: if the Program itself is interactive but
> > does not normally print such an announcement, your work based on
> > the Program is not required to print an announcement.)
> 
> This clause is known to be controversial.

This clause is known to be right on the borderline, to the point where
it can possibly be twisted to be non-free. However, in the vast
majority of packages, it is inactivated by the exception.

> However it's some orders of magnitude less demanding than the "do not
> drop the get-the-source-through-HTTP feature" clause, I would say.
> Printing one or two statements to stdout or in a splash screen is really
> really easier than implementing (or keeping) HTTP support and the
> capability to send the program's own source.

And a program which 'reads commands interactively when run' (this
means 'in the style of gdb', more or less) should be functionally
unaffected by displaying this text. It still does exactly the same
thing as before, just with a little extra chatter to the user. Note
that when being invoked entirely on the command line, or from a
script, or anything else like that, the clause makes no restrictions.

We'd probably be better off without this clause, but I can't even
think of a way it could be as bad as the 'pet a cat' license.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |

signature.asc
Description: Digital signature

Re: Linux and GPLv2

2005-03-26 Thread Francesco Poli

On Wed, 23 Mar 2005 10:49:34 +0100 (MET) Gerardo Ballabio wrote:

> > From: Francesco Poli <[EMAIL PROTECTED]>
[...]
> > I don't think it's forbidding to remove the code: it's merely  
> > forbidding to drop a feature.
> > You could reimplement it in a better (or even worse) way, but you  
> > must support it.
> 
> Then if my reimplementation has a bug that prevents it from working  
> properly, I may be accused of infringement?

I don't know (IANAL). Maybe if it can be proved that your
reimplementation is intentionally buggy.
But I repeat: I don't really know...

> 
> > Anyway I agree it's non-free.
> 
> Then you may be surprised to hear that the GPLv2 does have a "don't  
> remove this feature" clause:

Well, I was aware of that clause (even though maybe I was not thinking
about it, while discussing the "get the source through HTTP" feature and
its corresponding "do not drop this feature" clause...).

> 
> c) If the modified program normally reads commands interactively
> when run, you must cause it, when started running for such
> interactive use in the most ordinary way, to print or display an
> announcement including an appropriate copyright notice and a
> notice that there is no warranty (or else, saying that you provide
> a warranty) and that users may redistribute the program under
> these conditions, and telling the user how to view a copy of this
> License.  (Exception: if the Program itself is interactive but
> does not normally print such an announcement, your work based on
> the Program is not required to print an announcement.)

This clause is known to be controversial.
I would be happier if it were not present at all in the GNU GPL...
I'm not sure, but my mind seems to recall to have read a statement from
the FSF itself recommending against abusing this clause: but, after
searching for such a statement for a while, I failed to find it and gave
up...  :(

However it's some orders of magnitude less demanding than the "do not
drop the get-the-source-through-HTTP feature" clause, I would say.
Printing one or two statements to stdout or in a splash screen is really
really easier than implementing (or keeping) HTTP support and the
capability to send the program's own source.

I think that clause 2c of GPLv2 is really borderline with respect to
DFSG-freeness, but judging whether it's on one side or on the other one
is not easy.
On the one hand, it resembles to an acceptable requirement to include
copyright notices and warranty disclaimers.
On the other hand, it's a functional constraint, though a very little
one...

> 
> I'd even read this as saying "if the original program isn't  
> interactive, but the modified one is, you must _add_ that feature".

I had never noticed that, I must admit!  :-(
But reading and re-reading the clause seems to bring me to same
conclusion...
And this is a little worrysome...

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4

pgpAFMBskfg4c.pgp
Description: PGP signature

Re: Linux and GPLv2#

2005-03-26 Thread Glenn Maynard

On Sat, Mar 26, 2005 at 11:16:29AM -0500, Raul Miller wrote:
> > On Fri, Mar 25, 2005 at 09:55:40AM +, Andrew Suffield wrote:
> > > 'Worse' is purely a matter of perspective. There's irony here...
> 
> On Fri, Mar 25, 2005 at 05:31:27AM -0500, Glenn Maynard wrote:
> > No, there isn't.  It's very simple.  You called it a "perversion",
> > which means you think it's worse.  I asked why you think it's a
> > perversion.  (In other words, "what is your perspective that makes
> > you consider is worse?")  You won't answer.
> 
> This seems to imply that there's some single perspective which can be
> easily described to clarify this issue.

I was asking for Andrew's perspective, not The Perspective.  I don't
even feel strongly about this, and wasn't particularly expecting to
argue about the answer; I was just curious why he dislikes fair use
so much as to use such a strongly negative word, and found it strange
that a simple "why do you think that?" inquiry resulted in evasive
maneuvers.

-- 
Glenn Maynard

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2#

2005-03-26 Thread Raul Miller

> On Fri, Mar 25, 2005 at 09:55:40AM +, Andrew Suffield wrote:
> > 'Worse' is purely a matter of perspective. There's irony here...

On Fri, Mar 25, 2005 at 05:31:27AM -0500, Glenn Maynard wrote:
> No, there isn't.  It's very simple.  You called it a "perversion",
> which means you think it's worse.  I asked why you think it's a
> perversion.  (In other words, "what is your perspective that makes
> you consider is worse?")  You won't answer.

This seems to imply that there's some single perspective which can be
easily described to clarify this issue.

Personally, while I wouldn't describe things using the terms Andrew has,
I think I see something similar to his point.

For example, one perspective is: computer programs, in the general case,
shouldn't be regulated by copyright law.

Note that this particular flavor of perspective is not claiming that
computer programs should not be regulated (though it does fit with that
kind of argument).  It could just as easily be a part of an argument for
other kinds of regulations (perhaps far more restrictive than anything
we've seen to date).

That said, it's probably worth noting that until the mid-1970s, computer
programs were thought to be not copyrightable.  And, because of the
economics of the time this wasn't a big deal for a lot of people.

I think one of the reasons IBM has taken to open sourced software so
well is that their business model was developed under those conditions
-- they actually started losing ground, financially, when they switched
to an ultra-restrictive license model.  [But they were in some sense
forced to do so, because if something isn't copyright protected it can be
incorporated in something which is copyright protected by someone else,
which has unpleasant business connotations.]

Anyways, the original quip should probably just be taken as a statement
that Andrew is dissatisfied with the system of copyright laws.  We don't
have to turn this into some kind of forum for discussing potential
alternative systems.

-- 
Raul

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-26 Thread Henning Makholm

Scripsit "Anthony W. Youngman" <[EMAIL PROTECTED]>

> Even when the work is not copyrightable? (eg header files :-)

It is false that header files are not copyrightable.

-- 
Henning Makholm  "What has it got in its pocketses?"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-26 Thread Anthony W. Youngman

In message <[EMAIL PROTECTED]>, Glenn Maynard 
<[EMAIL PROTECTED]> writes
On Thu, Mar 24, 2005 at 07:45:24AM +, Andrew Suffield wrote:
Fair use is an American perversion. It does not exist in most of the
rest of the world in anything like the same form. Anything that relies
on the American notion of "fair use" is non-free, because in the UK
that means "Non-commercial use only".
Out of curiosity, what is it about fair use that makes you call it a
"perversion"?  It may not be useful to Debian's purposes, but I have
a hard time looking down on things that weaken the strength of IP laws,
even if only by a little.  (Perhaps it causes confusion about "what's
free enough" and all that, but that's the licensor's fault, not the law's.)
It's an American concept, that does not exist in Europe.
That's the problem - "fair use" only works in America.
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-26 Thread Anthony W. Youngman

In message <[EMAIL PROTECTED]>, Andrew Suffield 
<[EMAIL PROTECTED]> writes
On Wed, Mar 23, 2005 at 08:10:57PM +0100, M?ns Rullg?rd wrote:
Henning Makholm <[EMAIL PROTECTED]> writes:
>> Concluding: when you write a ".c" file, it is or not a derivative work
>> on another original work independently of what the compiler and linker
>> will do in the future.
>
> I repeat: No, but the resulting .o file may be derived from another
> work that the compiler also read while producing it.
The object file may contain bits from header files, or whatever, but
this has no bearing on the distributability of it.
Nonsense. Literal copying is always copyright infringement.
Even when the work is not copyrightable? (eg header files :-)
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-25 Thread Jeremy Hankins

Henning Makholm <[EMAIL PROTECTED]> writes:
> Scripsit Jeremy Hankins <[EMAIL PROTECTED]>

>> My understanding is that, in practice, myfile.c could infringe as well,
>> If the only reasonable way to use it is by creating a work that is
>> derivative of errno.h
>
> Some people say that. I do not agree with them.

But what you (or I) believe is only tangentially relevant, because we
don't get to make the decision.  This is a grey area, and therefore when
try to give "the" answer to the question we're simply gambling on the
outcome of a court case that may never even happen.  So myfile.c *could*
be infringing in the sense that that's one of the possible decisions
that a judge could make.  Saying you disagree with that isn't the same
as saying that you think I'm wrong.

-- 
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2#

2005-03-25 Thread Glenn Maynard

On Fri, Mar 25, 2005 at 09:55:40AM +, Andrew Suffield wrote:
> > > > > Fair use is an American perversion. It does not exist in most of the
> > > > > rest of the world in anything like the same form. Anything that relies
> > > > > on the American notion of "fair use" is non-free, because in the UK
> > > > > that means "Non-commercial use only".
> > > > 
> > > > Out of curiosity, what is it about fair use that makes you call it a
> > > > "perversion"?
> > > 
> > > In opposition to the norm. That's the real definition, once you
> > > discard the arbitrary labels of 'right' and 'wrong'.
> > 
> > Something which is merely "in opposition to the norm" is "unusual".  A
> > perversion is something which is both unusual and worse.  Fair use may
> > be unusual, but I don't really understand how it's worse.
> 
> 'Worse' is purely a matter of perspective. There's irony here...

No, there isn't.  It's very simple.  You called it a "perversion", which means
you think it's worse.  I asked why you think it's a perversion.  (In other
words, "what is your perspective that makes you consider is worse?")  You
won't answer.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2#

2005-03-25 Thread Andrew Suffield

On Thu, Mar 24, 2005 at 01:26:18PM -0500, Glenn Maynard wrote:
> On Thu, Mar 24, 2005 at 03:38:19PM +, Andrew Suffield wrote:
> > On Thu, Mar 24, 2005 at 03:10:41AM -0500, Glenn Maynard wrote:
> > > On Thu, Mar 24, 2005 at 07:45:24AM +, Andrew Suffield wrote:
> > > > Fair use is an American perversion. It does not exist in most of the
> > > > rest of the world in anything like the same form. Anything that relies
> > > > on the American notion of "fair use" is non-free, because in the UK
> > > > that means "Non-commercial use only".
> > > 
> > > Out of curiosity, what is it about fair use that makes you call it a
> > > "perversion"?
> > 
> > In opposition to the norm. That's the real definition, once you
> > discard the arbitrary labels of 'right' and 'wrong'.
> 
> Something which is merely "in opposition to the norm" is "unusual".  A
> perversion is something which is both unusual and worse.  Fair use may
> be unusual, but I don't really understand how it's worse.

'Worse' is purely a matter of perspective. There's irony here...

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Linux and GPLv2

2005-03-24 Thread Glenn Maynard

On Thu, Mar 24, 2005 at 03:38:19PM +, Andrew Suffield wrote:
> On Thu, Mar 24, 2005 at 03:10:41AM -0500, Glenn Maynard wrote:
> > On Thu, Mar 24, 2005 at 07:45:24AM +, Andrew Suffield wrote:
> > > Fair use is an American perversion. It does not exist in most of the
> > > rest of the world in anything like the same form. Anything that relies
> > > on the American notion of "fair use" is non-free, because in the UK
> > > that means "Non-commercial use only".
> > 
> > Out of curiosity, what is it about fair use that makes you call it a
> > "perversion"?
> 
> In opposition to the norm. That's the real definition, once you
> discard the arbitrary labels of 'right' and 'wrong'.

Something which is merely "in opposition to the norm" is "unusual".  A
perversion is something which is both unusual and worse.  Fair use may
be unusual, but I don't really understand how it's worse.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-24 Thread Henning Makholm

Scripsit Humberto Massa <[EMAIL PROTECTED]>
> Henning Makholm wrote:

>>Snip "explanation" that does not do anything the idea that bits are
>>treated differently by copyright just becuase they are in a file
>>called .h.

> Repeating: bits that are in files called .h are not copied in your
> work,

They may be, as I have explained.

> The compiled executable may or may not be an anthology
> work containing the contents of the .h.

Which means that they are copied there.

> It's not the magical fact that the file is ending in .h (or .inc).

Your claim was: "Bits in .h files are not copyrightable".

> It's the fact that you do not transform it, so you do not create a
> derivative work.

Derivative work, anthology: Does the difference matter? To copy either
you need the permission of the original author.

>>So what? They are being reproduced, and the mechanicalness of the
>>reproduction does not prevent copyright from applying to the result.

> But the relationship of the result WRT the individual copyrights is
> different than many people (including who wrote the damned "do not
> link" paragraph in the GPL) expect.

The relationship is: "If you copy the result you need to have the
permission of the author (or fall within whatever specific exemptions
your jurisdiction happens to offer)."

>>>Nothing that comes out of an automated process is *per-se*
>>>copyrightable.

>>Do you still think this applies if the automated process is an offset
>>press?

> Yes.

So if I buy a book that has been produced in an offset press, you
assert that the book is not *per se* copyrightable. Hence I can freely
create as many reprints as I like and sell them?

> The copyright does not apply to the printed book /per-se/... it's
> applied to the intellectual content (the original creation of
> spirit). Imagine I make a program that prints random words. The result
> is not copyrightable, even if it makes any sense at all.

That has nothing to do with whether an offset press has been produced
to print the words.

>>No, it's a processed work. Which is still coverved by the copyright of
>>the original work.

> What you are calling a processed work is just another "face" of the
> same work;

Whatever you like. The outcome is still that you need the original
author's permission to copy it.

>>I repeat: No, but the resulting .o file may be derived from another
>>work that the compiler also read while producing it.

> Not derived. Never. To derive you need inteligence (in Brazilian
> letter-of-law, "spirit").

Says who? Again, the offset press is not intelligent, but the books
that it spits out are still covered by the author's copyright.

>>No, but myfile.o may be. (I feel like I'm repeating myself here).

> An anthology work, maybe, a derivative work, never.

Why do you distinguish between those to cases?

> The rules for anthology works and derivative works are
> different.

How so? Your examples seem to try to explain how you choose to apply
different words to slightly different situations, but the end result
about which rights you need to have to copy the result is the same.

-- 
Henning Makholm "However, the fact that the utterance by
   Epimenides of that false sentence could imply the
   existence of some Cretan who is not a liar is rather unsettling."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-24 Thread Henning Makholm

Scripsit Jeremy Hankins <[EMAIL PROTECTED]>
> Henning Makholm <[EMAIL PROTECTED]> writes:
>> Scripsit Humberto Massa <[EMAIL PROTECTED]>

>>> Trying to explain more: my "myfile.c" is not a derivative work on
>>> "errno.h",

>> No, but myfile.o may be. (I feel like I'm repeating myself here).

> My understanding is that, in practice, myfile.c could infringe as well,
> if the only reasonable way to use it is by creating a work that is
> derivative of errno.h

Some people say that. I do not agree with them.

-- 
Henning Makholm"I, madam, am the Archchancellor!
   And I happen to run this University!"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-24 Thread Andrew Suffield

On Thu, Mar 24, 2005 at 03:10:41AM -0500, Glenn Maynard wrote:
> On Thu, Mar 24, 2005 at 07:45:24AM +, Andrew Suffield wrote:
> > Fair use is an American perversion. It does not exist in most of the
> > rest of the world in anything like the same form. Anything that relies
> > on the American notion of "fair use" is non-free, because in the UK
> > that means "Non-commercial use only".
> 
> Out of curiosity, what is it about fair use that makes you call it a
> "perversion"?

In opposition to the norm. That's the real definition, once you
discard the arbitrary labels of 'right' and 'wrong'.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Linux and GPLv2

2005-03-24 Thread Glenn Maynard

On Thu, Mar 24, 2005 at 10:55:40AM +0100, Måns Rullgård wrote:
> Andrew Suffield <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Mar 23, 2005 at 08:10:57PM +0100, M?ns Rullg?rd wrote:
> >> Henning Makholm <[EMAIL PROTECTED]> writes:
> >> 
> >> >> Concluding: when you write a ".c" file, it is or not a derivative work
> >> >> on another original work independently of what the compiler and linker
> >> >> will do in the future.
> >> >
> >> > I repeat: No, but the resulting .o file may be derived from another
> >> > work that the compiler also read while producing it.
> >> 
> >> The object file may contain bits from header files, or whatever, but
> >> this has no bearing on the distributability of it.
> >
> > Nonsense. Literal copying is always copyright infringement.
> 
> Unless you had permission to make copies, which the GPL explicit
> grants you.  We were talking about GPL'd stuff here, right?

No, all of the above was spoken in very broad terms, not specifically
about the GPL.  You said "The object file may contain bits from header
files, or whatever, but this has no bearing on the distributability of
it", which is false: if you create an object file with substantial bits
from my header file, and I grant you no permission to redistribute the
header file, the object file is undistributable as a direct result of
containing bits from my header files.

-- 
Glenn Maynard

Re: Linux and GPLv2

2005-03-24 Thread MÃ¥ns RullgÃ¥rd

Andrew Suffield <[EMAIL PROTECTED]> writes:

> On Wed, Mar 23, 2005 at 08:10:57PM +0100, M?ns Rullg?rd wrote:
>> Henning Makholm <[EMAIL PROTECTED]> writes:
>> 
>> >> Concluding: when you write a ".c" file, it is or not a derivative work
>> >> on another original work independently of what the compiler and linker
>> >> will do in the future.
>> >
>> > I repeat: No, but the resulting .o file may be derived from another
>> > work that the compiler also read while producing it.
>> 
>> The object file may contain bits from header files, or whatever, but
>> this has no bearing on the distributability of it.
>
> Nonsense. Literal copying is always copyright infringement.

Unless you had permission to make copies, which the GPL explicit
grants you.  We were talking about GPL'd stuff here, right?

>> They only found their way there as the result of implementation
>> details.
>
> Under your rather strange theory, copying a file can never be
> copyright infringement, because the way cp moves the bits around is
> just an 'implementation detail'. So presumably you don't think
> copyright infringement using a computer is possible.

You are obviously deliberately misinterpreting what I said.

-- 
Måns Rullgård
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-24 Thread MÃ¥ns RullgÃ¥rd

Andrew Suffield <[EMAIL PROTECTED]> writes:

> On Wed, Mar 23, 2005 at 11:45:45PM +0100, M?ns Rullg?rd wrote:
>> > If my implementation puts things in macros, and you distribute my
>> > implementation as part of your binaries as a result, that's *your*
>> > problem.  I don't even know what you're trying to say here--"you put
>> > your copyrighted code in a header and I copied it into my object
>> > file--that's your problem, not mine!" doesn't make any sense at all.
>> 
>> The only reasonable way to use your library (which for this discussion
>> shall be assumed to have been legally obtained), is to compile
>> programs using its header files, and link these programs against it.
>> What did you expect me to do with those headers?  Frame them and hang
>> them on the wall?
>
> Probably. The absence of a useful license for a project does
> *not* mean that you can make up whatever license you'd like to
> have. Generally it means that you can't do anything.
>
> An example of a package with a license of the form you describe here
> would be Sun Java. You get the source code, but you cannot link
> programs against it and then redistribute them. All you can really do
> with it is to look at it; hanging it on the wall is probably okay too.

It's perfectly OK to build the thing, and use it for running Java
programs, just not distribute it.

-- 
Måns Rullgård
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-24 Thread Glenn Maynard

On Thu, Mar 24, 2005 at 07:45:24AM +, Andrew Suffield wrote:
> Fair use is an American perversion. It does not exist in most of the
> rest of the world in anything like the same form. Anything that relies
> on the American notion of "fair use" is non-free, because in the UK
> that means "Non-commercial use only".

Out of curiosity, what is it about fair use that makes you call it a
"perversion"?  It may not be useful to Debian's purposes, but I have
a hard time looking down on things that weaken the strength of IP laws,
even if only by a little.  (Perhaps it causes confusion about "what's
free enough" and all that, but that's the licensor's fault, not the law's.)

-- 
Glenn Maynard

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-23 Thread Andrew Suffield

On Wed, Mar 23, 2005 at 08:10:57PM +0100, M?ns Rullg?rd wrote:
> Henning Makholm <[EMAIL PROTECTED]> writes:
> 
> >> Concluding: when you write a ".c" file, it is or not a derivative work
> >> on another original work independently of what the compiler and linker
> >> will do in the future.
> >
> > I repeat: No, but the resulting .o file may be derived from another
> > work that the compiler also read while producing it.
> 
> The object file may contain bits from header files, or whatever, but
> this has no bearing on the distributability of it.

Nonsense. Literal copying is always copyright infringement.

> They only found
> their way there as the result of implementation details.

Under your rather strange theory, copying a file can never be
copyright infringement, because the way cp moves the bits around is
just an 'implementation detail'. So presumably you don't think
copyright infringement using a computer is possible.

> Allowing the
> a particular method of implementation to stretch the reach of
> copyright in such a way would be absurd, and this is what "fair use"
> is about.

Fair use is an American perversion. It does not exist in most of the
rest of the world in anything like the same form. Anything that relies
on the American notion of "fair use" is non-free, because in the UK
that means "Non-commercial use only".

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |

signature.asc
Description: Digital signature

Re: Linux and GPLv2

2005-03-23 Thread Andrew Suffield

On Wed, Mar 23, 2005 at 11:45:45PM +0100, M?ns Rullg?rd wrote:
> > If my implementation puts things in macros, and you distribute my
> > implementation as part of your binaries as a result, that's *your*
> > problem.  I don't even know what you're trying to say here--"you put
> > your copyrighted code in a header and I copied it into my object
> > file--that's your problem, not mine!" doesn't make any sense at all.
> 
> The only reasonable way to use your library (which for this discussion
> shall be assumed to have been legally obtained), is to compile
> programs using its header files, and link these programs against it.
> What did you expect me to do with those headers?  Frame them and hang
> them on the wall?

Probably. The absence of a useful license for a project does
*not* mean that you can make up whatever license you'd like to
have. Generally it means that you can't do anything.

An example of a package with a license of the form you describe here
would be Sun Java. You get the source code, but you cannot link
programs against it and then redistribute them. All you can really do
with it is to look at it; hanging it on the wall is probably okay too.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |

signature.asc
Description: Digital signature

Re: Linux and GPLv2

On Wed, Mar 23, 2005 at 11:45:45PM +0100, Måns Rullgård wrote:
> Glenn Maynard <[EMAIL PROTECTED]> writes:
> 
> >> >>  extern char **__err_msgs;
> >> >>  #define perror(s) 
> >> >> (fprintf(stderr,"%d:%s:%s\n",errno,__err_msgs[errno]))
> >> >
> >> >> Is "myfile.c" a derivative work on "errno.h"? The answer is NO.
> >> >
> >> > Of course. But myfile.o might have been if perror() were complex
> >> > enough to leave any room for expressive choice.
> >> 
> >> Again, irrelevant.  If your implementation puts things in macros,
> >> that's your problem.
> >
> > Uh, what?
> >
> > If my implementation puts things in macros, and you distribute my
> > implementation as part of your binaries as a result, that's *your*
> > problem.  I don't even know what you're trying to say here--"you put
> > your copyrighted code in a header and I copied it into my object
> > file--that's your problem, not mine!" doesn't make any sense at all.
> 
> The only reasonable way to use your library (which for this discussion
> shall be assumed to have been legally obtained), is to compile
> programs using its header files, and link these programs against it.

That's fine if you're building the program for your own use -- absent a EULA
prohibiting certain uses of the work, you've got no problems (since
copyright law doesn't dictate use).  However, if you attempt to distribute
your compiled work, with my implementation bits in them, you do need to
comply with the licence of my implementation in regards to your
redistribution of my copyrighted work.

The issue at hand is whether the compilation phase creates an anthology work
(AKA mere aggregation, I believe), or a derivative work.  Are you taking the
position that not even aggregation takes place during compilation?

- Matt

signature.asc
Description: Digital signature

Re: Linux and GPLv2

On Wed, Mar 23, 2005 at 04:19:31PM -0300, Humberto Massa wrote:
> Henning Makholm wrote:
> 
> >Snip "explanation" that does not do anything the idea that bits are
> >treated differently by copyright just becuase they are in a file
> >called .h.
>
> Repeating: bits that are in files called .h are not copied in your work, 

I think you need to stop referring to .h files.  There's no general rule
that can be applied to files based purely on their extension.

I think what you meant to say is something like "files referenced by a .c
file by means of #include are only mechanically copied into your work, no
creative transformation takes place and therefore no derivation takes
place".  Would that be accurate?

That having been said, your example earlier of errno.h and the internal
__err_msgs array could be an interesting example.  If I reference that
__err_msgs array in my own code, does that then "pull in" errno.h in a
deeper fashion, such that I have then created a derived work of errno.h?

> >>Concluding: when you write a ".c" file, it is or not a derivative work
> >>on another original work independently of what the compiler and linker
> >>will do in the future.
> >
> >I repeat: No, but the resulting .o file may be derived from another
> >work that the compiler also read while producing it.
>
> Not derived. Never. To derive you need inteligence (in Brazilian 
> letter-of-law, "spirit"). A compiler does not have it. Neither does a 
> linker. Only a person does.

So whether or not a source file is derived from a file it includes by
reference is determined before you ever wave a compiler near it?  Seems
sensible enough, if a little tricky to determine (I guess that's why we have
courts for this, to stuff it up *properly*).

> >I do not see how that has anything to do with the supposed magical
> >copyright-evading capabilities of filenames that end in .h.
>
> This is an artifact of your imagination... I said only that, in general, 
> the *usual* .h does not contain copyrightable bits. And I suspect you 

What you actually said initially was "Basically, ".h" bits are *not*
copyrightable." Nothing in there about "in general" or "*usual*", except
what might be implied by "Basically".  I'm happy to believe that you merely
misexpressed yourself, but on the face of it, what you wrote implies that if
you put your novel in a file called foo.h, it's not copyrightable. 
Remember, all we have here is written word.  Cultural or linguistic
shorthand rarely works well on a mailing list.

Something like "the common contents of a .h file, being prototypes, symbol
definitions, and trivial macros, are not copyrightable" would have probably
had the same meaning (for you) as what you did write, and would have saved
all of this subsequent confusion for the rest of us.

- Matt

signature.asc
Description: Digital signature

Re: Linux and GPLv2

2005-03-23 Thread MÃ¥ns RullgÃ¥rd

Glenn Maynard <[EMAIL PROTECTED]> writes:

>> >>  extern char **__err_msgs;
>> >>  #define perror(s) (fprintf(stderr,"%d:%s:%s\n",errno,__err_msgs[errno]))
>> >
>> >> Is "myfile.c" a derivative work on "errno.h"? The answer is NO.
>> >
>> > Of course. But myfile.o might have been if perror() were complex
>> > enough to leave any room for expressive choice.
>> 
>> Again, irrelevant.  If your implementation puts things in macros,
>> that's your problem.
>
> Uh, what?
>
> If my implementation puts things in macros, and you distribute my
> implementation as part of your binaries as a result, that's *your*
> problem.  I don't even know what you're trying to say here--"you put
> your copyrighted code in a header and I copied it into my object
> file--that's your problem, not mine!" doesn't make any sense at all.

The only reasonable way to use your library (which for this discussion
shall be assumed to have been legally obtained), is to compile
programs using its header files, and link these programs against it.
What did you expect me to do with those headers?  Frame them and hang
them on the wall?

-- 
Måns Rullgård
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-23 Thread Glenn Maynard

On Wed, Mar 23, 2005 at 06:41:58PM +0100, Måns Rullgård wrote:
> > Inline functions are certainly being included in the machine code that
> > comes out of the compiler, at least if they are called by the rest of
> > the compilation unit.
> 
> Irrelevant.  If someone chooses to implement a particular interface
> using an inline function, that should not impact the derivedness of
> code using the interface.

Obviously it doesn't impact whether *source code* using that interface is
a derivative work, but it certainly affects whether *binary code* is.  The
resulting binary from compiling against a header containing inline code
can contain substantial pieces of that code--almost verbatim, if it's inline
assembly--and that obviously makes the binary connected to the source.
(Whether it's a "derived work" or a "combined work" or an "aggregate" work or
something else, I'm not sure--it's clearly not a creative transformation--but
the result is certainly affected by the license of that code.)

> >>   extern char **__err_msgs;
> >>   #define perror(s) (fprintf(stderr,"%d:%s:%s\n",errno,__err_msgs[errno]))
> >
> >> Is "myfile.c" a derivative work on "errno.h"? The answer is NO.
> >
> > Of course. But myfile.o might have been if perror() were complex
> > enough to leave any room for expressive choice.
> 
> Again, irrelevant.  If your implementation puts things in macros,
> that's your problem.

Uh, what?

If my implementation puts things in macros, and you distribute my implementation
as part of your binaries as a result, that's *your* problem.  I don't even know
what you're trying to say here--"you put your copyrighted code in a header and
I copied it into my object file--that's your problem, not mine!" doesn't make
any sense at all.

-- 
Glenn Maynard

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-23 Thread MÃ¥ns RullgÃ¥rd

Henning Makholm <[EMAIL PROTECTED]> writes:

> Scripsit Humberto Massa <[EMAIL PROTECTED]>
>> Matthew Palmer wrote:
>
>>> > Basically, ".h" bits are *not* copyrightable.
>
>>>  Under what theory do you come to that conclusion?  Note that a .h
>>>  file can contain more than function prototypes, and function
>>>  prototypes don't have to be in a .h file.
>
>> Whoa, slow down, cowboy! Re-read what I have written up there: <<".h"
>> _bits_ are not copyrightable>>. Now take a deep breath.
>
> Deep breath taken. I still want to know why you think bits are treated
> differently by copyright just because they happen to be in a file
> whose name ends in .h.

Obviously, the precise name of the file is irrelevant.  What counts is
that the file forms the definition of an interface.

>> The thing is: it is considered by USofA and other countries case law
>> that the bits that are at compile/link time from a .h file (as you
>> mentioned down here, as macros and inline functions) are not really
>> being "included" in the work, but are in reality being "referenced"
>> on it.
>
> Inline functions are certainly being included in the machine code that
> comes out of the compiler, at least if they are called by the rest of
> the compilation unit.

Irrelevant.  If someone chooses to implement a particular interface
using an inline function, that should not impact the derivedness of
code using the interface.

>>   extern char **__err_msgs;
>>   #define perror(s) (fprintf(stderr,"%d:%s:%s\n",errno,__err_msgs[errno]))
>
>> Is "myfile.c" a derivative work on "errno.h"? The answer is NO.
>
> Of course. But myfile.o might have been if perror() were complex
> enough to leave any room for expressive choice.

Again, irrelevant.  If your implementation puts things in macros,
that's your problem.

>> In the Abstraction, Filtration, Comparison process, bits that come
>> from a ".h" by way of its interface (as opposed to "by way of its
>> implementation") are filtered OUT in the filtration phase.
>
> The compiler does not even know which bits in it input come from .h
> file and which come from a .c file. It has no means of filtering on
> them specifically. (Well, excluding #line markers, but they should
> *not* influence the machine code being generated).

Are you even trying to be serious?

-- 
Måns Rullgård
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

Jeremy Hankins wrote:
Trying to explain more: my "myfile.c" is not a derivative work on
"errno.h",
 

No, but myfile.o may be. (I feel like I'm repeating myself here).
   

My understanding is that, in practice, myfile.c could infringe as well,
if the only reasonable way to use it is by creating a work that is
derivative of errno.h (if, e.g., errno.h contains something that is
significant and used in myfile.o).
 

There is a lot of case law that says otherwise: using an API does not 
contaminate the copyrights of the user.

Massa

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

Henning Makholm wrote:
Snip "explanation" that does not do anything the idea that bits are
treated differently by copyright just becuase they are in a file
called .h.
 

Repeating: bits that are in files called .h are not copied in your work, 
so your work is not a derivative work of the .h by way of copying it. 
The compiled executable may or may not be an anthology work containing 
the contents of the .h. It's not the magical fact that the file is 
ending in .h (or .inc). It's the fact that you do not transform it, so 
you do not create a derivative work.

Inline functions are certainly being included in the machine code
that comes out of the compiler, at least if they are called by the
rest of the compilation unit.
 

 

They are not being included by the author, in a creative -- 
intelectually-novel -- process; they are being included by the
compiler/linker in an automated/automatable process.
   

So what? They are being reproduced, and the mechanicalness of the
reproduction does not prevent copyright from applying to the result.
 

But the relationship of the result WRT the individual copyrights is 
different than many people (including who wrote the damned "do not link" 
paragraph in the GPL) expect.

Nothing that comes out of an automated process is *per-se*
copyrightable.
   

Do you still think this applies if the automated process is an offset
press?
 

Yes. The copyright does not apply to the printed book /per-se/... it's 
applied to the intellectual content (the original creation of spirit). 
Imagine I make a program that prints random words. The result is not 
copyrightable, even if it makes any sense at all.

Obviously, something that comes out of an automated
process and is equivalent (repeatable result of processing of) a
copyrightable work is, to the eyes of the law, the unprocessed work
itself
   

No, it's a processed work. Which is still coverved by the copyright of
the original work.
 

What you are calling a processed work is just another "face" of the same 
work; as a matter of fact, my copy of linux/errno.h and your copy of 
linux/errno.h are THE SAME WORK (not considered two different copies, 
unless you want to talk about the cost of copying... which is another 
subject altogether)

 

The compiler does not even know which bits in it input come from .h
file and which come from a .c file. It has no means of filtering on
them specifically. (Well, excluding #line markers, but they should
*not* influence the machine code being generated).
 

 

Looking from a legal standpoint, the compiler and linker are tools
like the binding machine in a book factory: they just transform and
stitch together things (imagine the manufacturing of an anthology
book) but they realize no transformation on the work itself. They do
not affect copyrights.
   

Exactly. The copyright of the original function definition is *not*
affected by its having been placed in a .h file somewhen in the process.
 

We seem to agree on this, but...
 

Concluding: when you write a ".c" file, it is or not a derivative work
on another original work independently of what the compiler and linker
will do in the future.
   

I repeat: No, but the resulting .o file may be derived from another
work that the compiler also read while producing it.
 

Not derived. Never. To derive you need inteligence (in Brazilian 
letter-of-law, "spirit"). A compiler does not have it. Neither does a 
linker. Only a person does.

 

The output of a compiler/linker is related to the source code as the
ready-to-be-sold-in-the-bookstore book is related to the original,
typewritten, version of one of the novelettes inside the book.
   

Yes. And if I want to reprint the entire book it may well be that I
need the permission not only of the author byt also of the guy who
wrote the preface.
 

Yes. These are the rules for anthology works.
 

Trying to explain more: my "myfile.c" is not a derivative work
on "errno.h",
   

No, but myfile.o may be. (I feel like I'm repeating myself here).
 

An anthology work, maybe, a derivative work, never. That's the part you 
seem not to be understanding. The rules for anthology works and 
derivative works are different. The "division" or "difusing" is 
different in each case:

Anthology work: the act of choosing/selecting/ordering 2+ different 
works *is* the intellectual act

A = B + C + W
where B and C are original works and W is the work of thinking, hmmm, an 
anthology having B and C in this order would be cool.
license of A = independent;
activities (copy, derivation) on A are only restricted by licenses of B 
and C to the extent that you are doing (copy, derivation) on B and C. 
For instance, to make another anthology with B, C and E, you only have 
to abide to the license of A (IRT the anthology as a whole -- you will 
have to abide to the license of B, C, and E IRT the copy of each that 
you will put in the anthology)

Classical example: NDIS driver using the GPLd adapters to the Linux 
kernel. If you di

Re: Linux and GPLv2

2005-03-23 Thread MÃ¥ns RullgÃ¥rd

Henning Makholm <[EMAIL PROTECTED]> writes:

>> Concluding: when you write a ".c" file, it is or not a derivative work
>> on another original work independently of what the compiler and linker
>> will do in the future.
>
> I repeat: No, but the resulting .o file may be derived from another
> work that the compiler also read while producing it.

The object file may contain bits from header files, or whatever, but
this has no bearing on the distributability of it.  They only found
their way there as the result of implementation details.  Allowing the
a particular method of implementation to stretch the reach of
copyright in such a way would be absurd, and this is what "fair use"
is about.

-- 
Måns Rullgård
[EMAIL PROTECTED]

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-23 Thread Jeremy Hankins

Henning Makholm <[EMAIL PROTECTED]> writes:
> Scripsit Humberto Massa <[EMAIL PROTECTED]>

>> Trying to explain more: my "myfile.c" is not a derivative work on
>> "errno.h",
>
> No, but myfile.o may be. (I feel like I'm repeating myself here).

My understanding is that, in practice, myfile.c could infringe as well,
if the only reasonable way to use it is by creating a work that is
derivative of errno.h (if, e.g., errno.h contains something that is
significant and used in myfile.o).

-- 
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-23 Thread Henning Makholm

Scripsit Humberto Massa <[EMAIL PROTECTED]>
> Henning Makholm wrote:

>> Deep breath taken. I still want to know why you think bits are
>> treated differently by copyright just because they happen to be in a
>> file whose name ends in .h.

> Well, this is kind of easy to explain.

Snip "explanation" that does not do anything the idea that bits are
treated differently by copyright just becuase they are in a file
called .h.

> >Inline functions are certainly being included in the machine code
> >that comes out of the compiler, at least if they are called by the
> >rest of the compilation unit.

> They are not being included by the author, in a creative -- 
> intelectually-novel -- process; they are being included by the
> compiler/linker in an automated/automatable process.

So what? They are being reproduced, and the mechanicalness of the
reproduction does not prevent copyright from applying to the result.

> Nothing that comes out of an automated process is *per-se*
> copyrightable.

Do you still think this applies if the automated process is an offset
press?

> Obviously, something that comes out of an automated
> process and is equivalent (repeatable result of processing of) a
> copyrightable work is, to the eyes of the law, the unprocessed work
> itself

No, it's a processed work. Which is still coverved by the copyright of
the original work.

> >The compiler does not even know which bits in it input come from .h
> >file and which come from a .c file. It has no means of filtering on
> >them specifically. (Well, excluding #line markers, but they should
> >*not* influence the machine code being generated).

> Looking from a legal standpoint, the compiler and linker are tools
> like the binding machine in a book factory: they just transform and
> stitch together things (imagine the manufacturing of an anthology
> book) but they realize no transformation on the work itself. They do
> not affect copyrights.

Exactly. The copyright of the original function definition is *not*
affected by its having been placed in a .h file somewhen in the process.

> Concluding: when you write a ".c" file, it is or not a derivative work
> on another original work independently of what the compiler and linker
> will do in the future.

I repeat: No, but the resulting .o file may be derived from another
work that the compiler also read while producing it.

> The output of a compiler/linker is related to the source code as the
> ready-to-be-sold-in-the-bookstore book is related to the original,
> typewritten, version of one of the novelettes inside the book.

Yes. And if I want to reprint the entire book it may well be that I
need the permission not only of the author byt also of the guy who
wrote the preface.

> Trying to explain more: my "myfile.c" is not a derivative work
> on "errno.h",

No, but myfile.o may be. (I feel like I'm repeating myself here).

> Now, just to make my self more clear, when you do a derivative work,
> then you are transforming something -- akin to Peter Jackson
> transforming the works of Tolkien. You had something -- a series of
> books -- and you got other thing in the other extremity -- a series of
> screenplays, plus casting instructions, storyboards, etc. The second
> series of stuff (derivative) came out of the spirit of Peter Jackson,
> but resulted of transformation (novel, intellectual) of the works of
> Tolkien.

I do not see how that has anything to do with the supposed magical
copyright-evading capabilities of filenames that end in .h.

-- 
Henning Makholm   "No one seems to know what
   distinguishes a bell from a whistle."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Raul Miller wrote:
Even assuming that this "considered" has some legal basis, this "rule" utterly misses the point. You have a decent heuristic there, but it's just a heuristic -- it doesn't mean anything legally.

Yes and no. Every legal issue is judged (by an attorney, before be
definitively judged by a Judge of Law) with basis on heuristics. In
Brasil, the most important heuristic is the letter of law and its
possible hermeneutics (case law has a very small weight here, compared
to the USofA, for instance). In the USofA, the most important heuristic
is the former intepretation given to some law (case law).

In the U.S., derivative works don't need to include a literal copy of any of the original to be derivative works. All they need to do is include more creative content than "fair use".

But it is well-established in the US that using/replicating/implementing
APIs and ABIs are "fair use". And that is the point I am discussing here.

See circular 14 (http://www.copyright.gov/circs/circ14.pdf) for more detail on what is and is not a derivative work. In particular, note that it uses the phrase "based on" 11 times. See circular 21 (http://www.copyright.gov/circs/circ21.pdf) for more detail on fair use.

Again, using an API to make a program is not making a program "based on"
another work -- and this, too, is well established in USofAn case law.

Outside the free software community, copyright infringment cases frequently
involve works with many superficial differences. Just because we're usually
dealing with relatively unambiguous questions doesn't mean that's always the
case for copyright law.
Which, perhaps, is one of the reasons proving "financial harm" is one of the key issues in most copyright infringement cases. As another heuristic, that's when use isn't fair use.

Agreed.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

Henning Makholm wrote:
>Scripsit Humberto Massa <[EMAIL PROTECTED]>
>>Matthew Palmer wrote:
>
Basically, ".h" bits are *not* copyrightable.
>
>>> Under what theory do you come to that conclusion?  Note that a .h 
file can contain more than function prototypes, and function prototypes 
don't have to be in a .h file.
>
>>Whoa, slow down, cowboy! Re-read what I have written up there: <<".h" 
_bits_ are not copyrightable>>. Now take a deep breath.
>
>Deep breath taken. I still want to know why you think bits are treated 
differently by copyright just because they happen to be in a file whose 
name ends in .h.
>
>Well, of course bits in general are not copyrightable. The digits 0 
and 1 are everybody's property. A particular sequence of bits can, 
however, form a copy of a copyrightable work.

Well, this is kind of easy to explain. Imagine that copyright is a right 
(a reserved, time-limited [?] monopoly) on something *your* spirit 
created. Ok? The law -- letter of law and case law -- restricts the 
rights in some cases. /In/ /casu/, there are two pertinent limitations: 
one, you cannot own the copyright to an API; two, any person can use 
your work in their work to make citations (also, but not pertinent to 
the case, parody, commentary, etc -- "fair use". So, your spirit can 
create stuff and put it on writing, but you do not own -- or better yet, 
you are not entitled to exert your monopoly in some conditions -- IRT 
that creation.

Well, my point is: in the software development process -- and more 
specifically in the C software dev process -- the author of a program 
".c" that "#include"s a ".h" file is not copying the ".h" bits, but 
making references to them. More below...

>>The thing is: it is considered by USofA and other countries case law 
that the bits that are at compile/link time from a .h file (as you 
mentioned down here, as macros and inline functions) are not really 
being "included" in the work, but are in reality being "referenced" on it.
>
>Inline functions are certainly being included in the machine code that 
comes out of the compiler, at least if they are called by the rest of 
the compilation unit.

They are not being included by the author, in a creative -- 
intelectually-novel -- process; they are being included by the 
compiler/linker in an automated/automatable process. Nothing that comes 
out of an automated process is *per-se* copyrightable. Obviously, 
something that comes out of an automated process and is equivalent 
(repeatable result of processing of) a copyrightable work is, to the 
eyes of the law, the unprocessed work itself (or better yet, just a 
copy... imagine I get page 11 of a book and Xerox it, magnifying it by 
200%; it's not identical to the original, but it's still a copy).

>The compiler does not even know which bits in it input come from .h 
file and which come from a .c file. It has no means of filtering on them 
specifically. (Well, excluding #line markers, but they should *not* 
influence the machine code being generated).

Looking from a legal standpoint, the compiler and linker are tools like 
the binding machine in a book factory: they just transform and stitch 
together things (imagine the manufacturing of an anthology book) but 
they realize no transformation on the work itself. They do not affect 
copyrights.

If the author of one of the novelettes in an anthology did not gave to 
the publishing house permission to publish it, it does not make any 
difference if they used the hardcover or paperback, if they put it first 
or last in the book, nor if they interspaced each line of the novelette 
with one line of another work. The "binding machine" does not affect 
this. The work is the original, handwritten/typewritten work that came 
out of the author's mind.

Concluding: when you write a ".c" file, it is or not a derivative work 
on another original work independently of what the compiler and linker 
will do in the future. That's why "abstraction, filtration, comparison" 
are operations to be done on SOURCE CODE. The output of a 
compiler/linker is related to the source code as the 
ready-to-be-sold-in-the-bookstore book is related to the original, 
typewritten, version of one of the novelettes inside the book. Trying to 
explain more: my "myfile.c" is not a derivative work on "errno.h", 
independently of the definition of perror() being a macro, an inline 
function, or just a function prototype to be fulfilled at link-time (or 
even possibly at run-time, in case of dyn linking). OTOH, my "myerrno.h" 
is a derivative work anyway... it's an improvement and so a 
transformation of the original "errno.h".

Now, just to make my self more clear, when you do a derivative work, 
then you are transforming something -- akin to Peter Jackson 
transforming the works of Tolkien. You had something -- a series of 
books -- and you got other thing in the other extremity -- a series of 
screenplays, plus casting instructions, storyboards, etc. The second 
series

Re: Linux and GPLv2

2005-03-23 Thread Raul Miller

On Wed, Mar 23, 2005 at 10:56:49AM -0300, Humberto Massa wrote:
> Whoa, slow down, cowboy! Re-read what I have written up there: <<".h" 
> _bits_ are not copyrightable>>. Now take a deep breath. The thing is: it 
> is considered by USofA and other countries case law that the bits that 
> are at compile/link time from a .h file (as you mentioned down here, as 
> macros and inline functions) are not really being "included" in the 
> work, but are in reality being "referenced" on it.

Even assuming that this "considered" has some legal basis, this "rule"
utterly misses the point.  You have a decent heuristic there, but it's
just a heuristic -- it doesn't mean anything legally.

In the U.S., derivative works don't need to include a literal copy of
any of the original to be derivative works.  All they need to do is
include more creative content than "fair use".

See circular 14 (http://www.copyright.gov/circs/circ14.pdf) for
more detail on what is and is not a derivative work.  In particular,
note that it uses the phrase "based on" 11 times.  See circular 21
(http://www.copyright.gov/circs/circ21.pdf) for more detail on fair use.

Outside the free software community, copyright infringment cases
frequently involve works with many superficial differences.  Just because
we're usually dealing with relatively unambiguous questions doesn't mean
that's always the case for copyright law.

Which, perhaps, is one of the reasons proving "financial harm" is one
of the key issues in most copyright infringement cases.  As another
heuristic, that's when use isn't fair use.

-- 
Raul

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-23 Thread Henning Makholm

Scripsit Humberto Massa <[EMAIL PROTECTED]>
> Matthew Palmer wrote:

>> > Basically, ".h" bits are *not* copyrightable.

>>  Under what theory do you come to that conclusion?  Note that a .h
>>  file can contain more than function prototypes, and function
>>  prototypes don't have to be in a .h file.

> Whoa, slow down, cowboy! Re-read what I have written up there: <<".h"
> _bits_ are not copyrightable>>. Now take a deep breath.

Deep breath taken. I still want to know why you think bits are treated
differently by copyright just because they happen to be in a file
whose name ends in .h.

Well, of course bits in general are not copyrightable. The digits 0
and 1 are everybody's property. A particular sequence of bits can,
however, form a copy of a copyrightable work.

> The thing is: it is considered by USofA and other countries case law
> that the bits that are at compile/link time from a .h file (as you
> mentioned down here, as macros and inline functions) are not really
> being "included" in the work, but are in reality being "referenced"
> on it.

Inline functions are certainly being included in the machine code that
comes out of the compiler, at least if they are called by the rest of
the compilation unit.

>   extern char **__err_msgs;
>   #define perror(s) (fprintf(stderr,"%d:%s:%s\n",errno,__err_msgs[errno]))

> Is "myfile.c" a derivative work on "errno.h"? The answer is NO.

Of course. But myfile.o might have been if perror() were complex
enough to leave any room for expressive choice.

> In the Abstraction, Filtration, Comparison process, bits that come
> from a ".h" by way of its interface (as opposed to "by way of its
> implementation") are filtered OUT in the filtration phase.

The compiler does not even know which bits in it input come from .h
file and which come from a .c file. It has no means of filtering on
them specifically. (Well, excluding #line markers, but they should
*not* influence the machine code being generated).

-- 
Henning Makholm  "En tapper tinsoldat. En dame i
 spagat. Du er en lykkelig mand ..."

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

Matthew Palmer wrote:
 On Wed, Mar 23, 2005 at 10:22:12AM -0300, Humberto Massa wrote:
> Matthew Palmer wrote:
>
>>> That said, it looks questionable whether the FTP plugin should
>>> reallybe considered a derivative of the plugin loader. If the
>>> latter has a  documented API and the former only communicates
>>> with it through that API, I'd probably say no. Even more so if
>>> that plugin could conceivably work with another, non-GPL'd
>>> plugin loader.
>>
>> It's a tricky issue.  Even if the plugin does only communicate
>> via the published interface, it is entirely possible that the
>> plugin includes copyrighted elements from the plugin loader code
>> itself.  It'd have to be decided on a case-by-case basis.
>
> Basically, ".h" bits are *not* copyrightable.
 Under what theory do you come to that conclusion?  Note that a .h
 file can contain more than function prototypes, and function
 prototypes don't have to be in a .h file.
Whoa, slow down, cowboy! Re-read what I have written up there: <<".h" 
_bits_ are not copyrightable>>. Now take a deep breath. The thing is: it 
is considered by USofA and other countries case law that the bits that 
are at compile/link time from a .h file (as you mentioned down here, as 
macros and inline functions) are not really being "included" in the 
work, but are in reality being "referenced" on it. I will try to 
ilustrate it (any coincidence on names of real people is what it seems 
to be):

// errno.h:
// (C) LT, 1991
 #define ENOENT 23
 extern int errno;
 /* implementation detail: never use this array; its name can change at 
any time */
 extern char **__err_msgs;
 #define perror(s) (fprintf(stderr,"%d:%s:%s\n",errno,__err_msgs[errno]))

// myfile.c:
// (C) Massa, 2005
 if( !(f = fopen("arqname.txt", "r")) )
   perror("The file arqname.txt must exist!");
Is "myfile.c" a derivative work on "errno.h"? The answer is NO. In the 
Abstraction, Filtration, Comparison process, bits that come from a ".h" 
by way of its interface (as opposed to "by way of its implementation") 
are filtered OUT in the filtration phase. This basically translates as 
following: to the extent that you don't mess with the inner workings of 
a ".h" file (eg, in the above example the __err_msgs array), 
independently if it has macros/inline functions in it, "myfile.c" (that 
is, in the ultimate analisys, the copyrighted work) does not include, 
properly, "errno.h", merely reference it.

IOW: myfile.c is not a derivative work on errno.h. Now, look:
// myerrno.h:
// (C) LT, 1991
// (C) modifications Massa, 2005
 #define ENOENT 24 /* the stupid other guy used the wrong number */
 extern int errno;
 extern int perror(const char *s); /* let's move this to the lib */
THAT is Obviously a derivative work of errno.h. Got the difference? This 
example have something that is a *transformation* -- novel, 
intellectually-worked -- on the original work. When you abstract out 
what errno.h does, filter the non-copyrightable parts (if any) and 
compare, myerrno.h is clearly a derivative work.

Even if kernel developers did not know it at the time, this is the real 
power behind EXPORT_SYMBOL_GPL vs EXPORT_SYMBOL: the latter mark things 
in the kernel as being part of the API/ABI and the former, as being part 
of the implementation, *effectively* regulating what is messing with the 
kernel inner workings enough to be considered a derivative work (and 
hence, to be mandatorily GPL-compatible-licensed).

> Which other elements of the plugin loader may be _included_ in the
> plugin?
 Macros and inline functions spring immediately to mind, although I
 don't think inlines normally cross library boundaries.  My linker fu
 is rusty.
Any others?
 - Matt
Massa

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

On Wed, Mar 23, 2005 at 10:22:12AM -0300, Humberto Massa wrote:
> Matthew Palmer wrote:
> 
> >> That said, it looks questionable whether the FTP plugin should
> >> reallybe considered a derivative of the plugin loader. If the
> >> latter has a  documented API and the former only communicates with
> >> it through that API, I'd probably say no. Even more so if that
> >> plugin could conceivably work with another, non-GPL'd plugin
> >> loader.
> >
> > It's a tricky issue.  Even if the plugin does only communicate via
> > the published interface, it is entirely possible that the plugin
> > includes copyrighted elements from the plugin loader code itself.
> > It'd have to be decided on a case-by-case basis.
> 
> Basically, ".h" bits are *not* copyrightable.

Under what theory do you come to that conclusion?  Note that a .h file can
contain more than function prototypes, and function prototypes don't have to
be in a .h file.

> Which other elements of the plugin loader may be _included_ in the plugin?

Macros and inline functions spring immediately to mind, although I don't
think inlines normally cross library boundaries.  My linker fu is rusty.

- Matt


signature.asc
Description: Digital signature

Re: Linux and GPLv2

Matthew Palmer wrote:
> That said, it looks questionable whether the FTP plugin should
> reallybe considered a derivative of the plugin loader. If the
> latter has a  documented API and the former only communicates with
> it through that API, I'd probably say no. Even more so if that
> plugin could conceivably work with another, non-GPL'd plugin
> loader.
 It's a tricky issue.  Even if the plugin does only communicate via
 the published interface, it is entirely possible that the plugin
 includes copyrighted elements from the plugin loader code itself.
 It'd have to be decided on a case-by-case basis.
Basically, ".h" bits are *not* copyrightable. Which other elements of 
the plugin loader may be _included_ in the plugin?

 - Matt

Massa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Linux and GPLv2

2005-03-23 Thread Glenn Maynard

On Wed, Mar 23, 2005 at 10:34:28AM +0100, Gerardo Ballabio wrote:
> So, the FTP plugin's license must be _the GPL_, and it must not  
> depend on GPL-incompatible code.

No.  It must be GPL-compatible, but it need not be the GPL.  For example,
you can reuse a third party's MIT-licensed code in your code, and that
software does not suddenly receive the restrictions of the GPL--in fact,
if you havn't modified the code enough to have a copyright claim in it
(which you often don't have to do, with well-written code), you don't
have any grounds to be placing the GPL's restrictions on that code at all.

-- 
Glenn Maynard

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Linux and GPLv2

On Wed, Mar 23, 2005 at 10:34:28AM +0100, Gerardo Ballabio wrote:
> >From: Matthew Palmer <[EMAIL PROTECTED]>
> 
> >I don't think it's a GPL violation.  To my way of thinking, the  
> >derivatives graph would look like this (where "A --> B" means "B is
> >a derivative work of A"):
> >
> >GPL'd library --> FTP plugin <-- plugin loader
> 
> [snip]
> 
> >So, reading this, the FTP plugin is a derivative of the loader and  
> >the GPL'd library, so the FTP plugin's licence must be compatible  
> >with both of those (with the loader being MIT, the plugin could be  
> >MIT, BSD, GPL, whatever).
> 
> Sorry, no. It's the other way around

What's the wrong way around?  The derivative work calculations?  That's the
only thing I can see that's got a direction.  Whichever item you think needs
to change, it's undeniable that the licence of the FTP plugin must be
compatible with that of any work that it is derived from.

> -- if A depends on B and A is  

I'd stay away from terms like "depends", since they don't have any real
meaning in copyright terms.

> GPL'd, then B must be GPL-compatible (by the way, that isn't a  
> restriction on B. It's a restriction on A: if B isn't GPL-compatible,  
> you can't distribute A at all

I thought that's what I said.  I may not have been as clear as I could have
been, for which I apologise, but I think we're pretty much in violent
agreement here.

> (wouldn't it be wonderful if I could  
> release a GPL'd program for Windows and, voila! Windows must be GPL'd  

You can't force another work's licence to change regardless of the licence
you choose for your work.  Also, if your work is GPL, anything else related
doesn't need to be GPL, it just need to be GPL compatible.

> So, the FTP plugin's license must be _the GPL_, and it must not  
> depend on GPL-incompatible code.

No, it doesn't need to be licenced under the GPL.  It merely needs to be GPL
compatible.

> That said, it looks questionable whether the FTP plugin should really  
> be considered a derivative of the plugin loader. If the latter has a  
> documented API and the former only communicates with it through that  
> API, I'd probably say no. Even more so if that plugin could  
> conceivably work with another, non-GPL'd plugin loader.

It's a tricky issue.  Even if the plugin does only communicate via the
published interface, it is entirely possible that the plugin includes
copyrighted elements from the plugin loader code itself.  It'd have to be
decided on a case-by-case basis.

- Matt

signature.asc
Description: Digital signature

Re: Re: Linux and GPLv2

2005-03-23 Thread Gerardo Ballabio

From: Francesco Poli <[EMAIL PROTECTED]>

On Mon, 14 Mar 2005 17:53:35 + Gervase Markham wrote:
[about the "don't remove get_source feature"]
> - The requirement to not remove certain particular code is
> probably non-free;
I don't think it's forbidding to remove the code: it's merely  
forbidding to drop a feature.
You could reimplement it in a better (or even worse) way, but you  
must support it.
Then if my reimplementation has a bug that prevents it from working  
properly, I may be accused of infringement?

Anyway I agree it's non-free.
Then you may be surprised to hear that the GPLv2 does have a "don't  
remove this feature" clause:

c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License.  (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
I'd even read this as saying "if the original program isn't  
interactive, but the modified one is, you must _add_ that feature".

Gerardo Ballabio

Re: Re: Linux and GPLv2

2005-03-23 Thread Gerardo Ballabio

From: Matthew Palmer <[EMAIL PROTECTED]>

I don't think it's a GPL violation.  To my way of thinking, the  
derivatives graph would look like this (where "A --> B" means "B is
a derivative work of A"):

GPL'd library --> FTP plugin <-- plugin loader
[snip]
So, reading this, the FTP plugin is a derivative of the loader and  
the GPL'd library, so the FTP plugin's licence must be compatible  
with both of those (with the loader being MIT, the plugin could be  
MIT, BSD, GPL, whatever).
Sorry, no. It's the other way around -- if A depends on B and A is  
GPL'd, then B must be GPL-compatible (by the way, that isn't a  
restriction on B. It's a restriction on A: if B isn't GPL-compatible,  
you can't distribute A at all (wouldn't it be wonderful if I could  
release a GPL'd program for Windows and, voila! Windows must be GPL'd  
(of course forgetting that the GPL makes an exception for code  
"normally distributed with the operating system" (whoa, too many  
nested parentheses. Stop that madness now!. But if it's B that is  
GPL'd, then A must be GPL'd too.

So, the FTP plugin's license must be _the GPL_, and it must not  
depend on GPL-incompatible code.

That said, it looks questionable whether the FTP plugin should really  
be considered a derivative of the plugin loader. If the latter has a  
documented API and the former only communicates with it through that  
API, I'd probably say no. Even more so if that plugin could  
conceivably work with another, non-GPL'd plugin loader.

Gerardo Ballabio

Re: Linux and GPLv2

2005-03-16 Thread Anthony DeRobertis

Matthew Palmer wrote:
Add another one -- "must offer an [...] opportunity for all users [...] to
request immediate transmission by HTTP" -- doesn't mean that the request
must be successfully honoured...  
Strictly speaking, yes. However, if you intentionally saw that all 
requests would fail to be honored and made that argument, I suspect 
that's a quick way to piss off the judge.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-16 Thread Anthony DeRobertis

Francesco Poli wrote:
|   9. The Free Software Foundation may publish revised and/or new
| versions of the General Public License from time to time.  Such new
| versions will be similar in spirit to the present version, but may
| differ in detail to address new problems or concerns.
   ^^^
I wonder what the effect of adding something like this to the copyright 
notice would be:

The licensor considers the lack of restrictions on running the
program, as spelled out in clause 0, essential to the spirit of
the license.
I suspect something like this could aid in arguing that a hypothetical 
future "GPL" with a web-services restriction is not a "revised and/or 
new version" without hampering the ability to use this code along with 
other GPL-licensed code.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-15 Thread Sean Kellogg

On Tuesday 15 March 2005 01:34 pm, Glenn Maynard wrote:
> Nope.  It says "similar in spirit", which is much weaker to me.  Certainly
> it's also not a major stretch to claim that a license which says "if you
> use this program as part of your webpage, you must make source available"
> is "similar in spirit", since the "spirit" of the GPL is making source
> available and reusable.  (Of course, there are plenty of potential
> restrictions in that "spirit" that go too far and aren't free.)

Such languages is not very useful anyway.  Against whom does this language 
apply?  The FSF?!  Doubtful, they are not participants in the license, nor 
beneficiaries in the contract (note that I am politely avoiding the important 
legal ambiguity as to whether this is a license or a contract).  The phrase 
is a very nice pledge of intent, but its not going to be enforceable in a 
court of law.

-Sean

-- 
Sean Kellogg
2nd Year - University of Washington School of Law
GPSS Senator - Student Bar Association
Editor-at-Large - National ACS Blog [http://www.acsblog.org]
c: 206.498.8207    e: [EMAIL PROTECTED]

So, let go
 ...Jump in
  ...Oh well, what you waiting for?
   ...it's all right
    ...'Cause there's beauty in the breakdown

Re: Linux and GPLv2

2005-03-15 Thread MÃ¥ns RullgÃ¥rd

"Anthony W. Youngman" <[EMAIL PROTECTED]> writes:

> And doesn't the GPL contain a promise that any future GPL will be
> identical in spirit to the original?

It uses the phrase "similar in spirit", which has yet to be given an
exact definition.

>>Of course, this assumes you actually want to take the matter to court...  an
>>act often prohibitively expensive for most FOSS developers...  but then
>>again, most of this conversation is academic anyway because it assumes people
>>will actually dislike v3 AND that there is infringement ABD that the
>>infringement is authorized under v3 but not v2.
>
> If the new GPL breaks that promise, then the original licensor has a
> very good case in law that the new GPL is *not* a "later" version, but
> a "different" version to which the "or later" wording doesn't apply...

That would be a, maybe not desirable, but at least very interesting
case.

-- 
Måns Rullgård
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-15 Thread Glenn Maynard

On Mon, Mar 14, 2005 at 09:50:54PM +, Anthony W. Youngman wrote:
> And doesn't the GPL contain a promise that any future GPL will be 
> identical in spirit to the original?

Nope.  It says "similar in spirit", which is much weaker to me.  Certainly
it's also not a major stretch to claim that a license which says "if you
use this program as part of your webpage, you must make source available"
is "similar in spirit", since the "spirit" of the GPL is making source
available and reusable.  (Of course, there are plenty of potential
restrictions in that "spirit" that go too far and aren't free.)

-- 
Glenn Maynard

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-15 Thread Anthony W. Youngman

In message <[EMAIL PROTECTED]>, Sean Kellogg 
<[EMAIL PROTECTED]> writes
Missing from this discussion is a rather important aspect of this license...
the law.  If GPL v3 comes out with provisions that are even arguablly
different from GPL v2 there will be all sorts of grounds for developers to
strike out the 'or later' language from all prior grants of access to their
code.
It is a matter of equity that is a) critical to any issue like this, and b)
all too often over looked by this list.  It is quite difficult for someone to
agree to terms they have not seen before.  More importantly, I don't see how
I could possibly agree to terms propagated by a body that does not have
privity in the contract (FSF).  Unless you have assigned your copyright over
to them (and may programs have) I don't think that language is going to be
enforceable.
And doesn't the GPL contain a promise that any future GPL will be 
identical in spirit to the original?
Of course, this assumes you actually want to take the matter to court...  an
act often prohibitively expensive for most FOSS developers...  but then
again, most of this conversation is academic anyway because it assumes people
will actually dislike v3 AND that there is infringement ABD that the
infringement is authorized under v3 but not v2.
If the new GPL breaks that promise, then the original licensor has a 
very good case in law that the new GPL is *not* a "later" version, but a 
"different" version to which the "or later" wording doesn't apply...
-Sean
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-14 Thread Henri Sivonen

On Mar 15, 2005, at 03:24, Kuno Woudt wrote:
On Mon, Mar 14, 2005 at 08:00:24PM -0500, Jeremy Hankins wrote:
A valid concern, arguably, even if it does hinge on certain ideas 
about
how the computing field will evolve that I doubt will turn out to be
accurate.  But the only licenses we've seen so far that deal with this
problem (if it is a problem) give up too much freedom in exchange.  At
least, IMHO.
Can you be specific on which licenses you think attempt to deal with
this problem?
The license of POV-Ray 3.0 and 3.1 (free as in beer, source available; 
not free in the DFSG sense) addressed this issue in the section called 
"ONLINE OR REMOTE EXECUTION OF POV-Ray".

Charging for CPU time was allowed provided that the charge for POV-Ray 
CPU time was the same as for other CPU time. Obscuring the fact the 
POV-Ray was being run was prohibited. The users had to be provided with 
access to the files of the POV-Ray package.

--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-14 Thread Arnoud Engelfriet

Kuno Woudt wrote:
> Can you be specific on which licenses you think attempt to deal with
> this problem?  So far I only know of the Affero GPL, which I already
> mentioned elsewhere in this thread, and I am curious how other license
> authors have attempted to fix this problem.

Larry Rosen's Open Software License also tries to cover this.
In article 5 it defines External Deployment as follows:

   5.  External Deployment.  The term "External Deployment" means the
   use or distribution of the Original Work or Derivative Works in any
   way such that the Original Work or Derivative Works may be accessed or
   used by anyone other than You, whether the Original Work or Derivative
   Works are distributed to those persons or made available as an
   application intended for use over a computer network.

This quite clearly is intended to cover usage on a website by an ASP.

And then article 5 goes on to say:

   As an express condition for the grants of license hereunder, You
   agree that any External Deployment by You shall be deemed a
   distribution and shall be licensed to all under the terms of this
   License, as prescribed in section 1(c) herein.

Article 1(c) is the "you may distribute, but derivatives must be
OSL as well" article.

Arnoud

-- 
Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-14 Thread Jeremy Hankins

Kuno Woudt <[EMAIL PROTECTED]> writes:
> On Mon, Mar 14, 2005 at 08:00:24PM -0500, Jeremy Hankins wrote:

>> A valid concern, arguably, even if it does hinge on certain ideas
>> about how the computing field will evolve that I doubt will turn out
>> to be accurate.  But the only licenses we've seen so far that deal
>> with this problem (if it is a problem) give up too much freedom in
>> exchange.  At least, IMHO.

> Can you be specific on which licenses you think attempt to deal with
> this problem?  So far I only know of the Affero GPL, which I already
> mentioned elsewhere in this thread, and I am curious how other license
> authors have attempted to fix this problem.

The Affero GPL is the main one.  Back when it came up on this list I
think there was some discussion about possibly clauses that might serve
the same purpose, but I don't think we came up with anything
satisfactory.

The APSL tries to do this, I think, through the use of the term
"externally deploy".  I think it does a somewhat better job than the
Affero license does, but is still subject to a lot of confusion about
what sorts of things count as providing a service (which is part of the
"externally deploy" definition).  It's also not clear where it gets the
legal authority to place restrictions on providing services that it
does.  Possibly by claiming that it would be a "public performance".

You can see the discussion in the archives, if you're interested.  It
was in August of '03 & came up again in June of '04.

-- 
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-14 Thread Glenn Maynard

On Mon, Mar 14, 2005 at 02:44:02PM +0100, Måns Rullgård wrote:
> There is no single "the community", sharing a single opinion on
> "freedom".  There are many different views out there, and some recent
> moves from FSF have been in a direction away from a large enough
> number of people, with loud enough voices, to make it noticeable.

Historically, the FSF had been very consistent, enough so that many
people have been willing to trust the FSF to act in good faith with
the "will be similar in spirit to the present version" of GPL#9.

Given the relatively recent developments, we're in agreement, though.

-- 
Glenn Maynard

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-14 Thread Don Armstrong

On Mon, 14 Mar 2005, Jeremy Hankins wrote:
> Francesco Poli <[EMAIL PROTECTED]> writes:
> > Could you please elaborate on the "PHP loophole"?  I've never heard of
> > it: what do you mean by that?
> 
> It's the whole web-as-platform idea.

This is commonly refered to as the "ASP[1] loophole" not the "PHP
loophole" for the obvious reasons that the former describes the actual
problem, whereas the latter is just a language that isn't restricted
to usage by ASPs.

Search for affero and asp loophole from somewhere around 2003 on
-legal if you want more information on why closing this loophole is
probably not possible to do in a free manner.


Don Armstrong

1: Where ASP is application service provider.
-- 
The solution to a problem changes the problem.
 -- Peer's Law

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-14 Thread Kuno Woudt

On Mon, Mar 14, 2005 at 08:00:24PM -0500, Jeremy Hankins wrote:
> A valid concern, arguably, even if it does hinge on certain ideas about
> how the computing field will evolve that I doubt will turn out to be
> accurate.  But the only licenses we've seen so far that deal with this
> problem (if it is a problem) give up too much freedom in exchange.  At
> least, IMHO.
Can you be specific on which licenses you think attempt to deal with
this problem?  So far I only know of the Affero GPL, which I already
mentioned elsewhere in this thread, and I am curious how other license
authors have attempted to fix this problem.

(I am in the position that I've chosen the Affero GPL for a project [1] a
 few years ago, but after reading the license again today, and the
 comments here -- it is obvious to me that i should start using a
 different license for it).

-- Kuno.
  
[1] a photo album written in php, nothing particularly interesting or
important. 
   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-14 Thread Matthew Palmer

On Mon, Mar 14, 2005 at 05:53:35PM +, Gervase Markham wrote:
> Kuno Woudt wrote:
> >  * d) If the Program as you received it is intended to interact with
> >  users through a computer network and if, in the version you received,
> >  any user interacting with the Program was given the opportunity to
> >  request transmission to that user of the Program's complete source
> >  code, you must not remove that facility from your modified version of
> >  the Program or work based on the Program, and must offer an
> >  equivalent opportunity for all users interacting with your Program
> >  through a computer network to request immediate transmission by HTTP
> >  of the complete source code of your modified version or other
> >  derivative work.
> 
> Incidentally, this is pretty badly drafted, IMO. For example:

Add another one -- "must offer an [...] opportunity for all users [...] to
request immediate transmission by HTTP" -- doesn't mean that the request
must be successfully honoured...  

- Matt


signature.asc
Description: Digital signature

Re: Linux and GPLv2

2005-03-14 Thread Jeremy Hankins

Francesco Poli <[EMAIL PROTECTED]> writes:

> Could you please elaborate on the "PHP loophole"?  I've never heard of
> it: what do you mean by that?

It's the whole web-as-platform idea.  Let's say I take a copy of latex
(assuming for the moment that it were GPL, which it isn't IIRC), and I
"enhance" it (maybe I integrate it with word somehow, under NDA) so that
it is no longer remotely compatible with the standard latex, and then
set up a web site offering a document processing service for a fee.  I
never distribute the program in binary form, so I never have to
distribute code either.  I'm therefore able to take advantage of all the
work the latex & tex folks have done without contributing my own changes
back to the community -- or to the users of the software.

A valid concern, arguably, even if it does hinge on certain ideas about
how the computing field will evolve that I doubt will turn out to be
accurate.  But the only licenses we've seen so far that deal with this
problem (if it is a problem) give up too much freedom in exchange.  At
least, IMHO.

-- 
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

Francesco Poli <[EMAIL PROTECTED]> writes:

> On Sun, 13 Mar 2005 19:14:09 -0500 Glenn Maynard wrote:
>
> [...]
>> There havn't been any such bugs, though, fortunately.  Some people
>> don't like the "PHP loophole" or whatever you want to call it, but I
>> don't believe that's fixable in a free license,
>
> Could you please elaborate on the "PHP loophole"?
> I've never heard of it: what do you mean by that?
>
> (feel free to change the subject or even to reply to me in private, if
> you think it's better)

I'm also curious about this one.

-- 
Måns Rullgård
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-14 Thread Francesco Poli

On Sun, 13 Mar 2005 19:14:09 -0500 Glenn Maynard wrote:

[...]
> There havn't been any such bugs, though, fortunately.  Some people
> don't like the "PHP loophole" or whatever you want to call it, but I
> don't believe that's fixable in a free license,

Could you please elaborate on the "PHP loophole"?
I've never heard of it: what do you mean by that?

(feel free to change the subject or even to reply to me in private, if
you think it's better)

[...]
> > Such language is fine as long as the copyright holder and the
> > license author are the same entity.  New versions of the license are
> > likely to reflect changes in the opinions of the authors, and they
> > have every right to make provisions for a modified license to
> > automatically apply to already released works.  The danger arises
> > when people start out-sourcing the writing of licenses to third
> > parties.  The FSF has its own agenda, and has little reason to
> > consider the opinions of others, who just happen to use their
> > license texts, when writing the next version.
> 
> A couple years ago, this would all have been patently false.  The FSF
> has a very strong interest in their notion of "freedom" being
> considered reliable, and having the community trust them to remain
> consistent--as they did quite well for a very long time.  A couple
> years ago, I wouldn't have had a problem with the FSF being able to
> make such changes--the alternatives are "don't fix problems" and
> "fragment GPL source", neither of which is any good.  I'd have
> considered the FSF's track record and reputation good enough to allow
> it.
> 
> That's no longer the case, unfortunately.

The same happened to me.
They undermined their good reputation with the GFDL affair, IMHO.
Especially for how they are (not) dealing with it and for how much they
are (not) caring about others' opinions...  :-(((

-- 
  Today is the tomorrow you worried about yesterday.
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp0vnLSmmiv3.pgp
Description: PGP signature

Re: Linux and GPLv2

2005-03-14 Thread Francesco Poli

On Mon, 14 Mar 2005 17:53:35 + Gervase Markham wrote:

[about the "don't remove get_source feature"]
> - The requirement to not remove certain particular code is probably
>non-free;

I don't think it's forbidding to remove the code: it's merely forbidding
to drop a feature.
You could reimplement it in a better (or even worse) way, but you must
support it.

Anyway I agree it's non-free.

Suppose for example that my derivative work is intended for use on an
embedded system with very limited hardware resources.
I could fail to comply with my constraints, due to this prohibition to
drop a functionality (in the meanwhile, perhaps, I'm distributing my
derivative work separately, through my website, in both source and
binary forms and even through Debian archives, since I'm a DD myself and
have packaged my derivative work for Debian! Thus I'm a very good guy!).

Obviously, this is a thoroughly hypothetical example (I don't write
programs for embedded systems, IANADD, and, above all things, I wouldn't
create derivative works of AGPL'd programs!)

> 
> - The general requirement to make code available for download could be
>asserted without the "don't remove code X" clause;

Yes, though I don't think such clauses could be made DFSG-free...  :(

> 
> - Specifying HTTP is not future-proof, and may not be appropriate for
>some programs or environments;

Definitely agreed.

> 
> - What happens if the program interacts with other programs over a
>network? How do you define "interacting with a user"?

Who knows?
I agree that this is very gray and unclear.

-- 
  Today is the tomorrow you worried about yesterday.
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4

pgproudW5yfWV.pgp
Description: PGP signature

Re: Linux and GPLv2

2005-03-14 Thread Francesco Poli

On Sun, 13 Mar 2005 18:29:36 -0500 Glenn Maynard wrote:

> There's a more significant problem: if you say "or later", and you
> don't like GPLv3--either because it allows things you don't like, or
> (as recent events suggest may be more likely) includes restrictions
> you don't like, people can take your work, modify it, and place their
> modifications under GPLv3-only.  If you want to keep your code
> available under GPLv2, you can't incorporate those changes, since
> they're not available under v2.
>
> Considering that a primary motivator of the GPL is to prevent the case
> where you can't incorporate other people's enhancements to your work
> due to licensing, this seems like a potentially major failure.

Indeed.

[...]
> > The "or later" gives the FSF more flexibility to change the license
> > terms for a vast amount of software they really have no connection
> > at all with, with or without the approval of the copyright holders
> > of said software.
> 
> The "or later" is intended, as I understand--from rational logic, as
> I don't believe I've seen any statement from the FSF--to allow the
> FSF to fix problems in the GPL.

You've seen it, believe me!
It's in the GPLv2 text itself!  ;-)

|   9. The Free Software Foundation may publish revised and/or new
| versions of the General Public License from time to time.  Such new
| versions will be similar in spirit to the present version, but may
| differ in detail to address new problems or concerns.
   ^^^

>  Without "or later", it's impossible:
> the only way a "bugfixed" GPL could be used is after getting explicit
> permission from every copyright holder of a GPL work.  Further, and
> just as importantly, the "bugfixed" GPLv3 would be incompatible with
> the original GPLv2!  That would fragment the GPL at a fundamental
> level.

Yes, at level that only dual licensing (which is what "GPLv2 or later"
actually is) can cure...

> 
> That would be fine, if the FSF had maintained its traditional
> consistency. Frankly, they broke that trust with the GFDL, and so I'd
> sympathise with people no longer willing to use the "or later"
> language.  The above problem doesn't go away, though.

Agreed entirely.

The "or later" trick works as long as the FSF is trusted to actually fix
problems and release better and better GPL versions.
But I'm not sure that this trust is deserved any longer...

:-(  and  :-((  and then  :-(((


-- 
  Today is the tomorrow you worried about yesterday.
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpJdE7XjSW0A.pgp
Description: PGP signature

Re: Linux and GPLv2

2005-03-14 Thread Gervase Markham

Kuno Woudt wrote:
  * d) If the Program as you received it is intended to interact with
  users through a computer network and if, in the version you received,
  any user interacting with the Program was given the opportunity to
  request transmission to that user of the Program's complete source
  code, you must not remove that facility from your modified version of
  the Program or work based on the Program, and must offer an
  equivalent opportunity for all users interacting with your Program
  through a computer network to request immediate transmission by HTTP
  of the complete source code of your modified version or other
  derivative work.
Incidentally, this is pretty badly drafted, IMO. For example:
- The requirement to not remove certain particular code is probably
  non-free;
- The general requirement to make code available for download could be
  asserted without the "don't remove code X" clause;
- Specifying HTTP is not future-proof, and may not be appropriate for
  some programs or environments;
- What happens if the program interacts with other programs over a
  network? How do you define "interacting with a user"?
Gerv
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-14 Thread Humberto Massa

Arnoud Engelfriet wrote:
You're correct in that anything that's a derivative work of any
GPLv2 code also cannot be distributed under GPLv3 or later. But
it's going to be very interesting to figure out what code is
a derivative work of what.
Anyway, this seems rather theoretical.
Arnoud
 

Yeah, but in a back-of-envelop calculation, to completely determine what 
code is derivative of what in Linux, one would take approximately 19 
man-years. Maybe some automated way to study cvs.kernel.org changesets 
would shorten it up a bit, but ... ;-)

Massa

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-14 Thread Arnoud Engelfriet

Humberto Massa wrote:
> Everything that is not completely independent and extractable and beyond
> any doubt non-historically-derived of Linus code is a derivative work
> and, as such, can only be distributed under the terms of the GPLv2.

You're correct in that anything that's a derivative work of any
GPLv2 code also cannot be distributed under GPLv3 or later. But
it's going to be very interesting to figure out what code is
a derivative work of what.

Anyway, this seems rather theoretical.

Arnoud

-- 
Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

Kuno Woudt <[EMAIL PROTECTED]> writes:

> On Sun, Mar 13, 2005 at 03:30:28PM +0100, Måns Rullgård wrote:
>> Arnoud Engelfriet <[EMAIL PROTECTED]> writes:
>> 
>> > And probably it will also deal with running the code on a publicly
>> > accessible server. 
>> 
>> The question is if a license based on copyright can legally place such
>> restrictions on use of the program.
>
> Some idea of how the FSF may attempt this can be seen from the Affero
> General Public License. Apparantly the Affero GPL is a modified version
> of the GNU GPL, it adds Section 2(d):
>
>   * d) If the Program as you received it is intended to interact with
>   users through a computer network and if, in the version you received,
>   any user interacting with the Program was given the opportunity to
>   request transmission to that user of the Program's complete source
>   code, you must not remove that facility from your modified version of
>   the Program or work based on the Program, and must offer an
>   equivalent opportunity for all users interacting with your Program
>   through a computer network to request immediate transmission by HTTP
>   of the complete source code of your modified version or other
>   derivative work.

This appears to only apply to self-distributing programs.  If the
program does not have a send-the-source function, I don't see any
requirement that source be provided to users of a service based on the
program.

> It also adds an "interesting" twist on the "or later" thing often used
> with the GPLv2:
>
>   Affero Inc. may publish revised and/or new versions of the Affero
>   General Public License from time to time. Such new versions will be
>   similar in spirit to the present version, but may differ in detail to
>   address new problems or concerns.

I've always wondered what "similar in spirit" is supposed to mean.
AFAIK, that phrase has no established legal interpretation.

>   Each version is given a distinguishing version number. If the Program
>   specifies a version number of this License which applies to it and "any
>   later version", you have the option of following the terms and
>   conditions either of that version or of any later version published by
>   Affero, Inc. If the Program does not specify a version number of this
>   License, you may choose any version ever published by Affero, Inc.

This looks similar to the language used in the GNU GPL.

>   You may also choose to redistribute modified versions of this program
>   under any version of the Free Software Foundation's GNU General Public
>   License version 3 or higher, so long as that version of the GNU GPL
>   includes terms and conditions substantially equivalent to those of this
>   license.

It would be interesting to see the reaction of these people, if the
GNU GPLv3 does not include a source-for-service clause, after all.

-- 
Måns Rullgård
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

Humberto Massa <[EMAIL PROTECTED]> writes:

> Arnoud Engelfriet wrote:
>
>>Interesting point. But the statement would apply certainly to
>>Linus' own contributions. And that would preclude distribution
>>of anything containing those contributions under anything but GPLv2
>>I think. But if you can take out his code (and any other that's
>>GPLv2 only), you'd be free to apply GPLv3 if and when it comes out.
>>
>>Arnoud
>>
>>
> Sorry, but no, no, no.
>
> Everything that is not completely independent and extractable and beyond
> any doubt non-historically-derived of Linus code is a derivative work
> and, as such, can only be distributed under the terms of the GPLv2.
>
> To prove something not derivative, you would have to show that
> historically, it was made for other kernel, and that there is no
> tranformation of the linux kernel that resulted in that something. There
> *is* at least one example in the tree: the ppp code is derivative from
> one of the BSDs.

Some of the filesystems (XFS and JFS, at least) have external origins,
although they must have been somewhat adapted to the Linux VFS layer.

-- 
Måns Rullgård
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

2005-03-14 Thread Kuno Woudt

On Sun, Mar 13, 2005 at 03:30:28PM +0100, Måns Rullgård wrote:
> Arnoud Engelfriet <[EMAIL PROTECTED]> writes:
> 
> > And probably it will also deal with running the code on a publicly
> > accessible server. 
> 
> The question is if a license based on copyright can legally place such
> restrictions on use of the program.

Some idea of how the FSF may attempt this can be seen from the Affero
General Public License. Apparantly the Affero GPL is a modified version
of the GNU GPL, it adds Section 2(d):

  * d) If the Program as you received it is intended to interact with
  users through a computer network and if, in the version you received,
  any user interacting with the Program was given the opportunity to
  request transmission to that user of the Program's complete source
  code, you must not remove that facility from your modified version of
  the Program or work based on the Program, and must offer an
  equivalent opportunity for all users interacting with your Program
  through a computer network to request immediate transmission by HTTP
  of the complete source code of your modified version or other
  derivative work.

It also adds an "interesting" twist on the "or later" thing often used
with the GPLv2:

  Affero Inc. may publish revised and/or new versions of the Affero
  General Public License from time to time. Such new versions will be
  similar in spirit to the present version, but may differ in detail to
  address new problems or concerns.

  Each version is given a distinguishing version number. If the Program
  specifies a version number of this License which applies to it and "any
  later version", you have the option of following the terms and
  conditions either of that version or of any later version published by
  Affero, Inc. If the Program does not specify a version number of this
  License, you may choose any version ever published by Affero, Inc.

  You may also choose to redistribute modified versions of this program
  under any version of the Free Software Foundation's GNU General Public
  License version 3 or higher, so long as that version of the GNU GPL
  includes terms and conditions substantially equivalent to those of this
  license.

So, if you wish to use the AGPL, you as copyright holder can choose 
between AGPLv1 and AGPLv1 or later.  But whichever you choose, you 
cannot remove the option to 'upgrade' to GNU GPLv3.

-- Kuno.
   (ps. this is probably my first post to this list, so.. hi! everyone :).

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2