remove imagesharp recommendation #8577
Conversation
The recent license changes for ImageSharp could be a risk item for customers adopting it. For that reason, we should not recommend it. See [SixLabors announcement](https://sixlabors.com/posts/license-changes/) and the resulting [blog post from the .NET Foundation](https://dotnetfoundation.org/blog/2022/10/20/imagesharpupdate)
ghost
assigned 
|
Tagging subscribers to this area: @dotnet/area-system-drawing Issue DetailsThe recent license changes for ImageSharp could be a risk item for customers adopting it. For that reason, we should not recommend it. See SixLabors announcement and the resulting blog post from the .NET Foundation
|
|
Learn Build status updates of commit f37ee1e: ✅ Validation status: passed
For more details, please refer to the build report. Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report. For any questions, please:
|
@BillWagner Could you clarify why changing a license to something that may potentially help the company behind the product can be a risk item for customers? What kind of risk do you mean and how it is measured? How other projects can make sure that once they are listed here, and benefit from the listing, are not removed when they migrate they license? It'd be great if the requirements for being listed would be public so that company can assess whether being removed from the list is a risk item for them. |
Yeah, this reasoning doesn't hold at all for me. If anything the License updates decrease risk and make the library more likely to last over the long term. Businesses can make make their own decision on if paying for the service is worth it or if they want to home roll it/use an alternative. Also, I know of at least one other library that is referenced in the docs that uses a similar model and isn't being removed. |
|
I personally feel like the official docs should only recommend projects under OSI approved licenses that are in the .NET Foundation. That'd guarantee no costs being incurred due to switching to them, relatively active support and oversight over changes related to the terms of usage. On the other hand, changes like this should be properly announced and communicated, doing them in stealth is harmful to all the sides concerned. |
|
How does this square with including Duende - also a non-Microsoft commercial product - not only in docs but also in samples and templates? |
|
Corporations will be afraid to use a non-standard license dependency as they don't have a predetermined guarantee that the license is compatible for their use cases. They would have to go out of their way to analyse the non-standard license and even then the license isn't as tried and tested as a standard one, so it's still a risk. HOWEVER, these are the same corporations that led the library to switch license in the first place so... to each their own. It certainly doesn't warrant it no longer being recommended, I'm sure hobbyists would love to hear about a library like this. Recommend it for its merits, and let the reader decide whether the license is a problem. That's my take anyway. |
|
Another thing is, having random - non-.Net Foundation libraries - in the official documentation just makes it a free advertisement board for external companies. Supporting DNF projects there makes sense, but why would outside projects be allowed? And if they are, shouldn't every single person and company be allowed to add theirs to the docs?
I've never used it, but being consistent with what I said - it shouldn't be there. |
This isn’t a concern of the MS docs at all. Each company can make their own decisions.
The docs IMHO are there to help the dev community understand what .NET offers, what their options are, and learn how to perform tasks. If an external lib is able to fulfill that, why not prompt it? Check out other docs as well (eg laravel). They’re about furthering the community as a whole. |
|
Oh no how dare Microsoft foster a diverse selection of open source libraries outside of the few that have been graced with an DNF badge with lots of caveats... Ultimately, the community is clued into which libraries are "good" and "recommended", whereas beginners are not. ImageSharp is incredibly popular and basically de facto in C# image manipulation, but beginners don't know that. The documentation's main point is to regurgitate best practices and ecosystem consensuses to give the reader an idea of how things are actually done in the C# world. It doesn't matter who came up with those things, or what its caveats are; if it's what developers are actually doing then new developers should know about that. The intricacies of "the license" can be evaluated separately (the docs can point the license out if it must, but this doesn't change the fact that the docs should be recommending what developers are actually using) You might think "well that's subjective how do we decide what the consensus is". And I'd say "well that's a silly question, but the numbers Mason!". ImageSharp is the most popular NuGet package with the "Image" tag. Lacking an official way to manipulate images within the framework, surely that's a good enough metric on consensus? |
|
Companies can read the license and decide on their own if they want to use the library or not, where is the risk exactly? No one should use nuget packages without reading the license first |
|
I generally dislike jumping on thread necromancy about these kinds of things, but this really is:
It would absolutely suffice to just add: (dual licensed) After the mention of ImageSharp in the original line. I appreciate that folks are searching for a non-controversial decision for official docs, but unfortunately the wider context here makes this a particularly unfortunate and poor decision. The notion elsewhere that Microsoft should only reference OSI licensed things is equally absurd, given the origins of a vast majority of software in the ecosystem. It shouldn't be a hard decision to cite the most popular example of a thing in our official documentation, even if companies have to contend with the position they might have to pay for something down the line. |
@MichalPetryka what would you suggest replacing it with? Nothing? That would just harm the ecosystem and community. Also suggesting that any project that isn't under the control of DNF is "random" is disrespectful to people like James who've put lots and lots of time into projects that are used in many commercial scenarios. Especially as in this case it was under the DNF - just because it left doesn't make it "random". |
Being in the DNF is not an endorsement. There is no "outside" or "inside". A DNF library isn't a "blessed" or even a "supported" library. There are some legal resources available, that is all. It should not be some arbitrary recommendation bar. |
DNF needs to be removed. It hasn’t achieved anything to date and is a pointless hindrance to OSS. |
I do not think you understand what the DNF actually do in practice. There is no guarantee of "relative active support", and project owners are free to fork their project, change license, and stop development of the original project in DNF. For most projects, DNF is at best a sticker. That's not necessarily a bad thing, it does give certain users of the projects a sense of (false) security, which is also why my OSS projects is part of DNF. However, DNF certainly doesn't help guarantee any kind of active support... |
"Open-source" - ImageSharp is a semi-commercial product, requiring OSI approved licenses is a valid way to filter out libraries that might cause issues for the users.
Thing is, ImageSharp is not dual-licensed. It's licensed under a single custom license that comes with different terms depending on the use-case, you can't just choose between using it under Apache 2 or commercial terms.
Why should the official documentation contain examples for a single commercial product? Isn't it its job to show how it can be used?
Random might've been a bit of a wrong word here - the point here is that if one place would recommend 3rd party replacements, why wouldn't every single page contain those? Why wouldn't the BinaryFormatter doc recommend MessagePack-CSharp or protobuf-net instead? Why wouldn't the docs contain samples on how to use Themida to obfuscate and protect binaries? If we choose that one product is worthy of being there, every single one should be.
However it's a well defined set of criteria that a project must meet to be there - and it also solves the issue of cherry picking arbitrary projects there. Coming up with a separate list of conditions for a library to be included in the docs is a valid option however then more people would need to check if they still meet them.
And then what? Would having .Net directly under MS control be better than a foundation? The issue with DNF is that MS has nearly total control over it, the solution should be having more companies involved and sharing ownership over it, not removing it. If you think that .Net should not have any company oversight - open-source is just not possible without corporate backing, people just won't work all the time on a project for free - see even ImageSharp for example. Even Linux has tons of it.
But it does. And projects must at least meet it at the moment of submission. |
|
As a .NET Foundation project maintainer, I can safely attest to .NET Foundation projects having no guarantee of active support or support to create one. |
At least on paper they do, not having it enforced is another issue. But being that, it's not fully related to the matter at hand. |
|
I don't think there's anything I can add beyond what I've already said. There is absolutely no reason to make mere inclusion dependent on factors like these, if it's what developers are doing, put it in the docs! By all means note the caveats like the license, but include it nonetheless. Otherwise you end up with documentation which is wildly detached from reality, and leaves developers being recommended inferior options that end up kicking themselves when they discover the better, more popular way to do things later down the line. Setting arbitrary barriers to inclusion doesn't help anyone in the long run compared to just listing the options and their pros and cons. Ensuring the reader knows all they need to know about X in the .NET ecosystem allows developers to be aware of the ways developers are actually doing things in the ecosystem, make their own choices, and decide for themselves whether they want to hinder their experience on something as little as a license. And if you think that's not the case, then you're just simply wrong. |
It’s already under direct control. MS has 100% control over the foundation. So it serves no purpose. If anything MS should have a minor non controlling stake in the foundation. |
Popularity is a perfectly valid measure here. That's what people largely want to know - "how do people normally do this". This commercial/non-commercial split is an odd artefact of our community. Even "fully open source" communities that feature commercial upsell don't struggle with this. There are well storied reasons as to why we struggle with this, but it's easier to be kind and coherent. |
|
@BillWagner As long as you are actively using Duende's IdentityServer in templates, samples and docs, you have absolutely no business removing other similarly licensed .NET libraries from the docs. IdentityServer made a much more massive change going from a completely free product to a commercial one - after being included in .NET Templates for years and thus having a huge captive audience. If you can still actively promote IdentityServer, you can certainly include ImageSharp as an option in the docs. ImageSharp is a massive technical accomplishment, being completely managed code. It demonstrates the power of the .NET platform by frequently being faster than native implementations. If anything, Microsoft should promote and support ImageSharp even more. If Microsoft (and other big commercial users) had done the right thing and supported ImageSharp financially, then it might not even need these license changes in the first place. |
Right, moment of submission being the key here. |
That means Azure products (e.g. authentication) should also not be recommended in any .NET docs? |
|
I don't know if I agree or disagree with the decision, but the issue's start is lacking to me. For those of us that do not actively use ImageSharp, and do not keep up with license drift, doesn't it behoove you to document what the licensing was before, and what was changed so we can make a better informed decision? Yeah I saw the links, but the DNF post is gone. A overview of the issue at play should be included in the issue for documentation purposes if you ask me, and then yes link to the full text. Having experienced the pain of agencies deciding to completely rug pull links when management changes, I expect better from the DNF. |
Having it on paper but not enforced is really the same issue with different presentation layers. It effectively means the same thing at the end of the day and trying to argue this point in good faith is really inappropriate. There’s no reason why the documentation couldn’t have added a bold note that it has implications for commercial users. Throwing the entire thing out and alienating a sizable portion of the dotnet community is a misstep here. Taking this action and attempting to justify it after the fact without clear public communication is really disappointing. |
The DNF post is available at the old site: https://old.dotnetfoundation.org/blog/2022/10/20/imagesharpupdate |
The recent license changes for ImageSharp could be a risk item for customers adopting it. For that reason, we should not recommend it.
See SixLabors announcement and the resulting blog post from the .NET Foundation