Topic: SVPFlow plugins source

Hi, I am developer of MVTools software (plugin for Avisynth) since 2005,
see my site at http://avisynth.org.ru/mvtools/mvtools2.html

1. I consider SVP plugins (not only SVPFlow1 but also SVPFlow2.dll and early LibFlowsse.dll) as derivative work (fork) of original MVTools2 code.
In particular my MVFlow.cpp, MVFlowFps.cpp, Maskfun.cpp files contain code for video "smoothing" by pixel motion interpolation (in a time) based on analyzed motion of blocks.

"SVP team" (Chainik) copied and read original MVTools code.
Then they used this code to implemented new DLL with code optimization, renaming, reordering, translating to other language (compiler), adopting to other interface and so on.
Your contribution is great but it is not independent but derivative work.

2. MVTools is free software distributed with source code under GNU GPL.

GNU GP License v2. Clause  2.  b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program (MVTools) or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.

3. So, I ask for source code of SVPFlow plugins. (not SVP manager).

4. All other known mods of MVTools (for Avisynth and Vaporsynth) are distributed without this issue.


Regards, Fizick.

Re: SVPFlow plugins source

All code that was taken from MVTools (cleaned, refactored and optimized) - was placed into svpflow1.dll, which is licensed under GPL.

svpflow2.dll is the completely different from M***Fps functions implementation of the base idea "move pixels by the motion vectors".
It's not the fork of MVTools. It's not using any piece of code from MVTools.

Yes, it was inspired by MVTools, but I believe that "inspiration" is not covered by the GPL.

3 (edited by Fizick 05-04-2016 20:09:08)

Re: SVPFlow plugins source

There are several issues with your last declaration.

1. How to check (beleve) that your code SVPFlow2 is completely different and is not "refactored" MFlowFPS?

2. You cirtanly have read not only MVTools documentation to be "inspired" by algos, but full source code too.
For example, Libflow.h from your (not recent) MVtools 2.5.11.9 package http://www.svp-team.com/files/gpl/mvtoo … .9-svp.zip contains the information:
    AlgoFast_1dir =1,//MFlow "1-dir"
    AlgoFast_2dir =2,//MFlow "2-dir"
    AlgoNoMask1 =11,//MBlockFps, mode=0
    AlgoNoMask2 =12,//MBlockFps, mode=1
    AlgoNoMask3 =13,//MBlockFps, mode=2
    AlgoSimple =21, //like FlowInterSimple from MaskFun.cpp OR MBlockFps, mode=3
    AlgoNormal =22, //FlowInter
    AlgoExtended=23, //FlowInterExtra
Same (or almost same) are presented in modern SVPFLow2 too.
I am in doubt that SVP team used "Clean Room" to re-implement the algos.

3. As I wrote in first post, the translation to other language, else  assembler or pascal from C or even from Avisynth script language (e.g. Youshko GPL script)

is derivative (for significant portions, not one word of course).

4 There are also other issues (linking, artifical separating, distribution, moral).

BTW, I could consider to give you some special permission to use portions of MVTools (MFlow) in some parts (e.g. GPU-related.) under close-source license.
But you never asked for it and I prefer that somebody else could be inspired by SVPFlow and its code.

Re: SVPFlow plugins source

Just as a daily user here. And it's none of my business. But I recommend you guys finish this discussion in private. So you can message each other freely (via email or using the forum messages).

But I hope as a user you guys come to a solution for this problem, if there even is a problem. Who knows maybe you can all work together and improve everything.

Regards, Blackfyre.

Re: SVPFlow plugins source

Oh boy, here we go.

For what it's worth, I hope ya'll work something out. GPL licenses deserve to be respected, but no-one wants to see all of SVP's work and awesomeness go down over a license issue.

@Blackfyre
I agree, I think this should be a private discussion. But Fizick might want the discussion to be public since it's a GPL license issue, not 100% sure.

Re: SVPFlow plugins source

brucethemoose wrote:

@Blackfyre

I agree, I think this should be a private discussion. But Fizick might want the discussion to be public since it's a GPL license issue, not 100% sure.

I understand. And if the truth needs to come out (if there's anything wrong going on) either one or both parties can disclose what was written in private.

But I hope they come to an agreement because like you, I never wish for this project to end. We need it, the whole community needs it, and I hope all parties involved understand the importance of this.

I wish to see all the developers working together and helping each other achieve better things.

Re: SVPFlow plugins source

> 1. How to check (beleve) that your code SVPFlow2 is completely different and is not "refactored" MFlowFPS?

Not our business. It's your obligation to prove that it IS NOT different.


> Same (or almost same) are presented in modern SVPFLow2 too.

Yeah. But consider this: all these "algos" are just a simple (very simple) algebra formulas.
For example the "AlgoNoMask1 =11,//MBlockFps, mode=0" is just as follows:

R = A*t + B*(1-t)

and "AlgoFast_1dir =1,//MFlow "1-dir" is

R = A*t

Do you really want to say that every other code that uses those trivial formulas are now violates MVTools' GPL? Really? o_O


> 3. As I wrote in first post, the translation to other language, else  assembler or pascal from C or even from Avisynth script language (e.g. Youshko GPL script)

And again. "Youshko" script is a complex Avisynth script with some masks extraction and other stuff.
"SAD masking" in svpflow is just an another variable added to the algebra formulas mentioned above.
Can you see the difference? In what universe this can be defined as a "translation to other language"?


Blackfyre wrote:

But I recommend you guys finish this discussion in private. So you can message each other freely (via email or using the forum messages).

Obviously he wants do to this in public.

Re: SVPFlow plugins source

We have had private discussion with Chainik about 5 years ago.
I pointed to several GPL violations. Some was corrected.
But in main points (svpflowsse.dll itself and its linking at that time) we did not get in agreement.
Finally I wrote that will wait for about two years with hope that the SVP code will be opened in order to somebody else could contribute.
In last years several people privately asked me about this issue and my position.
That is why I posted it to public forum. And because SVPFlow is become more and more closed.

And I still do do get clear answer to my questions besides strange double eggs o_O

(And AlgoExtended=23, //FlowInterExtra
is not so simple)

Blackfyre, brucethemoose,
I do not want to close SVP. On contrary, I want to open it (portion of it) or at least resolve the issue.

Re: SVPFlow plugins source

> I still do do get clear answer to my questions besides strange double eggs o_O

Really? o_O big_smile

Ok then, one more time:

> 1. How to check (beleve) that your code SVPFlow2 is completely different and is not "refactored" MFlowFPS?

It's totally up to you.

> 2. ... I am in doubt that SVP team used "Clean Room" to re-implement the algos.

Don't be in doubt.

> 3. ... the translation to other language, else  assembler or pascal from C or even from Avisynth script language (e.g. Youshko GPL script)

There're no "translations to other languages", especially in case of "Youshko GPL script'.

> 4. There are also other issues ...

> linking

What about linking?

> artifical separating

Sorry, I don't get it, could you rephrase the question?

> distribution

As you may notice, GPLd library is distributed via downloadable package and IS NOT included into the distribution file.

> moral

Yeah, lets talk about moral!

As you're a way stronger in GPL than I am, so please, here're a few questions:

Program 1:

int main() {
     return strlen("four")-1;
}

Program 2:

int main() {
    return 3;
}

Both programs get the same input and produce the same output.

- Do you think that "Program 2" is a derivative work of "Program 1"?
- If yes, do you think it's moral for the developer of "Program 1" to insist on the GPL violation by the author of "Program 2"?

=============
If we (ok, I) wanted to steal something from you (or from "the community", whatever), SVP 4 was just a great point to announce switching to "completely new in-house developed Avisynth plugin". Why the hell I am even playing in all these games with GPLd svpflow1?

10 (edited by nemoW 06-04-2016 18:13:29)

Re: SVPFlow plugins source

Chainik wrote:
Blackfyre wrote:

But I recommend you guys finish this discussion in private. So you can message each other freely (via email or using the forum messages).

Obviously he wants do to this in public.

...and in international forum section despite both are Russians.

Re: SVPFlow plugins source

to Chainik.

1. See 10.

2. Really I am no in doubt: Chainik is the only SVPFlow lib developer at  http://www.svp-team.com/wiki/Credits
Have anybody else from SVP team the full source code?

4. Linking.
4a) Unlike Avisynth.h header, there is no any special exception in MVTools code license which permits static or dynamic linking closed library with any MVTools parts.
http://www.gnu.org/licenses/gpl-faq.en. … atibleLibs
For example, older libflowsse.dll linking to MVTools is (was) not compatible with GPL (even it is not derivative itself).

4b) new SVPFlow2 shares some memory (e.g. structures) with SVPFlow1, and therefore communication is not "solely via avisynth.h interface".
4c) Possible usage some classes in SVPFlow2.dll from SVPFlow1 or MVTools.

5 Artifical separating.
MVTools is single package as whole. You separated it by two parts to try avoid GPL.

6 Distribution.
Again "all is fine" answer like a robot.
May be I missed something but where is a link to svpflow1 source code at http://www.svp-team.com/wiki/Download ?
See also your "packages" at SVP Russian download page.

But if you will properly distribute your GPL parts "after court's decision only" ("только по решению суда" in Russian, from your post
https://www.svp-team.com/forum/viewtopi … 537#p36537 )
then it is not my problem to teach you about GPL.

7. a) MVTools really includes very simple code lines, but there are many lines.
b) GPL is virulent. It is well known.

8. Games with svpflow1.
Probably it is not easy to rewrite optimised assember code from x264 project used in MAnalyse (and SVPflow1).

9 Moral.
Respecting to authors of MVTools it is not attribution and credits (unlike BSD license) but following their intention (free open source library).

10.
There are many "small" "partial" "not 100%" "not proved" possible violations of GPL.
It is quite possible that recent SVP lib are more consistent with GPL, but may be not.
SVP-team give me not so many options to check it especially if
"SVP libs must not be decompiled, disassembled, reverse engineered or otherwise modified."

Bottom line. Possible options to resolve the issue:
1. Easy. Open full source of SVPFlow2 under GPL.
2. Intermediate (not final). Privately (under non-disclose agreement) send source code to me to check the absence of GPL violations, with discussions and corrections after.
3. Sort of compromise. Consider refactoring of SVPlow2. Separate and open code part derivative on MVTools (inspired), e.g. with SSE shader or (new?) C shader (not empty wrapper).  Other parts may be closed DLL with special link permission (exception).
4. Suggest your. (privately if you prefer).

Re: SVPFlow plugins source

Current progress:
Sort of option 2. Intermediate (not final) above.
I privately have got from Chainik some part of SVPFlow2 source code for consideration.