[ruby-talk:444479] Curious about adoption implications of choosing MPL-2.0 for a gem?

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

···

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

--
  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 -- Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org

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 --
Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org