So this is one problem with using an MIT license for SciRuby.
Our distribution gem -- well, technically, Claudio's distribution gem, but used by SciRuby -- has some Ruby code in it derived from C code in the GNU Scientific Library. Being a GNU library, GSL is licensed under the GPL.
Interestingly, the GSL-derived code is only utilized if the user does not have libgsl installed. And my understanding is that code which uses libgsl is not technically a derivative work, and therefore not required to be GPL'd itself.
I suppose one possibility is to abstract the GPL'd code into yet another gem (distribution-gsl?), which is itself licensed under the GPL.
The main reason we initially chose GPL, I think, was because while we had strong respect and appreciation for the MIT-license-like Ruby culture, we were more concerned about the science culture.
In other words, what could we do to provide another arm-twisting mechanism to force publishing authors to release their source code? We wanted to facilitate openness among people who might join the Ruby community by way of SciRuby, as opposed to those who might join the SciRuby community by way of Ruby.
Whether or not we can actually enforce release of source code is an open question. Certainly many journals and funding agencies have enormous problems here.
What about a joint license? For example, is the following practical? "If you publish your work in an academic context, SciRuby is GPLv3 for you. If you do not publish your work in an academic context, SciRuby is MIT."
Noah -- I'd love to get your thoughts on how to make it easier to include people in our project. Would you be willing to send me an email? john dot woods at marcottelab dot org.
Could you go into more detail? Since we haven't released yet, we might still switch. But I haven't heard a lot of compelling reasons for doing BSD instead.