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

[Anima123]

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

[ryrynz]

Originally Posted by Anima123

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

.NET Framework Repair Tool

[madshi]

Originally Posted by 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.

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]

Originally Posted by madshi

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_Ge...ulti-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.

Originally Posted by SEt

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,

Originally Posted by madshi

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]

Originally Posted by Belphemur

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]

Originally Posted by Zachs

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.co...ce-application

[Shiandow]

Originally Posted by madshi

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]

Originally Posted by madshi

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

Originally Posted by madshi

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]

Originally Posted by Shiandow

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]

Originally Posted by Belphemur

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.co...ce-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]

Originally Posted by Shiandow

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]

Originally Posted by Zachs

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]

Originally Posted by Shiandow

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...

Originally Posted by Shiandow

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.

Originally Posted by Zachs

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.

Originally Posted by Belphemur

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.

Originally Posted by Belphemur

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]

Originally Posted by Belphemur

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]

Originally Posted by madshi

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.