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.
As a matter of course, MIT and BSD licenses are non-threatening to businesses and organizations who do not necessarily have software as their primary focus.
Non-software shops who may be interested in using a piece of software may balk at using GPL3'd software because they don't know what the legal ramifications are of failing to comply, or the knowledge/wherewithal/processes to do release the software that they're using.
Talking to people about BSD/MIT is really easy: "You can do whatever you want with it as long as you retain the license and copyright".
At the risk of getting into a FOSS license debate, i'd like to think that FOSS contributors do it out of a motivation other than license restriction (and hell a lot of people still rip libs off, even when they are GPL'd!).
I am sure that most FOSS contributors do it out of a motivation other than license restriction, but I am also certain that many potential FOSS contributors work for organizations that may have questions about contributing to a GPL project (not particularly valid concerns/questions, but the less you have to deal with the legal department the easier it is to get sign-off on contributing to a project...) When you are talking about semi-specialized software like numerical analysis tools it is quite possible that there is a latent pool of potential contributors in industry who would find it easier to contribute to a BSD/MIT project than a GPL one.
It is also the case that this is basically a library, and many who would have no problems using/contributing on a GPL application will balk when it comes to a library or framework.
The resurrection of SciRuby is great news, but the use of the GPL was one of the first things I noticed, and I strongly recommend using a more permissive license. The MIT license would be a good choice. In addition to avoiding the fears associated with the viral nature of the GPL, using the MIT license would be more in line with the culture of the Ruby community. Most Ruby software I know of (though not, strangely enough, Ruby itself) is MIT-licensed, and people will be more comfortable with SciRuby if it conforms to this expectation.
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."
Sure. My understanding is that you can't include GPL'd code in a project that is not itself licensed under the GPL. This may be an oversimplification, since you could potentially use the tools without actually including them in a project, but this is sort of a legal gray area that I don't fully understand (e.g. what constitutes inclusion of GPL'd code in a project?)
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.
Non-software shops who may be interested in using a piece of software may balk at using GPL3'd software because they don't know what the legal ramifications are of failing to comply, or the knowledge/wherewithal/processes to do release the software that they're using.
Talking to people about BSD/MIT is really easy: "You can do whatever you want with it as long as you retain the license and copyright".
At the risk of getting into a FOSS license debate, i'd like to think that FOSS contributors do it out of a motivation other than license restriction (and hell a lot of people still rip libs off, even when they are GPL'd!).