Media Player .NET (MPDN) - D3D HQ GPU Video Renderer [v2.49.0/v1.31.0 27 Dec 2018]

[Zachs]

Just a quick heads up. I've added OpenCL NNEDI3 as a prescaler of SuperRes.
You'll need to delete "%localappdata%\MediaPlayerDotNet\RenderScripts.x??\SuperRes.config" again for this option to appear after you've downloaded the new scripts from GitHub.

[nekromantik]

To upscale anything to 4k is this chain good enough? if not any suggestions.

NNEDI -> SuperChromaRes + NNEDI

[Zachs]

I'm not sure I understand your script chain at all.
Specifically what does NNEDI -> SuperChromaRes + NNEDI mean?

[nekromantik]

I'm not sure I understand your script chain at all.
Specifically what does NNEDI -> SuperChromaRes + NNEDI mean?

Sorry ignore the + NNEDI.

It goes NNEDI image doubling and then SuperChromaRes upscaling.
Or is SuperRes with NNEDI and then SuperChromaRes better?

[Zachs]

You have to scale chroma before you can use any render script upscalers. SuperChromaRes has to come before NNEDI in your case. I usually do deband right after chroma upscaling, then followed by NNEDI3 with SuperRes (very low strength). Even when running NNEDI3 with 64 neurons on my gtx680, I still find SuperRes to increase image quality both in sharpening and reducing aliasing.

[nekromantik]

You have to scale chroma before you can use any render script upscalers. SuperChromaRes has to come before NNEDI in your case. I usually do deband right after chroma upscaling, then followed by NNEDI3 with SuperRes (very low strength). Even when running NNEDI3 with 64 neurons on my gtx680, I still find SuperRes to increase image quality both in sharpening and reducing aliasing.

Thanks will give that a go.

[Shiandow]

Hi there! I made some changes to the renderscripts again, based on the feedback on the MadVR thread and some of things madshi noticed while implementing them.

A short summary:
- Tried to improve the quality of the debanding, it should have less artifacts around edges and might be slightly faster.
- SuperChromaRes now works in rgb, this should improve quality and be slightly faster, although the anti-ringing still needs some work, it'll work correctly, but the performance isn't too good at the moment.
- Some minor performance tweaks / fixes to SuperRes and SuperChromaRes.
- Better defaults for SuperRes and SuperChromaRes.

[Zachs]

Hmm just found out madVR is in violation of the LGPL license (section 4d and/or 4e) - i.e. including the source isn't enough. Section 4d requires that the user be able to modify the LGPL source and have the app run the modified version and/or link to it. MadVR is also in violation of section 4c which requires that it displays a proper copyright notice. The ancillaries required to run those shaders have also been converted to closed source, which is also in violation of LGPL.

On a similar note, it would appear that its NNEDI3 implementation is also in violation of LGPL, as changing the included source in the zip file won't affect madVR's implementation. The original NNEDI3 OpenCL source code by SEt is LGPL and is in full compliance with LGPL.

[Anima123]

I hate to mention it, especially in such a circumstance, but, using NEDI with SuperRes via madVR does not suffer from rendering time increasing for my laptop.

[Zachs]

Seeing as no one else with Optimus has seen this problem, could it be something to do with your .NET installation?

[Anima123]

How can I tell if my .NET is damned? Any suggestions on how to get a 'clean' installation of it?

[ryrynz]

How can I tell if my .NET is damned? Any suggestions on how to get a 'clean' installation of it?

.NET Framework Repair Tool (https://www.microsoft.com/en-us/download/details.aspx?id=30135)

[madshi]

Hmm just found out madVR is in violation of the LGPL license (section 4d and/or 4e) - i.e. including the source isn't enough. Section 4d requires that the user be able to modify the LGPL source and have the app run the modified version and/or link to it. MadVR is also in violation of section 4c which requires that it displays a proper copyright notice. The ancillaries required to run those shaders have also been converted to closed source, which is also in violation of LGPL.

On a similar note, it would appear that its NNEDI3 implementation is also in violation of LGPL, as changing the included source in the zip file won't affect madVR's implementation. The original NNEDI3 OpenCL source code by SEt is LGPL and is in full compliance with LGPL.
Ok, sorry. I thought providing the source code would be enough. I will do the necessary changes in the next build. FWIW, I'm only using Shiandow's code, not yours, and he had allowed me via PM to hard code his algorithms into madVR as a stop-gap measure until my own "extended custom shader" feature is implemented. Anyway, as I said, it was not my intention to violate any licenses, so I'll fix that.

BTW, since you mentioned NNEDI3: I think MPDN is in violation, too. The OpenCL kernel is LGPL, but the weight database is GPL. SEt wrote a "new" kernel, so he probably had the right to license it under LGPL (and I'm happy that he did), but he didn't recreate the weights, so the weights are still part of the original NNEDI3 package, which is GPL. Nobody can recreate the weights because that part of NNEDI3 was never published, not even under GPL, AFAIK. tritical has explicitly allowed me to use the weights in closed source madVR. Has he allowed that for MPDN, too?

[Zachs]

Uh, you do understand what GPL is, don't you? They cover source code, not data files. And the weights are freely available on GitHub from Avisynth plugin source. Unless Tritical makes specific mention of the use of the trained datasets, I'm not sure how you could claim it cannot be used.

[Zachs]

Btw MPDN does not have NNEDI3.

[Zachs]

Also your NNEDI3 is based on SEt's source which is LGPL. Whether or not you have permission from tritical isn't relevant at all.

[madshi]

The GPL says: "“The Program” refers to any copyrightable work licensed under this License". I see no limitation to source code. E.g. there are also icons available under GPL (e.g. http://genericons.com). From what I can see, tritical has released the whole NNEDI3 package under GPL, which AFAICS would include the weights. See here:

http://bengal.missouri.edu/~kes25c/

You do understand that the weights are the very core of the NNEDI3 algorithm? The kernel we're using is just a small part of NNEDI3. The weights are where all the magic comes from. Without the weights the kernel is just an empty shell. And whether or not something is "freely available" on some website has no effect on licenses - unless tritical has officially changed his license on that website.

Anyway, I'm out of here. I wouldn't have said anything about your use of the NNEDI3 weights. But since you seemed so interested in clearing up any NNEDI3 related legal issues, I thought I'd mention this potential issue, too...

[Belphemur]

Ok, sorry. I thought providing the source code would be enough. I will do the necessary changes in the next build. FWIW, I'm only using Shiandow's code, not yours, and he had allowed me via PM to hard code his algorithms into madVR as a stop-gap measure until my own "extended custom shader" feature is implemented. Anyway, as I said, it was not my intention to violate any licenses, so I'll fix that.

BTW, since you mentioned NNEDI3: I think MPDN is in violation, too. The OpenCL kernel is LGPL, but the weight database is GPL. SEt wrote a "new" kernel, so he probably had the right to license it under LGPL (and I'm happy that he did), but he didn't recreate the weights, so the weights are still part of the original NNEDI3 package, which is GPL. Nobody can recreate the weights because that part of NNEDI3 was never published, not even under GPL, AFAIK. tritical has explicitly allowed me to use the weights in closed source madVR. Has he allowed that for MPDN, too?

If we come to the Licenses used, and from my understanding. The version of SEt can't be LGPL, it's a violation of the GPL license of the original NNEDI3 that is under GPL.

GPLv2 is a very restrictive license asking the developer that use a GPL lib/source code to be GPL also. In other word, if SEt used even a fraction of the code of NNEDI3, he can't release it as LGPL but must use the same license (since you can only go to more and more restrictive). This is were the first mistake was done.

Again, this my understanding of the way the license work, it can be wrong, and I'd be happy to be corrected.

NNEDI Orignal : http://forum.doom9.org/showthread.php?t=147695
OpenCL SEt : http://forum.doom9.org/showthread.php?t=169766

License compatibility : https://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing

[Zachs]

Thanks for bringing that to my attention. I am very serious about licensing issues, especially when it comes to free software as I fully believe all credits should always be given to the rightful owners.

However, I'll quote SEt and my believe is in line with his.

Somewhat unknown issue is nnedi3 nn coefficients data: no idea how they are related to licenses since it's not a code. Preprocessed but conceptually unchanged version of them is currently embeded in dll. If tritical has any issues with current situation – I'm ready to listen.

And another quote from yourself,

FWIW, many months ago I had asked tritical about implementing NNEDI3 in madVR, even though madVR is closed source, and he allowed it. So it seems to me he's quite generous with licensing issues, so I don't think you need to worry about that part. Haven't heard from him in a while, though. Not sure if he's still around...

And another from tritical (from your link above),

All filters presented here are either licensed under the GPL or have no license at all (check the source code) *** operative keywords - source code.

The weights we're using for MPDN extensions (see note1) are similar to SEt's preprocessed ones. They came from tritical's bin file. While the whole package is GPL, SEt chose to not open source the coefficients and it is his believes that it does not fall under GPL. MPDN extensions have not put any explicit licenses on it so it falls under the default license which is LGPL. This can be changed though and MPDN extension's NNEDI3 would simply be GPL.

note1: MPDN is render script agnostic - in fact, MPDN does not come distributed with MPDN extensions. This is no different from a user using AviSynth (GPL) and have madVR (closed source) render the frames served. Or the fact that madVR users can use MPC-HC's pixel shader filters.

However, the issue still remains that you can't claim the files you have are under LGPL license when in fact you have not adhered to the licensing terms. This applies for madVR's NNEDI3 code, which as you've said,
SEt wrote a "new" kernel, so he probably had the right to license it under LGPL and your code is based on his OpenCL version.

I'm just trying to make sure everyone respects free software licenses.

[Zachs]

If we come to the Licenses used, and from my understanding. The version of SEt can't be LGPL, it's a violation of the GPL license of the original NNEDI3 that is under GPL.

GPLv2 is a very restrictive license asking the developer that use a GPL lib/source code to be GPL also. In other word, if SEt used even a fraction of the code of NNEDI3, he can't release it as LGPL but must use the same license (since you can only go to more and more restrictive). This is were the first mistake was done.

Strictly speaking that is correct - but it does fall into a bit of a grey area. GPL is not the right license to use from the very beginning (I'm sure if tritical picks a license today he'd have picked LGPL since he was creating an AviSynth plugin), seeing as it's for programs (read applications) rather than libraries (which LGPL was specifically created to address). So anything that isn't suitably covered by GPL (e.g. icons) falls under that grey area. There's something called the spirit of a contract when lawyers write them up. The spirit of GPL is to make sure the program as a whole and/or any parts of it do not become closed source (LGPL's spirit is inline with GPL in this regard, and naturally so). However, it's being used as a viral licensing term in recent years.

LGPL has a more user-centric spirit, which is why MPDN extensions use it. It mandates that everything that has been done to it can be modified by the end-user (for fixing bugs, optimizing etc.) without having the need to recompile or have access to the host app. However, taking away users' ability to change LGPL portions of the code definitely violates the very spirit of LGPL.

[Belphemur]

Strictly speaking that is correct - but it does fall into a bit of a grey area. GPL is not the right license to use from the very beginning (I'm sure if tritical picks a license today he'd have picked LGPL), seeing as it's for programs (read applications) rather than libraries (which LGPL was specifically created to address). So anything that isn't suitably covered by GPL (e.g. icons) falls under that grey area. There's something called the spirit of a contract when lawyers write them up. The spirit of GPL is to make sure the program as a whole and/or any parts of it do not become closed source. However, it's being used as a viral licensing term in recent years.

LGPL has a more user-centric spirit, which is why MPDN extensions use it. It mandates that everything that has been done to it can be modified by the end-user (for fixing bugs, optimizing etc.) without having the need to recompile or have access to the host app. However, taking away users' ability to change LGPL portions of the code definitely violates the very spirit of LGPL.

From what I learned LGPL is mostly for libraries since it mean you can use it (when provided with the location of the source and a copy of the licence) in any program under any licence (when used in a compiled version). It was created to keep the open-source spirit but still let proprietary solution use it without stealing.

Of course, if you modify it, you need to republish it and provide it to the end-user but just using it, you need to give credit and it need to be separate from the rest of your code.

Edit: If you put NNEDI3 as GPL, it can't be used in MPDN since the license will propagate to it. (or that's my understanding of GPL) : https://programmers.stackexchange.com/questions/158789/can-i-link-to-a-gpl-library-from-a-closed-source-application

[Shiandow]

Ok, sorry. I thought providing the source code would be enough. I will do the necessary changes in the next build. FWIW, I'm only using Shiandow's code, not yours, and he had allowed me via PM to hard code his algorithms into madVR as a stop-gap measure until my own "extended custom shader" feature is implemented. Anyway, as I said, it was not my intention to violate any licenses, so I'll fix that.

It seems the LGPL license was slightly more restrictive than I thought, regardless I'd still prefer if you could make MadVR's use compatible with it. So, just to clear up any ambiguity. If you could make it possible to "relink" the shader files as outlined in LGPL in the next build and implement them using the "extended custom shader" support when it is ready, then I have no issues with MadVR using those algorithms (Debanding, Superes and SuperChromaRes).

[Zachs]

Nobody can recreate the weights because that part of NNEDI3 was never published, not even under GPL, AFAIK.

From what I can see, tritical has released the whole NNEDI3 package under GPL, which AFAICS would include the weights.

So what are you actually saying?

[Zachs]

It seems the LGPL license was slightly more restrictive than I thought, regardless I'd still prefer if you could make MadVR's use compatible with it. So, just to clear up any ambiguity. If you could make it possible to "relink" the shader files as outlined in LGPL in the next build and implement them using the "extended custom shader" support when it is ready, then I have no issues with MadVR using those algorithms (Debanding, Superes and SuperChromaRes).

I have no issues with that too for any of MPDN's extension files.
Like I said, I'm just trying to make sure the license is respected. LGPL only helps, not hinder - e.g. the typical dev gets run over by a bus scenario, any LGPL portions can still be updated.

[Zachs]

From what I learned LGPL is mostly for libraries since it mean you can use it (when provided with the location of the source and a copy of the licence) in any program under any licence (when used in a compiled version). It was created to keep the open-source spirit but still let proprietary solution use it without stealing.

Of course, if you modify it, you need to republish it and provide it to the end-user but just using it, you need to give credit and it need to be separate from the rest of your code.

Edit: If you put NNEDI3 as GPL, it can't be used in MPDN since the license will propagate to it. (or that's my understanding of GPL) : https://programmers.stackexchange.com/questions/158789/can-i-link-to-a-gpl-library-from-a-closed-source-application

Well it'll be the user 'linking' it then, in the same manner as anyone who's using MPC-HC's GPL shader files in madVR.

[Belphemur]

It seems the LGPL license was slightly more restrictive than I thought, regardless I'd still prefer if you could make MadVR's use compatible with it. So, just to clear up any ambiguity. If you could make it possible to "relink" the shader files as outlined in LGPL in the next build and implement them using the "extended custom shader" support when it is ready, then I have no issues with MadVR using those algorithms (Debanding, Superes and SuperChromaRes).

All the code that you wrote, that is not based on any other code, you have full control on the license AND on the written permission. You can give madvr a permission to MadVR to use your code in his environment/program.

Even the GPL state this :

10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.

[Belphemur]

Well it'll be the user 'linking' it then, in the same manner as anyone who's using MPC-HC's GPL shader files in madVR.

yeah that's the tricky part ... because in the end your program DOES use GPL content which mean, it should be under GPL.

In the case of MPDN extension, as you said, they are under LGPL, MDPN then link to LGPL extension, that's perfectly fine. Now for MadVR and the MPC-HC Gpl, madvr should then be also under GPL ... or ask for a permission from MPC-HC to not be GPL.

[madshi]

It seems the LGPL license was slightly more restrictive than I thought
Seems we had the same incomplete idea of how LGPL worked. :) Well, a day we don't learn something new is a day wasted, I guess...

regardless I'd still prefer if you could make MadVR's use compatible with it. So, just to clear up any ambiguity. If you could make it possible to "relink" the shader files as outlined in LGPL in the next build and implement them using the "extended custom shader" support when it is ready, then I have no issues with MadVR using those algorithms (Debanding, Superes and SuperChromaRes).
Sure, of course I will do that. Hope to have a new build out today which should be fully LGPL compliant. And thanks again for your nice algos.

So what are you actually saying?
Sorry, I guess my wording has been a bit unclear. Let me try again:

tritical has run thousands (or ten or hundred thousands, I don't remember) of images through some neural network software, to create those weights. Basically this "server side" software has analyzed all those images, extracted edge information from them and somehow fused them into the weight database we're using. The NEDI kernel we're using practically could be considered the "client side" software which just uses the weight database to interpolate images. tritical has released the client side software and the weight database under GPL, but he has not released the server side software with which he created the weights at all. Because of that nobody can create a different/new/updated set of weights. All the NNEDI3 magic is hidden in those weights, they are the center piece of the algorithm.

So to sum up, the client side of the NNEDI3 algorithm is available as GPL, which IMHO includes the weights. The server side is not available at all.

But my understanding is that tritical is actually quite generous. I had asked him about using NNEDI3 in madVR before the OpenCL kernel even existed, and he was ok with that. I think he would most probably allow SEt and the MPDN extensions to use NNEDI3, too, in their current form as LGPL. So maybe you could just PM him to make sure. The key problem is that tritical hasn't been on doom9 for a long time, so it might be difficult to get a reply from him.

If we come to the Licenses used, and from my understanding. The version of SEt can't be LGPL, it's a violation of the GPL license of the original NNEDI3 that is under GPL.
To be honest, I was wondering about that, too. But since I had the "ok" from tritical for using NNEDI3 in madVR, it didn't matter much to me. SEt's kernel being LGPL practically meant that SEt was fine with me using it in madVR (as long as I'm compliant with LGPL, of course). And tritical was fine with it, too, so I was covered in any case.

Now for MadVR and the MPC-HC Gpl, madvr should then be also under GPL ... or ask for a permission from MPC-HC to not be GPL.
Well, I do not distribute MPC-HC, nor do I link in any part of MPC-HC. It's not madVR using MPC-HC. It's the other way round. madVR is also not a plugin to MPC-HC, it's simply an official DirectShow renderer which anyone can use who wants to use it. I don't see how that would have any legal effect on madVR. I mean Microsoft also doesn't have to publish their EVR sources as GPL, just because MPC-HC uses EVR, right?

[Shiandow]

All the code that you wrote, that is not based on any other code, you have full control on the license AND on the written permission. You can give madvr a permission to MadVR to use your code in his environment/program.

Isn't that what I just did? I made a somewhat limited exception to whatever parts of LPGL are currently violated. It was limited on purpose though, to avoid introducing any more ambiguity.

[nevcairiel]

Well, I do not distribute MPC-HC, nor do I link in any part of MPC-HC. It's not madVR using MPC-HC. It's the other way round. madVR is also not a plugin to MPC-HC, it's simply an official DirectShow renderer which anyone can use who wants to use it. I don't see how that would have any legal effect on madVR. I mean Microsoft also doesn't have to publish their EVR sources as GPL, just because MPC-HC uses EVR, right?

The entire concept of COM used in DirectShow obfuscates any licensing borders.
By using COM, individual components are never directly linked, and only communicate through a defined and common API.

Its probably impossible for anyone of us to answer if that requires compatible licenses, unless one here is an experienced copyright/license lawyer, and even then if someone would try this in court, it could IMHO go both ways.

Commercial products tend to avoid shipping GPL components like LAV Filters directly, but instead recommend simply installing them manually.

[Belphemur]

To be honest, I was wondering about that, too. But since I had the "ok" from tritical for using NNEDI3 in madVR, it didn't matter much to me. SEt's kernel being LGPL practically meant that SEt was fine with me using it in madVR (as long as I'm compliant with LGPL, of course). And tritical was fine with it, too, so I was covered in any case.


I think we can also assume tritical have also provided the same kind of permission to SEt. (Let's assume be because ... GPL ... is really one of the messier license where it's OpenSource by OpenSource for OpenSource (which is nice but tricky), that's why they came with LGPL)


Well, I do not distribute MPC-HC, nor do I link in any part of MPC-HC. It's not madVR using MPC-HC. It's the other way round. madVR is also not a plugin to MPC-HC, it's simply an official DirectShow renderer which anyone can use who wants to use it. I don't see how that would have any legal effect on madVR. I mean Microsoft also doesn't have to publish their EVR sources as GPL, just because MPC-HC uses EVR, right?

No of course not, it's a one-way relation. You use GPL, you are GPL. If you're under GPL you can use proprietary software/lib/etc ...

This part of the comment was about the claim of Zachs you use some of the Shader code of MPC-HC, if it's the case, the GPL license propagate to MadVr if you don't have the same kind of permission you got from tritical.

(some light of the GPLv3 : http://blog.milkingthegnu.org/2008/04/gpl-for-dummies.html)
In the case you said with EVR, since EVR is a system lib, no problem else ... it's tricky again ... GPL is really more an ideal than anything else ... and if I'm right, haven't been tested in court either.

Anyway, for that nevcairiel cleared up the question, and well the API is provided by the system.

Isn't that what I just did? I made a somewhat limited exception to whatever parts of LPGL are currently violated. It was limited on purpose though, to avoid introducing any more ambiguity.

Yeap, I just meant, the agreement you did before with madvr was already enough ;)

[madshi]

I'm not directly using any MPC-HC shader code in madVR. What Zachs meant is that users can setup MPC-HC to send shader code to madVR via an official custom shader interface.

FWIW, I've also asked the LumaSharpen and FineSharp devs (both AviSynth and HLSL), and they were all ok with me using the shaders in madVR. Really, I thought I had everything covered and thought that I did everything correctly. I just wasn't aware of those extended LGPL requirements. I'm working on fixing that right now.

[Belphemur]

I'm not directly using any MPC-HC shader code in madVR. What Zachs meant is that users can setup MPC-HC to send shader code to madVR via an official custom shader interface.

FWIW, I've also asked the LumaSharpen and FineSharp devs (both AviSynth and HLSL), and they were all ok with me using the shaders in madVR. Really, I thought I had everything covered and thought that I did everything correctly. I just wasn't aware of those extended LGPL requirements. I'm working on fixing that right now.

Sorry, I misunderstood that part.

To be honest, all those license are really complicated and usually an MIT or BSD license is enough to cover you as a developer and give right to other dev to use your work in any kind of settings (with correct credit). The best part of those permissive license, if you feel other are not respecting your work, you can then change the license to a less permissive one.

Anyway, you've done nothing wrong, maybe it would have been better that Zachs sent you an MP instead of posting it here, even if it triggered an interesting conversation on the different licenses used.

[Zachs]

Well, I do not distribute MPC-HC, nor do I link in any part of MPC-HC. It's not madVR using MPC-HC. It's the other way round. madVR is also not a plugin to MPC-HC, it's simply an official DirectShow renderer which anyone can use who wants to use it. I don't see how that would have any legal effect on madVR. I mean Microsoft also doesn't have to publish their EVR sources as GPL, just because MPC-HC uses EVR, right?

No, but that's the thorny issue with GPL - when user supplies madVR with GPL'ed shader files via GPL'ed MPC-HC, violation happens. I'm just not sure who is violating the license. The same applies for NNEDI3 for MPDN if it remains GPL. Since tritical is unreachable for years now, I guess leaving it as LGPL isn't too bad since it has the same spirit as GPL, and where MPDN's NNEDI3 implementation goes, the whole thing is LGPL'ed.

There are plenty of ways GPL violation could occur - and they do all the time without the user knowing it - e.g. Using Windows Media Player with LAV Filter is a violation.

Like I said, GPL wasn't meant to be used for libraries, let alone binary files that have weights in them or shader files that can be used in other apps. They can be copyrighted, but GPL is the wrong license for it.

I work for a global corporation with access to and have been trained frequently by lawyers specializing in patents, copyright and licensing laws. We avoid GPL code like the plague. Think of LGPL is the 'bug-fixed' version of GPL if you like.

[Belphemur]

No, but that's the thorny issue with GPL - when user supplies madVR with GPL'ed shader files via GPL'ed MPC-HC, violation happens. I'm just not sure who is violating the license. The same applies for NNEDI3 for MPDN if it remains GPL. Since tritical is unreachable for years now, I guess leaving it as LGPL isn't too bad since it has the same spirit as GPL, and where MPDN's NNEDI3 implementation goes, the whole thing is LGPL'ed.

There are plenty of ways GPL violation could occur - and they do all the time without the user knowing it - e.g. Using Windows Media Player with LAV Filter is a violation.

Like I said, GPL wasn't meant to be used for libraries, let alone binary files that have weights in them or shader files that can be used in other apps. They can be copyrighted, but GPL is the wrong license for it.

I work for a global corporation with access to and have been trained frequently by lawyers specializing in patents, copyright and licensing laws. We avoid GPL code like the plague. Think of LGPL is the 'bug-fixed' version of GPL if you like.

As nevcairiel pointed out, it's not a violation to use LAV with Windows media player, same that madvr is not in violation when used with MPC-HC.

They all implement a system API, the way the module communicate together is through the system, they are not linked together neither provided as a package. It's the system doing the link, in that case, no violation ensue ... because else, you could go sue Microsoft just because you installed a GPL software on it ... it wouldn't make any sense.

[Zachs]

Commercial products tend to avoid shipping GPL components like LAV Filters directly, but instead recommend simply installing them manually.

That's because company lawyers like what we have in our company would be considering it a 'derivative work' - they believe COM is no different from calling something directly as a DLL. Recommending a manual install is a very dangerous practice too.

[madshi]

Well, I guess we can close the issue here. The next madVR build should be fully LGPL compliant (if not, let me know, maybe I missed something again). @Zachs, if I may suggest: Send a PM to tritical, but keep things in MPDN as they are. Then he has the chance to complain, and you did all you could. If he doesn't complain, all is well. My 2cents, at least...

[nevcairiel]

That's because company lawyers like what we have in our company would be considering it a 'derivative work' - they believe COM is no different from calling something directly as a DLL. Recommending a manual install is a very dangerous practice too.

Well if you believe that, then MPDN violates LAVs GPL. Can i haz moneyz noaw? :D

[Zachs]

As nevcairiel pointed out, it's not a violation to use LAV with Windows media player, same that madvr is not in violation when used with MPC-HC.

They all implement a system API, the way the module communicate together is through the system, they are not linked together neither provided as a package. It's the system doing the link, in that case, no violation ensue ... because else, you could go sue Microsoft just because you installed a GPL software on it ... it wouldn't make any sense.

WMP with LAV filter is considered a violation - in fact that's the very example those lawyers used. This is the very reason nev said commercial software don't include LAV filters.

madVR in MPC-HC is a different matter - that's the opposite of WMP with LAV Filters. What I said before was user using MPC-HC shaders in madVR.

[Belphemur]

That's because company lawyers like what we have in our company would be considering it a 'derivative work' - they believe COM is no different from calling something directly as a DLL. Recommending a manual install is a very dangerous practice too.

But technically speaking, it's not even linked with it ... neither loading it, since it's done through the system.

That's always what bother me with legal and technical ... two differents reality.

[Zachs]

Well, I guess we can close the issue here. The next madVR build should be fully LGPL compliant (if not, let me know, maybe I missed something again). @Zachs, if I may suggest: Send a PM to tritical, but keep things in MPDN as they are. Then he has the chance to complain, and you did all you could. If he doesn't complain, all is well. My 2cents, at least...

Oh I did more than half a year ago, I'll try again now that MPDN extensions include NNEDI3.

Well if you believe that, then MPDN violates LAVs GPL. Can i haz moneyz noaw? :D

Sure but you'd have to sue me first :)
I was talking about the licensing terms in the strictest terms where big corporations are concerned. And the whole point was to say that GPL is the wrong license to use - perhaps consider LGPL for LAV? Commercial apps would have no problem including it.

[nevcairiel]

LAV was originally based on partial GPL code from MPC-HCs old built-in filters, if anything or how much of that remains is impossible to say - but it also makes it impossible to relicense it LGPL without a lot of research.

[Zachs]

But technically speaking, it's not even linked with it ... neither loading it, since it's done through the system.

That's always what bother me with legal and technical ... two differents reality.

Yeah it's dynamically loading it (yes it's loaded, it has to be - ask Nev). The mechanism that loads it is besides the point - technically it's still loaded. What companies tend to do is ask the user to install LAV filters on their own so it's the users violating the GPL license, not them (but advising the users would land them in legal troubles).

[madshi]

Oh well, it's sad tritical appears to be "gone". He was working on NNEDI4 at some point (although from what I saw the improvement compared to NNEDI3 was very small), and on a sharpener based on NNEDI technology.

[Zachs]

Oh well, it's sad tritical appears to be "gone". He was working on NNEDI4 at some point (although from what I saw the improvement compared to NNEDI3 was very small), and on a sharpener based on NNEDI technology.

Yeah. I was monitoring his "last activity" since before I started MPDN...
It still remains at "22nd December 2013 03:55".

[Belphemur]

LAV was originally based on partial GPL code from MPC-HCs old built-in filters, if anything or how much of that remains is impossible to say - but it also makes it impossible to relicense it LGPL without a lot of research.

For what I understood, if you can contact the authors of the code you used and get a permission to re-license that part under LGPL, you should be okay ...

In that case, you need to put both license specifying until which version the GPL apply and from which version the LGPL apply.

Speaking of license, I saw that ffmpeg also have a tricky licensing system : https://github.com/FFmpeg/FFmpeg/blob/master/LICENSE.md

[Zachs]

BTW, giving special permissions as permitted by GPL is also a sketchy clause (there's no such provision under LGPL by the way) - if Nev were to say MPDN could include LAV Filters as MIT, then if someone uses the LAV Filters from MPDN, but in the source is in every way similar to the GPL version, would they be in violation? See why companies avoid GPL now? :)

[nevcairiel]

For what I understood, if you can contact the authors of the code you used and get a permission to re-license that part under LGPL, you should be okay ...
I'm aware, which brings it back to the "research" point, first finding the code which is not mine, and then tracing back the original authorship (or re-writing it). Sounds like days of boring work. Anyone volunteer? :p
I have tried to get rid of some of the old code since it was mostly hacks which were better suited properly re-implemented inside ffmpeg, but some are still present.


Speaking of license, I saw that ffmpeg also have a tricky licensing system : https://github.com/FFmpeg/FFmpeg/blob/master/LICENSE.md

While FFmpeg includes code under varying licenses, you basically specify which license you want at build-time, and it'll only build code that is available under that license, resulting in properly licensed binaries.

LAV already uses a LGPL build of FFmpeg, fwiw.

[Zachs]

Ah now I remember, I never succeeded in sending tritical any PMs because it was full the first time I tried, and it is still full now!

[madshi]

Argh, that's bad. Is there a known email address? I don't remember...