Hi Matthew, thanks for the reply and advice! The MPL-2.0 is not quite as permissive as Rails' (MIT) and is closer to LGPL in permissiveness. That's actually what has me worried about trying to use it. I've thought about the axes you mentioned. The relevant axis for me is the modififications one. I'd like people to do whatever they want with the software but if they benefit from non-private-use of improvements, then I would like to have access to those improvements. Best I can tell, researching this, none of the popular open-source licenses really give me this in a practical sense for this type of project. AGPLv3 seems to have the broadest terms that trigger sharing-back but seems more restrictive on use than I want. MPL-2.0 is close but its definition of distribution doesn't include the typical use-cases of this type of software (accessed over a server instead of offered to the user.) Another thought... I don't think there's much incentive to horde your own improvements to a project like Sinatra or Rails . It's usually less hassle for me to just upstream those improvements than maintain a fork. So a license that requires sharing back might not really increase the amount of code shared back in this type of project over not having an explicit requirement. So, MPL-2.0 is closest to what I want but probably wouldn't actually impact behavior differently than MIT would for the reasons mentioned. So the risk of picking an unusual license for this ecosystem I suppose isn't worth it in this case and I'm leaning towards just using MIT again and stopping overthinking it and getting back to hacking. Cheers! On Mon, May 20, 2024 at 5:28 PM Matthew Kerwin via ruby-talk < ruby-talk@ml.ruby-lang.org> wrote:
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/ ______________________________________________ ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org ruby-talk info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.org...