New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider switch to non-GPL license #31
Comments
Now use std::atomic functionality to allow thread-safe access to bit-wise data, as per issue #98. **This means MRtrix now requires the compiler to support C++11.** This is also relevant for issues #32 (move to C++11) and #31 (switch to non-GPL license). The use of the std:atomic::compare_exchange_weak() function is also a bit of a hack, relying on the implementation of std::atomic<T> being a thin wrapper around its type T, with no additional state. This is the case with GCC on Linux, and I expect any other compiler on relatively recent Intel-compatible hardware. While this should cover the overwhelming majority of likely MRtrix installations, there is a distinct possibility that this will fail to compile or run on different CPUs. Will increment version number to duly reflect the ominousness of the occasion...
Now that we are getting close to merging |
By the way, I'm not married to the MPL - it just seems to strike a good balance between allowing use in 3rd party applications (including commercial ones) and protecting the code. But there are plenty of other options available - I'd be happy to have a discussion about what the best license would be if anyone has any feelings about this...? |
Any thoughts about what license we should go for? Everyone happy with the MPL? |
In my opinion, the choice of the licence is up to Donald, Dave, and Rob, and definitely not mine to make as my contribution to the library is rather limited. That said, I found this excellent website for comparing different licence options, in case anyone is interested: http://choosealicense.com I am happy with MPL. More on this in #415. |
OK, let's go MPL. @dchristiaens, I've merged in your pull request (#415) on that understanding. This is what I propose we use for the notice in each file:
Is everyone happy with that? If so, it would be much appreciated if some kind soul would get on with the process of updating every file with that notice... 😉 Hopefully someone can devise a nice little script to automate the process... If anyone is willing to take this on, feel free to assign yourself to the task. |
I'll have a go at writing such script in the morning. I suppose we do keep the liability notice, distributing the code without warranty? |
Ah, yes, I think we should keep that part. Good call. And thanks for taking this on... |
One more thing: we should probably mention the www.mrtrix.org website in that notice, as a way of clarifying what we mean by "the MRtrix3 developers"... |
Would this be OK as the new header of all files?
Should I add a reference to the github project too? Or to some sort of |
Seems fine to me - go for it. |
And no need to mention the GitHub repo - we own the mrtrix.org domain, we may decide to switch repos at point in the future (unlikely though). The mrtrix website will point to the appropriate repo anyway. And yes, we should include a LICENSE file in the top-level folder, with the contents of the MPLv2. No exceptions that I can think of... |
Done. Found a very handy tool for the job, works like a charm. @jdtournier, can you add the LICENCE file? |
done. |
(direct copy from previous discussion)
I've been thinking for a while now that it would be good to use a different license than the GPL to allow integration of MRtrix into other projects, whether proprietary or that simply use different licenses. Something like the Mozilla Public License or even MIT/BSD. This would require stripping out all GSL dependencies - it's the only GPL component used in MRtrix.
I've had a quick look through to find which bits would need to be modified. Obviously all the linear algebra stuff would need to be modified. For this, I've just come across the FLENS project, which is basically a templated C++ header-only implementation of all of BLAS and LAPACK, which is perfect. That would basically replace a lot of the
lib/math
folder in one go...Other things that would need re-implementation are actually not too bad. I'd already re-implemented the SH & Legendre functions, so that's no issue. The FFT stuff is currently not used in the main branch, but it would be trivial to use something like kissFFT if needed. The only other sticking point is a decent multidimensional optimiser, which is currently only used in gendir, so no big deal. I've come across one decent-looking implementation of the BFGS conjugate gradient optimiser, which looks relatively simple to adapt to our needs.
So all in all, nothing too difficult to do, but would nonetheless require a fair bit of work. Question is, is this something that we'd consider important, and if so, is this something that we want done before release, or are we happy to wait till later...?
It might also be worth looking into the boost library. In particular the Math, Random and uBLAS parts might be useful. Math has special functions implemented, but apparently you already coded those. uBlas provides templated c++ BLAS. As fas as I know LAPACK is not included though... Also Eigen might be interesting for linear algebra. Pretty sure it will cover most of your linear algebra needs... Not sure if it's license is liberal enough.
Eigen looks good - it's C++98, while FLENS uses C++11 features. I'd like to move to C++11, there's a lot of features that we could use straight away, for example the Mersenne Twister random number generator, which is what we use with the GSL currently. Only issue with moving to C++11 is that it might prevent deployment on older clusters and HPC setups - but then they can always compile static binaries if required. Maybe it's time we tried it...
Otherwise, Eigen is MPL, which is what I was leaning towards anyway. We'll need to discuss the best license at some point if we're going to switch. In the short term though, I think we'll need to release under the GPL to get the software out...
As to FLENS, the license seems very relaxed. The other advantage is it's header-only, so we can simply include it within the MRtrix code if we want. I'm slightly concerned about the level of support though - it looks like Eigen has a bigger community around it, which is definitely a big advantage...
Eigen is header-only as well. I haven't used it myself, but some of our colleagues here are using it and I hear nothing but good stories.
The text was updated successfully, but these errors were encountered: