Skip to content
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

Closed
Lestropie opened this issue May 8, 2014 · 13 comments
Closed

Consider switch to non-GPL license #31

Lestropie opened this issue May 8, 2014 · 13 comments

Comments

@Lestropie
Copy link
Member

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

jdtournier added a commit that referenced this issue Aug 14, 2014
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...
@jdtournier
Copy link
Member

Now that we are getting close to merging updated_syntax and hopefully full release, it seems a good time to resolve this issue. updated_syntax is now completely free of the GSL, and with it of any GPL dependencies. We should be fine to switch to a Mozilla Public License - assuming everyone is OK with that?

@jdtournier
Copy link
Member

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

@jdtournier jdtournier reopened this Dec 9, 2015
@jdtournier
Copy link
Member

Any thoughts about what license we should go for? Everyone happy with the MPL?

@dchristiaens
Copy link
Member

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.

@jdtournier
Copy link
Member

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:

Copyright 2008-2016 the MRtrix3 contributors

This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/. 

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.

@jdtournier jdtournier removed their assignment Dec 10, 2015
@jdtournier jdtournier modified the milestones: Updated syntax merge, MRtrix3 3.0 release Dec 10, 2015
@dchristiaens
Copy link
Member

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?

@dchristiaens dchristiaens self-assigned this Dec 10, 2015
@jdtournier
Copy link
Member

Ah, yes, I think we should keep that part. Good call. And thanks for taking this on...

@jdtournier
Copy link
Member

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

@dchristiaens
Copy link
Member

Would this be OK as the new header of all files?

/*
 * Copyright (c) 2008-2016 the MRtrix3 contributors
 * 
 * This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/
 * 
 * MRtrix is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 * 
 * For more details, see www.mrtrix.org
 * 
 */

Should I add a reference to the github project too? Or to some sort of LICENCE file in the repository? Do exceptions need to be made for some parts of the library?

@jdtournier
Copy link
Member

Seems fine to me - go for it.

@jdtournier
Copy link
Member

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

@dchristiaens
Copy link
Member

Done. Found a very handy tool for the job, works like a charm.

@jdtournier, can you add the LICENCE file?

@dchristiaens dchristiaens removed their assignment Dec 11, 2015
jdtournier added a commit that referenced this issue Dec 11, 2015
@jdtournier
Copy link
Member

done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants