Licensing in m4/
Issue #11
resolved
Fedora Packaging Review flagged a concern that while the overall license is BSD, files in the m4/ directory contain files under a different license, namely "GPL v2 or later" and "GPL v3 or later". Note that the exception is granted for the output of those macro, but not macro themselves.
Since we're on topic, do we actually need m4?
It's used by libtool, but nowadays, as long as platform has gcc, it works in exactly the same way, only paths are different. This includes OSX. I think we could dump libtool.
It is also used by the CPU checking, but I need Kevin to rethink this. The CPU checking with m4 is done at the build CPU, but it may have a different architecture from the runtime CPU! My package-builder machines may have AMD CPUs for crying out loud.
Please consider this licensing issue an opportunity to fix libtool and cross-compilation.
Comments (12)
-
-
@zaitcev Removing the GPL dependency seems doable, though I'll have to learn how to do it without libtool. As for runtime CPU checking, that will take longer. This is much easier said than done. We can do it for liberasurecode, but cannot enforce such checking for backend libraries (such as jerasure/gf-complete), so I am not sure how useful that will be for liberasurecode. Also, there are no immediate plans to do it for gf-complete, since it would be a pretty substantial change.
This means that I will work to remove the GPL dependencies, but will not do runtime CPU detection. This means that package builders will have to create non-Intel and Intel versions.
-
@tsg- @zaitcev
Here is the fix: https://bitbucket.org/tsg-/liberasurecode/commits/738d57918577386d65435c0733735d24be7f5a9f?at=master
If it looks reasonable, I will merge the branch with master. I will also update gf-complete and jerasure to use the same thing to prevent any issues in the future.
@zaitcev Tushar and I have decided to stick with libtool for now. In addition, I recalled why we cannot do dynamic detection for SIMD. Loic and I talked this through over a year ago and he actually tried to prototype it. It is near impossible to get it right because gf-complete uses the Intel intrinsics, which requires -msse* gcc flags. This means that gcc will not only include what we are explicitly using, it will also try to implicitly optimize other functions, such as memcpy. This prevents a "single" artifact for all architectures, and means package maintainers will have to create separate artifacts for different scenarios.
As a result of all of this, the fix above is sufficient to close this ticket out.
-
repo owner
@kmgreen2, it might be better if we get rid of the m4 directory altogether and add the simple, new cpuid detection code we discussed earlier this week, inline to configure.ac .. the current patch may raise some licensing concerns.
-
@tsg- We could, but we would also have to write our own code to handle libtool, right?
-
@tsg- I'll just get rid of all of the m4 CPUID stuff and put our own detection into configure.ac
-
-
@tsg- If this looks OK, I am going to port it over to jerasure and gf-complete to get rid of the m4 dependency. Heads-up @dachary ;)
-
@tsg- Any comments on the new patch?
-
@tsg- @zaitcev You guys cool with the commit that gets rid of the GPL'd code?
-
repo owner
@kmgreen2 I removed the remaining GPL references in m4/ as well. Thanks - I am going to merge this next.
-
- changed status to resolved
@tsg- and @kmgreen2 have committed the changes needed for this...
- Log in to comment
@zaitcev There are a few items I'd like to knock-out before getting to this. Do you have any more specific suggestions w.r.t. replacing libtool? Writing our own macro to check CPU info should be pretty easy.