Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Timo Rothenpieler]

> But before doing any of this, there has to be an agreement, whether or not
> the header should be included at all.

Of course.
Here's what I intend to do once I find some time again, which could take
a few days/weeks:

Split this up into three patches.

One that adds a check for NVENC Version 6, so only the MIT licensed
header can be used.
One that adds the exception text(With all authors of nvenc.c on CC) and
drops non-free.
And a final one that bundles the header and enables it by default.

That way the issues can hopefully be sorted seperately.



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 15.12.2015 14:42, Timo Rothenpieler wrote:
> So, to get somewhere with this, would everybody be ok if I change this
> to remove the non-free marking, but keep it disabled by default for now?

That would be OK for me.

> Or is putting that exception-text in nvenc.c enough to make enabling it
> by default viable?

I think so.

But before doing any of this, there has to be an agreement, whether or not
the header should be included at all.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Timo Rothenpieler]

So, to get somewhere with this, would everybody be ok if I change this
to remove the non-free marking, but keep it disabled by default for now?

Or is putting that exception-text in nvenc.c enough to make enabling it
by default viable?



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Jean-Baptiste Kempf]

On 15 Dec, Timo Rothenpieler wrote :
> So, to get somewhere with this, would everybody be ok if I change this
> to remove the non-free marking, but keep it disabled by default for now?

I still don't understand why you want to fork this header into the
FFmpeg tree.


-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Matt Oliver]

>
> When running ffmpeg on Debian (main), where these Nvidia blobs
> are not present and not needed (because nouveau is used as driver),
> no component of the operating system, major or not,
> has been distributed with Nvidia's blobs, so the system library
> exception does not apply.
>
> I'm not sure about the situation for Windows.
>

For reference Windows automatically supplies nvidia driver binaries and
keeps them upto date via Windows Update. These drivers are often not as
upto date as the ones supplied directly by nvidia but as far as the system
library debate goes they are still provided by the OS as standard.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Philip Langdale]

On 2015-12-12 20:33, Nicolas George wrote:

Le duodi 22 frimaire, an CCXXIV, Philip Langdale a écrit :
it would be highly illogical to conclude that section 6/7 do not apply 
to
the original code itself and that we need to construct a separate 
entity

that does the combination for it to be licence compliant.


It would be fairly illogical to conclude that any clause in the 
license,
either GPL or LGPL, requires us to worry about the specifics of a file 
we do

not know anything about since it resides on the user's system.

We only have to worry about the files that were used to build the 
binary.


I actually completely agree with you, but I'm trying to make an 
incremental

argument. :-)

The source code that goes into the ffmpeg build is 100% (L)GPL 
compatible,

including the MIT licensed nvEncodeAPI.h. No one doubts that. This code
will dlopen nvenc.so (and the windows equivalent) on the system where it
is run. We do not know if that file exists or what licence that file
is under. It could be the nvidia binary, it could be some hypothetical
GPL reimplementation of the interface or it could rm -rf your 
filesystem.


So, to me, and to you, it seems clear that the combination with 
non(L)GPL
code cannot happen any earlier than when the library is actually 
dlopen'ed.


--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> I don't agree as I have already explained previously.

Fortunately, your arguments have no legal standing.

> Have a look at what some of the proprietary licenses require for distribution
> that has absolutely nothing to do with how the binary was built.

A lot of licenses have crazy and illegal clauses.

> For example, a license could allow distribution only under full moon,
> independently of when the binary was built.

Fortunately, the (L)GPL does not have such a crazy rule.

> Or, to take a more realistic example, the NVIDIA Software License [1] allows
> redistribution of it's software only if it is "designed exclusively for use
> on the Linux or FreeBSD operating systems". That's completely independent
> of where or how the binary was built.

Ditto.

The (L)GPL does not have a rule against distributing a binary that can load
a proprietary file. That would make ffmpeg all but useless, I hope you
realize that, because most of the licenses for the multimedia files
themselves are GPL-incompatible.

Regards,



signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> However, the (L)GPL has a rule that allows distribution of a
> binary only together with the complete corresponding source code,
> that also includes the source code of any dynamically loaded
> library needed at run-time.

No, it does not. Dynamically-loaded libraries are not part of the binary.

> Multimedia files are no library of executable code.

Define the difference.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> Is in a previous mail.

I looked and did not see it.

> I'm not continuing this silly conversation.
> You can look up the meaning of words in a dictionary.

This has nothing silly. Having the code of a codec interpret the bitstream
of a multimedia file is exactly equivalent to having the processor microcode
or cabled logic interpret the machine language of a library.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 13:27, Philip Langdale wrote:
> On 2015-12-12 19:26, Andreas Cadhalpun wrote:
>> Anyway, I think your idea about a license exception would be a good solution.
>> We could add a special exception to nvenc.c, allowing its use with Nvidia's
>> blobs, something like [1]:
>>
>>  In addition, as a special exception, the copyright holders give you
>>  permission to combine this code with free software programs or libraries
>>  that are released under the GNU LGPL and with code included in the standard
>>  release of the CUDA and NVENC libraries under the NVIDIA Software License
>>  (or modified versions of such code, with unchanged license).
>>  You may copy and distribute such a system following the terms of the GNU 
>> LGPL
>>  for this code and the licenses of the other code concerned.
>>
>>  Note that people who make modified versions of this code are not obligated
>>  to grant this special exception for their modified versions; it is their
>>  choice whether to do so. The GNU Lesser General Public License gives
>>  permission to release a modified version without this exception; this
>>  exception also makes it possible to release a modified version which carries
>>  forward this exception.
> 
> This is fair enough,

OK.

> but I want to close out the LGPL conversation. The FAQ
> specifically discusses GPLv2 and GPLv3 and not LGPL, and I'll claim that's 
> because
> it doesn't apply.

I'll claim that's because the text for the LGPL would be mostly duplicated.

> The fact that a third party can take LGPL ffmpeg and combine it
> with proprietary code in certain ways means that clearly we can do so as well.

No, because the LGPL allows this only for a "program that contains no 
derivative of
any portion of the Library". Otherwise anyone could just add proprietary code
to FFmpeg, distribute that and claim it is in accordance with the LGPL.

> it
> would be highly illogical to conclude that section 6/7 do not apply to the 
> original
> code itself and that we need to construct a separate entity that does the 
> combination
> for it to be licence compliant.

No, that's not illogical, that's the core component of the LGPL:
It ensures freedom of the library code, while allowing anyone to use the 
library.

Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 12:55, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXIV, Carl Eugen Hoyos a écrit :
>> I am glad we agree that there is no difference (license-wise) if 
>> a library is linked statically, dynamically or via dynamic 
>> loading;-)
> 
> You are, unfortunately, completely wrong. It makes all the difference in the
> world. Static linking is done under the distributor's responsibility while
> dynamic loading (pure dlopen()) happens under the recipient's sole
> responsibility. The only case where dlopen() would cause a license problem
> is if someone wanted to distribute a core dump of the resulting process.

I don't agree as I have already explained previously.

> There is a very simple rule of thumb to apply here: can we build the ffmpeg
> binary on a system without libnvenc.so? If the answer is yes, then there is
> no way the license of libnvenc.so could affect the distribution of the
> binary.

The distribution of the binary is only affected by it's license, not by
made-up rules of thumb. Thus you have to base your arguments on the former,
not the latter.

Have a look at what some of the proprietary licenses require for distribution
that has absolutely nothing to do with how the binary was built.
For example, a license could allow distribution only under full moon,
independently of when the binary was built.

Or, to take a more realistic example, the NVIDIA Software License [1] allows
redistribution of it's software only if it is "designed exclusively for use
on the Linux or FreeBSD operating systems". That's completely independent
of where or how the binary was built.

Best regards,
Andreas


1: http://www.nvidia.com/content/DriverDownload-March2009/licence.php?lang=us
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 10:37, Matt Oliver wrote:
>>
>> When running ffmpeg on Debian (main), where these Nvidia blobs
>> are not present and not needed (because nouveau is used as driver),
>> no component of the operating system, major or not,
>> has been distributed with Nvidia's blobs, so the system library
>> exception does not apply.
>>
>> I'm not sure about the situation for Windows.
>>
> 
> For reference Windows automatically supplies nvidia driver binaries and
> keeps them upto date via Windows Update. These drivers are often not as
> upto date as the ones supplied directly by nvidia but as far as the system
> library debate goes they are still provided by the OS as standard.

Based on that one can probably argue that these are system libraries
on Windows.

Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 11:35, Hendrik Leppkes wrote:
> On Sat, Dec 12, 2015 at 11:25 AM, Andreas Cadhalpun
>  wrote:
>> On 12.12.2015 10:50, Hendrik Leppkes wrote:
>>> We should just add an exception into the license to explicitly allow
>>> using it with the NVIDIA CUDA library and be done with this debate for
>>> ever.
>>
>> That would be an option.
>>
>>> You know that Open-Source has failed when the project itself is
>>> arguing days and days for including a feature on license reasons that
>>> any closed-source app would just write, enable and offer to its users
>>> without a second thought.
>>
>> Please try to take a step back.
>> The "nvenc" feature is already included in FFmpeg, just not enabled by
>> default.
>>
> 
> And not enabled on any distribution, hence 99% of all users don't see
> it or get to use it.

You can't blame distributors for following our license.

Anyway, I think your idea about a license exception would be a good solution.
We could add a special exception to nvenc.c, allowing its use with Nvidia's
blobs, something like [1]:

 In addition, as a special exception, the copyright holders give you
 permission to combine this code with free software programs or libraries
 that are released under the GNU LGPL and with code included in the standard
 release of the CUDA and NVENC libraries under the NVIDIA Software License
 (or modified versions of such code, with unchanged license).
 You may copy and distribute such a system following the terms of the GNU LGPL
 for this code and the licenses of the other code concerned.

 Note that people who make modified versions of this code are not obligated
 to grant this special exception for their modified versions; it is their
 choice whether to do so. The GNU Lesser General Public License gives
 permission to release a modified version without this exception; this
 exception also makes it possible to release a modified version which carries
 forward this exception.

Best regards,
Andreas


1: https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le primidi 21 frimaire, an CCXXIV, Carl Eugen Hoyos a écrit :
> I am glad we agree that there is no difference (license-wise) if 
> a library is linked statically, dynamically or via dynamic 
> loading;-)

You are, unfortunately, completely wrong. It makes all the difference in the
world. Static linking is done under the distributor's responsibility while
dynamic loading (pure dlopen()) happens under the recipient's sole
responsibility. The only case where dlopen() would cause a license problem
is if someone wanted to distribute a core dump of the resulting process.

There is a very simple rule of thumb to apply here: can we build the ffmpeg
binary on a system without libnvenc.so? If the answer is yes, then there is
no way the license of libnvenc.so could affect the distribution of the
binary.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Philip Langdale]

On 2015-12-12 19:26, Andreas Cadhalpun wrote:

On 12.12.2015 11:35, Hendrik Leppkes wrote:

On Sat, Dec 12, 2015 at 11:25 AM, Andreas Cadhalpun
 wrote:

On 12.12.2015 10:50, Hendrik Leppkes wrote:

We should just add an exception into the license to explicitly allow
using it with the NVIDIA CUDA library and be done with this debate 
for

ever.


That would be an option.


You know that Open-Source has failed when the project itself is
arguing days and days for including a feature on license reasons 
that
any closed-source app would just write, enable and offer to its 
users

without a second thought.


Please try to take a step back.
The "nvenc" feature is already included in FFmpeg, just not enabled 
by

default.



And not enabled on any distribution, hence 99% of all users don't see
it or get to use it.


You can't blame distributors for following our license.

Anyway, I think your idea about a license exception would be a good 
solution.
We could add a special exception to nvenc.c, allowing its use with 
Nvidia's

blobs, something like [1]:

 In addition, as a special exception, the copyright holders give you
 permission to combine this code with free software programs or 
libraries
 that are released under the GNU LGPL and with code included in the 
standard
 release of the CUDA and NVENC libraries under the NVIDIA Software 
License

 (or modified versions of such code, with unchanged license).
 You may copy and distribute such a system following the terms of the 
GNU LGPL

 for this code and the licenses of the other code concerned.

 Note that people who make modified versions of this code are not 
obligated
 to grant this special exception for their modified versions; it is 
their

 choice whether to do so. The GNU Lesser General Public License gives
 permission to release a modified version without this exception; this
 exception also makes it possible to release a modified version which 
carries

 forward this exception.


This is fair enough, but I want to close out the LGPL conversation. The 
FAQ
specifically discusses GPLv2 and GPLv3 and not LGPL, and I'll claim 
that's because
it doesn't apply. The fact that a third party can take LGPL ffmpeg and 
combine it
with proprietary code in certain ways means that clearly we can do so as 
well. it
would be highly illogical to conclude that section 6/7 do not apply to 
the original
code itself and that we need to construct a separate entity that does 
the combination

for it to be licence compliant.

--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> It does.

[citation needed]

> Multimedia files can't be executed, only decoded.

Define the difference.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 10:50, Hendrik Leppkes wrote:
> On Sat, Dec 12, 2015 at 10:39 AM, Andreas Cadhalpun
>  wrote:
>> On 12.12.2015 01:46, Philip Langdale wrote:
>>> On 2015-12-12 00:03, Andreas Cadhalpun wrote:
 On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
> My point is that so far several people have said that if nvenc
> is a system library there is no issue (and I fully agree). I
> didn't see a mail (and even less a patch with a commit message
> that says so) that claims nvenc is a system library (only that
> it "should" be one).

 So let's ask: Is someone here who claims that nvenc is a system
 library and can explain why?
>>>
>>> I'm not going to claim it's a system library.
>>
>> Interesting...
>>
>>> I'm, instead, going to
>>> ask why we're having this conversation about nvenc, when the qsx/mfx
>>> situation is exactly the same.
>>
>> We have this conversation, because someone sent a patch to enable it
>> by default, together with including the header and removing the
>> 'die_license_disabled nonfree nvenc' line.
>>
>>> The functionality is provided by a
>>> proprietary set of modules that are part of the intel driver on windows
>>> and a separate (almost undiscoverable) download on linux (actually,
>>> that's worse than nvenc where the functionality is shipped with the
>>> driver in both cases). The only structural difference is that ffmpeg
>>> links against a wrapper library for mfx and dlopens in the nvenc
>>> case, but because of your following statement, that cannot make any
>>> difference.
>>
>> Since this requires the mfx wrapper to link, it is not enabled by
>> default. As the license situation seems similar, it might be a good idea
>> to add a 'die_license_disabled nonfree libmfx' line. But these don't have
>> any effect on the legal situation anyway, they are just a help
>> for our users.
>>
> I am glad we agree that there is no difference (license-wise) if
> a library is linked statically, dynamically or via dynamic
> loading;-)

 There is that, at least. ;-)
>>>
>>> Oh, and do you know what's funny - I just realised that the primary ffmpeg
>>> code base is LGPL and not GPL, so this whole conversation is slighlty
>>> pointless.
>>
>> No, it's not, because the LGPL and GPL are very similar in terms of the
>> requirements about distributing object code of (L)GPL-ed source code.
>>
>>> Combining ffmpeg with proprietary libraries is covered under section 6 and
>>> section 7,
>>
>> These sections only cover "work that uses the Library" (defined in section 
>> 5),
>> not the Library itself.
>>
>>> so even if building the nvenc codec is considered to combine
>>> ffmpeg with nvenc in this sense, it would be acceptable. The key requirement
>>> is that the LGPL covered parts can be rebuilt and modified as desired, and
>>> that is certainly true.
>>>
>>> These sections are generally thought of as enabling a larger proprietary
>>> program to pull in an LGPL library, but the language is symmetric.
>>
>> No, see section 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"
>>
>>> Note that I actually don't believe with have a GPL problem here,
>>
>> Why?
>>
>>> but as a step forward, if we can all agree that the nvenc codec is a valid
>>> part of an lgpl build of ffmpeg, that's a step forward.
>>
>> I don't agree with that interpretation, see above explanation.
>>
> 
> We should just add an exception into the license to explicitly allow
> using it with the NVIDIA CUDA library and be done with this debate for
> ever.

That would be an option.

> You know that Open-Source has failed when the project itself is
> arguing days and days for including a feature on license reasons that
> any closed-source app would just write, enable and offer to its users
> without a second thought.

Please try to take a step back.
The "nvenc" feature is already included in FFmpeg, just not enabled by
default.

Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 14:42, Nicolas George wrote:
> Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> It does.
> 
> [citation needed]

Is in a previous mail.

>> Multimedia files can't be executed, only decoded.
> 
> Define the difference.

I'm not continuing this silly conversation.
You can look up the meaning of words in a dictionary.

Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 01:46, Philip Langdale wrote:
> On 2015-12-12 00:03, Andreas Cadhalpun wrote:
>> On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
>>> My point is that so far several people have said that if nvenc
>>> is a system library there is no issue (and I fully agree). I
>>> didn't see a mail (and even less a patch with a commit message
>>> that says so) that claims nvenc is a system library (only that
>>> it "should" be one).
>>
>> So let's ask: Is someone here who claims that nvenc is a system
>> library and can explain why?
> 
> I'm not going to claim it's a system library.

Interesting...

> I'm, instead, going to
> ask why we're having this conversation about nvenc, when the qsx/mfx
> situation is exactly the same.

We have this conversation, because someone sent a patch to enable it
by default, together with including the header and removing the
'die_license_disabled nonfree nvenc' line.

> The functionality is provided by a
> proprietary set of modules that are part of the intel driver on windows
> and a separate (almost undiscoverable) download on linux (actually,
> that's worse than nvenc where the functionality is shipped with the
> driver in both cases). The only structural difference is that ffmpeg
> links against a wrapper library for mfx and dlopens in the nvenc
> case, but because of your following statement, that cannot make any
> difference.

Since this requires the mfx wrapper to link, it is not enabled by
default. As the license situation seems similar, it might be a good idea
to add a 'die_license_disabled nonfree libmfx' line. But these don't have
any effect on the legal situation anyway, they are just a help
for our users.

>>> I am glad we agree that there is no difference (license-wise) if
>>> a library is linked statically, dynamically or via dynamic
>>> loading;-)
>>
>> There is that, at least. ;-)
> 
> Oh, and do you know what's funny - I just realised that the primary ffmpeg
> code base is LGPL and not GPL, so this whole conversation is slighlty
> pointless.

No, it's not, because the LGPL and GPL are very similar in terms of the
requirements about distributing object code of (L)GPL-ed source code.

> Combining ffmpeg with proprietary libraries is covered under section 6 and
> section 7,

These sections only cover "work that uses the Library" (defined in section 5),
not the Library itself.

> so even if building the nvenc codec is considered to combine
> ffmpeg with nvenc in this sense, it would be acceptable. The key requirement
> is that the LGPL covered parts can be rebuilt and modified as desired, and
> that is certainly true.
> 
> These sections are generally thought of as enabling a larger proprietary
> program to pull in an LGPL library, but the language is symmetric.

No, see section 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"

> Note that I actually don't believe with have a GPL problem here,

Why?

> but as a step forward, if we can all agree that the nvenc codec is a valid
> part of an lgpl build of ffmpeg, that's a step forward.

I don't agree with that interpretation, see above explanation.

Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Hendrik Leppkes]

On Sat, Dec 12, 2015 at 10:39 AM, Andreas Cadhalpun
 wrote:
> On 12.12.2015 01:46, Philip Langdale wrote:
>> On 2015-12-12 00:03, Andreas Cadhalpun wrote:
>>> On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
 My point is that so far several people have said that if nvenc
 is a system library there is no issue (and I fully agree). I
 didn't see a mail (and even less a patch with a commit message
 that says so) that claims nvenc is a system library (only that
 it "should" be one).
>>>
>>> So let's ask: Is someone here who claims that nvenc is a system
>>> library and can explain why?
>>
>> I'm not going to claim it's a system library.
>
> Interesting...
>
>> I'm, instead, going to
>> ask why we're having this conversation about nvenc, when the qsx/mfx
>> situation is exactly the same.
>
> We have this conversation, because someone sent a patch to enable it
> by default, together with including the header and removing the
> 'die_license_disabled nonfree nvenc' line.
>
>> The functionality is provided by a
>> proprietary set of modules that are part of the intel driver on windows
>> and a separate (almost undiscoverable) download on linux (actually,
>> that's worse than nvenc where the functionality is shipped with the
>> driver in both cases). The only structural difference is that ffmpeg
>> links against a wrapper library for mfx and dlopens in the nvenc
>> case, but because of your following statement, that cannot make any
>> difference.
>
> Since this requires the mfx wrapper to link, it is not enabled by
> default. As the license situation seems similar, it might be a good idea
> to add a 'die_license_disabled nonfree libmfx' line. But these don't have
> any effect on the legal situation anyway, they are just a help
> for our users.
>
 I am glad we agree that there is no difference (license-wise) if
 a library is linked statically, dynamically or via dynamic
 loading;-)
>>>
>>> There is that, at least. ;-)
>>
>> Oh, and do you know what's funny - I just realised that the primary ffmpeg
>> code base is LGPL and not GPL, so this whole conversation is slighlty
>> pointless.
>
> No, it's not, because the LGPL and GPL are very similar in terms of the
> requirements about distributing object code of (L)GPL-ed source code.
>
>> Combining ffmpeg with proprietary libraries is covered under section 6 and
>> section 7,
>
> These sections only cover "work that uses the Library" (defined in section 5),
> not the Library itself.
>
>> so even if building the nvenc codec is considered to combine
>> ffmpeg with nvenc in this sense, it would be acceptable. The key requirement
>> is that the LGPL covered parts can be rebuilt and modified as desired, and
>> that is certainly true.
>>
>> These sections are generally thought of as enabling a larger proprietary
>> program to pull in an LGPL library, but the language is symmetric.
>
> No, see section 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"
>
>> Note that I actually don't believe with have a GPL problem here,
>
> Why?
>
>> but as a step forward, if we can all agree that the nvenc codec is a valid
>> part of an lgpl build of ffmpeg, that's a step forward.
>
> I don't agree with that interpretation, see above explanation.
>

We should just add an exception into the license to explicitly allow
using it with the NVIDIA CUDA library and be done with this debate for
ever.
You know that Open-Source has failed when the project itself is
arguing days and days for including a feature on license reasons that
any closed-source app would just write, enable and offer to its users
without a second thought.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Philip Langdale a écrit :
> it would be highly illogical to conclude that section 6/7 do not apply to
> the original code itself and that we need to construct a separate entity
> that does the combination for it to be licence compliant.

It would be fairly illogical to conclude that any clause in the license,
either GPL or LGPL, requires us to worry about the specifics of a file we do
not know anything about since it resides on the user's system.

We only have to worry about the files that were used to build the binary.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 14:29, Nicolas George wrote:
> Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> However, the (L)GPL has a rule that allows distribution of a
>> binary only together with the complete corresponding source code,
>> that also includes the source code of any dynamically loaded
>> library needed at run-time.
> 
> No, it does not.

It does.

> Dynamically-loaded libraries are not part of the binary.

I haven't claimed that.

>> Multimedia files are no library of executable code.
> 
> Define the difference.

You're arguments are getting silly.
Multimedia files can't be executed, only decoded.
Try to convince any judge otherwise.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Hendrik Leppkes]

On Sat, Dec 12, 2015 at 11:25 AM, Andreas Cadhalpun
 wrote:
> On 12.12.2015 10:50, Hendrik Leppkes wrote:
>> On Sat, Dec 12, 2015 at 10:39 AM, Andreas Cadhalpun
>>  wrote:
>>> On 12.12.2015 01:46, Philip Langdale wrote:
 On 2015-12-12 00:03, Andreas Cadhalpun wrote:
> On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
>> My point is that so far several people have said that if nvenc
>> is a system library there is no issue (and I fully agree). I
>> didn't see a mail (and even less a patch with a commit message
>> that says so) that claims nvenc is a system library (only that
>> it "should" be one).
>
> So let's ask: Is someone here who claims that nvenc is a system
> library and can explain why?

 I'm not going to claim it's a system library.
>>>
>>> Interesting...
>>>
 I'm, instead, going to
 ask why we're having this conversation about nvenc, when the qsx/mfx
 situation is exactly the same.
>>>
>>> We have this conversation, because someone sent a patch to enable it
>>> by default, together with including the header and removing the
>>> 'die_license_disabled nonfree nvenc' line.
>>>
 The functionality is provided by a
 proprietary set of modules that are part of the intel driver on windows
 and a separate (almost undiscoverable) download on linux (actually,
 that's worse than nvenc where the functionality is shipped with the
 driver in both cases). The only structural difference is that ffmpeg
 links against a wrapper library for mfx and dlopens in the nvenc
 case, but because of your following statement, that cannot make any
 difference.
>>>
>>> Since this requires the mfx wrapper to link, it is not enabled by
>>> default. As the license situation seems similar, it might be a good idea
>>> to add a 'die_license_disabled nonfree libmfx' line. But these don't have
>>> any effect on the legal situation anyway, they are just a help
>>> for our users.
>>>
>> I am glad we agree that there is no difference (license-wise) if
>> a library is linked statically, dynamically or via dynamic
>> loading;-)
>
> There is that, at least. ;-)

 Oh, and do you know what's funny - I just realised that the primary ffmpeg
 code base is LGPL and not GPL, so this whole conversation is slighlty
 pointless.
>>>
>>> No, it's not, because the LGPL and GPL are very similar in terms of the
>>> requirements about distributing object code of (L)GPL-ed source code.
>>>
 Combining ffmpeg with proprietary libraries is covered under section 6 and
 section 7,
>>>
>>> These sections only cover "work that uses the Library" (defined in section 
>>> 5),
>>> not the Library itself.
>>>
 so even if building the nvenc codec is considered to combine
 ffmpeg with nvenc in this sense, it would be acceptable. The key 
 requirement
 is that the LGPL covered parts can be rebuilt and modified as desired, and
 that is certainly true.

 These sections are generally thought of as enabling a larger proprietary
 program to pull in an LGPL library, but the language is symmetric.
>>>
>>> No, see section 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"
>>>
 Note that I actually don't believe with have a GPL problem here,
>>>
>>> Why?
>>>
 but as a step forward, if we can all agree that the nvenc codec is a valid
 part of an lgpl build of ffmpeg, that's a step forward.
>>>
>>> I don't agree with that interpretation, see above explanation.
>>>
>>
>> We should just add an exception into the license to explicitly allow
>> using it with the NVIDIA CUDA library and be done with this debate for
>> ever.
>
> That would be an option.
>
>> You know that Open-Source has failed when the project itself is
>> arguing days and days for including a feature on license reasons that
>> any closed-source app would just write, enable and offer to its users
>> without a second thought.
>
> Please try to take a step back.
> The "nvenc" feature is already included in FFmpeg, just not enabled by
> default.
>

And not enabled on any distribution, hence 99% of all users don't see
it or get to use it.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 14:03, Nicolas George wrote:
> Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> I don't agree as I have already explained previously.
> 
> Fortunately, your arguments have no legal standing.

Neither have yours.

> The (L)GPL does not have a rule against distributing a binary that can load
> a proprietary file.

However, the (L)GPL has a rule that allows distribution of a
binary only together with the complete corresponding source code,
that also includes the source code of any dynamically loaded
library needed at run-time.

> That would make ffmpeg all but useless, I hope you
> realize that, because most of the licenses for the multimedia files
> themselves are GPL-incompatible.

Multimedia files are no library of executable code.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
> On Friday 11 December 2015 12:16:48 am Andreas Cadhalpun wrote:
>> Well, the problem is that the answer may depend on the system.
> 
> If Nvidia offers Graphics Driver for download on its ftp server 
> for multiple operating systems, they are either system libraries 
> or not, I really don't see how this can depend on the operating 
> system.

For reference, here is the system library exception from LGPL-2.1 [1]:
"However, as a special exception, the materials to be distributed need
not include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on)
of the operating system on which the executable runs, unless that
component itself accompanies the executable."

So in general, there can be operating systems were Nvidia's blobs
are normally distributed together with e.g. the kernel and others
were this is not the case.

> I don't see any reason why the fact that these drivers 
> have to (or can) be downloaded by the user does not make them 
> system libraries.

When running ffmpeg on Debian (main), where these Nvidia blobs
are not present and not needed (because nouveau is used as driver),
no component of the operating system, major or not,
has been distributed with Nvidia's blobs, so the system library
exception does not apply.

I'm not sure about the situation for Windows.

> My point is that so far several people have said that if nvenc 
> is a system library there is no issue (and I fully agree). I 
> didn't see a mail (and even less a patch with a commit message 
> that says so) that claims nvenc is a system library (only that 
> it "should" be one).

So let's ask: Is someone here who claims that nvenc is a system
library and can explain why?

> I am glad we agree that there is no difference (license-wise) if 
> a library is linked statically, dynamically or via dynamic 
> loading;-)

There is that, at least. ;-)

Best regards,
Andreas


1: https://www.gnu.org/licenses/lgpl-2.1-standalone.html

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Philip Langdale]

On 2015-12-12 00:03, Andreas Cadhalpun wrote:

On 11.12.2015 09:41, Carl Eugen Hoyos wrote:

On Friday 11 December 2015 12:16:48 am Andreas Cadhalpun wrote:

Well, the problem is that the answer may depend on the system.


If Nvidia offers Graphics Driver for download on its ftp server
for multiple operating systems, they are either system libraries
or not, I really don't see how this can depend on the operating
system.


For reference, here is the system library exception from LGPL-2.1 [1]:
"However, as a special exception, the materials to be distributed need
not include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on)
of the operating system on which the executable runs, unless that
component itself accompanies the executable."

So in general, there can be operating systems were Nvidia's blobs
are normally distributed together with e.g. the kernel and others
were this is not the case.


I don't see any reason why the fact that these drivers
have to (or can) be downloaded by the user does not make them
system libraries.


When running ffmpeg on Debian (main), where these Nvidia blobs
are not present and not needed (because nouveau is used as driver),
no component of the operating system, major or not,
has been distributed with Nvidia's blobs, so the system library
exception does not apply.

I'm not sure about the situation for Windows.


My point is that so far several people have said that if nvenc
is a system library there is no issue (and I fully agree). I
didn't see a mail (and even less a patch with a commit message
that says so) that claims nvenc is a system library (only that
it "should" be one).


So let's ask: Is someone here who claims that nvenc is a system
library and can explain why?


I'm not going to claim it's a system library. I'm, instead, going to
ask why we're having this conversation about nvenc, when the qsx/mfx
situation is exactly the same. The functionality is provided by a
proprietary set of modules that are part of the intel driver on windows
and a separate (almost undiscoverable) download on linux (actually,
that's worse than nvenc where the functionality is shipped with the
driver in both cases). The only structural difference is that ffmpeg
links against a wrapper library for mfx and dlopens in the nvenc
case, but because of your following statement, that cannot make any
difference.


I am glad we agree that there is no difference (license-wise) if
a library is linked statically, dynamically or via dynamic
loading;-)


There is that, at least. ;-)


Oh, and do you know what's funny - I just realised that the primary 
ffmpeg

code base is LGPL and not GPL, so this whole conversation is slighlty
pointless.

Combining ffmpeg with proprietary libraries is covered under section 6 
and

section 7, so even if building the nvenc codec is considered to combine
ffmpeg with nvenc in this sense, it would be acceptable. The key 
requirement
is that the LGPL covered parts can be rebuilt and modified as desired, 
and

that is certainly true.

These sections are generally thought of as enabling a larger proprietary
program to pull in an LGPL library, but the language is symmetric.

Note that I actually don't believe with have a GPL problem here, but as 
a
step forward, if we can all agree that the nvenc codec is a valid part 
of

an lgpl build of ffmpeg, that's a step forward.

--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Carl Eugen Hoyos]

On Friday 11 December 2015 12:16:48 am Andreas Cadhalpun wrote:
> On 11.12.2015 00:03, Carl Eugen Hoyos wrote:
> > On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote:
> >> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab
> >>
> >>  die_license_disabled nonfree libaacplus
> >>  die_license_disabled nonfree libfaac
> >> -die_license_disabled nonfree nvenc
> >
> > Sorry, but this makes absolutely no sense imo:
> > I asked you if nvenc is a system library and your answer did
> > not indicate that you are certain it is a system library (and
> > I did ask you if I maybe misunderstood your answer),
>
> Well, the problem is that the answer may depend on the system.

If Nvidia offers Graphics Driver for download on its ftp server 
for multiple operating systems, they are either system libraries 
or not, I really don't see how this can depend on the operating 
system. I don't see any reason why the fact that these drivers 
have to (or can) be downloaded by the user does not make them 
system libraries.

My point is that so far several people have said that if nvenc 
is a system library there is no issue (and I fully agree). I 
didn't see a mail (and even less a patch with a commit message 
that says so) that claims nvenc is a system library (only that 
it "should" be one).

I am glad we agree that there is no difference (license-wise) if 
a library is linked statically, dynamically or via dynamic 
loading;-)

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Hendrik Leppkes]

On Fri, Dec 11, 2015 at 12:03 AM, Carl Eugen Hoyos  wrote:
> On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote:
>> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab
>>
>>  die_license_disabled nonfree libaacplus
>>  die_license_disabled nonfree libfaac
>> -die_license_disabled nonfree nvenc
>
> Sorry, but this makes absolutely no sense imo:
> I asked you if nvenc is a system library and your answer did
> not indicate that you are certain it is a system library (and
> I did ask you if I maybe misunderstood your answer),
>
> If it is not a system library, you must not remove this line.
>
> If it is a system library, please enable auto-detection as we
> already have enough untested features and as we generally do
> autodetect system libraries.
>

You should read the entire discussion, we have already touched on all
of these points.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Philip Langdale]

On 2015-12-08 02:53, Timo Rothenpieler wrote:
Nvidia finaly decided to put a propper MIT license on their nvenc 
header, so

it can be included, removing any external dependencies for nvenc and
making it no longer require the non-free flag.

nvenc.h is the original nvEncodeApi.h from the NVENC SDK 6.0.1, with a
slight modification to make it work on cygwin.


Works for me.

--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Carl Eugen Hoyos]

On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote:
> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab
>
>  die_license_disabled nonfree libaacplus
>  die_license_disabled nonfree libfaac
> -die_license_disabled nonfree nvenc

Sorry, but this makes absolutely no sense imo:
I asked you if nvenc is a system library and your answer did 
not indicate that you are certain it is a system library (and 
I did ask you if I maybe misunderstood your answer),

If it is not a system library, you must not remove this line.

If it is a system library, please enable auto-detection as we 
already have enough untested features and as we generally do 
autodetect system libraries.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 11.12.2015 00:03, Carl Eugen Hoyos wrote:
> On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote:
>> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab
>>
>>  die_license_disabled nonfree libaacplus
>>  die_license_disabled nonfree libfaac
>> -die_license_disabled nonfree nvenc
> 
> Sorry, but this makes absolutely no sense imo:
> I asked you if nvenc is a system library and your answer did 
> not indicate that you are certain it is a system library (and 
> I did ask you if I maybe misunderstood your answer),

Well, the problem is that the answer may depend on the system.

> If it is not a system library, you must not remove this line.
> 
> If it is a system library, please enable auto-detection as we 
> already have enough untested features and as we generally do 
> autodetect system libraries.

What should be done if it is a system library on Windows, but
not on Debian?

Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel