[MPlayer-cvslog] r26723 - in trunk: Makefile av_opts.c av_opts.h

[Diego Biurrun]

On Tue, May 13, 2008 at 02:29:23PM +0200, Michael Niedermayer wrote:
> On Tue, May 13, 2008 at 10:37:23AM +0200, Diego Biurrun wrote:
> > On Sun, May 11, 2008 at 03:07:44PM +0200, Michael Niedermayer wrote:
> > > IMO a simple central statement somewhere about license header less files is
> > > enough, there should be no need to copy and paste the header into each
> > > file.
> > 
> > We have already had this discussion for FFmpeg, which has a much clearer
> > licensing situation than MPlayer.  Let me reiterate the main points that
> > apply here:
> > 
> > 1) MPlayer is a patchwork of different libraries and files from diverse
> > sources.  They have a multitude of different licensing terms.  Some of
> > these files do have license headers, some do not.  However, not all
> > files without such a header are covered by the terms outlined in the
> > LICENSE file, as an example look at some of the files below vidix/ that
> > come from xfree86.
> > 
> > So a statement about files without license headers would have to list
> > exactly which license applies to which file. Move some files around and
> > this quickly becomes a burden to maintain and you can be sure that
> > updates to such a file will be forgotten.
> > 
> > 2) Some people (our developers even) interpret the lack of a license header
> > as meaning GPL v2 instead of any version, as clearly stated in the text
> > of the GPL.  So there obviously is room for misinterpretation.  Unified
> > license headers avoid this ambiguity.
> > 
> > 3) Last and absolutely not least, code from MPlayer gets copied around a
> > lot.  Once it has moved between two or three code bases, attributions
> > can easily get lost.  It will no longer be clear where a file comes from
> > and which license it is under.  It might become a part of code that is
> > not compatible with the GPL.  This would violate the intentions of the
> > authors.
> > 
> > 
> > If we were to start afresh and could say that all files in this project
> > are under license XYZ, that would be great.  Unfortunately we do not
> > have that luxury.
> > 
> > I can understand that license headers for all files are burdensome, but
> > there simply is no acceptable alternative.  It is the smallest evil.
> 
> a simple
> // This file can be used under the GPL v2+
> at the top of each file should solve the problems you point at

Possibly, but you have omitted even that.

There are still some practical problems left with your proposal:

You can always use a program for any purpose, provided that you aquired
it legally.  Being allowed to "use" it under the GPL is not saying much.
The interesting things are modification and redistribution.

GPL v2+ is a common shorthand, but possibly ambiguous; "GPL version 2 or
later" is better.

If you combine this, you arrive at something very similar to

  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation; either version 2 of the License, or
  (at your option) any later version.

So why not go with the standard version right away?

Not all people know what the GPL is and the text of the GPL may not come
included with the source file in question.  Thus, information about
where to get the licensing terms are useful.  Snail mail may seem
somewhat anachronistic, but the GPL version 2 dates from 1991.  The GPL
version 3 uses a URL in its boilerplate text.

Add to that the standard disclaimer of warranty that even X11/ISC-style
licenses contain and you arrive pretty close to the standard GPL
boilerplate text.

Additionally, it is what people have come to expect from files that are
put under the GPL and it is the way recommended by the license itself.

Again, I'm not saying that I am terribly fond of the license headers in
each file, but I see no alternative that does not put us on legally
shaky ground.


> -- 
> 
> Awnsering whenever a program halts or runs forever is
> On a turing machine, in general impossible (turings halting problem).

undecidable

> On any real computer, always possible as a real computer has a finite number
> of states N, and will either halt in less than N cycles or never halt.

semidecidable

What were you trying to say there?  Any particular instance of the
halting problem is semidecidable, the general problem is not.

Diego