[Ffmpeg-devel] CyberLink PowerCinema for Linux
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
It contains no code from ffmpeg, only unresolved references to the
external API, more specifically:
>> 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
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.
mru at inprovide.com
More information about the ffmpeg-devel