On Tue, 21 May 2024 at 08:49, Miles Georgi via ruby-talk <ruby-talk@ml.ruby-lang.org> wrote:
Hey hey!
I suspect this might not be the best place to ask this, but, I'm eager to release some gems and normally I'd just pick MIT and not even think about it. But, I did some research to see if maybe I want to try something different this time. MPL-2.0 seems like an interesting/robust/"permissive-ish" license and I'm tempted to try it. But I'm scared that I might harm adoption. Reading the text of the license and its corresponding FAQ, I feel like this shouldn't be an issue for adoption, but I'm worried regardless.
Any body happen to have advice on how I could preemptively assess the adoption risk of choosing MPL-2.0? The gem would be a software framework collection of gems (same category as Sinatra and Rails, basically)
I suppose another way I could ask it... if Rails had hypothetically originally released under MPL-2.0, would they have regretted it and relicensed under MIT later due to running into adoption snags?
Thanks!
Miles
Hi Miles, When it comes to licenses and library distributions like this I think in terms of three axes: using locally vs redistributing, unmodified vs with modifications, and free (as in either speech or beer) vs commercially. I'm not 100% familiar with the Mozilla licenses so I don't know what they say, but it's important when choosing a license to be clear in your own head what your intentions are for all three axes, and then to read the license text with those in mind. You need to define "adoption" in terms of what you want people to be able to do, and then make sure you grant a license that allows them to do that. If you want your gem to be used the same ways as Rails, then it should use a license that's as permissive as Rails's'es's. However as to whether they would have regretted it, your best bet would be to ask them and see what they say. dhh is still around, right? Cheers -- Matthew Kerwin [he/him] https://matthew.kerwin.net.au/