[FFmpeg-devel] GOM Player on the Blacklisted Projects
Thu Apr 10 02:51:57 CEST 2008
On Wed, Apr 9, 2008 at 8:29 PM, Michael Niedermayer <michaelni at gmx.at>
> On Wed, Apr 09, 2008 at 07:59:00PM -0400, Francois Oligny-Lemieux wrote:
> > Below are the specific questions/answer asked to FSF:
> > > Q. What ffmpeg requires is that the new developer mention on which
> > > revision he branched the original tree (to comply apparently with GPL
> > > ?!? is this true?), and secondly, to produce a diff of its change (to
> > > comply with 2.a).
> I do not remember that anyone of us did require this, are you a native
> english speaker?
The diff file you have for download is not created in a way that makes
> it useful. It is very cumbersome to handle because it covers all the
> metadata of the Subversion revision control system and all files that
> were removed instead of changed. Tell your engineers that the command
> 'svn diff' is able to produce the correct output without all this hassle.
> So to answer your question: You are still not in compliance with FFmpeg
> licensing terms. Fix the issues I pointed out above and we can continue
Then I understand that to be in compliance with FFmpeg licensing terms, he
has to fix the issues about the diff. Which means the diff is somehow needed
for the compliance with FFmpeg licensing terms (which are supposedly LGPL
> > (FSF) << No, the requirement is that I (as an example of "any third
> > should be able to acquire, from the new developer, the corresponding
> > source to build the same binary which the new developer is
> > > Q. When a new developer branches a GPL project into a new GPL
> > > Is he required to list all the date of all changes on every files
> > > of the original GPL code that he himself modified after the branching
> > (FSF) << Generally speaking, yes, but this should not be done in an
> > cumbersome way. Note that if it would be too cumbersome to comply with
> > this term, then you would lose the freedom to modify the software.
> > To be more specific, you need to add a notice such as:
> > "This file was modified by YOUR NAME in April 2008" or even more
> > just "Copyright 2008 YOUR NAME", stating when you first changed the
> > file. Anything else, including the dates of subsequent changes and
> > description might be nice, but is not a requirement of the GPL.
> > Section 5(a) of GPLv3 states:
> > "The work must carry prominent notices stating that you modified it,
> > giving a relevant date."
> > The FSF feels that this better reflects the meaning of the language
> > GPLv2 as well (one of the reasons GPLv3 is a better license is that
> > of these issues have been cleared up considerably).
> > >>
> > > > Changes made:
> > > > Original source:
> > > > libavcodec version 51.40.4
> > > > libavutil version 49.4.0
> > >
> > > That's a good start, but not very precise. A sufficiently precise
> > > answer would be the Subversion revision number you based your work
> > >
> > > > Changes:
> > > > libavcodec ported to win32 dll using MinGW
> > >
> > > That's also a good start, but not precise enough. A sufficiently
> > > precise answer would be a diff file with your changes.
> > >
> > As a reminder, it's might be ok to ask to produce svn revision in
> > order to comply with GPL v2 section 2.b however to ask to produce a
> > diff (to someone who has already produced the full source code) and
> > ask it in a way that it is to comply with GPL/LGPL is not right.
> As i already asked above, are you a native english speaker? I have the
> feeling you are not because your interpretation is not what diego wrote.
> "That's a good start"
> clear i guess
> "but not very precise."
> also clear i assume
> "A sufficiently precise answer ..."
> emphasis is on _sufficiently_ is not _necessarily_, i assume you
> misunderstood this?
> There is nothing wrong with asking for diff and svn revission, asking is
> the same as requireing
> SVN revission and diff greatly simplify our work in judging what has been
> changed and if any of that can be merged into ffmpeg svn.
> > There
> > might be people reading ffmpeg-devel posts in order to educate
> > themselves on licensing issues (in order to not be on the blacklisted
> > projects) and care should be taken not to bring misconception about
> > GPL.
> Thats what you get for listening to programmers about legal issues, same
> as with listening to butchers about heart surgery. Such people are fools
> and cannot be helped.
More information about the ffmpeg-devel