[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Overview of copyright issues + Debian

From: Anthony W. Youngman
Subject: Re: Overview of copyright issues + Debian
Date: Thu, 10 Sep 2009 23:07:06 +0100
User-agent: Turnpike/6.07-M (<UtY6T13YPTC$k3mvCGf+2+66d9>)

In message <address@hidden>, Reinhold Kainhofer <address@hidden> writes
Am Donnerstag, 10. September 2009 17:12:42 schrieb Anthony W. Youngman:
In message <address@hidden>, Joseph Wakeling
<address@hidden> writes

>Now, future policies -- I would suggest new contributions be requested
>to follow these rules:
>    -- for code, GPLv2 or later or a more liberal compatible license;


Some people are likely to be unhappy with "or later".

The requirement should be "compatible with GPLv2 *AND* GPLv3".

... So we'll have the same problem again in some years... By then it will be
even harder tracking down all contributors, who submitted a patch years ago...

Hopefully we won't. Hopefully contributors will use the "or later" version.

But the problem with *demanding* "or later" is that you are *forcing* potential contributors to give the FSF carte blanche to relicence their work. Why should I, having given long and careful thought to the licence I want for my code, allow other people to change those terms without as much as a "by your leave"? I'm not saying I agree with Linus, but he has his reasons for licencing Linux as "v2 only", and I'm sure there'll be people who think he has a valid point!

>    -- for docs, GFDLv1.1 or later/GPLv2 or later dual license (or
>       more liberal compatible license);

GFDL must be "with no invariant sections". While the FSF may want
invariant sections, it's meant for political diatribes. Do we *really*
want chunks of documentation that we can't update as lilypond changes?
There is NO REASON WHATSOEVER for having invariant sections in what is
real documentation, and every reason for NOT having them.

Huh? nobody ever spoke of adding invariant sections. I though it was clear
that our docs would not have invariant sections..

Not to me it wasn't! The original proposal was "GFDL for documentation" with no reference whatsoever to invariant sections, for or against.

>    -- when altering a file that already exists, use the same license
>       as for the rest of that file (so if someone contributes a code
>       file under a BSD/MIT-esque license, anyone who adds to that file
>       uses the same);

Yup. Use the word "should" rather than "must", however - see below.

See the introduction before the list: ... "be requested to follow these

>    -- patches that make a significant alteration to a file should add
>       the author's name to the copyright notice

Along with the author's licence - if the "significant alteration" is
tantamount to a major rewrite, they might want to change the licence.
And if the resulting file is mostly their work, then why shouldn't they?

Because they are not allowed by copyright law. They cannot change the license
if the file is only "mostly" their work. They can only change the license if
the file is SOLELY their work.

Sorry - you're wrong there. If the original licence is MIT, and the rewrite is GPL, then copyright law DOES allow them to change the licence DESPITE the file not being all (or even mostly!) their own work. I don't think we should allow a minor GPL change to change the licence for a MIT/BSD file, but it's okay if it's actually a major rewrite.

Going back to an earlier point of yours - "See the introduction before the list: ... "be requested to follow these rules"..." - that wasn't clear.

I think we should drop that "be requested" (I never saw it ...) and write the rules in rfc-style-speak.


"Licencing: the licence on any contribution MUST be compatible with GPLv2 and GPLv3. The PREFERRED licence is "GPLv2 or later" or something more liberal such as MIT/BSD"

Otherwise it will be perfectly okay - because it says "be requested" - for people to STILL TODAY contribute GPLv2-only code! And where will the move to v3 go then?

Anthony W. Youngman - address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]