[Ffmpeg-devel] CyberLink PowerCinema for Linux

Måns Rullgård mru
Mon Jun 6 18:54:26 CEST 2005


Diego Biurrun <diego at biurrun.de> writes:

> On Mon, Jun 06, 2005 at 06:12:35PM +0200, M?ns Rullg?rd wrote:
>> Diego Biurrun <diego at biurrun.de> writes:
>> 
>> > It contains more tarballs and a few patches.  Among them is an
>> > unmodified version of MPlayer 1.0pre7 and an object file in the ffmpeg
>> > directory:
>> >
>> > http://mplayerhq.hu/~diego/PCMLinux_GPL_sources/ffmpeg/ff_all.o
>> >
>> > Can anybody make heads or tails of this one?  There is no source code,
>> > which they should be distributing alongside the object file...
>> 
>> That's a few C++ classes (VideoPictureQueue, PacketQueue, Decoder,
>> and a few others), some of which use the normal lavc/lavf API.  There
>> are also references to Python and SDL, and of course libc.  The
>> wonderful tool "nm" will tell you all this.
>
> Yes, I already ran it through nm and strings, but being unfamiliar with
> ffmpeg internals, I could not tell if this was an unmodified version or
> not.

It contains no code from ffmpeg, only unresolved references to the
external API, more specifically:

   av_close_input_file
   av_dup_packet
   av_find_stream_info
   av_free
   av_gettime
   av_malloc
   av_mallocz
   av_open_input_file
   av_read_frame
   av_register_all
   avcodec_decode_audio
   avcodec_decode_video
   avcodec_find_decoder
   avcodec_open
   avpicture_fill
   img_convert

>> My understanding of the LGPL is that there is no requirement to
>> release source code to that file.
>
> That's not my understanding, which is based on LGPL ?4:
>
>     4. You may copy and distribute the Library (or a portion or
>   derivative of it, under Section 2) in object code or executable form
>   under the terms of Sections 1 and 2 above provided that you accompany
>   it with the complete corresponding machine-readable source code, which
>   must be distributed under the terms of Sections 1 and 2 above on a
>   medium customarily used for software interchange.
>
>     If distribution of object code is made by offering access to copy
>   from a designated place, then offering equivalent access to copy the
>   source code from the same place satisfies the requirement to
>   distribute the source code, even though third parties are not
>   compelled to copy the source along with the object code.

Then it goes on with section 5:

    5. A program that contains no derivative of any portion of the
  Library, but is designed to work with the Library by being compiled
  or linked with it, is called a "work that uses the Library".  Such a
  work, in isolation, is not a derivative work of the Library, and
  therefore falls outside the scope of this License.

Section 5 goes on with some irrelevant claims of debatable correctness
concerning what constitutes a derived work.  After that, section 6
follows:

    6. As an exception to the Sections above, you may also combine or
  link a "work that uses the Library" with the Library to produce a
  work containing portions of the Library, and distribute that work
  under terms of your choice, provided that the terms permit
  modification of the work for the customer's own use and reverse
  engineering for debugging such modifications.

    You must give prominent notice with each copy of the work that the
  Library is used in it and that the Library and its use are covered
  by this License.  You must supply a copy of this License.  If the
  work during execution displays copyright notices, you must include
  the copyright notice for the Library among them, as well as a
  reference directing the user to the copy of this License.  Also, you
  must do one of these things:

    a) Accompany the work with the complete corresponding
    machine-readable source code for the Library including whatever
    changes were used in the work (which must be distributed under
    Sections 1 and 2 above); and, if the work is an executable linked
    with the Library, with the complete machine-readable "work that
    uses the Library", as object code and/or source code, so that the
    user can modify the Library and then relink to produce a modified
    executable containing the modified Library.  (It is understood
    that the user who changes the contents of definitions files in the
    Library will not necessarily be able to recompile the application
    to use the modified definitions.)

    b) Use a suitable shared library mechanism for linking with the
    Library.  A suitable mechanism is one that (1) uses at run time a
    copy of the library already present on the user's computer system,
    rather than copying library functions into the executable, and (2)
    will operate properly with a modified version of the library, if
    the user installs one, as long as the modified version is
    interface-compatible with the version that the work was made with.

It looks like they are doing one or both of these.  Not having
examined the thing carefully, I can't say whether they use dynamic
linking.  The remaining options are irrelevant to this discussion.

It seems to me that there is nothing to complain about here.

-- 
M?ns Rullg?rd
mru at inprovide.com





More information about the ffmpeg-devel mailing list