l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2005 Apr 01 18:46

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Self-replacing license [was Urgent news: Linux maybe relicensed]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Self-replacing license [was Urgent news: Linux maybe relicensed]

Rick Moen wrote:
Quoting Micah Cowan (micah@cowan.name):

As an /author/, I elect GPLv2 (no "or later").

As an author, you have no downside from "or later" if FSF issues a
proprietary-leaning GPLv3, because (1) your recipients can always reject
it and elect GPLv2, and (2) you would probably follow up latest release
n with an n.001 that newly omitted the "or later".
(2) is more or less pointless, though, as the code is already available to people in GPLv3 now, until I (or others) have added sufficient code to make it less attractive to "downgrade" to an older version of the software. (2) is also impossible to execute if it is a collective-work, collaboratively authored by enough other people that it would be impractical to obtain their permission. This is, of course, still assuming that the paragraph I indicated earlier as being an obvious misinterpretation, is in fact what I claim it to be.

I.e., obviously the threat of then forking release n-or-less under FSF's
new restrictive terms isn't of concern.
Less restrictive, more restrictive... licensing is a balance between restriction on the developer and restriction on the user. GPL is relatively liberating to the user, and relatively restrictive to the developer (as a consequence, not as an intention). Proprietary licenses are liberating to the developer (well, no: IP owner) and restrictive to the user.

But if the GPL were to step a little further past the edge of what I deem reasonable to give up as my owner privileges, that's when the "or later" becomes a problem to me as an author. While I cannot imagine a specific example, I'm sure it could exist.

A little more possible: it could simultaneously be both more restrictive and more liberating in separate ways... or just more "different" in ways that I don't condone.

The bottom line is that I want the person who decides the limits of what can happen to my code to be me, and no one else. This is why I dislike using the "or later."

However, there is an interesting situation: when I'm both recipient and author (as in the case of modifying-and-distributing).
Then, you enjoy rights over the codebase without needing to accept the
licence on any instance of it in the first place.
I'm having problems parsing that sentence.

But certainly, I enjoy only the rights specifically granted to me by the license notice that is (hopefully) at the top of each source code file. My understanding of the "or later" bit is that, if it is included, I could actually remove the "or later" part from all of the source code, and re-release it with my changes. But I would not feel comfortable doing so, and am still not entirely certain that's legal.

Reads a lot into 17 USC 201,
Actually, into caselaw.
Not sure what you mean here. It's their interpretation of a specific sentence in 17 USC 201 that I find extremely questionable.

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.