search

dotnet-foundation / project-maturity-model

Proposal/RFC for new .NET library development model.
MIT License
39 stars 8 forks source link

Uses MIT or other compatible license, and third party contributions are documented in a notice file. #1

Open ghuntley opened 5 years ago

ghuntley commented 5 years ago

Hiya folks 👋

Over at https://github.com/dotnet-foundation/project-maturity-model/blob/master/maturity-ladder.md

Uses MIT or other compatible license, and third party contributions are documented in a notice file.

Why is MIT specified and what is "other compatible license"?

Specifics:

richlander commented 5 years ago

Great question.

Answer: https://opensource.org/faq#permissive

MIT is a "permissive" license, maybe the most permissive. So, by "compatible", I really mean "permissive" since that's the primary characteristic at issue. Apache 2 and BSD are also permissive, for example.

None of the licenses you referenced are permissive.

We are wanting to build an open source ecosystem that does not limit what can be done with the source. For example, on the LicenseZero page, there are doors with locks. We want an ecosystem that has doors without locks at the lowest layers. That in no way limits individuals and organizations from offering for-pay or pay-for-support software. Those models are great. It just isn't what the maturity ladder is about with this current proposal. However, it is important that the lowest level packages are aways free and not limited.

We did discuss integrating with GitHub Sponsors or adding support programs. I think those are good ideas, but we are not likely to take those on until we have this version of the maturity ladder fully established.

Cool?

richlander commented 5 years ago

More specific thoughts:

Hopefully that explanation is helpful.

LicenseZero seems like it solves a real problem and does so in an interesting and novel way. In my mind, it's a modern version of ShareWare, upgraded and improved for the modern age.

Tornhoof commented 5 years ago

Both GPL and MIT (and like licenses) are conducive to building open source ecosystems and enabling commercial use, per their respective terms. This is easy to observe in the industry today.

Did you mix GPL with LGPL? GPL licensed libraries are not really conductive to enable commercial use.

richlander commented 5 years ago

I didn't mix them, but I realized that what I wrote was a little too nuanced.

MIT and other permissive licenses are the most obvious choices for building an open and commercial-friendly ecosystem. For sure.

Linux is GPL v2 and it has a huge commercial ecosystem around it, of tools, libraries and other things.

So, my comment was intended to be very general, and I think still stands. My comment of "easy to observe in the industry today" is the key part. GPL has a great ecosystem and so does MIT. Both have a lot of commercial activity. The two ecosystems are not the same and the rules differ greatly, but they are both objectively successful.

If we talk only about OSS libraries, then MIT is clearly the one that is the most flexible and easiest to reason about. And, of course, that's why this proposal is based on MIT.

benaadams commented 5 years ago

Linux is GPL v2 and it has a huge commercial ecosystem around it, of tools, libraries and other things.

Linux while an Operating System; is also an end product so more of an App model. Linux doesn't become part of your library or application; whereas libraries do. i.e. Linux does force a constraint on the licence of products and applications running on it by it being GPL.

However; GPL for libraries does force a constraint on the licencing other things built on them as they form part of them and thus need to have a GPL compatible licence; so in that sense GPL is not permissive.

richlander commented 5 years ago

@benaadams -- fully agree.

terrajobst commented 5 years ago

Yeah I guess for tech similar to ours LGPL would make more sense for commercial offerings than GPL. We could probably have a conversation around whether LPGL would make sense. My gut feel is "no", because it's not considered a permissive license.

richlander commented 5 years ago

I re-read the LGPL license. I don't see how it fits, because it's not permissive, as you say.

terrajobst commented 5 years ago

I re-read the LGPL license. I don't see how it fits, because it's not permissive, as you say.

My rationale was that (as I understand the licenses) LGPL will make it harder for OSS to be build on top or derived off of it , but it generally shouldn't pose a massive risk for applications to depend on it. That's a significant improvement over, say, GPL, but it's clearly not as nice as MIT.