Is a licensing restriction really needed?
daveaglick opened this issue · comments
There have already been some good issues like #1, #9, and #14 which bring up the licensing requirement in level 1 of the maturity ladder, but I'd like to question whether a licensing requirement is needed at all. For reference, level 1 includes (as it's very first health metric no less!):
Uses MIT or other compatible license, and third party contributions are documented in a notice file.
The TL;DR is that, at least in my opinion, licenses and maturity are completely orthogonal concerns. Mandating a particular style of license (permissive in this case) perpetuates the myth that healthy and mature projects only use that kind of license. In reality, alternate licensing strategies can be one of many powerful levers a project can use to actually ensure health and sustainability. Whether a project uses a permissive license, a copyleft license, or any other kind of license does not say anything about it's maturity and health.
Let me dive into this assertion a little bit... All licenses place restrictions on the consumer, even permissive ones. The only question is to whom the restrictions apply and whether or not they're compatible with the given use. I can think of at least four broad categories of licenses:
| Category | Example Licenses | Primary Restriction(s) |
|---|---|---|
| Permissive | MIT, Apache 2.0 | Notice/Attribution, Liability |
| Copyleft | GPL, OSL | Proprietary Use |
| Non-Commercial | CC BY-NC, Prosperity | Commercial Use |
| Behavioral | Hippocratic | "Harmful" Use |
Any one of these licensing categories may or may not be appropriate and suitable for a given consumer. In many cases (though not all) they're also combined with other licenses in a dual-license scheme where alternate (usually more permissive) licensing is available (usually via payment or waivers).
Also note that the way a license applies and it's suitability to a consumer is also partly dependent on the type of project being licensed. Each license applies differently depending on whether the software being licensed is a utility library intended for embedding or referencing, a framework or platform, or an application.
In my mind, none of these concerns have anything to do with maturity. An application that publishes source code, participates with the community, accepts pull requests, and otherwise adheres to the other tenants described in the ladder but is licensed under a dual non-commercial license scheme could be just as mature as a utility library that's licensed under MIT. Likewise, a library like ImageSharp is certainly quite mature (~7,000 commits, ~80 contributors, active issue triage, etc.) but is planning on using a dual non-commercial licensing strategy to ensure sustainability.
I don't want it to sound like I'm downplaying the importance of understanding the licenses a project chooses to consume. That's critical and I'd love to see tooling similar to what's being proposed for the maturity model applied to licensing as well. I'd love to see more prominent badges or banners displayed on the NuGet gallery with licensing details. Open source consumers particularly need tools that help them understand the closure of licensing requirements for all their dependencies, the resulting complete set of licensing obligations they have, and their compatibility to each other. Then a consumer can make an informed decision about the licenses they choose to adopt and adhere to.
I'm also not at all opposed to the Foundation placing licensing requirements on becoming a member project. It's entirely appropriate and good that member projects be licensed with permissive licenses. But this proposal isn't just about member projects since the ladder is designed to apply to the entire ecosystem of .NET open source.
I think the root of my concern is that with a few requirements like licensing the proposed maturity ladder confuses "is this project healthy/mature?" with "is this project acceptable for my use?". That last for my use is important because if everything goes as planned and this program is successful, badges will go up on NuGet, Microsoft and the DNF will promote the maturity ladder and maturity levels as indications of suitability, and consumers/companies will rally behind this as a single-glance seal of approval. The problem is that for my use is not a one-size-fits-all determination. In addition to compatibility with particular licensing caveats, a consumer might have different security goals or might favor the stability of slower, more deliberate releases over a more rapid cadence. The acceptability of a given project for a given use includes many dimensions including maturity and licensing (among others), but attempting to collapse them all into a single step-wise series of levels seems like it's doing a disservice to a healthy ecosystem that produces projects at various levels across all the dimensions. To put it another way, I may prefer a more mature project with a non-commercial license over an immature project with a permissive license if I'm not subject to the non-commercial clause or don't mind paying for an alternate license, but I may favor a less mature project with a permissive license if I'm writing proprietary software.
I'm also certainly not of the opinion that any project not on a higher ladder tier will suddenly loose users or be unable to continue, but I do think it's unfortunate that a plan designed to foster a vibrant and healthy open source ecosystem around our platform may actually have the opposite effect by limiting the success of projects that fall outside the one-size-fits-all measure of maturity. As a community (both within .NET, but also the broader open source movement) I would love to see us move beyond open source gate keeping and accept that there are many styles of open source and may ways to run an open source project that are still "open source" (in the general sense of the term), healthy and mature, and suitable for consumption.
You are right that there are many styles of Open Source and the maturity is not dependent on the license chosen (in most cases). Some might argue you should at least choose a license that meets the Open Source Definition: https://opensource.org/osd-annotated
But IMHO, the real point of this ladder is not to define once and for all what "maturity" means in the .NET OSS community (despite the name). It's really a project dependability ladder. Can my project or company depend on this project and what risks will it take if it does? And licensing does play a part in that. And I think it's fine to have an opinion and recommendation there that plays to the vast majority of .NET consumers. It might not meet everyone's needs, but how could it? It would be a free-for-all.
It might be worth thinking about a project maturity matrix though where the rows are the levels and the columns are broad groupings of licenses that appeal to different philosophical approaches to licensing to make this as inclusive as possible.
Thanks a lot for the thoughtful response @haacked.
Some might argue you should at least choose a license that meets the Open Source Definition
I understand that viewpoint (I used to hold it) and also understand that there are a lot of people in the open source community that feel very strongly about it. That said, in my opinion the open source community has got to evolve past the mentality of "open source means total freedom for the consumer" and normalize a wider variety of schemes.
There is a growing movement of maintainers who recognize that the permissive/OSI model places the emphasis on the freedom of those consuming the work and not with those performing the work. There are alternative models that don't have to impact the dependability of a project and might actually enhance it by making the project more sustainable in ways that promote ongoing participation by the maintainers (such as financial incentives). Yes, there are other ways of accomplishing this too like donation platforms, support contracts, etc. but I'd rather see maintainers have the option to choose sustainability strategies that work for them and their projects without fear of being ostracized by the open source community for philosophical reasons.
And licensing does play a part in that. And I think it's fine to have an opinion and recommendation there that plays to the vast majority of .NET consumers.
Does it though? The inference here is that the vast majority of .NET consumers are either unable or unwilling to accept licenses that place restrictions on them such as proprietary or commercial use. Is that really the kind of community we want to broadly promote? Given that the license is known ahead of time and can't be changed once granted, what dependability risks are inherent in using non-permissive licenses or for obtaining a permissive license through a waiver or license fee if you understand the restriction? I honestly can't think of any.
It might be worth thinking about a project maturity matrix though where the rows are the levels and the columns are broad groupings of licenses that appeal to different philosophical approaches to licensing to make this as inclusive as possible.
This sounds like a great idea.
Thanks for this detailed write-up and the chart (which to my read is accurate).
First, I didn't initially like the "maturity" term because it causes people to think about the proposal in a certain way. When I saw that other foundations used that term, it made sense to use it to help better communicate that this proposal was intended to be similar.
I agree with you that maturity and license are not the same and not directly overlapping. I also agree that different consumers will be happy to make different choices on multiple dimensions, including licenses. That said, I do agree with @haacked on his perspective on licensing being a part of dependability.
The challenge is around goals ... here are the key ones I was operating on:
- Every project that starts at level 1 can get to level 4, specifically that there are no allowances at level 1 that would prevent getting to level 4.
- Any project can take a dependency on any other project (modulo specific rules to the contrary in the ladder).
- All projects can be consumed by anyone for free.
To a large degree, those three goals boil down to the same thing, but are worth calling out. That explains the focus on MIT. I'm sounding like a broken record, but this also aligns with the way that CNCF and Apache function for projects in their foundations.
So, we could have pulled licensing out, but then the ladder becomes hard to navigate. You end up with a set of sub-ladders that cannot interact with one another. It would be like if Apache had both GPL and Apache 2 projects. That would be a mess to navigate. The people on the Apache 2 projects wouldn't even be able to look into source control of the GPL projects, let alone take a dependency on them.
To my mind, a ladder that allows multiple licenses (of different kinds) at the start and then limits licenses to just one kind part way through is broken by construction. In most cases, it is impossible to change the license type mid-point. Big projects have tried to do and it is very painful. It would mean that projects with certain licenses can only move to a certain level with the option to progress further.
Dual licensing has similar challenges as the (fake) Apache/GPL example. I'm totally supportive of maintainers adopting dual licensing or other forms of licensing. The challenge is that these systems don't really allow transitive dependencies using that license. In fact, the dual licensing I've seen relies entirely on permissive licensing, if you are going to use anything other the base framework. Dual licensed components cannot depend on GPL to it really is MIT and friends.
So, I would think that people who want to use dual licensing would be strong proponents of a maturity ladder that requires permissive licencing. It encourages a large set of libraries that you can freely use. Your reliance on permissive components is effectively the same as a closed source project at a bank.
Put very simply, I am super sympathetic to maintainers who want to use other licensing models and applaud them for trying and using that. It's just not compatible with general open source. Also, open source is never going to move to such models because it's not composable at any large scale.
Put very simply, I am super sympathetic to maintainers who want to use other licensing models and applaud them for trying and using that. It's just not compatible with general open source. Also, open source is never going to move to such models because it's not composable at any large scale.
To my thinking, this is the key issue.
The motivation here wasn't to prescribe arbitrary maturity rules to enforce an agenda or methodology. We really want to enable a composable ecosystem, in which projects, libraries, tooling, documentation, etc. can be built on durable interdependencies. We wanted to work towards a solution to the perennial question of "Why EF/Identity/MSTest/etc.?" "Because it's in the box and supported, so my tech lead/company says I need to use it." We'd love to see a future where we've got a number of community run projects who can stand up to that argument and say, "Look, we comply with every technical requirement that project does, including security, continuity, servicability, you name it... plus, it also ships in the File/New project templates. Checkmate, boss."
The choice to penalize non-permissive licenses seems to be a choice to maximise the reuse of source code, while minimizing the return on the investment of the creators. At least, if you read this answer, non-permissive licenses are the best for creators, financially, which would imply a greater project longevity: https://opensource.stackexchange.com/a/210/21962
@FrankHileman in my mind, it isn't even about financials (many projects have no financial goals). IMHO, reciprocal licenses (non-permissive licenses) are about the community. I wrote about it here: https://robmensching.com/blog/posts/2020/7/16/the-decline-of-reciprocal-licenses-through-corporate-leadership/
@robmen I agree with your blog post. It is not only about financials. And probably, doesn't make much difference financially, until a project really takes off. Unfortunately, many choose a license without thinking much, and without much experience. I have a friend that started with permissive, and switched to restrictive/reciprocal later in his life. Asking him about the choice, he explained how his license had been ignored (he found his code in the code base for a consulting client with no attribution). A restrictive license did not help him prevent illegal behavior in the future... but it probably made him feel better.