Repository navigation
Licensing Community Discussion #1024
Description
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.
Activity
sandorfr commentedon Oct 12, 2019
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 commentedon Oct 12, 2019
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 commentedon Oct 12, 2019
@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
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 commentedon Oct 12, 2019
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 commentedon Oct 12, 2019
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 commentedon Oct 12, 2019
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 commentedon Oct 12, 2019
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...
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.
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 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.
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.
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 commentedon Oct 12, 2019
@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 commentedon Oct 12, 2019
@daveaglick thanks a lot for the valuable feedback!
Pragmatic approach, personally, I agree 100%. Helps avoiding useless debate and focus on the topic. (Although I also "think it should apply 🤐")
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 commentedon Oct 12, 2019
@antonfirsov Thanks for the reply. I understand the exception. I'm wondering about the case for new FOSS libraries.
antonfirsov commentedon Oct 12, 2019
@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 commentedon Oct 12, 2019
@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 😄
12 remaining items
castholm commentedon Oct 14, 2019
@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 commentedon Oct 14, 2019
@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 commentedon Oct 14, 2019
@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 commentedon Oct 14, 2019
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 commentedon Oct 14, 2019
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 commentedon Oct 14, 2019
@castholm
I think you are getting yourself mixed up.
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
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.
@tthiery That makes zero sense. We haven't even released a V1 yet.
castholm commentedon Oct 14, 2019
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 commentedon Oct 14, 2019
Nothing. That's why I said we are opening up ourselves to exploitation.
You did read my opening statement above?
castholm commentedon Oct 14, 2019
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 commentedon Oct 14, 2019
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.
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 commentedon Oct 14, 2019
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 commentedon Aug 5, 2020
For future people that find this issue this decision was reverses and ImageSharp is licenced un Apache-2