Re: Overview of copyright issues

[Graham Percival]

On Sat, Sep 19, 2009 at 06:23:06PM +0200, Joseph Wakeling wrote:
> Graham Percival wrote:
> >>> 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.)

I'm glad you see it my way.


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

But since the notices will be out of date, you'll need to look in
the git log anyway.

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

Unless we have a dedicated legal secretary spending 5 hours a week
maintaining such notices, they will be out of date and therefore
useless.

> [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+?

Huh?  If somebody forks lilypond, that's their problem.

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

No.  Changing the license will be an all-or-nothing affair.

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

You severely underestimate the effort involved in the
documentation.  For example, I recently moved the command-line
info from the AU into the new website.  At a complete guess,
- 5-30 lines came from Han-Wen
- 5-30 lines came from Mats
- 5-20 lines were corrected by Werner
- 5-20 lines had a correction sent to a mailist by random users,
  and were added by Graham or Mats.
- 20-50 lines had English grammatical fixes by Graham, but no
  actual content changes

Now, if 15 lines is the magical cut-off, who gets their name added
to Documentation/general/download.itely ?  I'd have to hunt
through the git log for all these lines -- looking at both
grammatical/spelling fixes *and* content fixes -- to decypher
whether I used 14 of Han-Wen's original lines or 16.

I'm not going to do that.  It's a gargantic amount of wasted
effort.  I mean, everybody in that list is deeply involved in
lilypond, we all want the best for lilypond, and we all agree to
the same license.  Spending an hour looking through git logs every
time I want to clarify the documentation helps *nobody*.

For this reason, I categorically refuse to have file-specific
ownership.  Documentation is documentation; any doc committers
will be listed in the same place.


It's true that code doesn't change as much as the docs, although I
could well imagine some kinds of useful reshuffling that would
require hours of extra work if we had file-specific ownership.
(say, what if we decided to split \mark into \markText and
\markRehearsal ?  Oops, now we need to track down exactly who
wrote which lines in the relevant file(s), to make sure that info
gets into the new file(s)).

I still think it would be a complete waste of time, but if you
really want to track down file ownership of source code, _I_ won't
stop you.  You'd better check that everybody else is ok with this,
though.  And by "ok", I mean "agrees to you doing the initial
work, *and* commits to maintain such info in the future".

Cheers,
- Graham