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.

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.

> 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"?

Obviously he wants do to this in public.

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

Really? o_O

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?

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