Closed caseymcc closed 7 years ago
I "think" neither of FreeImage's licenses actually works with the BSD license.
I can't find anything about this. From what I understand from the FIPL, it has no restrictions regarding this.
I am no where near expert on this (I don't even like this stuff, I like to stay with the default licenses, just easier) but when reading about FreeImage's license I happened upon this https://github.com/imageio/imageio/issues/114, which is where my thoughts come from on this. FreeImage's gpl license is not usable by a BSD project, so you are left using the FIPL. If the people in the thread are correct and the FIPL is a modification of MPL 1.0 it will cause downstream issues. The BSD license would be fine with it but I believe the gist is that by using the FIPL your code is now FIPL (not BSD) and since it is incompatible with GPL any users including forge would be violating their projects GPL. Users expecting to use it with project under BSD it would work fine.
There was a discussion started to alter the FIPL, https://sourceforge.net/p/freeimage/discussion/36111/thread/22c6c0bb/, but I don't think anything ever happened.
@caseymcc I am not sure how that affects the licensing when using FreeImage as an external dependency.
@ghisvail I see that you are involved in the imageio thread linked in the previous comment. I trust your insights with licensing issues. Can you provide your thoughts on this issue ?
I am not sure how that affects the licensing when using FreeImage as an external dependency.
It does not affect the code of permissively licensed software using a dependency governed by the FIPL, CDDL or any MPL-1.x based license. It would however give more work to potential downstream projects using forge compiled with freeimage, and distributing the corresponding derived work under a FIPL-incompatible license such as GPL or Apache.
For the GPL, one could get around the issue using the fact that FreeImage is dual-licensed under the GPL too. However for Apache, the only solace would have been to get the text of the FIPL upgraded to MPL-2.0, which has yet to happen. As far as forge is concerned, support for optional compilation with FreeImage would therefore help, provided it does not affect critical functionalities of the library.
@ghisvail Thanks!
@caseymcc Can you please update the review to error out properly when FreeImage is not available instead of silently exiting ?
np, Ill make the change. Do you want me to split the FreeImage option into another PR?
@9prady9 what do you think ?
@pavanky Seems like a good way of managing CMake dependencies. @caseymcc Couple of requests before merging.
CMakeModules
that contains all the .cmake
modules. Is there any specific reason you have put HunterGate.cmake
file in a new directory cmake/Hunter/HunterGate.cmake
? If not, Can you please move it to the CMakeModules
folder.Should be fixed, the location of HunterGate is more habit. Most of the packages in hunter have it like that but there is no real reason for it. After these changes go in I can set forge up as a package in hunter, might do a release on the dev branch to get it in then the next release from you all can be be put in hunter as the official release.
Thank you. May be you can wait for 1.0 release of Forge, we will do most probably do it before or along with ArrayFire 3.5 release - which is in next week or two.
This adds Hunter (a cmake package handler, https://docs.hunter.sh/en/latest/) to the build system. It will automatically fetch boost, glm, and freetype and compile them for the current build. I modified the build to allow FreeImage to be turned off. For one, hunter does not have a package for it (and I didn't want to make one) and two, I "think" neither of FreeImage's licenses actually works with the BSD license.
I know modifying the build system in this manner could be controversial so I provide the push more as a possibility. Some of the other packages the source uses could be created for hunter if this is something you all are interested in.