2019-02-19 20:25 GMT+01:00, Soft Works :
>> > From your explanations, the situation doesn't seem to be as
>> > bad as it could be. When the CPU code of the filters can be
>> > changed to dynamic linking
>>
>> The type of the linking of course cannot change the license.
>
> Maybe I should have said
On 2019-02-19 11:25, Soft Works wrote:
> From your explanations, the situation doesn't seem to be as
> bad as it could be. When the CPU code of the filters can be
> changed to dynamic linking
The type of the linking of course cannot change the license.
Maybe I should have said 'dynamic loading
> > From your explanations, the situation doesn't seem to be as
> > bad as it could be. When the CPU code of the filters can be
> > changed to dynamic linking
>
> The type of the linking of course cannot change the license.
Maybe I should have said 'dynamic loading' rather than 'dynamic
linking'.
2019-02-18 22:44 GMT+01:00, Soft Works :
> From your explanations, the situation doesn't seem to be as
> bad as it could be. When the CPU code of the filters can be
> changed to dynamic linking
The type of the linking of course cannot change the license.
Carl Eugen
__
> > Thanks again for your kind reply. Although I’m not a lawyer myself, I
> > know
> > that if you’re the sole(!) author of the yadif_cuda kernel source, then
> > you
> > would be allowed to publish that code under any additional license you
> > want.
> >
> > But that would be your very own decisi
On 2019-02-18 20:08, Soft Works wrote:
Thanks again for your kind reply. Although I’m not a lawyer myself, I
know
that if you’re the sole(!) author of the yadif_cuda kernel source, then
you
would be allowed to publish that code under any additional license you
want.
But that would be your
> > At least from my understanding it would be perfectly legal to exclude
> > the CUDA kernel code from ffmpeg and add an option to the filters
> > for specifying a file containing the compiled CUDA kernel to be loaded
> > at runtime (via cuModuleLoadData).
> >
> > What do you think?
>
> It's certa
On Mon, 18 Feb 2019 21:44:33 +
Soft Works wrote:
>
> Hi Phil,
>
> thanks for replying. I was just about to start migrating the filters
> to dynamic loading (nv-codec-headers)..
>
> From your explanations, the situation doesn't seem to be as bad as it
> could be. When the CPU code of the fi
> > in the above context I'm wondering about whether it is mandatory to
> > treat the "cuda_sdk" option as a non-free option?
> >
> > In case of libnpp it's obviously required to statically link to
> > proprietary Nvidia code code for which there's not public source code
> > available.
> >
> > But
On Sun, 17 Feb 2019 06:24:05 +
Soft Works wrote:
> Hi,
>
> in the above context I'm wondering about whether it is mandatory to
> treat the "cuda_sdk" option as a non-free option?
>
> In case of libnpp it's obviously required to statically link to
> proprietary Nvidia code code for which the
> On 5/12/2017 5:21 AM, Timo Rothenpieler wrote:
> Am 12.05.2017 um 15:34 schrieb James Almer:
> > On 5/12/2017 5:21 AM, Timo Rothenpieler wrote:
> >> Am 12.05.2017 um 07:32 schrieb Yogender Gupta:
> > +cuda_sdk
> > libnpp
> >>>
> >>> IMO, Libnpp is part of the CUDA SDK, and we ca
11 matches
Mail list logo
