Re: Overview of copyright issues

[Joseph Wakeling]

Graham Percival wrote:
> Bugger the GNU project guidelines.  They're not the be-all and
> end-all of good project mangement.  In many ways, they're pure
> rubbish.  Toodle-pip, cheers, and all that.
> 
> (I'm trying to be more British... I was really surprised at the
> use of "cheers" here.  It's a greeting!  It's a farewell!  It's a
> thanks!  It's an airplaine... no, it's super-word!  :)

One of the best words in the English language. ;-)

GNU guidelines seem to me to be least important reason to do anything,
but worth reading and understanding the motivation behind them,
particularly where copyright/licensing is concerned -- just because the
people behind GNU have put a lot of thought into these things and have a
lot of experience.

>>> Really?  Line 22 says "Version 2, June 1991" to me.  How exactly
>>> do you propose to change the COPYING file?
>> I propose to add text closer to the statement recommended by the FSF/GNU
>> foundation and by the GPL itself:
>>
>>     GNU Lilypond is free software; you can redistribute it and/or modify
>>     it under the terms of version 2 of the GNU General Public License as
>>     published by the Free Software Foundation.
> 
> ok.
> 
>> ... plus some further explanatory text that will probably be close to
>> what the existing file says.  Perhaps also a line emphasising the
>> licensing situation (i.e. v2 only) as the Linux kernel COPYING file
>> does,
> 
> ok.

I'll put forward a patch for this, then.

>> and a note explaining how we are attempting to change the
>> licensing situation.
> 
> Not ok.

Will not be in the aforementioned patch, then.

>>>>           (v) the link on the main page which (still) points to the
>>>>               text of GPLv3 on gnu.org (and has ever since v3 was
>>>>               released -- the first message pointing out this
>>>>               discrepancy was sent to the -devel mailing list over
>>>>               2 years ago!).
>>> This is fixed on the new website.
>> But not on the current one, which is still live ... :-)
> 
> Patches accepted.

I'll see what I can do.  (Depending on the timeline for launch of the
new site.  Not much point patching the current one if you're going to
launch the new one in a couple of weeks' time.)

>> Sure; this is just a useful policy to have (and maintain) because it
>> clarifies the licensing situation on a file-by-file basis.
> 
> But we *don't* have "a licensing situation" on a file-by-file
> basis.  Everything[1] under Documentation/  is FDL; everything
> else[2] is GPLv2.

I'll come to this in a moment after addressing your next points...

> [1] it would be very useful if somebody could create an example to
> replace cary.ly, since that's non-free.
> 
> [2] it would be very useful if somebody could identify anything
> (other than texinfo.tex and input/* since those are slated for
> demolition) that isn't GPLv2.
> 
> [3] haha, an unreferenced footnote!  It would be very useful if
> the note at the top of /COPYING had these exceptions noted.

I can work on at least [2] and [3].  I can try to do [1] as well.

> What's the point of per-file stuff?  The only thing that I can
> think of is that if somebody discovers the file via a google
> search (say, in gitweb), but is too lazy to look at the top of the
> gitweb repository, they can see the license and comply with it.
> 
> That's ridiculous.  Anybody who is moral will take the extra 30
> seconds to find the appropriate COPYING file.  Anybody who isn't
> moral is going to ignore the license anyway and just take whatever
> they want.

OK, well.  Perhaps I should say 'credit on a per-file basis' rather than
licensing[1].  The reason I can see is this: if I decide I want to use a
file from Lilypond in my own piece of code, it's helpful to me to know
exactly who the authors and copyright holders are for that particular
file.  With such a notice I immediately know who I have to contact if I
need/want further permissions, I know who I have to credit in my AUTHORS
file, etc. etc.

Now, I can of course go searching through the git log to track them
down.  But then what happens when I discover the apparent contributors
don't match with the copyright notice in the file (currently the case)?
 What happens if I trust the copyright/credit notice, then suddenly
later get someone I didn't know about coming along and saying, 'Hey,
you're using my code without credit'?

(Or, what happens if someone adds third-party material to Lilypond code
or docs?  OK, we have the git log, but it's handy to be able to see
without delving into version history whether a particular file contains
material from a given source.)

So, I see maintaining good file-by-file contribution records as being
both helpful to Lilypond (it helps us track who did what) and courteous
to people receiving the code (it helps facilitate the process of
adapting parts of the code for other projects).

[1] Where the licensing issue might be important is this: what if
someone forks Lilypond and adds a bunch of their own code with a
different but compatible license statement -- like GPLv2+?  It helps
clarify the situation if each file has a specific license statement
rather than just relying on 'files should be assumed to be under license
 X unless otherwise stated'.

The other motivation is if there _is_ a desire to alter the license it
might be useful to be able to do this incrementally, e.g. move to (say)
GPL2+ all those files where the authors give permission as soon as that
permission is given.

> I will admit that the docs could use better signage, especially
> after I moved the license into a @macro (oops).  But a simple
> paragraph for the main manuals in Documentation/, and a sentence
> or two pointing back to those main manuals for everything in a
> subdir, would suffice for this.

It's potentially more important with docs than code simply because the
docs get moved/copy-pasted/messed around with far more than the code, so
it's much less easy to track contributions with git. :-(

> Now, if they simply stated that material under FDL1.2 could be
> relicensed as CC, that would be fine.  They could then -- as
> indeed they did -- release FDL1.3, so people could choose to use
> 1.3 or higher to avoid the relicensing.  But to introduce a
> time-specific window... an indication that they don't really
> approve of this other license, but that they're willing to hold
> their noses for political benefit or whatever... ick.

Well, they COULDN'T say that 'FDL1.2 can be relicensed...' because they
can't apply new licensing terms like that to material where they don't
own the copyright. :-)

The relicensing option in 1.3 was very narrowly defined both in terms of
scope (what kind of material could be relicensed) and time window (I
think it is no longer open).  It was pretty much a 'let Wikipedia
relicense' clause.  I think the logic was along the lines that GFDLv2 is
going to be compatible/exchangeable with CC-BY-SA in any case; the broad
function of the licenses are compatible, it's just legalese which means
they clash; and it's convenient for Wikipedia and some other projects to
have CC-BY-SA compatibility now rather than later, so let's make it happen.

> I now seriously want to stop releasing my doc work as "FDL 1.1 or
> later"; the FSF has shown that they cannot be trusted with such a
> blank cheque.  However, this is a bad time to introduce such a
> debate, so I'll keep with the status quo.  We can reopen this in a
> few months.

Yes, I think licensing debates are best held off (as opposed to
credit-tracking issues).  I'll just say that from my point of view it's
a question of, what problems do you want to have?  If you have copyright
held by a single entity, you can relicense freely but that decision may
be made (or blocked) for bad reasons or vested interests.  If you have
copyright held by individual authors and a fixed license, you have the
problem of tracking down contributors and getting their permission when
you _do_ need to relicense.  If you have copyright held by authors and a
'for later' clause, you risk the possibility that at some point in the
future someone might get to fork your code under a license you don't like.

I prefer the risks of the last option to those of the other two, but I
understand very well why not everyone agrees.

> For the record, I am NOT giving such permission.  When we reach an
> appropriate time to consider license changes -- say, at the
> beginning of 2010 -- I might give permission for whatever proposal
> is brought forth.

No worries.  If people do want to state now their license preferences I
will continue to track them, but I agree it's not an urgent debate.

> No.  If there's a detailed file-by-file, "Copyright 2003, 2008 by
> X who wrote 38 lines, copyright 2005 by Y who wrote 123 lines",
> then that creates pressure to maintain it.  That wastes
> *everybody's* time.

I think there are good reasons for wanting to maintain such
documentation (see above), and I don't think it's so hard to sustain it
-- most files are worked on by relatively few people (so the author list
stays constant) and it's not so difficult for contributors to change the
year of copyright or just add their name to an author list.

It doesn't need to be as detailed as 'wrote X lines' or 'wrote functions
A, B, C', just a list of major (i.e. justifiably copyright-owning)
contributors and year(s) of their contributions, as in the sample patch
I put forward.  (I mentioned tweaks as well, but that was just a
courtesy to the tweakers rather than something that needs to be tracked.)

> Or rather, that wastes *your* time, because there's no way I'm
> going to bother with that.  If somebody wrote documentation for
> lilypond, I'm going to put it wherever I feel like.  If we improve
> the manual structure and move it somewhere else, I'm going to do
> that.  Keeping track of who wrote which lines is way too much work.

Not lines, but files.  Of course, in the case of the doc it's a bit
[lot] more complicated ... :-(

Best wishes,

    -- Joe