Imagesharp: Licensing Community Discussion

[JimBobSquarePants]

Edit for clarity

We reversed our decision on this and ImageSharp is now licenced under an Apache-2 license. @tocsoft

---

Original details

This issue exists for the community to discuss planned licensing changes in the ImageSharp Release Candidate.

For reference here is the statement we published back in January 2019.

ImageSharp, ImageSharp.Drawing, and ImageSharp.Web will all be dual licensed under a AGPLv3/Commercial license. The AGPLv3 license will come with exceptions which allow bundling the code alongside all well known open source licenses (Apache 2.0, MIT etc). Any projects seen as direct competition (Imaging SDKs) will not be able to utilize that exception.

The commercial license will apply to anyone that chooses not to open source any code which is derived from our APIs which is a direct violation of AGPLv3. Purchasing a commercial license will give the developer the right to bundle ImageSharp with their closed source codebase.

This has not changed and we intend to continue with our plans, however we want to clarify what this means to existing OSS projects that have already taken a dependency on ImageSharp.

We are fully committed to the Open Source community and do not want to actively harm projects with explicitly permissive licenses. Open Source means different things to different members of the community and it is not our place to determine how their projects permissiveness should be managed.

With that in mind we intend to implement a third licensing option for existing OSS projects that have already taken a dependency on ImageSharp.

OSS projects that can prove to us via commit history that they took a dependency on ImageSharp before the Release Candidate will be able to consume the library (and future versions) under its original Apache 2.0 license.

While we appreciate this opens us up to exploitation before the Release Candidate this seems to be the fairest way to make our transition to a less permissive license and offer a strong, commercial-grade, product.

We welcome all and any opinion on the matter (be nice) and encourage you to discuss it below.

I've tagged a couple of people in this issue to ensure that we are doing the right thing.

• @sebastienros (Because the OSS Orchard.Core project has been a long standing supporter and makes heavy use of ImageSharp.Web)
• @jongalloway (Because we want to ensure that our license plans do not jeopardize dotnet foundation membership in any manner)
• @ghuntley Because any discussion on open source licenses is better with him involved.

[sandorfr]

I think you could add a bit more background as to why you move away from Apache to switch to a agpl+commercial model.

Looking at open collective I can see that it’s unfortunately not generating any significant revenues. Generally speaking, Apache/MIT basically means you work for free and people expect free support on top of that.

So I imagine it all stems from that. I’d be curious to hear more background on how you arrived to that decision. What other options have been considered etc..

[x2bool]

But can you legally do this?

In my understanding there were 84 developers that contributed their code under Apache 2.0 into this repository. IANAL but don't you have to ask all 84 devs to relicense their code under AGPL?

[JimBobSquarePants]

@sandorfr It's a mixture of different things but the tl;dr version is that we are passionate about these libraries and we want to be able to work on them full-time to provide the best solution we can to the developer community. We cannot do this without continuous, reliable, funding though, and, as you've seen, alternative approaches (donations, attempting to secure corporate sponsorship) we have attempted have yielded little results.

@x2bool

But can you legally do this?

Yes it is legal. Each of those developers signed the Contributor License Agreement. We've also communicated several times with the developers in our Gitter channel and everyone involved is fully aware of the situation.

[GeraudFabien]

Can't you also make service to monetize? Like prioritize a merge request &/ issue buy paying. This way you can keep a permissive license, gain money and allow enterprise to have a real way to fix there costly issue without a more costly fork.
There is so much project on github that are used a lot but who die because no one want to pay. Open source become a cimetary where project start, people invest a lot of money to used it and the project die because no one want to invest in the project and it's too much work for nearly no revenue.

[Sergio0694]

NOTE: I've already spoken with @JimBobSquarePants about this and I've alread said that I don't mind having to pay for a license myself, even though I'm a contributor to the library. This is just to say that this message is not meant to be some convoluted way to avoid having to pay for a license.

I have a question about future contributions to the projects: don't you guys worry that having to pay for a license could drive away contributors? I'll use my case as an example (see note above): I've worked on a PR for a few months that took a lot of work, and resulted in a brand new feature (the bokeh blur effect) being added to the library. Now, since I'm using the library in one of my paid apps, I'll still have to pay for a license, even though I'm in part using my own code (see note above).

My point is that I fear that other developers in the same situation could just think it's not worth it, or something along the lines of "why should I work for free and then pay to be able to use my own code?". I agree that the library does need some form of paid license if the sponsorships alone are not enough to maintain the whole project, but don't you think that it might be a good idea to pair that with some sort of "rewards" for contributors? This could actually drive even _more_ contributors to the repo in the long run, which would benefit everyone.

I'm just confused about the potential repercussions of having a paid license on a project that still accepts (free) contributions from the very same developers that would use (and pay for) the library.

[Ryder25]

If I have a library that's licensed under MIT and references ImageSharp, does that mean closed source projects could no longer freely use my library unless they pay for ImageSharp? Or maybe I can't even license my library with MIT anymore?

[daveaglick]

This plan seems more than fair. Between the permissive compatibility you’re planning to add to the AGPLv3 terms and the amnesty to allow continued use of Apache 2.0, there’s clearly an effort to reduce the impact on open source consumers.

I do have some general thoughts...

Open Source means different things to different members of the community

One of the things I’ve been learning recently is that many developers have a _very strong opinion_ of exactly what “open source” means. I don’t want to debate the exact meaning (I’ve done plenty of that on the Twitters and have no desire to continue arguing about what is ultimately a subjective opinion), but it’s important to understand how loaded this phrase is when discussing commercialization and funding of openly developed projects.

To many, “open source” refers specifically and only to OSI and FSF approved licensing schemes. Using the term to describe projects that deviate from this often results in a focus on that language instead of a focus on the license, the project, or the problems being addressed via licensing.

In order to avoid getting caught up in discussions over semantics, I’ve stopped using the phrase “open source” to describe these kinds of projects when I can (even though I think it should apply 🤐). Instead I’ve been experimenting with “openly developed”, “source available”, and “equitable source” (I rather like that last one). Just something to consider.

Looking at open collective I can see that it’s unfortunately not generating any significant revenues

Can't you also make service to monetize? Like prioritize a merge request &/ issue buy paying. This way you can keep a permissive license

With a few notable exceptions, donation-based and other purely optional funding models like paying for issues just don’t work. That’s especially true for the .NET community - I can’t think of a successful .NET project that’s raised meaningful capital without placing restrictions _on use_.

I’d be curious to hear more background on how you arrived to that decision. What other options have been considered etc..

I think everyone would _like_ to see optional funding schemes like donations work out. No one gets into or sticks with openly developed projects for the money. That said, there’s absolutely nothing wrong with wanting to share in the value generated by software you write. It doesn’t even require an excuse like “we want to work on this full time” (though good on the team for having that goal). If the maintainers of a project decide that they would like to participate in the monetary gains of others due in part to their work, we should support and encourage that IMO.

don't you guys worry that having to pay for a license could drive away contributors?

I fear that other developers in the same situation could just think it's not worth it

I’ve started to advocate that maybe user count (and by extension, contributor count) as the sole metric of project success isn’t healthy. Each consumer is obviously totally free to choose whether they would like to use a project under the stated terms or not. That’s also true for contributors.

A contributor should not be expending effort on a contribution if they don’t like being held to the terms of the project once the contribution is done. There are plenty of reasons why a contributor might still choose to contribute like they need a feature in the box, they like the project regardless of licensing, etc. And maybe some _will_ be driven away. That’s okay too and shouldn’t be seen as the project being unsuccessful - it’s the natural result of maintainers, consumers, and contributors finding an equilibrium they can all live with.

we want to ensure that our license plans do not jeopardize dotnet foundation membership in any manner

This is a point I disagree with James on. My understanding is that the .NET Foundation is primarily interested in permissive-only projects. I understand and appreciate that position. I think it becomes a trade off of what benefit the Foundation provides vs. the benefit of a commercial licensing strategy. It’s okay for a project not to be in the Foundation - it shouldn’t indicate anything about the stability, maturity, or success of a project either way.

Also note that while commercial companies are _members_ of the Foundation, their commercial products are not Foundation _projects_ (as far as I know - correct me if I’m wrong).

[antonfirsov]

@Ryder25 my understanding:
If your FOSS library already exists and references ImageSharp (update: before RC1), you are a subject of the Apache 2.0 exception. => The users of your library can reference ImageSharp for free (since it's being licensed under Apache in your project).

@JimBobSquarePants looks like a back door wide open, but I guess we can do nothing but accept it.

[antonfirsov]

@daveaglick thanks a lot for the valuable feedback!

In order to avoid getting caught up in discussions over semantics, I’ve stopped using the phrase “open source” to describe these kinds of projects when I can (even though I think it should apply 🤐). Instead I’ve been experimenting with “openly developed”, “source available”, and “equitable source” (I rather like that last one). Just something to consider.

Pragmatic approach, personally, I agree 100%. Helps avoiding useless debate and focus on the topic. (Although I also _"think it should apply 🤐"_)

My understanding is that the .NET Foundation is primarily interested in permissive-only projects.

Can you refer to a direct (or less direct) statement on this? All information I was able to find on DNF website seems useless to clarify this question.

[Ryder25]

@antonfirsov Thanks for the reply. I understand the exception. I'm wondering about the case for new FOSS libraries.

[antonfirsov]

@Sergio0694 I totally see your points, and personally, I would consider donating free licenses to indie contributors. But nothing is simple in this licensing topic. I guess it may have side effects.

Also: In some cases, an external contribution may result in intensive maintainer effort.

[antonfirsov]

@Ryder25 sorry, it wasn't clear for me from your question!

It's a much harder topic (at least for me). I think if we will apply the same exception clause as ServiceStack, you won't be allowed to utilize ImageSharp from a new FOSS lib. I wonder if there are any alternatives to formulate that clause considering it's purpose. (Related point: I just don't get, why is a CMS an "end user app" under that clause?! One can develop plugins against it!)

I have opinions and all sorts of other random thoughts on this topic, but I don't feel authorized to state anything more without @JimBobSquarePants 😄

[kmgallahan]

My only comment for now is that it has been ~9 months since the licensing announcement and the only pricing information available is still:

• "cheap licenses for indie developers"
• "cheap, almost painfully so"
• "less than most people would spend on coffee per year" ~Reddit ($0 for me, $5 x 5 days x 52 weeks = $1,300 / year for some)

"Indie developers" and those using (or thinking about using) tiny fractions of the overall functionality would be the most interested in pricing info.

[JimBobSquarePants]

@Ryder25 @antonfirsov

I think I should clarify here. GPL licenses are FOSS.

In answer to your question. If you are developing a new FOSS library or SDK you must use either AGPL or GPLv3.

From the GNU documentation though is a very important note.

Please note that the GNU AGPL is not compatible with GPLv2. It is also technically not compatible with GPLv3 in a strict sense: you cannot take code released under the GNU AGPL and convey or modify it however you like under the terms of GPLv3, or vice versa. However, you are allowed to combine separate modules or source files released under both of those licenses in a single project, which will provide many programmers with all the permission they need to make the programs they want. See section 13 of both licenses for details.

The intended FOSS License Exception clause we intend to use that allows bundling alongside permissive licenses applies to end user applications only. @antonfirsov Content Management Systems fall under that category because they are complete web applications that can be extended via plugins.

@daveaglick Thanks for your insight there and for answering @GeraudFabien and @Sergio0694 's questions, much appreciated.

Also note that while commercial companies are members of the Foundation, their commercial products are not Foundation projects (as far as I know - correct me if I’m wrong).

The licenses for all the projects I've seen listed are FOSS, however, as I have noted above so is AGPLv3. What I do not know is what benefits from being members of the foundation the companies use for those projects? (Currently we use none as membership has not been completed).

If we cannot continue to be members I would obviously be disappointed but also would accept that decision. I want to be able to work with the foundation and the community as a whole to the benefit of all. That's why I introduced the Apache armistice (Yep, @antonfirsov huge hole for exploitation just now but I'm placing some faith in the community not to take advantage) and also tagged @jongalloway in the hope that we can work together on this issue.

@kmgallahan I was originally planning on several license tiers but its too complicated to manage. I will say though that I am thinking _a single fee of $99 per dev per year with bulk discounts at 10, 20 devs etc_.

This is not a final price and should be considered subject to change!

Will (what is a very low fee for an imaging library) provide enough of an income to fund future development? I do not know, I can only hope that companies appreciate the value that ImageSharp and co bring to their business.

PS. Downvoters who haven't already commented (thanks to those who have), please list your concerns, I really want to engage in productive conversation.

[sandorfr]

I don’t think commercial project belong in dotnet foundation just because they offer a AGPL (which has basically no use beyond academic and maybe research). I don’t think it aligns with the rest of the project including .net core. It would be misleading. This is just an opinion ofc.

Given the additional details I completely understand/support the move otherwise. Especially given your pricing model above (per dev seat license) which seems reasonably cheap. The problem is that even cheap things are hard to buy as an employee.

Ideally I’d rather have Microsoft buy you and the contributors out (and hire you to work on it) and make it part of .net framework. That would be fantastic for .net core world. But I’m probably just dreaming.

[jongalloway]

@JimBobSquarePants I'm going to need to find out how to go about this from the .NET Foundation side. I'll need to start by asking the legal counsel, then possibly the board would need to vote on it. The copyright is held by the .NET Foundation, and contributions since joining have been under the .NET Foundation CLA , so the foundation definitely needs to be involved in the change to the license. I'll need to find out exactly what that means, though.

Disclaimer: I don't make a decision on this at all, I'm just the go-between for the project, board, and legal counsel. As such, I'm going to opt out of the philosophical discussions on this issue as much as possible, hopefully completely.

[tthiery]

In our company we investigate product dependency trees with regards to their licenses. If we see a permissive licensed library X depending on an AGPL licensed library Y, the library X is immediately removed. Why? No company loves AGPL with an exception which is not court proved. And we engineers all know how commercial licensing works: we ask for it and management does not want to deal with the vendor and just forbids using Y.

I think this licensing strategy are driving library authors away from ImageSharp.

[JimBobSquarePants]

@sandorfr

Ideally I’d rather have Microsoft buy you and the contributors out (and hire you to work on it) and make it part of .net framework. That would be fantastic for .net core world. But I’m probably just dreaming.

I'm sure if that was a possibility Microsoft would have already approached the team.

@jongalloway

The copyright is held by the .NET Foundation, and contributions since joining have been under the .NET Foundation CLA , so the foundation definitely needs to be involved in the change to the license.

That's not actually true. We chose to contribute the project source code under an open source license not assign copyright to the .NET Foundation.

@tthiery

I think this licensing strategy are driving library authors away from ImageSharp.

I'd love to see your numbers that support this statement. Our Nuget stats indicate nothing but an uptick since January.

[antonfirsov]

GPL licenses are FOSS.

@JimBobSquarePants I should have been used the term "permissive FOSS" to avoid misunderstandings. @daveaglick has a good point:

One of the things I’ve been learning recently is that many developers have a very strong opinion of exactly what “open source” means. I don’t want to debate the exact meaning [...], but it’s important to understand how loaded this phrase is when discussing commercialization and funding of openly developed projects. [...] To many, “open source” refers specifically and only to OSI and FSF approved licensing schemes. Using the term to describe projects that deviate from this often results in a focus on that language instead of a focus on the license, the project, or the problems being addressed via licensing.

I also think that using the community's Lest Common Denominator in our communication would be beneficial for us, and help focusing on the topic.

My personal opinion/story:
As an OSS consumer working for large bureaucratic corporates, I deeply empathize with @tthiery, wearing the same shoes way too often. I don't like the word "free" being used in context of GPL-like licenses, even if it's correct by definition. GPL licenses put strong restrictions on the consumer, excluding a significant portion of users against their will. We shouldn't ignore them in our language.

---

EDIT: Corrected language, longer quote.

[samsosa]

Now that CoreCLR 3.0 has been released there is a new competitor: System.Drawing!
Sure, that's no comparison to your great image processing library called ImageSharp.

... but so far CoreCLR 2.x didn't provide a real way to handle image data. Now it
is (again) possible to perform simple image processing with the standard tools of
the .NET/CoreCLR 3.x framework. I'm pretty sure that as soon as ImageSharp get
a fee or the licensing becomes too complex people will tend to use System.Drawing.

I can only wish you good luck, the decision can mean anything or nothing for the
project and for you guys.

And by the way, your library is awesome! Keep up the good work.

[JimBobSquarePants]

Now that CoreCLR 3.0 has been released there is a new competitor: System.Drawing!
Sure, that's no comparison to your great image processing library called ImageSharp.

Thanks for your support @samsosa I appreciate that but I'd like to clarify the facts around System.Drawing. It has actually has been available since .NET Core 2.0

https://www.nuget.org/packages/System.Drawing.Common/

It still, however, comes with a warning.

Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions. For a supported alternative, see Windows Imaging Components.

[jkulubya]

Hi
I agree with all the comments above about how great your work is, and don’t really have an issue with the licensing specifically - it’s your work, and you get to choose what to do with it.

I just wanna make a point on the pricing. There are places in the world where $99 is a princely sum. And even when it’s an easily achievable amount of money, one might struggle to pay it due to no access to credit cards and what not.

If the licensing/pricing situation is a purely commercial decision, then ignore the above paragraph and set whatever price you need to set for the books to balance and tummies to get fed. If not, then a discussion around enabling less fortunate devs might be helpful.

[samsosa]

System.Drawing
It has actually has been available since .NET Core 2.0

That's right, I was wrong. It was the change from .NET Framework to CoreCLR 1.x where there was no suitable library for image editing. Since this change from System.Drawing to ImageSharp (the transition vom .NET Framework to Core) there have been no major important changes in CoreCLR 2.x. The change from CoreCLR 1.x to CoreCLR 2.x was just a setting in the compiler options. However, CoreCLR 3.x brings some improvements that can only be used by modifying existing source code (for example, Span/Memory, Sequences, ...). Now the return to System.Drawing can be re-evaluated and discussed again by those who are responsible for decission making.

[tthiery]

Regards the library transitive license situation and AGPL: you will not see any evidence. For that the library is too popular and without choice.

Companies are unreasonable afraid of GPL and even worse the AGPL. Only few understand them well. Take the sample of the .NET Core members discussing LGPL vs MIT with signs indicating that they just understood LGPL (no disrespect, licensing is hard).

I understand what you are doing here, building a commercial product (and you deserve any penny here). Since you will not be able to do license audits (I guess), why not do a commercial license with a free tier instead. This is much easier to process than a AGPL "nightmare". Just stay away from anything which has viral elements in it.

@jongalloway considering the recent controversy about "mandatory" permissive licensing in the Foundation, take this as an example. An ecosystem / dependency trees with hidden incompatible license gems are a huge pain point.

[castholm]

OSS projects that can prove to us via commit history that they took a dependency on ImageSharp before the Release Candidate will be able to consume the library (and future versions) under its original Apache 2.0 license.

The intended FOSS License Exception clause we intend to use that allows bundling alongside permissive licenses applies to end user applications only.

@JimBobSquarePants Pardon my ignorance, but does the wording "end user applications" here mean that dependent libraries that are licensed under a permissive license (for example, PdfSharpCore) will not be able to make use of this exception clause and must change their license to an AGPLv3-compatible one if they intend to continue to depend on later releases of ImageSharp?

[JimBobSquarePants]

@castholm Your first quote explains what this means for PDFSharpCore. They have taken ImageSharp as a dependency while it still has it's Apache 2.0 license. They will continue to use it (and future versions) under that license.

[castholm]

@JimBobSquarePants But if your statement that the exception clause would only apply to end-user applications carries the same implications as the ServiceStack license (linked earlier in the thread), projects such as PdfSharpCore would not be able to make use of it since they are libraries intended for use by software developers and not end-user applications.

I would appreciate some clarity on whether permissively licensed FOSS projects that are libraries and not end-user applications that took a dependency on ImageSharp before RC1 will be able to continue to consume it under Apache 2.0, because reading through the thread I'm getting mixed messages.

[x2bool]

That exception does not make any sense to be honest. In theory someone could make a tiny Apache 2.0 library that references ImageSharp and continue using newer versions of this lib.

Also I have nothing against commercial software, but I hope .NET Foundation excludes projects like this from the foundation, because apparently people cannot rely on open source licenses anymore: you have to study whether the contributors signed the Contributor License Agreement or something like that.

[tthiery]

Why not creating a new major version with a commercial/agpl license. Existing software can use the old major and new software can jump on the new major. That would avoid creating a commit based exception.

[JimBobSquarePants]

@castholm
I think you are getting yourself mixed up.

I would appreciate some clarity on whether permissively licensed FOSS projects that are libraries and not end-user applications that took a dependency on ImageSharp before RC1 will be able to continue to consume it under Apache 2.0, because reading through the thread I'm getting mixed messages.

That is what I said in the opening statement. If a library has taken ImageSharp as a dependency before the RC then ImageSharp will continue to be licensed to them under Apache 2.0.

@x2bool

That exception does not make any sense to be honest. In theory someone could make a tiny Apache 2.0 library that references ImageSharp and continue using newer versions of this lib.

The exception is part of the AGPLv3 license planned for the RC. It has nothing to do with the Apache license and pre RC versions. I cannot fathom why you are conflating the two. It explicitly prevents libraries like that from being created, allowing only end-user applications to benefit.

Why not creating a new major version with a commercial/agpl license. Existing software can use the old major and new software can jump on the new major. That would avoid creating a commit based exception.

@tthiery That makes zero sense. We haven't even released a V1 yet.

[castholm]

If a library has taken ImageSharp as a dependency before the RC then ImageSharp will continue to be licensed to them under Apache 2.0.

Then what is preventing a bad faith actor from (right at this very moment, since the project is still licensed under Apache 2.0) creating a permissively licensed library that is effectively a wrapper around ImageSharp with an identical API and continuing to keep it updated as ImageSharp moves beyond RC1?

Or as a less blatantly malicious example, say someone were to today create a library depending on ImageSharp that offers a subset of ImageSharp's functionality (such as image resizing and cropping) under an alternative API. Would there be anything preventing them from doing this?

[JimBobSquarePants]

Nothing. That's why I said we are opening up ourselves to exploitation.

While we appreciate this opens us up to exploitation before the Release Candidate this seems to be the fairest way to make our transition to a less permissive license and offer a strong, commercial-grade, product.

You did read my opening statement above?

[castholm]

Apologies if I come off as stubborn, but the reason I wanted you to clarify the exception clause is because what you wrote in this reply about it only applying to end-user applications contradicts what was written in the opening statement.

As a related follow-up question, what will happen if a project that is subject of this exception is forked? Will the fork also be subject to the exception or will it need to be relicensed?

I also want to make clear that I do completely sympathize with the project's situation. It is just unfortunate that this change happens right before the 1.0.0 release, after many projects (both OSS and proprietary) have taken a dependency on it. I understand that it is not anywhere near the intention, but this change does come off as a somewhat deceptive bait-and-switch.

Along the lines of what @tthiery suggested, I think this change would be a lot easier to swallow for dependents it were to occur going from 1.*.* to a 2.0.0 major version (hell, even a 1.1.0 minor version) instead of right before the first production-ready release.

[Sergio0694]

To be honest, the "proxy library exploit" (the one mentioned by @x2bool) was the first thing I thought would happen at some point, after reading about @JimBobSquarePants' "trusting the community" idea. Which, don't get me wrong, is absolutely admirable, but it's also very risky.
And as expected, it didn't take long before someone described the same exploit in here, and I'd really not be surprised if someone else was creating such a library right at this moment.

"Expecting the worst of people might be a sin, but you often end up being right" (cit.).

Now, I know that this issue does not have an easy solution, and the whole thing is extremely complex. This is just my two cents, but I wouldn't be surprised if after a while using the "proxy library" simply became the norm for closed source projects that didn't want to pay for the license.
Which as a result would force you to raise the prices of the licenses, and the whole maintenance cost would just fall on the shoulders of those (hopefully many, but still) honest developers that did want to support you guys working on the library. This could end up being just like tax evasion: people not paying them would still benefit from services, while those paying them would also have to account for the others. With the main difference being that in this case, bypassing the license would actually be perfectly legal. I'm worried this could also potentially result in developers paying for the license perceiving the whole thing as being "unfair" because, again, they'd be paying money where other developers without the same good faith would instead be using the same exact services, but for free. Again, not unlike tax evasion. At the end of the day, such a system would virtually become just like the existing donation system, just in a more convoluted way.

I want to note: I'm not actually proposing a solution as I wouldn't really know how to solve the issue, I'm just sharing my thoughts on the ongoing discussion. It's great that you guys dediced to open a discussion thread before making any actual changes, imho that was a good call! 👍

[JimBobSquarePants]

Ok. I’m locking this discussion now as it’s becoming increasingly obvious that nothing productive is to be gained. I encourage certain individuals in this thread to read before they comment on future threads here and elsewhere.

[tocsoft]

For future people that find this issue this decision was reverses and ImageSharp is licenced un Apache-2