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

Re: MPlayer reloaded



Walter Landry writes:
 > Don Armstrong <don@donarmstrong.com> wrote:
 > > On Wed, 17 Mar 2004, Diego Biurrun wrote:
 > > > We had modified it, but it was not labeled as such.  Clearly a
 > > > license violation but one easily remedied.  So I added the line
 > > > 
 > > >   Modified for use with MPlayer, see the CVS log for details.
 > > 
 > > Ideally you would add the following:
 > > 
 > > Initially modified for use with MPlayer by A N Other on 4-2-1492
 > > $Id$
 > > See detailed CVS changelog at http://cvs.mplayer.org
 > > 
 > > > The GPL requires giving dates of changes. 
 > > 
 > > Date of any change. I personally find the initial modification and
 > > current modification date to be sufficient.
 > 
 > It is unlikely that a particular change was made on only one day.  I
 > always used the year.  So something like
 > 
 >   Copyright (C) 2003 J. Doe
 > 
 > right after the first copyright statement.  This certainly indicates
 > that J. Doe has modified the file and gives an approximate date.

The date of the first modification sounds most feasible to me.  Giving
the last date is also easy via the $Id$ tag as you pointed out.  The
most interesting information should be the first modification date,
though.  If you want to trace it back to the original version this is
the date you need.

 > > > I consider this close to impossible as it would more or less require
 > > > adding the date and log message of every commit to that file. This
 > > > is what CVS is for.
 > > 
 > > That's why you can use CVS to indicate when the last change was done,
 > > and the file itself to indicate when the first change was done.
 > > 
 > > Look at the Id tag of CVS and Subversion.
 > 
 > I wouldn't say that is really supported by the letter of the license.
 > The license states "the date of any change", not the first and last
 > with a pointer.  You could point to existing practice, but not to the
 > license.
 > 
 > In general, I think that section 2a is a bit more restrictive than was
 > really intended, which is why it is so widely flouted.

I agree fully.  As I said, adhering to the letter of 2a is completely
infeasible IMHO.  That's why I explicitly asked for alternatives that
are existing practice and acceptable for Debian.

Diego



Reply to: