subject:"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

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

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 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#

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 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 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

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

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

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

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 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 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 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-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-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-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 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 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 MakholmI, 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 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 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: 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: Linux and GPLv2

2005-03-23 Thread Humberto Massa

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: Linux and GPLv2

2005-03-23 Thread Humberto Massa

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

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

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]

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

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]

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 Humberto Massa

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

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

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 Matthew Palmer

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 Matthew Palmer

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

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-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 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 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-14 Thread Humberto Massa

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.
So, you could take ppp and distribute under the BSD but not a lot else.
HTH,
Massa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Linux and GPLv2

Glenn Maynard [EMAIL PROTECTED] writes:

 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

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.

-- 
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

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

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

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

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 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 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 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

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 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

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...  grin

- Matt


signature.asc
Description: Digital signature

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 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 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 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 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]

Linux and GPLv2

Hello,

My understanding is that Linux is distributed under the GPLv2 exclusively. That 
is, instead of the usual GPL version 2 or later it just says GPL version 2.

Given the vast number of Linux contributors, this means that Linux won't be 
able to migrate to the GPLv3 when it comes out, correct?

Cheers,
-- 
Daniel Carrera  | I don't want it perfect,
Join OOoAuthors today!  | I want it Tuesday.
http://oooauthors.org   | 


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

Re: Linux and GPLv2

Daniel Carrera [EMAIL PROTECTED] writes:

 Hello,

 My understanding is that Linux is distributed under the GPLv2
 exclusively. That is, instead of the usual GPL version 2 or later it
 just says GPL version 2.

That's what it says, yes.  People occasionally question the validity
of that, though, arguing that the statement was added after many
people had already made contributions.

 Given the vast number of Linux contributors, this means that Linux
 won't be able to migrate to the GPLv3 when it comes out, correct?

That would be the case.  Is this a problem?

Personally, I'd be very sceptical about releasing code under a license
containing a blanket permission to use it under another yet to be
written license.  What if I don't at all agree with GPLv3?

-- 
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-13 Thread Matthew Palmer

On Sun, Mar 13, 2005 at 02:09:10PM +0100, M?ns Rullg?rd wrote:
 Daniel Carrera [EMAIL PROTECTED] writes:
  Given the vast number of Linux contributors, this means that Linux
  won't be able to migrate to the GPLv3 when it comes out, correct?
 
 That would be the case.  Is this a problem?
 
 Personally, I'd be very sceptical about releasing code under a license
 containing a blanket permission to use it under another yet to be
 written license.  What if I don't at all agree with GPLv3?

The theory goes, apparently, that if you don't like the GPLv3 you can simply
remove the 'or later' from all copies you distribute, and you're effectively
exercising your granted right under version 2 or, at your option, any later
version.

I'm a little skeptical about how well this is or isn't going to work.  I
fear a lot of unpleasant forking action when the GPLv3 comes out, if it
contains significant language changes along the lines of the GFDL (which I
believe it will, from statements I've read from RMS and Hasn Reiser, amongst
others), between people who decide to go v2 only and those who like v3 and
will go v2 or later or even v3 or later, which will effectively produce
licence-incompatible forks.

- Matt


signature.asc
Description: Digital signature

Re: Linux and GPLv2

Måns Rullgård wrote:

  Given the vast number of Linux contributors, this means that Linux
  won't be able to migrate to the GPLv3 when it comes out, correct?
 
 That would be the case.  Is this a problem?

For a large colaborative project, possibly. Using only the GPLv2 means you are 
trapped in that license. Having an or later allows some measure of 
adaptability. Suppose that there is a good reason why the GPLv2 needs to be 
updated (e.g. to deal with software patents). Then you would like to have the 
choice of moving to the GPLv3 if you want.

 What if I don't at all agree with GPLv3?

Well, then it means you gave people more freedoms than you intended. You can 
still make a GPLv2 fork and make all subsequent releases GPLv2 only.

The point is, the or later gives you more flexibility and choice. I think 
it's a prudent precaution.

Cheers,
-- 
Daniel Carrera  | I don't want it perfect,
Join OOoAuthors today!  | I want it Tuesday.
http://oooauthors.org   |

Re: Linux and GPLv2

M?ns Rullg?rd wrote:
 Daniel Carrera [EMAIL PROTECTED] writes:
  My understanding is that Linux is distributed under the GPLv2
  exclusively. That is, instead of the usual GPL version 2 or later it
  just says GPL version 2.
 
 That's what it says, yes.  People occasionally question the validity
 of that, though, arguing that the statement was added after many
 people had already made contributions.

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

-- 
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

Arnoud Engelfriet wrote:

 I'm interested in why you think it's not.

Wow, hey. I was just asking a question. I didn't know there was an issue here. 
I certainly haven't thought about it half as much as you have.

Cheers,
-- 
Daniel Carrera  | I don't want it perfect,
Join OOoAuthors today!  | I want it Tuesday.
http://oooauthors.org   | 


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

Re: Linux and GPLv2

2005-03-13 Thread Matthew Palmer

On Sun, Mar 13, 2005 at 08:31:38AM -0500, Daniel Carrera wrote:
 Henning Makholm wrote:
 
  Yes, probably. (Which, if the signals we've been getting from FSF the
  last few years are to be trusted, does not strike me as a bad thing at
  all).
 
 This issue is new to me. What are those signals? What are you talking about? 
 Do 
 you have a URL that might help me get up to speed?

I'm too tired to dig up the exact reference, but in a large heated
discussion between Hans Reiser and many other people on d-devel last year
(or maybe the year before) about removing or obscuring credits in
mkreiserfs, Hans Reiser stated that he had information from RMS that there
would be some sort of invariant section-like clause in GPLv3.

Earlier than that, in a thread here on d-legal regarding the GFDL, RMS
himself made a few sideways comments regarding the content of the GPLv3.

More generally, the direction that the FSF appears to have been moving in
the last few years has, in some peoples' eyes, been diverging somewhat from
the Debianistic view of freedom.

- Matt


signature.asc
Description: Digital signature

Re: Linux and GPLv2

Daniel Carrera [EMAIL PROTECTED] writes:

 Måns Rullgård wrote:

  Given the vast number of Linux contributors, this means that Linux
  won't be able to migrate to the GPLv3 when it comes out, correct?
 
 That would be the case.  Is this a problem?

 For a large colaborative project, possibly. Using only the GPLv2
 means you are trapped in that license. Having an or later allows
 some measure of adaptability. Suppose that there is a good reason
 why the GPLv2 needs to be updated (e.g. to deal with software
 patents). Then you would like to have the choice of moving to the
 GPLv3 if you want.

We have to consider the possibility that GPLv3 will say something we
don not want.  Then we do not want people distributing it under those
terms.  Never give permission to do something you do not know what it
is.

 What if I don't at all agree with GPLv3?

 Well, then it means you gave people more freedoms than you
 intended. You can still make a GPLv2 fork and make all subsequent
 releases GPLv2 only.

Only if all the copyright holders agree.  Suppose A has accepted
contributions from B, with the or later option, and it turns out
that A does not approve of v3.  Now B refuses to drop this, so A is
effectively forced to distribute his code under a license he does not
approve of.

 The point is, the or later gives you more flexibility and
 choice. I think it's a prudent precaution.

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.

I'd be very cautious about placing my code at the hands of a third
party in such a manner, and I think it is unfortunate that so many
authors release code under the GPL (with or later option), without
properly considering the implications.

-- 
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

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.

-- 
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

Måns Rullgård wrote:

  Well, then it means you gave people more freedoms than you
  intended. You can still make a GPLv2 fork and make all subsequent
  releases GPLv2 only.
 
 Only if all the copyright holders agree.  Suppose A has accepted
 contributions from B, with the or later option, and it turns out
 that A does not approve of v3.  Now B refuses to drop this, so A is
 effectively forced to distribute his code under a license he does not
 approve of.

No, if you get code as GPLv2 or later, you can pick either GPLv2 or pick 
something later. In your example, A can say I pick GPLv2 and make a GPLv2 
fork. It's like dual licensing. At least, that's what the Debian FAQ says :-)

 I'd be very cautious about placing my code at the hands of a third
 party in such a manner, and I think it is unfortunate that so many
 authors release code under the GPL (with or later option), without
 properly considering the implications.

I guess it comes down to whether those copyright holders trust the FSF to not 
totally screw it up. I'd think they would have to do something really bad with 
the GPLv3 for this to be a problem.

Consider an extreme case. Suppose GPLv3 is non-free, propietary.

That means that your GPLv2 or later work is now dual licensed: 
GPLv2/proprietary

But that is still free. It's like MySQL for example (GPL/proprietary).
As long as the GPLv2 is an option, the work is free.

Or am I just confused?

Cheers,
-- 
Daniel Carrera  | I don't want it perfect,
Join OOoAuthors today!  | I want it Tuesday.
http://oooauthors.org   |

Re: Linux and GPLv2

Daniel Carrera [EMAIL PROTECTED] writes:

 Måns Rullgård wrote:

  Well, then it means you gave people more freedoms than you
  intended. You can still make a GPLv2 fork and make all subsequent
  releases GPLv2 only.
 
 Only if all the copyright holders agree.  Suppose A has accepted
 contributions from B, with the or later option, and it turns out
 that A does not approve of v3.  Now B refuses to drop this, so A is
 effectively forced to distribute his code under a license he does not
 approve of.

 No, if you get code as GPLv2 or later, you can pick either GPLv2
 or pick something later. In your example, A can say I pick GPLv2
 and make a GPLv2 fork. It's like dual licensing. At least, that's
 what the Debian FAQ says :-)

You're probably right, but I still don't like the look of it.

 I'd be very cautious about placing my code at the hands of a third
 party in such a manner, and I think it is unfortunate that so many
 authors release code under the GPL (with or later option), without
 properly considering the implications.

 I guess it comes down to whether those copyright holders trust the
 FSF to not totally screw it up. I'd think they would have to do
 something really bad with the GPLv3 for this to be a problem.

Take a look out there.  Freshmeat.net lists approximately 2
projects using the GPL.  How many of these authors do you think have
thoroughly read and understood the GPL?  I've seen several cases where
the GPL has been chosen for no reason in particular, other than it's
the most popular free software license, or similar.  I do not claim
to understand it myself either, far from it, which is one reason I do
not use it for my own work.

 Consider an extreme case. Suppose GPLv3 is non-free, propietary.

 That means that your GPLv2 or later work is now dual licensed: 
 GPLv2/proprietary

 But that is still free. It's like MySQL for example (GPL/proprietary).
 As long as the GPLv2 is an option, the work is free.

You are seeing it from the licensee's point of view.  There, there
will indeed be little difference after the introduction of a GPLv3.
From the licensors point of view, it is quite different.  Suppose the
GPLv3 relaxed the requirements to more resemble the BSD license.  This
would suddenly allow someone to take your (already released) code, and
incorporate it in a proprietary program.  Many have chosen the GPL for
the precise reason that it disallows this.

Consider next a (more likely) stricter GPLv3, with restrictions on use
as well as distribution (e.g. running a public server, as has been
mentioned (and debated at length)).  It may have been the author's
intent to allow unrestricted use of his program by anyone, and he may
wish that programs based on his give the users the same rights.  With
this version of the GPLv3, it could also be used against the authors'
will.

If, one might argue, the author wishes for the terms to remain those
of the GPLv2, why does he not remove the or any later version
option?  The answer is simple.  Such a license is not compatible with
the standard GPL (with the upgrade option), since it has further
restrictions, compared to the version allowing a switch to a later
version.  One common reason to use the GPL in the first place, is
precisely to be compatible with other GPL licensed software.  Remember
that few (none?) copyleft licenses are compatible with the GPL, be it
by design or by chance.

Placing your code under the GPL, is placing a large faith in the FSF
not to change the license terms in a manner you might disagree with, a
faith which in many case may be broken, should some of the rumored
clauses end up in the final GPLv3 text.

-- 
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-13 Thread Francesco Poli

On Sun, 13 Mar 2005 09:31:51 -0500 Daniel Carrera wrote:

 Måns Rullgård wrote:
 
   Well, then it means you gave people more freedoms than you
   intended. You can still make a GPLv2 fork and make all subsequent
   releases GPLv2 only.
  
  Only if all the copyright holders agree.  Suppose A has accepted
  contributions from B, with the or later option, and it turns out
  that A does not approve of v3.  Now B refuses to drop this, so A is
  effectively forced to distribute his code under a license he does
  not approve of.
 
 No, if you get code as GPLv2 or later, you can pick either GPLv2 or
 pick something later. In your example, A can say I pick GPLv2 and
 make a GPLv2 fork. It's like dual licensing. At least, that's what the
 Debian FAQ says :-)

It seems to me that you are right.
I can accept contributions under GPLv2 or later and then decide I want
to accept them under GPLv2 only: once I begin to release new versions
(or forks...) under GPLv2 only no one (apart from the totality of the
copyright holders!) can revert back to GPLv2 or later or switch to
GPLv3.

But... there is a but.
See below!

 
  I'd be very cautious about placing my code at the hands of a third
  party in such a manner, and I think it is unfortunate that so many
  authors release code under the GPL (with or later option), without
  properly considering the implications.
 
 I guess it comes down to whether those copyright holders trust the FSF
 to not totally screw it up. I'd think they would have to do something
 really bad with the GPLv3 for this to be a problem.

Well, I learned the trust no 1 rule the hard way, by following the
unfortunate GFDL affair...  :-(
[That is to say: I used to trust the FSF to always write and promote
Free and good licenses, but then I learned about the issues with the
GFDL and changed my mind...]

 
 Consider an extreme case. Suppose GPLv3 is non-free, propietary.
 
 That means that your GPLv2 or later work is now dual licensed: 
 GPLv2/proprietary
 
 But that is still free. It's like MySQL for example (GPL/proprietary).
 As long as the GPLv2 is an option, the work is free.

Proprietary means less freedoms to the public, more rights reserved for
the copyright holders.
So that would not be an issue, as long as the public can still choose to
redistribute and/or modify the work under the GPLv2.

Pains could instead arise, in the opposite case (that is if GPLv3 is
*more* permissive than GPLv2).

Suppose GPLv3 is a non-copyleft license (let's say GPLv3 becomes
equivalent to 2-clause BSD).
I really doubt FSF would do such a move, but let's assume it does for
the sake of example simplicity.
Maybe you chose the GPLv2 or later because you *want* copyleft and do
not want anyone be permitted to proprietarize your work: bang! they pick
GPLv3 and create a proprietary derivative work!
You cannot prevent this for already released versions, only for future
ones (by switching to GPLv2 only)...  :-(

Now a more concrete example.
Suppose GPLv3 allows something similar to GFDL Invariant Sections to
be included in the work.
Maybe you chose the GPLv2 or later because you believe that a Free
work should *not* include unmodifiable and unremovable parts: bang! they
pick GPLv3 and create a non-free derivative work containing some such
parts!
You cannot prevent this for already released versions, and, if you want
to incorporate some useful modifications from that derivative work back
to your official version, you cannot, unless you switch to GPLv3
or later *and* include the Invariant Sections (that you will never be
able to drop!).   :-(


To conclude, IMHO, it's a matter of trust.
Release under GPLv2 or later if you trust the FSF to never screw
things up with future GPL versions.
Release under GPLv2 only if you don't.

Of course, this is valid as long as you like GPLv2: if you don't, choose
another license (but, please, choose a DFSG-free and possibly
GPL-compatible one!).  ;-)

-- 
  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


pgpNTmud0ht6Q.pgp
Description: PGP signature

Re: Linux and GPLv2

2005-03-13 Thread Francesco Poli

On Sun, 13 Mar 2005 14:33:36 +0100 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.

Indeed.

There are parts under
 * GPLv2 only
 * GPLv2 or later
 * other GPLv2-compatible licenses (such as, if I recall correctly,
 3-clause BSD, X11, ...)
As a consequence, Linux (as a whole) is under GPLv2 only.

-- 
  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


pgpbzxK7Xa3fG.pgp
Description: PGP signature

Re: Linux and GPLv2

2005-03-13 Thread Francesco Poli

On Sun, 13 Mar 2005 16:50:39 +0100 Måns Rullgård wrote:

 If, one might argue, the author wishes for the terms to remain those
 of the GPLv2, why does he not remove the or any later version
 option?  The answer is simple.  Such a license is not compatible with
 the standard GPL (with the upgrade option), since it has further
 restrictions, compared to the version allowing a switch to a later
 version. 

I don't think so.
GPLv2 only is compatible with GPLv2 or later.

You can take work W_1 under GPLv2 only and work W_2 under GPLv2 or
later, combine them into derivative work W_d and distribute W_d under
GPLv2 only.
You received W_2 under GPLv2 or GPLv3 or ... at your option and you
simply chose GPLv2 (rather than all of them!); then you combined two
GPLv2-licensed works into one derivative and complied with both
instances of GPLv2, by releasing W_d source code under the GPLv2 itself,
not adding further restrictions, and so forth...

-- 
  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


pgpAOVWedSGsI.pgp
Description: PGP signature

Re: Linux and GPLv2

Francesco Poli [EMAIL PROTECTED] writes:

 On Sun, 13 Mar 2005 16:50:39 +0100 Måns Rullgård wrote:

 If, one might argue, the author wishes for the terms to remain those
 of the GPLv2, why does he not remove the or any later version
 option?  The answer is simple.  Such a license is not compatible with
 the standard GPL (with the upgrade option), since it has further
 restrictions, compared to the version allowing a switch to a later
 version. 

 I don't think so.
 GPLv2 only is compatible with GPLv2 or later.

 You can take work W_1 under GPLv2 only and work W_2 under GPLv2 or
 later, combine them into derivative work W_d and distribute W_d under
 GPLv2 only.
 You received W_2 under GPLv2 or GPLv3 or ... at your option and you
 simply chose GPLv2 (rather than all of them!); then you combined two
 GPLv2-licensed works into one derivative and complied with both
 instances of GPLv2, by releasing W_d source code under the GPLv2 itself,
 not adding further restrictions, and so forth...

On second thoughts, you seem to be right, fortunately.  The no
further restrictions must be as compared to the actual license text
(the COPYING file), not the note at the top of the source files.

-- 
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-13 Thread Andrew Saunders

On Mon, 14 Mar 2005 00:38:21 +1100, Matthew Palmer [EMAIL PROTECTED] wrote:

 I'm too tired to dig up the exact reference, but in a large heated
 discussion between Hans Reiser and many other people on d-devel last year
 (or maybe the year before) about removing or obscuring credits in
 mkreiserfs, Hans Reiser stated that he had information from RMS that there
 would be some sort of invariant section-like clause in GPLv3.

FWIW, RMS later posted to the list[1] stating that Hans was mistaken:

Reiser's statement was inaccurate. For GPL version 3 we are
considering requirements for preserving certain limited author
information in the source code, and making explicit that other
GPL-compatible licenses that are present on parts of the code cannot
be removed from the source, but nothing beyond that.

[1] http://lists.debian.org/debian-legal/2003/06/msg00173.html

-- 
Andrew Saunders


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

Re: Linux and GPLv2

M?ns Rullg?rd wrote:
 If, one might argue, the author wishes for the terms to remain those
 of the GPLv2, why does he not remove the or any later version
 option?  The answer is simple.  Such a license is not compatible with
 the standard GPL (with the upgrade option), since it has further
 restrictions, compared to the version allowing a switch to a later
 version.

The GPLv2 does not have an upgrade option. 

Authors may decide to offer a kind of dual license: one is GPLv2,
another is any later version of the GPL as published by the FSF.

I really don't see how I am imposing any further restrictions on
the rights granted by the GPLv2 by not offering a dual license
under a future GPLv3.

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

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.

I've heard people speculate that this could be called a
public performance of the work, like singing a song in front
of an audience. And the right of public performance is in
copyright law.

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

Arnoud Engelfriet [EMAIL PROTECTED] writes:

 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.

 I've heard people speculate that this could be called a
 public performance of the work, like singing a song in front
 of an audience. And the right of public performance is in
 copyright law.

I don't think this a very good analogy.  This is like saying that by
playing the guitar with an audience, I am publicly performing the book
I used when I learned how to play.  When performing a song, the actual
song, albeit somewhat altered, is what reaches the audience.  When
serving web pages, no information from the server software reaches the
clients.

Anyhow, this has been discussed at length here not long ago, so there
is no need to do it over again.

-- 
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-13 Thread Sean Kellogg

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.

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.

-Sean

p.s. For those waiting for my comments on treble damages and patent 
infringement, it is coming, I assure you...  unfortunately finals have reared 
their ugly head and I haven't had time to write something of reasonable 
quality on the subject.

-- 
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-13 Thread Jeremy Hankins

Mns Rullgrd [EMAIL PROTECTED] writes:

 If, one might argue, the author wishes for the terms to remain those
 of the GPLv2, why does he not remove the or any later version
 option?  The answer is simple.  Such a license is not compatible with
 the standard GPL (with the upgrade option), since it has further
 restrictions, compared to the version allowing a switch to a later
 version.

That's not my understanding.  The GPLv2  GPLv2 are logically distinct
licenses, one can simply decide to drop the or any later version in
code you distribute based on code with that clause.  The no extra
restrictions bit refers to the GPLv2 *or* the GPLv3 -- not both
together.

Of course, if someone contributes modifications under only GPLv3 (for
example) you then have to make a choice about accepting that code, or
retaining the GPLv2 license.  But that's not a new problem.

 One common reason to use the GPL in the first place, is
 precisely to be compatible with other GPL licensed software.  Remember
 that few (none?) copyleft licenses are compatible with the GPL, be it
 by design or by chance.

This is less a characteristic of the GPL in particular than of licensing
in general.

 Placing your code under the GPL, is placing a large faith in the FSF
 not to change the license terms in a manner you might disagree with, a
 faith which in many case may be broken, should some of the rumored
 clauses end up in the final GPLv3 text.

True, and given some of the rumors I'm rather skeptical about the
freeness of the GPLv3 to be.  But all in all I don't think the risks are
that great of using the or any later version language.  Worst case
scenario is that folks discover they've given more permissions than they
meant to.

But as for folks understanding better how they're licensing their
software, I couldn't agree more.

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

Re: Linux and GPLv2

2005-03-13 Thread Josselin Mouette

Le dimanche 13 mars 2005  14:09 +0100, Mns Rullgrd a crit :
 Personally, I'd be very sceptical about releasing code under a license
 containing a blanket permission to use it under another yet to be
 written license.  What if I don't at all agree with GPLv3?

Given that the FSF has already written and recommended blatantly
non-free licenses, I generally my software under the GPL v2 only.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Linux and GPLv2

M?ns Rullg?rd wrote:
 Arnoud Engelfriet [EMAIL PROTECTED] writes:
  I've heard people speculate that this could be called a
  public performance of the work, like singing a song in front
  of an audience. And the right of public performance is in
  copyright law.
 
 I don't think this a very good analogy.  This is like saying that by
 playing the guitar with an audience, I am publicly performing the book
 I used when I learned how to play.

You're publicly performing the work on the sheet music in front 
of you. So under this hypothetical GPLv3, you have to hand out 
copies of the sheet music. At least that was my analogy.

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

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.

In this case, terms that have not even been written yet, and over
which the someone has no influence whatsoever.

 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.

I'd go as far as to call it outright stupid to release something under
terms yet to be decided by a third party, legal or not.

 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.

Well, there are a few that dislike v2 already, or at least some of the
more far-reaching interpretations of it.  Seeing as v3 will attempt to
extend its reach even further, I see it as inevitable that a fair
amount of people will have a word or two to say about 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

Josselin Mouette [EMAIL PROTECTED] writes:

 Le dimanche 13 mars 2005 à 14:09 +0100, Måns Rullgård a écrit :
 Personally, I'd be very sceptical about releasing code under a license
 containing a blanket permission to use it under another yet to be
 written license.  What if I don't at all agree with GPLv3?

 Given that the FSF has already written and recommended blatantly
 non-free licenses, I generally my software under the GPL v2 only.
 -- 
  .''`.   Josselin Mouette/\./\
 : :' :   [EMAIL PROTECTED]
 `. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

-- 
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-13 Thread Sean Kellogg

On Sunday 13 March 2005 01:21 pm, Måns Rullgård wrote:
 Well, there are a few that dislike v2 already, or at least some of the
 more far-reaching interpretations of it.  Seeing as v3 will attempt to
 extend its reach even further, I see it as inevitable that a fair
 amount of people will have a word or two to say about it.

Well, if you don't like the interpretation of what v2 says then take it to 
court.  No one holds a monopoly on the right to decide what it says, and only 
the court reviewing the GPL can determine what its terms actually mean, and 
only within the jurisdiction in which it sits.

Of course, you may not end up liking what the judge says :)

Its actually quite a shame that there haven't been any court cases on the 
terms of the GPL...  would make for some fascinating reading.

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

-- 
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

Josselin Mouette [EMAIL PROTECTED] writes:

 Le dimanche 13 mars 2005 à 14:09 +0100, Måns Rullgård a écrit :
 Personally, I'd be very sceptical about releasing code under a license
 containing a blanket permission to use it under another yet to be
 written license.  What if I don't at all agree with GPLv3?

 Given that the FSF has already written and recommended blatantly
 non-free licenses, I generally my software under the GPL v2 only.

I usually use the MIT/X11/BSD license.  I can see some situations
where I might have preferred a copyleft license.  However, the BSD
license is simple enough that I can understand it (I think), and I
don't need to worry about which libraries I link with, as long as I
don't distribute binaries (which is far too cumbersome anyway).

PS. Sorry for the blank mail.  I slipped on the send button.

-- 
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