conducting a sane and efficient GPLv3, LGPLv3 Review

[Luis Villa-3]

[Warning: possible tilting at windmills ahead.]

On 7/31/07, Wilson, Andrew <andrew.wilson@...> wrote:
> Once you understand this, you see the compatibility problem.

I'd suggest that compatibility, while admittedly a pragmatic problem
and something we could discuss for many, many hours and many, many
words, is really not very useful for an OSI analysis of the v3:

* The v3 is already more widely adopted than some other OSI-approved,
but v2-incompatible licenses, so if a license is to be rejected on
proliferation grounds merely because it is incompatible, another
license should be retired instead.

* The OSI (to the best of my knowledge) does not maintain a formal
compatibility database, so a compatibility analysis does not help with
that.

More generally, I'd suggest that this discussion should focus very,
very strictly on whether or not the v3 is OSD-compatible; other issues
are either obviously resolved or otherwise not relevant:

* OSI typically wants to know if the existence of a new license is
justified; I'd suggest that the extensive review process and very
quick adoption of the license indicates very strongly that this is the
case. We could discuss endlessly whether individual members of this
list feel that the license is justified, but that would be a waste of
bits while others go ahead and use the thing.

* the license has already received the most extensive public review of
any license in history, and is finalized, so discussion of potential
flaws in the license (except inasmuch as they may impact
OSD-compatibility) are not useful. Again, time, money, and bits could
be wasted discussing non-OSD-relevant flaws (like the ACT "analysis"),
but that seems fairly pointless.

So, yeah. We could spend literally hundreds of hours discussing
compatibility, 'need', and potential license flaws, and in the process
finish driving away from license-discuss anyone of goodwill but
limited time/energy, but I'd strongly suggest that instead we limit
GPL v3 discussion to the strict question of OSD compatibility and save
each other the time and energy for other pursuits.

Luis

[Ernest Prabhakar]

Hi Luis,

On Jul 31, 2007, at 4:33 PM, Luis Villa wrote:
> More generally, I'd suggest that this discussion should focus very,
> very strictly on whether or not the v3 is OSD-compatible; other issues
> are either obviously resolved or otherwise not relevant:

Hear, hear!

Many other people are wrestling with the GPLv2/GPLv3 issue, so I  
don't see any need for OSI to poke its irons into that fire.

I'm sure OSD compatibility is plenty to keep us busy for a while. :-)

-- Ernie P.

[Jesse Hannah]

On 31 Jul 2007, at 17:00, Ernest Prabhakar wrote:

> On Jul 31, 2007, at 4:33 PM, Luis Villa wrote:
>> More generally, I'd suggest that this discussion should focus very,
>> very strictly on whether or not the v3 is OSD-compatible; other  
>> issues
>> are either obviously resolved or otherwise not relevant:
>
> Many other people are wrestling with the GPLv2/GPLv3 issue, so I don't
> see any need for OSI to poke its irons into that fire.
>
> I'm sure OSD compatibility is plenty to keep us busy for a while. :-)

That it is :) I agree with Luis completely: let's save the rest of  
the ibuprofen until AFTER it's been decided whether or not the GPLv3  
meets the Open Source Definition. The license has definitely gone  
through sufficient discussion and community review, already has  
received a very wide adoption, and it wasn't exactly written  
overnight on a whim, so one would think that its purpose is  
justified. As far as I can tell, the only question between it and the  
OSD would be over OSD number 9, and even that I don't think comes out  
to be anything that would keep it from getting approved. That's just  
at a glance, but personally I'm surprised it isn't approved already.  
(Then I look back at some of the threads on here and am reminded  
otherwise...)

Let's stay on focus, people :) I for one just want to use the darn  
thing, and arguing endlessly over compatibility &c. doesn't help the  
purpose of either the license or the OSI any. What matters at the end  
of the day is, is it open source?
--
jbh

~~~~
Jesse B Hannah
        <jesse.hannah@...>
        <jesse.hannah@...>

Homepage: <http://lifeisleet.com>
IRC Handle: <jbhannah@...>

GPG Key: 0xA6DC3EF3
        Available from the keyservers or at
        <http://files.lifeisleet.com/jesse.asc>

[Lawrence Rosen]

Luis Villa wrote:
> So, yeah. We could spend literally hundreds of hours discussing
> compatibility, 'need', and potential license flaws, and in the process
> finish driving away from license-discuss anyone of goodwill but
> limited time/energy, but I'd strongly suggest that instead we limit
> GPL v3 discussion to the strict question of OSD compatibility and save
> each other the time and energy for other pursuits.

I agree. GPLv3 is obviously OSD-compliant. Let's get right to the point. It
is an open source license, even if RMS prefers to use a different name for
it. :-)

Quite frankly, I'm more interested to see what category the license will be
placed in on the OSI list. Is it redundant? Or will OSI immediately call it
popular?

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * cell: 707-478-8932 * fax: [phone]
Skype: LawrenceRosen
Author of "Open Source Licensing: Software Freedom and
                Intellectual Property Law" (Prentice Hall 2004)

[Rick Moen]

Quoting Lawrence Rosen (lrosen@...):

> I agree. GPLv3 is obviously OSD-compliant. Let's get right to the point. It
> is an open source license, even if RMS prefers to use a different name for
> it. :-)

Indeed, I think what you say is abundantly obvious, and doing anything
else would merely waste everyone's time.

[Matthew Flaschen]

Luis Villa wrote:
> More generally, I'd suggest that this discussion should focus very,
> very strictly on whether or not the v3 is OSD-compatible; other issues
> are either obviously resolved or otherwise not relevant:

I agree.  I posted a message discussing possible OSD issues earlier
(http://www.nabble.com/Re%3A-Submitting-GPLv3-and-LGPLv3-for-OSI-inclusion.-p11367961.html).
  My conclusion is that it is OSD-compliant.

P.S. Russ, can you confirm whether or not the license has now been
properly submitted for approval?  If not, there are plenty of lawyers
here that should be more than capable of writing a legal analysis.

Matt Flaschen

[Alexander Terekhov-3]

On 8/1/07, Rick Moen <rick@...> wrote:
> Quoting Lawrence Rosen (lrosen@...):
>
> > I agree. GPLv3 is obviously OSD-compliant. Let's get right to the point. It
> > is an open source license, even if RMS prefers to use a different name for
> > it. :-)
>
> Indeed, I think what you say is abundantly obvious, and doing anything
> else would merely waste everyone's time.

Yeah, time aside, Google search yields this:

http://www.itbusinessedge.com/item/?ci=30043

---------
Question: You have said that one of the best things about the latest
draft of GPL v3 is that it allows its software to be used in
aggregations, which, as I understand it, do not trigger the requirement
that the other software must also be released under GPL v3? Can you
explain how that works?

Rosen: I'll try to do so. It really has to do with something that's in
the copyright law as well as something that's in the GPL. When you put
two works together, you can put them together in a number of different
ways. For example, you can build a collection of the greatest poems of
the 20th Century and put them together in a book. Each one of those
poems is written by its own author, has its own copyright, has its own
license terms. The publisher may or may not allow you to put that poem
in a collection of the greatest poems of the 20th Century. That's an
aggregation, and assuming that the authors of the works or the owners of
the works authorize you to put copies of the works into a collection
such as "Greatest Poems of the 20th Century," then you're allowed to do
that.

<sidebar>

Rather than trying to prevent software from being used if it has
patents in it, we ought to find ways of living with the patent problem
that exists — including companies like Microsoft that have patents and
other companies that have patents. I'm not sure that the way the GPL v3
tries to deal with patents is actually going to solve the problem."One
of the things about the GPL is it contains an explicit provision that
says you can make verbatim copies of GPL works and include them in
aggregations. What that means is essentially the same thing that the
copyright law means by this permission to create what is called
"collective works," or works like collections of poems. So, for example,
you can have collections of modules, collections of drivers, collections
of software that can be under various licenses. So long as those
licenses, like GPL v3, allow you to take verbatim copies and include
them in aggregations, that's fine.

</sidebar>

Question: And the new GPL now allows Apache licensed software to be used
in GPL projects, correct?

Rosen: Correct, but that's a different kind of combination, and we need
to be very careful to distinguish what I just described to you in terms
of collective works or aggregations, from the kind of combinations that
are allowed with Apache works. The thing that GPL v3 allows is that you
can take an Apache work, and modify it as the Apache License allows, in
order to fit it into and have it become a part of a GPL v3 work. For
example, you can create a GPLv3-licensed version of a Web server or any
other Apache software. You can release that software under the GPL
license because the Apache License and the GPL v3 are compatible. I
didn't say that you could do that kind of thing with other works in
aggregations. An aggregation is a little bit different. The Apache
compatibility is this ability to take Apache works and embed them into
and modify them for, evolve them into, GPL v3 works.

Question: But the same isn't true — you can't take a GPLv3 work and
embed it into Apache-licensed works, correct?

Rosen: No, you can't.... Well, again, it depends whether what you're
talking about is an aggregation or a more complicated — what I call a
derivative work. If all you're creating is an aggregation of modules,
you can combine Apache modules and GPL modules and any other modules, as
long as [the licenses] allow you to do that. And with respect to Apache
works being merged into a GPL work, that's allowed. But a GPL work being
merged into an Apache work? No. That can't be done.

Question: Why the difference?

Rosen: The difference is that the GPL license says — both v2 and v3 —
that if you create a derivative work, that derivative work must be
licensed under the GPL. So if I take an Apache work and mush it together
with a GPL work, the resulting work has to be GPL.

Question: Similarly, you've said that your least favorite terms in the
new GPL are the ones that deal with patent protection. The Free Software
Foundation, from what we've read, has been pretty clear that was
included in the new GPL specifically to prevent agreements like the one
between Microsoft and Novell from happening again. Why do you think they
took that particular approach, and what in your opinion, would be a
better approach to dealing with those issues?

Rosen: Well, it's a very complicated question. I think certainly the
authors of the GPL can specify any rules that they want with respect to
their software. If they don't like their software to be combined with
software that other people produce or with patents that other people
have, they're certainly free to do so.

My concern is that the software world is being inhibited by software
patents. Rather than trying to prevent software from being used if it
has patents in it, we ought to find ways of living with the patent
problem that exists — including companies like Microsoft that have
patents and other companies that have patents. I'm not sure that the way
the GPL v3 tries to deal with patents is actually going to solve the
problem.
---------

http://blogs.zdnet.com/Burnette/?p=331
(GPLv3 myth#2: You can't mix GPL software with other software)

---------
In his "Comments on GPLv3" essay, open source attorney Lawrence Rosen
writes that he believes this clause can even be used to combine GPL
licensed code "modules" with code from other licenses even in the same
program, though I think that's a bit of a stretch. When I told Larry
that he responded:

Stretch away. If you mean the term "module" is a "smallest unit of
compiled object code," then perhaps it is not copyrightable at all.
But in the general sense I meant that word as applied to larger,
commercially and computationally significant copyrightable works, such
as "a database module" or a "file system module," that contain
significant copyrightable expressive content. If those
independently-written copyrighted modules are used in a collective
work (a larger computer system), and both licenses permit verbatim
copies to be aggregated in that way, then I consider that a permitted
collective work. There is nothing derivative about it (unless,
perhaps, the resulting larger work is intended as a replacement
database or file system module for the originals, but that's a factual
issue relating to derivative works analysis).

I don't agree with this argument because the combination would be
possible not just with Apache licensed code, but with code covered by
any license, even proprietary, closed source code. I don't think RMS
(Richard Stallman) would agree either. To this, Larry replied:

He doesn't. But he wrote GPLv3 and he must now live by the words in his license.
---------

http://www.gnu.org/licenses/gpl3-final-rationale.pdf

---------
We have added these words to the aggregation clause to eliminate any
question that GPLv3 alters the scope of the copyleft as understood and
applied under GPLv2. In GPLv3, as in GPLv2, addition of modules or
other parts to a program results in a new program based on the old
program, with different functional characteristics created by the
merger of two expressions: the original program and the added parts.
Such added parts are "by their nature extensions of" the old program,
and therefore the entire new program which they and the old program
form must be licensed under the GPL. As subsection 5c states,
packaging of a work has no bearing on the scope of copyleft.
---------

Is there any followup to this exciting development of Rosen-vs-GNU wisdom? :-)

regards,
alexander.

[Rick Moen]

Quoting Alexander Terekhov (alexander.terekhov@...):
> On 8/1/07, Rick Moen <rick@...> wrote:

> > Indeed, I think what you say is abundantly obvious, and doing
> > anything else would merely waste everyone's time.
>
> Yeah, time aside, Google search yields this:

[snip 150 further lines of some series of rambles about patents,
collective works, and licence compatibility.]

No, actually, we're _not_ likely to set aside considerations of avoiding
time wasteage -- but thank you for the graphical reminder of why.

Is there even the faintest chance that you have a coherent point, and
that it might cast even the _dimmest_ light on OSD-compliance?  Or is
this all just some outrévariant of performance art?

--
Cheers,           find / -user your -name base -print | xargs chown us:us
Rick Moen
rick@...

[Alexander Terekhov-3]

On 8/1/07, Rick Moen <rick@...> wrote:

> Quoting Alexander Terekhov (alexander.terekhov@...):
> > On 8/1/07, Rick Moen <rick@...> wrote:
>
> > > Indeed, I think what you say is abundantly obvious, and doing
> > > anything else would merely waste everyone's time.
> >
> > Yeah, time aside, Google search yields this:
>
> [snip 150 further lines of some series of rambles about patents,
> collective works, and licence compatibility.]
>
> No, actually, we're _not_ likely to set aside considerations of avoiding
> time wasteage -- but thank you for the graphical reminder of why.

Speak for yourself, wannabe mafioso.

>
> Is there even the faintest chance that you have a coherent point, and
> that it might cast even the _dimmest_ light on OSD-compliance?  Or is
> this all just some outrévariant of performance art?

Reread it. And visit also

http://www.usfca.edu/law/determann/softwarecombinations060403.pdf

Hth.

regards,
alexander.

[Rick Moen]

Quoting Alexander Terekhov (alexander.terekhov@...):

> Speak for yourself, wannabe mafioso.

Oddly enough, I do indeed speak for myself, my domain, and my killfile.

--
Cheers,                                      "Reality is not optional."
Rick Moen                                             -- Thomas Sowell
rick@...

[Wilson, Andrew-2]

 
Staying strictly on-topic here, I believe that the final GPL/LGPLv3
both meet the OSD.  Earlier drafts did not because of the prohibition
against applying GPLv3 to implementations of DRM or to any SW which
could
be used to violate a user's privacy.  Whatever FSF intended to
accomplish with these provisions, they did discriminate against entire
classes
of applications; however, they are now gone.

You could argue that the requirement to provide "installation
information"
and to make covered code user-replaceable in a consumer product
discriminates against the class of applications which, by government
regulation,
cannot be modified on a device by end users.  Poster child: modifying SW
to exceed
the maximum allowed transmit power in a radio.  However, FSF could then
point to the "ROM exception," which artfully allows GPL/LGPLv3 to
be applied to such applications if they are embodied in ROM and
neither the end user nor the manufacturer or service provider has
technical means to modify code in the device.  So, the "installation
information" provision tests the boundaries of OSD but (IMO) does
not cross them.  I personally believe these licenses should be approved
by OSI.

[now veering slightly off topic]
There is the written OSD, and the so far uncodified, anti-license
proliferation agenda which OSI has nonetheless pursued for the last
several
years.  OSI has pursued this agenda because subdividing the world of
free/open source software along the lines of incompatible variant
licenses
amounts to fencing off the commons.  Compatibility matters, because
incompatibility dilutes the basic power of the free/open source concept
and its ability to create a software commons.

If we learn nothing else from the recent exchange between John
and myself, we learn that compatibility between GPL/LGPLv3 and previous
versions contains several areas which are unclear at best, and where
long-time active contributors to this list can draw sharply differing
conclusions.  As noted above, I think it's proper for the OSI board
to approve the licenses, but it would also be proper for OSI to request
that FSF, as GPL license stewards (a) provide more clarity on
compatibility
guidelines, and (b) where there is room for interpretation or
clarification,
to err on the side of interpretation or clarification
which increases rather than decreases compatibility with existing GPL
code.

Andy Wilson
Intel open source technology center

[David Woolley (E.L)]

It appears to me that everyone is attacking the wrong people.  The real
problem is that that the FSF doesn't care about getting OSI approval,
presumably because they think that the OSD is far too broad.

Maybe if someone were to send them a substantial donation conditional on
their getting OSD approval, they might change their mind!  I'm not
volunteering.
--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[John Cowan]

Alexander Terekhov scripsit:

> Is there any followup to this exciting development of Rosen-vs-GNU
> wisdom? :-)

Just that the disagreement between Larry and most other people is of
long standing and unlikely to go away, but has hitherto been of little
practical effect.  My own view (IANAL), is that Larry is probably right
on the letter of the law, but that community practice counts for a lot
too, even in court (judges have been known to look to the way the
relevant community traditionally interpreted standard contracts, e.g.).

It may or may not be legal to create combined works with GPLed and
proprietary parts, but it is definitely tacky and you shouldn't do it.

--
John Cowan  cowan@...  http://ccil.org/~cowan
The competent programmer is fully aware of the strictly limited size of his own
skull; therefore he approaches the programming task in full humility, and among
other things he avoids clever tricks like the plague.  --Edsger Dijkstra

[John Cowan]

David Woolley scripsit:

> It appears to me that everyone is attacking the wrong people.  The real
> problem is that that the FSF doesn't care about getting OSI approval,

True.

> presumably because they think that the OSD is far too broad.

Not much evidence for that.  Very few licenses have been OSI-approved
without being FSF-free as well (I can only think of the obsolete
APSL 1.1 and the Artistic License, which the FSF quite justifiably
thinks is too vague to be FSF-free).

The FSF's disagreement with the OSI is well expressed by RMS
at http://www.gnu.org/philosophy/free-software-for-freedom.html .
He does say the OSI definitions are looser, but doesn't offer any
analysis.

In any case, debian-legal is far more restrictive of what counts as
a free license than either the OSI or the FSF, and they use essentially
the same definitions as the OSI, another bit of evidence that it's
community interpretations that count most, day to day.

--
If you understand,                      John Cowan
   things are just as they are;         http://www.ccil.org/~cowan
if you do not understand,               cowan@...
   things are just as they are.

[David A. Temeles, Jr.]

FWIW, I and many of my colleagues in IP law think Rosen is incorrect  
on a number of key points.  However, given that the language of the  
GPL is clear as mud, there is plenty of room for reasonable minds to  
differ on how it should/will be applied to any given set of facts.  In  
the end. the only opinion that will matter in any given case is that  
of the judge who hears the case (or the appeal).

What Quoting John Cowan <cowan@...>:

> Alexander Terekhov scripsit:
>
>> Is there any followup to this exciting development of Rosen-vs-GNU
>> wisdom? :-)
>
> Just that the disagreement between Larry and most other people is of
> long standing and unlikely to go away, but has hitherto been of little
> practical effect.  My own view (IANAL), is that Larry is probably right
> on the letter of the law, but that community practice counts for a lot
> too, even in court (judges have been known to look to the way the
> relevant community traditionally interpreted standard contracts, e.g.).
>
> It may or may not be legal to create combined works with GPLed and
> proprietary parts, but it is definitely tacky and you shouldn't do it.
>
> --
> John Cowan  cowan@...  http://ccil.org/~cowan
> The competent programmer is fully aware of the strictly limited size  
>  of his own
> skull; therefore he approaches the programming task in full  
> humility, and among
> other things he avoids clever tricks like the plague.  --Edsger Dijkstra
>

[David A. Temeles, Jr.]

Ah, mea culpa - I did not mean to reference Rosen in my previous  
posting.  I meant to reference Moglen but there was a disconnect  
between my fingers and my brain.  A perfect example of why I should  
read more and post less!

Quoting dtemeles@...:

> FWIW, I and many of my colleagues in IP law think Rosen is incorrect
> on a number of key points.  However, given that the language of the
> GPL is clear as mud, there is plenty of room for reasonable minds to
> differ on how it should/will be applied to any given set of facts.  In
> the end. the only opinion that will matter in any given case is that
> of the judge who hears the case (or the appeal).
>
> What Quoting John Cowan <cowan@...>:
>
>> Alexander Terekhov scripsit:
>>
>>> Is there any followup to this exciting development of Rosen-vs-GNU
>>> wisdom? :-)
>>
>> Just that the disagreement between Larry and most other people is of
>> long standing and unlikely to go away, but has hitherto been of little
>> practical effect.  My own view (IANAL), is that Larry is probably right
>> on the letter of the law, but that community practice counts for a lot
>> too, even in court (judges have been known to look to the way the
>> relevant community traditionally interpreted standard contracts, e.g.).
>>
>> It may or may not be legal to create combined works with GPLed and
>> proprietary parts, but it is definitely tacky and you shouldn't do it.
>>
>> --
>> John Cowan  cowan@...  http://ccil.org/~cowan
>> The competent programmer is fully aware of the strictly limited  
>> size   of his own
>> skull; therefore he approaches the programming task in full    
>> humility, and among
>> other things he avoids clever tricks like the plague.  --Edsger Dijkstra
>>

[Lawrence Rosen]

> Ah, mea culpa - I did not mean to reference Rosen in my previous
> posting.  I meant to reference Moglen....

Thanks for the clarification, Dave.

Now all that I have to do is understand the basis for John's comment:

> >> Just that the disagreement between Larry and most other people is of
> >> long standing and unlikely to go away, but has hitherto been of little
> >> practical effect.

Disagreement with "most other people"? Hogwash! As I gather from my
conversations with many other attorneys, most other people think FSF and
SFLC are wrong on the legal issue of combining GPL software in collective
works with other works. I will admit that this disagreement "has been of
little practical effect," but this is at least partly because some people on
this list and elsewhere make general statements like yours with little basis
in law or fact.

I'll keep trying, John, despite your gloomy prognostication about effects.

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * cell: 707-478-8932 * fax: [phone]
Skype: LawrenceRosen
Author of "Open Source Licensing: Software Freedom and
                Intellectual Property Law" (Prentice Hall 2004)

> -----Original Message-----
> From: dtemeles@... [mailto:dtemeles@...]
> Sent: Wednesday, August 01, 2007 8:15 AM
> To: license-discuss@...
> Subject: Re: conducting a sane and efficient GPLv3, LGPLv3 Review
>
> Ah, mea culpa - I did not mean to reference Rosen in my previous
> posting.  I meant to reference Moglen but there was a disconnect
> between my fingers and my brain.  A perfect example of why I should
> read more and post less!
>
> Quoting dtemeles@...:
>
> > FWIW, I and many of my colleagues in IP law think Rosen is incorrect
> > on a number of key points.  However, given that the language of the
> > GPL is clear as mud, there is plenty of room for reasonable minds to
> > differ on how it should/will be applied to any given set of facts.  In
> > the end. the only opinion that will matter in any given case is that
> > of the judge who hears the case (or the appeal).
> >
> > What Quoting John Cowan <cowan@...>:
> >
> >> Alexander Terekhov scripsit:
> >>
> >>> Is there any followup to this exciting development of Rosen-vs-GNU
> >>> wisdom? :-)
> >>
> >> Just that the disagreement between Larry and most other people is of
> >> long standing and unlikely to go away, but has hitherto been of little
> >> practical effect.  My own view (IANAL), is that Larry is probably right
> >> on the letter of the law, but that community practice counts for a lot
> >> too, even in court (judges have been known to look to the way the
> >> relevant community traditionally interpreted standard contracts, e.g.).
> >>
> >> It may or may not be legal to create combined works with GPLed and
> >> proprietary parts, but it is definitely tacky and you shouldn't do it.
> >>
> >> --
> >> John Cowan  cowan@...  http://ccil.org/~cowan
> >> The competent programmer is fully aware of the strictly limited
> >> size   of his own
> >> skull; therefore he approaches the programming task in full
> >> humility, and among
> >> other things he avoids clever tricks like the plague.  --Edsger
> Dijkstra
> >>

[John Cowan]

Lawrence Rosen scripsit:

> Now all that I have to do is understand the basis for John's comment:
>
> > >> Just that the disagreement between Larry and most other people is of
> > >> long standing and unlikely to go away, but has hitherto been of little
> > >> practical effect.

A mere typo:  for "most other people" read "most other people here".
My bad.

--
Cash registers don't really add and subtract;           John Cowan
        they only grind their gears.                    cowan@...
But then they don't really grind their gears, either;  
        they only obey the laws of physics.  --Unknown

[Alexander Terekhov-3]

On 8/1/07, John Cowan <cowan@...> wrote:

> Lawrence Rosen scripsit:
>
> > Now all that I have to do is understand the basis for John's comment:
> >
> > > >> Just that the disagreement between Larry and most other people is of
> > > >> long standing and unlikely to go away, but has hitherto been of little
> > > >> practical effect.
>
> A mere typo:  for "most other people" read "most other people here".
> My bad.

Do you really think that most other people here are not kind of
puzzled by the following piece of GNU "denationalization" wisdom?

http://gplv3.fsf.org/denationalization-dd2.html

------
Works Based On Other Works

Although the definition of "work based on the Program" made use of a legal
term of art, "derivative work," peculiar to US copyright law, we did not
believe that this presented difficulties as significant as those associated
with the use of the term "distribution." After all, differently-labeled
concepts corresponding to the derivative work are recognized in all
copyright law systems. That these counterpart concepts might differ to some
degree in scope and breadth from the US derivative work was simply a
consequence of varying national treatment of the right of altering a
copyrighted work.

Ironically, the criticism we have received regarding the use of US-specific
legal terminology in the "work based on the Program" definition has come
not primarily from readers outside the US, but from those within it, and
particularly from members of the technology licensing bar. They have argued
that the definition of "work based on the Program" effectively misstates
what a derivative work is under US law, and they have contended that it
attempts, by indirect means, to extend the scope of copyleft in ways they
consider undesirable. They have also asserted that it confounds the con-
cepts of derivative and collective works, two terms of art that they assume,
questionably, to be neatly disjoint under US law.

We do not agree with these views, and we were long puzzled by the
energy with which they were expressed, given the existence of many other,
more difficult legal issues implicated by the GPL. Nevertheless, we realized
that here, too, we can eliminate usage of local copyright terminology to good
effect. Discussion of GPLv3 will be improved by the avoidance of parochial
debates over the construction of terms in one imperfectly-drafted copyright
statute. Interpretation of the license in all countries will be made easier
by replacement of those terms with neutral terminology rooted in description
of behavior.

Draft 2 therefore takes the task of internationalizing the license further
by removing references to derivative works and by providing a more globally
useful definition of a work "based on" another work. We return to the basic
principles of users' freedom and the common elements of copyright law.
Copyright holders of works of software have the exclusive right to form new
works by modification of the original, a right that may be expressed in
various ways in different legal systems. The GPL operates to grant this
right to successive generations of users, particularly through the copyleft
conditions set forth in section 5 of GPLv3, which applies to the conveying
of works based on the Program. In section 0 we simply define a work based
on another work to mean "any modified version for which permission is
necessary under applicable copyright law," without further qualifying the
nature of that permission, though we make clear that modification includes
the addition of material.1 1 We have also removed the paragraph in section
5 that makes reference to "derivative or collective works based on the
Program.
-------

Very interesting, to say the least. :-)

regards,
alexander.

[Zak Greant]

Greetings Larry, Aloha All,

>> Just that the disagreement between Larry and most other people is of
>> long standing and unlikely to go away, but has hitherto been of  
>> little
>> practical effect.
>
> Disagreement with "most other people"? Hogwash! As I gather from my
> conversations with many other attorneys, most other people think  
> FSF and
> SFLC are wrong on the legal issue of combining GPL software in  
> collective
> works with other works. I will admit that this disagreement "has  
> been of
> little practical effect," but this is at least partly because some  
> people on
> this list and elsewhere make general statements like yours with  
> little basis
> in law or fact.

Please cite relevant published opinions and cases, not "conversations  
with many other attorneys."

Cheers!
--zak