Le 9 juin 2011 à 16:28, Soltic Lucas a écrit :
It *sounds* like you are complying with the license. But I have not seen
your application code, and I am not a lawyer.
Phil
Thank you all for you answers. And I'll take your advice Phil and I'll
entirely read the LGPL, so that I can be
Hi Lucas,
On 06/30/2011 01:41 PM, Soltic Lucas wrote:
Le 9 juin 2011 à 16:28, Soltic Lucas a écrit :
It *sounds* like you are complying with the license. But I have not seen
your application code, and I am not a lawyer.
Phil
Thank you all for you answers. And I'll take your advice Phil
Hi,
On Wed, Jun 8, 2011 at 2:19 AM, Soltic Lucas soltic.lu...@gmail.com wrote:
From what you say, I suppose I shouldn't even care for that kind of issue,
and should statically link my library against FFmpeg, as LGPL is not a
problem to me. Actually I'm getting a bit lost between those who
Hi Lucas,
On 06/07/2011 08:19 PM, Soltic Lucas wrote:
Le 7 juin 2011 à 17:29, Phil Turmel a écrit :
Admirable intent, but you must make it possible for your users to substitute
their own compilation of FFmpeg into your application. Dynamic linking is
the simplest way to satify that
you still have to comply with the LGPL's rules on making the source code and
build details available
But do not fall into another extreme, your server should not provide
an alternative branch for FFmpeg development. Keep a snapshot of the
exact state of the LGPL code you've linked against
Hi Lucas,
On 06/07/2011 09:47 AM, Soltic Lucas wrote:
Hello,
On the Legal page is written the following:
*16. Do not rename FFmpeg dlls to some obfuscated name, but adding a suffix
or prefix is fine (renaming avcodec.dll to MyProgDec.dll is not fine,
but to avcodec-MyProg.dll is).*
What
The purpose here is to avoid having loads of dlls. Initially I was linking
the static libraries to my own product. But I got issues with Visual Studio
and wanted to give a try with dynamic linking. However I don't want the user
to have to care about 5 dlls when he would actually need only one
