ok, will see if I can reproduce it here
Yes, happening here as well with After Effects CC. It is due to the plugin architecture changes introduced by Adobe - it is working fine with AE CS6 (which I used to test). Will try to fix it in the next days!
Playing devils advocate here but is this permitted by the CeCILL license?
Afaik CeCILL is a copy left license with similar provisions to the GPL that would require After Effects (or at the very least it’s SDK) to be released under a compatible license?
Thanks Jonas for your comment! Actually this is what I have been working on with David for some time now to allow G’MIC to work with third party applications.
First of all, there are several CeCILL license types: CeCILL-A (like GPL), CeCILL-B (like BSD) and CeCILL-C (comparable to LGPL, so more permissive).
As you said, the problem was for example that for creating these plugins, I need to include sources from the Adobe After Effects SDK or the OpenFX SDK/API that are not compatible in distribution with the G’MIC CeCILL license.
We came up with the following approach to this:
-
The G’MIC main distribution contains two new targets in the make file (‘libc’ and ‘staticlibc’) for creating a pure C interface of the G’MIC functionality that I have written. As this is part of the G’MIC sources, code is under CeCILL-A license.
-
There is an interface in the G’MIC community repository (GitHub - dtschump/gmic-community: Community contributions to the G'MIC software) that I have written that allows accessing this library from external applications without linking to G’MIC. These files are put under a dual license: CeCILL-C (close to LGPL) and CeCILL-A (GPL-compatible).
-
Finally, my plugins here are calling only the functions from the wrapper above, but do not link directly against the G’MIC sources. In fact, they do not have any dependencies on G’MIC at all and just use the functionality of a binary G’MIC release if present on the user’s system. I do however provide my sources as well under a CeCILL-C license.
This should hopefully allow combining G’MIC functionality with other licensing types.
Just to be more precise about the potential licensing problem.
Tobias, I’ve never wanted to make the G’MIC license more permissive for proprietary software. I find your OpenFX plug-ins project terrific, mainly for the use in the open-source software Natron. I’ve just asked you to make your G’MIC bridge code available with the more permissive license CeCILL-C (close to LGPL) for practical reasons (I was building the gmic-community repo at that time, and this is a license I wanted to favor for this particular repository).
The CeCILL license used by G’MIC is a free license, compatible with the GPL. One of the important thing to understand about it is how the notion of Module is defined. The license says:
Module: means a set of sources files including their documentation that enables supplementary functions or services in addition to those offered by the Software.
External Module: means any or all Modules, not derived from the Software, so that this Module and the Software run in separate address spaces, with one calling the other when they are run.
Internal Module: means any or all Module, connected to the Software so that they both execute in the same address space.
and the license defines a Contribution by:
Contribution: means any or all modifications, corrections, translations, adaptations and/or new functions integrated into the Software by any or all Contributors, as well as any or all Internal Modules.
And then, the rules for distributing and licensing those so-called Modules are:
5.3.3 DISTRIBUTION OF EXTERNAL MODULES
When the Licensee has developed an External Module, the terms and conditions of this Agreement do not apply to said External Module, that may be distributed under a separate license agreement.
This is the unconstrained way of using G’MIC. Just use it as an external module, and you can license your own code using it as you want (including proprietary and closed licenses if you wish).
For Internal modules, it’s a bit more complicated. Creating an Internal Module is in fact considered as a Contribution the the initial Software, and the Software becomes thus a Modified Software and is subject to these redistribution rules, as stated by the license:
5.3.2 DISTRIBUTION OF MODIFIED SOFTWARE
When the Licensee makes a Contribution to the Software, the terms and conditions for the distribution of the resulting Modified Software become subject to all the provisions of this Agreement.
The Licensee is authorized to distribute the Modified Software, in source code or object code form, provided that said distribution complies with all the provisions of the Agreement and is accompanied by:
a copy of the Agreement,
a notice relating to the limitation of both the Licensor’s warranty and liability as set forth in Articles 8 and 9,
and, in the event that only the object code of the Modified Software is redistributed,
a note stating the conditions of effective access to the full source code of the Modified Software for a period of at least three years from the distribution of the Modified Software, it being understood that the additional acquisition cost of the source code shall not exceed the cost of the data transfer.
which is clearly the viral aspect of the license, just as it works with the GPL too (that’s why both licenses can be considered as compatible by the way).
So, the question is now : should an OpenFX plug-in be considered as an Internal Module or an External Module ? (does it run on the same address space than the host software?). I really don’t know enough about how the OpenFX architecture works to have a clear opinion on that question, but this is certainly something we need to investigate. The answer actually depends on the fact that an OpenFX plug-in is run as an external process or not (just as it is done in GIMP for instance).
In any case, I know at least one software that you can freely use to run OpenFX plug-ins without worrying about these licensing problems, it’s Natron, and at least just for this one, it is worth releasing these OpenFX plug-ins based on G’MIC. If someone else wants to use these plug-ins for another software and are not allowed to do so, I think he has to take his responsibilities.
What do you think?
Thanks for clarification, David!
In my opinion, it is clearly an external module. It calls functionality that is not present when compiling, relying upon that the G’MIC binary distribution is present with its C DLL somewhere on the user’s system/path. That is more or less the same (again, in my opinion), as writing a simple UI frontend that just calls the standard gmic.exe process in the background. This approach has also been a very common way to work around the MP3 licensing issues: many software for encoding, decoding or simply playing MP3 files contained no code at all in their applications for that, but relied on installed codecs or DLLs present from others, like LAME or Fraunhofer, or in later Windows versions the DLL that Microsoft included themselves.
The problem as far as I can see it is that the CeCIL uses address space to (essentially) define what an external module is. And and least literally interpreting that leads me to believe that a after effects plugin would be in violation of the license.
I agree with you to the extent that I personally think that definition is fairly absurd. I’m not a lawyer, and I don’t know how french copyright law operates. I’m forced to assume that the people who wrote the license had a much better understanding of the issues than I do.
Still to me it implies that when for instance After Effects loads the Plugin into it’s address space (via DLL) After Effects becomes an internal module of G’MIC and would need to follow the rules of the CeCIL. On the other hand a piece of software called ‘The G’MIC gui’ that does nothing but expose the functionality of G’MIC but runs it in a sub process would be considered a separate work. The whole notion of address space opens another can of worms. For instance the IP address space can very well be considered an address space. So does sharing the same IP address space now imply being an internal module? The same goes for a whole lot of other things in computing.
I personally try to avoid the GPL for libraries for this reason (among others). But I do also understand that there are benefits, especially when pursuing a dual licensing strategy.
Well, what about a batch file that sends commands to the G’MIC interpreter? That is more or less what the AE plugin is doing as well. AE loads the plugin DLL, which in turn sends command to the external G’MIC C interface which then sends it to G’MIC. The idea of address spaces and modules is really difficult to consider in a license in my opinion as well.
If anyone has a better solution/approach/idea to this, please let me know 
AE loads the plugin DLL, which in turn sends command to the external G’MIC C interface which then sends it to G’MIC.
I guess the question is how the sending commands to the external c interface part works. If it lives in the same process it’s at least according to the licence an issue, if it’s running in another process it is not (that’s at least the most reasonable interpretation of address space I can come up with).
Yes, under that “adress space” definition they share it (as that is what DLLs do), but that seems really awkward in terms of defining a license. What about piping (standard) input and output using the console/shell like the G’MIC CLI does, here all processes run in the “same” address space of the operating system and share data? It would make much more sense (again, in my humble opinion) to define these license cases according to how intertwined they are, e.g. if they are part of another application or not. In the AfterEffects plugin case for example, the whole binary G’MIC DLL comes from the official distribution and can be replaced with newer versions without having to recompile the plugins.
Again, I am very open to how to handle this licensing case best, any input appreciated!
I also looked into how other plugin developers handle this, but sadly, most don’t seem to care. There are successful (commercial, closed-source) AfterEffects wrapper plugins for FFMPEG for example that do not seem to adhere to any license. Which is obviously what I want to prevent
Mmmh, I see there are several free After Effects plugins licensed under GPL, e.g.:
http://www.andrewdavidson.com/aeflame/
Also, an AE plugin for the popular OpenColorIO (proprietary license by Sony) exists that also does not seem to conflict with the Adobe SDK: http://opencolorio.org/License.html
Then again, Adobe pretty much explicitly forbids open source licenses in their AE SDK (http://www.adobe.com/devnet/aftereffects/sdk/cc2017/eula.html) :
"6. Open Source Software.
Developer is not licensed to (and Developer agrees not to) integrate or use the SDK, other than third-party software described in Section 14.6, with any Open Source Software in a manner that requires disclosure, distribution or licensing of all or any part of the SDK in source code form, for the purpose of making derivative works, or at no charge. For the purposes of this Section 6, “Open Source Software” shall mean software licensed under the GNU General Public License, GNU Affero General Public License (AGPL), the GNU Lesser General Public License or any other license terms that could require, or condition Developer’s use, modification or distribution of such software on, the disclosure, distribution or licensing of any other software in source code form, for the purpose of making derivative works, or at no charge. Any violation of the foregoing provision shall immediately terminate all of Developer’s licenses and other rights to the SDK granted under this Agreement."
Although this is also an official statement from Adobe, encouraging you to do so:
http://blogs.adobe.com/notesfrommnr/2006/04/using_adobe_sdk.html
Using any code licensed under GPL or similar (opposed to LGPL or similar) would probably invalidate that permission from the license side though: http://www.linuxquestions.org/questions/programming-9/gpl-license-questions-338920/
Good news: making some more steps forwards to making this even better: the After Effects plugins now seem to work fine with automation and parameter changes again, also in the latest Adobe CC releases. The OpenFX plugins no longer revert to only one plugin visible after a crash. Descriptions work much better now and several other changes and improvements have been added. Expect a new release soonish
New release here (binaries for After Effects and OpenFX plugin hosts for Windows) with lots of bugfixes:
http://reduxfx.com/gmic/rfx_gmic_plugin_0.2b.zip
Updated sources are available in the G’MIC community repository now under a dual license (CeCILL-A and CeCILL-C)…
[quote=“Tobias_Fleischer, post:52, topic:452”]
Yes, under that “adress space” definition they share it (as that is what DLLs do), but that seems really awkward in terms of defining a license.
[/quote]I totally agree. As far as I can tell the only ‘safe’ (ish) way to get around the license constraint is to run the two applications in separate processes and to use IPC to communicate between the processes. Now at least from what I know the usual way to do low latency high throughput IPC is via shared memory so there we go again.
I think a better solution is to just talk to @David_Tschumperle assuming that he is the single copyright holder of G’MIC.
At least in my opinion you are clearly following the spirit of the license and as far is I know ‘wo kein Kläger, da kein Richter’ (No plaintiff, no judge) applies to copyright issues so that should solve the issue iff David agrees.
Yes, of course I talked with David about it already
And my intention is not to exploit it commercially (nor let others do it), so both sources and binaries will be distributed freely.
Hello Tobias,
Your last beta is fine everything works in the changes, for years I waited to see it in After. Thank you!
I tried the previous “bug” on this version, everything is stable so it doesnt appear anymore; but I just wanted to talk a little about the results this config can give. I tried this effect, generally at 64%, on a lot a different types of pictures and it’s much much better every time. It can’t be deleted, everything seems to be blurry after that (also tested on pro ultra hd renders found on the net, high dpi scans of paintings, pro photos, mate paintings, …). But the real advantage is that the effect is applied only on blurry parts on the picture. I took time to compare it with other FX of course (including Red giant Finisher, Sharpen, fake HDR effect, even with Denoiser 2 to really push the enhancement) the result is always better in one click with your old config than with several combos of FX, due to localized enhancement and a total different contrast behaviour; on video, I tested it on my own demo, some projects look just cinematic now.
Still have to mask out some parts (or adding Denoiser 2) in fast camera moves, and a real pain to render, but seing the results it’s a thing I’ll do to every of my projects from now on.
Just wanted to tell you, I think you have a real plug on his own here. 
Hi Pierre,
not sure which effect in particular you are talking about. Rodilius?
In any case, what you saw in the early version was the effect being applied with its default parameters, so that result should be identical or reproducable also with the latest release.
Hi Tobias,
I’m talking about the Rodilius effect, with the first beta you sent to me on this forum. Being unable to make changes with values, I put the Rodilius on an adjustment layer just to change his opacity (theorically it shouldn’t reduce the lines, just lower their opacity, but wanted to test anyway) and this doesn’t appear anymore with your new version, which is stable.
Putting the Rodilius on the adjustment layer, with the old config, gives the picture a much much better look (no common point with the native Rodilius effect).
Mmmh, strange. I justed tested old and new version, and no matter if I put them on an video layer or an adjustment layer, the output is identicaly in both builds - as it should be, as Rodilius gets applied with default values. In the first beta version, parameter changes would not have any effect, but the initial output when the effect is applied is identical.