Search options

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

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.