VNext License Changes #2151
Replies: 19 comments 52 replies
-
|
If I was making this decision for my project I would be researching how enforceable this is. Hopefully doesn't require any lawyer or anything. Seems like a reasonable change though if your goal is to make it more viable income wise. |
Beta Was this translation helpful? Give feedback.
-
|
It allowed us to go full time on our "project" and even employ people now. That's what we wanted to achieve. |
Beta Was this translation helpful? Give feedback.
-
especially the big corporates don't care about money. All they care about is compliance. They cannot "afford" to run with "under-licensed" software. |
Beta Was this translation helpful? Give feedback.
-
|
The 1M USD threshold sounds reasonable, what about non-profit institutions, how do they fit into this scheme? |
Beta Was this translation helpful? Give feedback.
-
|
Is that question targeted at this license or Duende? @leastprivilege Great to hear it's been a success for you! |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Hi, That said, I have a few thoughts here, in no particular order :
Otherwise, it sounds like a good balance between making big companies pay for the software they use and letting small business freedom to tinker with the project. |
Beta Was this translation helpful? Give feedback.
-
|
@jeremyVignelles It looks like @Webreaper has answered some of your questions below but I'll answer the others.
The transitive clause is actually really important, I'll explain why. I've explicitly called out the following to ensure that the Split License is non viral.
In practical terms this means that If you are granted a license, that's the one you're use, not the Split License which exists to derive the license to be granted to you. So if you're OSS, you should only be concerned about and reference the Apache 2.0 license - downstream consumers shouldn't need to care. That, on the surface makes the whole transitive/direct thing seem redundant except for the fact we have to use the Split License in NuGet packages, so if someone is looking up their supply chain then they can reference the transitive clause to determine liability (none). Can it be exploited. Yes, but as I've said elsewhere. "Evil Corp is gonna evil". They're actually more likely to simply ignore the license. Most won't blink though and simply comply as @leastprivilege pointed out.
Now to answer your other question.
They do know it exists because you as a good contractor should be presenting a solution to them which takes into consideration all costs. |
Beta Was this translation helpful? Give feedback.
-
Congratulations - your company is growing fast, and now you can afford to licence the commercial software that allowed it to do so. This seems like a win for everyone.
This seems no different from any other licence agreement. If you work at a large corp/fortune 500 company and don't get management approval to use the appropriate licence, then you're either going to a) not use the software, or b) breach the legal T&Cs of the software you're using, making your enterprise company liable to face litigation. All the large corps I've worked at would frown upon that. If you're implying that the manager wants you to "just fix that bug" and that can only be done by moving from ImageSharp v2.0.0 to ImageSharp v3.x, then the manager/company has to make a decision on just how critical that bug is to their enterprise, if they're trying to avoid the costs associated with upgrading to the new version. |
Beta Was this translation helpful? Give feedback.
-
Except it might have had zero impacts on the growth. Either it's Apache 2.0, or it's not, you can't suddenly just change the Apache license after the fact, then it's not in fact an Apache license, but the "split license" you are using all the time. As a corporate developer, this is just a $5000/year library, with some weird license quirks, however great the library might be, if we only needed maybe 2% of the features, which would make it much more likely a big corporation will just find an alternative and less feature-rich library released under a true Apache 2.0 or MIT license instead. Don't get me wrong it's not that I don't want to support the devs, I just think this whole license stuff is raising more issues than it resolves, and casts a dark cloud over what seems like a great library. It would probably make a lot more sense to differentiate the features, and have a more limited "core" set of features, that are truly Apache 2.0/MIT with no ambiguity (which this library's license is imho as a corp dev (but also open-source dev in my free time)). Then you could expose the rest as this weird split license thing. I'm sure it's just a matter of time, before there are other libraries out there that are plain MIT licensed, that has the most used features from this library. Just look at Newtonsoft.Json, many have switched to just using the new built-in JSON classes to avoid extra dependencies. (not that there is any ambiguity for Newtonsoft.Json, it's plain MIT, not split this or that). I'm not using this library as a corp dev, but might for some open-source projects (MIT), but even then, this whole license cloudness, where it's Apache 2.0, but not really all the time but only if this or that, that might change or not, might push me in other directions there, it's just too much of a hassle to deal with. |
Beta Was this translation helpful? Give feedback.
-
|
I would suggest two slight changes to firm up the exclusions (and perhaps bring in a class of inclusion where it is only fair that you get your share)
|
Beta Was this translation helpful? Give feedback.
-
|
I chose the same metric as Duende but will have a deeper look. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
This looks similar to what I want to do with Statiq. It's already dual-licensed, but without a small business exception that I'd love to add. I've been looking at Ployform Small Business as an alternative to the License Zero license I've been using so far: https://polyformproject.org/licenses/small-business/1.0.0/. I also see @leastprivilege in here - the Duende license is one I also really like. As for your bespoke license...on the one hand, writing a custom license seems like the kind of thing lawyers should do. On the other hand, it's not like it's ever going to really end up in court or anything. And like you said, openly developed software licenses are violated and interpreted all over the place - at best it seems like they're usually just a polite request to most folks. From that perspective I'm not sure a bespoke license is any better or worse than any other, and I like the cleanliness of this one. I've also seen lots of discussions about businesses needing "standard" licenses - which usually translates to "only pure open source OSI approved" which kind of defeats the whole purpose. My feeling on that is: if they want to use the software I developed at the terms I'm willing to offer it, they'll find a way to adhere to those terms or are welcome to find another tool. |
Beta Was this translation helpful? Give feedback.
-
|
We did use a lawyer - and frankly never looked into other licenses. Our priority was the "community" vs "paid" aspect and to minimize our own risk (warranty, indemnity) etc.. because that's appropriate for a downloadable off-the-shelf library. There's other boilerplate stuff that must be there.
Well - how do you know that? ;) You might get sued, so you want a watertight license. |
Beta Was this translation helpful? Give feedback.
-
Yeah, this is the part that does bother me. I'm certainly never going to sue anyone, the cost of lawyers along would obliterate any benefit - but you're absolutely right that a bad actor could end up giving you a very bad day. Having some well crafted, professionally lawyered protective terms is definitely good CYA. The Polyform licenses were written by lawyers for general purpose use and all say this:
|
Beta Was this translation helpful? Give feedback.
-
That's ideal ;) but will not sit well with certain companies/lawyers. But probably also depends on the type of software you are building. It wouldn't work for us at least in many cases. |
Beta Was this translation helpful? Give feedback.
-
|
The extent to which that clause is acceptable probably has a lot to do with how much the project skews between single(ish) maintainer open source and corporate backed entity. I suspect I can get away with it because I don't really have another choice (back to that not wanting to end up in court for what amounts to a hobby) and I don't particularly care if a potential user backs away because of it. On the other hand I can see where Duende probably needs to provide some sort of guarantees for what's being purchased. Not sure where ImageSharp falls on that spectrum though. |
Beta Was this translation helpful? Give feedback.
-
|
I think there's two different markets there. Duende must provide warranty due to the nature of the environment. ImageSharp and co don't need to and it doesn't appear that there is a market for explicit support anyway since no-one was buying support licenses. I'd much rather make it pay-to-play and reintroduce the QA discussion channel here. |
Beta Was this translation helpful? Give feedback.
-
|
In layman terms, what's the actual diff between this new license and your current one? Just the 1M$ clause? I have very similar concerns regarding oss sustainability (with libvlcsharp) so I'll be following this thread :) |
Beta Was this translation helpful? Give feedback.
-
|
The old license was opt-in. The new license is not. They must comply. |
Beta Was this translation helpful? Give feedback.
-
|
Ok. Sounds great man, all the best. |
Beta Was this translation helpful? Give feedback.
-
|
Not bad! $1m seems like a very fair bar for the "time to give back" bell to toll 🔔. Maybe just research to make sure it's definitely the clear signal that it feels like and make it a policy to have a regularly scheduled review? Nice and simple though, and very approachable for people who want to use the library early on in an ideas life. 👏 |
Beta Was this translation helpful? Give feedback.
-
|
Fair move. I am not saying this licensing move is wrong, on the contrary. All I am discussing is if there could be a way to consider such cases. It would be easier for such projects to invest now and pay their dues when it is viable for them. |
Beta Was this translation helpful? Give feedback.
-
|
Can I ask a real-world version of this scenario? ReactiveUI which is MIT licensed open source decides to include ImageSharp as a plugin for Bitmap loading and manipulation. What are my obligations as an OSS creator towards ImageSharp, and how do we make sure that ImageSharp doesn't get screwed over by a company bypassing the license by not being aware of the transient licenses? Would it be a scenario where we should be naming our package that does this manipulating to have ImageSharp in the name and make it obvious in our documentation it's not free in all scenarios? |
Beta Was this translation helpful? Give feedback.
-
|
If you've consumed ImageSharp as an MIT licensed OSS project then you are explicitly granted ImageSharp under the terms of the Apache 2.0 license. From the license.
There's no obligations and nothing for a company to bypass. It's Apache 2.0 The license has been designed specifically to allow business as usual for OSS consumers. You'd be able to seamlessly upgrade to V3 without any change to your current processes. |
Beta Was this translation helpful? Give feedback.
-
|
@JimBobSquarePants -- Package A is not a problem. That's good behavior. This is where we want to take NuGet more generally. It has a lot more to do with versioning than licensing. Private dependencies are beneficial for two reasons:
For example, the Azure SDK team struggles with both these topics, with JSON.NET.
But this makes sense. If it wants to use ImageSharp it can by installing it. This isn't what transitive dependencies are intended for. The fact that they do is a side-effect that can cause problems. |
Beta Was this translation helpful? Give feedback.
-
|
That's useful knowledge and actually works in my favor! I'd be happy if that becomes the trend moving forward. |
Beta Was this translation helpful? Give feedback.
-
|
Let's do another scenario, you have an open-source project, that you would like to get funding for yourself, so you offer dual licenses for it, one with a commercial license, and another with an MIT license, since it's not really a proper "Apache 2.0" license, you are below the 1M revenue, but the customers that purchase the commercial license, might be over, would I need to resell a $5000/y license in that case to each customer, or would the customer need to purchase it. For this reason alone I could see even some open-source project's not wanting to deal with this weird split license issue, which is completely unclear. (let's assume the project only used ImageSharp for a tiny fraction of their overall project), I think many would just find a "real" MIT/Apache 2.0 library in that case even for an open-source project? |
Beta Was this translation helpful? Give feedback.
-
|
In general, I like this model. I think it's only fair to require for-profit users of the project to support the development of the project when they have the resources to do so. To that end, I feel like the "Transitive Package Dependency" clause provides too big a loophole. It would be trivially easy to publish a package, under a valid OSS license, that references ImageSharp and does nothing else. Because of how .NET references work, anyone depending on my package could call ImageSharp APIs directly and avoid purchasing a commercial license using that clause. I don't think that's ethical, but it's permitted under the license. I understand the intent, but even when a company is using an OSS package that internally uses ImageSharp, that company is still benefiting from the resources invested into ImageSharp and should be expected to contribute (assuming they meet the revenue requirements, etc.). I suppose there are cases where ImageSharp could be in the dependency graph but unused, and in a perfect world it would be nice to carve out an exception for those cases but I'm not sure how you'd do that without creating this loophole or requiring complex analysis of call graphs (plus I don't know how often that happens in practice anyway). |
Beta Was this translation helpful? Give feedback.
-
|
Yeah see above there's gonna be bad actors but the transitive portion is important. |
Beta Was this translation helpful? Give feedback.
-
|
New model makes sense. I really like the approach where personal users and small businesses can use it for free. "Free" is simple. You can publish an open source project with massive user count without worrying about licensing fees and you can experiment with building a business. I think a key part of making this work so well is your clause:
This is extremely friendly to the open source community. Want to make an open source project that links to this library because it uses it as part of powering an implementation, or maybe wraps it and adds value? You have zero legal work to do, because it's just Apache 2.0. Brilliant. I understand you're going for a pragmatic approach where your goal isn't to have something that would allow you to be 100% confident you'd win in court if a bad actor badly acts, but I had an idea of how you might address the loophole people describe in this discussion, where a bad actor could just wrap the library with an open source library of their own that simply exposes this library to their priority software project, where it could be used for free. You could break the library up into two - one for its API and one for its implementation. The API library would be released with a 100% open source license. For example, Apache 2.0. The implementation library would be released with whichever license you want that you think will address your main goal - getting paid. It could for example be this license, minus that "free if transitive dependency" clause. That clause would no longer be necessary because open source projects in the community could depend on the API library, not the implementation library. These open source community projects would provide a mechanism for their users to provide an instance of the implementation at runtime. It wouldn't be terribly complicated. They might, for example, change usage from: class MyOpenSourceProj
{
private ImageSharp imageSharp;
public MyOpenSourceProj()
{
this.imageSharp = new ImageSharp();
}
}To: class MyOpenSourceProj
{
private ImageSharp imageSharp;
public MyOpenSourceProj(ImageSharp imageSharp)
{
this.imageSharp = imageSharp;
}
}The consumers of the open source community project, which may be commercial software projects, would therefore need to depend on both the API (which is free) and the implementation, subjecting them to the terms that result in you getting paid. The open source community project would also need to depend on both the API and implementation, but that's no problem for them because unlike their consumers, they are open source, and therefore subject to Apache 2.0, not your getting paid license. I think an additional benefit of this approach is that you'd be structuring the project in a way that makes it very easy to support alternative implementations, making room for the community to step in and create one if they choose to. This might help you avoid bad PR in open source. I know you've gotten flak before over license changes in pursuit of your goal of getting paid. I for one, regularly purchase food, which I eat. I can empathize with the idea of wanting to get paid. I think that flak was stupid. It isn't a perfect world, but maybe this could help with that PR goal. |
Beta Was this translation helpful? Give feedback.
-
|
have u considered requiring a license file? So people need to select either OSS or paid, and then use that license file to run? |
Beta Was this translation helpful? Give feedback.
-
|
Great in theory, but not generally effective in practice. Either it's a generated key, which motivated bad actors will eventually figure out how to spoof, or the software needs to phone home in some fashion to verify the license. The latter option would likely be a deal breaker for consumers that require a strictly-controlled environment. Just my two cents, obviously. |
Beta Was this translation helpful? Give feedback.
-
|
Came here to write this. Also, key-based licensing typically generates a huge amount of support (when keys expire, don't work, etc etc) which is probably not something that @JimBobSquarePants et al want to get into if they can avoid it. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I have considered them (with almost everything else over the years) but it didn't seem contribution friendly enough nor worth the complexity. |
Beta Was this translation helpful? Give feedback.
-
|
Don't waste money or time on "copy protection" - the "bad actors" can download the source code and compile it themselves. You also don't want those people as customers anyway. Just attach a LICENSE to it and make everyone accept the license when they pull in the nuget. That's a good effort/benefit ratio (at least to start with). But the most important part is, more projects need to make that step. Companies will happily pay you - but not voluntarily. |
Beta Was this translation helpful? Give feedback.
-
|
I'd imagine there'd be some admin involved, like finding licenses and stuff like that, unblocking teams and stuff like that. Not sure how much admin time there is involved in that Imagine the sustainability model rewards if it works out outweighs the additional admin burden |
Beta Was this translation helpful? Give feedback.
-
|
Seems fair. |
Beta Was this translation helpful? Give feedback.
-
|
How do you avoid the situation where someone games the license by providing a vacuous nuget package that brings in ImageSharp as a "transitive dependency" for use in the parent app/package? By vacuous, I mean this package could be an auto-generated wrapper, or just anything that ends up bringing in ImageSharp as something the parent app/package could call into. Perhaps even an empty DLL. The vacuous package could be open source and free, generating no revenue of its own, and published by an individual unassociated with any for-profit entity. (I'm not trying to game your license, I just want to make sure this can't be done) |
Beta Was this translation helpful? Give feedback.
-
|
Quting @JimBobSquarePants from #2151 (reply in thread):
|
Beta Was this translation helpful? Give feedback.
-
|
Do you plan to make this change with a new major version, like There are certain tactical advantages, too. For example, imagine you found a serious security issue in ImageSharp a few days after you made the license change (and published to NuGet.org with that new license). It would good to at least have option to deploy that change to users with the old license. That wouldn't be possible if you just used the next version number, like |
Beta Was this translation helpful? Give feedback.
-
|
Yep major only. Some of the libraries (Drawing, Fonts) do not even have a V1 release yet so I'll release those under the current license and then a V2 under the new one.
|
Beta Was this translation helpful? Give feedback.
-
|
That sounds good. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
Related, what license would you expect to show up on Nuget.org, after the change? It (correctly) says Apache 2.0 today.
|
Beta Was this translation helpful? Give feedback.
-
|
We'd switch to the Six Labors Split License as a file embedded in the package. <PackageLicenseFile>LICENSE</PackageLicenseFile>
<ItemGroup>
<None Include="..\..\LICENSE" Pack="true" PackagePath="" />
<None Include="..\..\shared-infrastructure\branding\icons\imagesharp\sixlabors.imagesharp.128.png" Pack="true" PackagePath="" />
</ItemGroup>
|
Beta Was this translation helpful? Give feedback.
-
|
Sounds good. What I expected. |
Beta Was this translation helpful? Give feedback.
-
|
Instead of licensing change, why not include a EULA (End User License Agreement) or Terms of Use file in the package, that then companies can then see on nuget.org? Some libraries (like bass.net for example), have a registration system to where in order to use the apis, one must request a unique "product key" at their website:
This also have the added benefit of not breaking it like how richlander described to where if you released a new major version, then later found bugs in that new version (and the older one). It should also be the least time consuming. if they simply clone the source and remove the code for the licensing (free for non-companies unless they are non-profit) they would be in violation of the Terms of Use then and then they would be in trouble (cease use of SixLabors libraries). They can however fix bugs in the code as long as they do not remove the code specifically for licensing. I think this would be a great compromise for everyone. |
Beta Was this translation helpful? Give feedback.
-
|
Also, on another note: I need some help as well with something similar, I need sponsors for my code as well as 0$ a month just does not make me feel like open source is worth it (if just feels like an endless source of "entitled to update this code" with nothing to be able to use to pay the costs of maintaining it monetarily (like electric bills, cost of new pc if mine stops working, etc). |
Beta Was this translation helpful? Give feedback.
-
If only they'd actually do that before license change was introduced... |
Beta Was this translation helpful? Give feedback.
-
|
I haven't paid attention the last months. Did you successfully change the license? How is it working out with the DNF? ..and in general? thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
thanks! |
Beta Was this translation helpful? Give feedback.
-
|
I don't know that this adds any value to the discussion here, but I have to say, I'm completely okay with whatever licensing the ImageSharp team feels is appropriate. Everyone who has contributed, and continues to contribute, to the ImageSharp project has given up an irreplaceable commodity that none of us can ever get back: time. If an organization can't understand how valuable that is and pay the completely reasonable licensing fees that the team is implementing, I have no problem with them looking elsewhere. I mean, do the math: at $800 USD, you're looking at roughly $2.19 per day. That's barely a cup of plain ol' coffee. The enterprise license? About $13.70 USD per day. That'll get you one Jimmy Johns sub delivered once a day. I think the team has earned a sandwich, don't you? /end-semi-rant |
Beta Was this translation helpful? Give feedback.
-
|
I would like to ask what the end result of this discussion was. |
Beta Was this translation helpful? Give feedback.
and others
-
What is Happening?
The Six Labors libraries occupy a domain of software developmental that is considered very complex. As such, huge effort is required to research, develop, and maintain the libraries which is unsustainable for a very small team of developers working in their spare time.
Previous attempts (sponsorship, support license) to provide a sustainable income to ensure the continued development of the Six Labors libraries have not proven successful, yielding less than a few months of developer income over a period of several years.
To ensure the continuation of the Six Labors libraries we are planning to introduce license changes for the following versions:
This license has been explicitly designed to allow business as usual for Open Source or Source available consumers.
The License
Questions And Answers
Q. What do I need to do as an Open Source or Source Available consumer following these changes?
A. Absolutely nothing. No changes are required in any form. The license will continue to be granted to you under the Apache License 2.0. You and any consumers of your work continue to enjoy exactly the same freedom as before.
Q. What does this mean to me as a Non-profit organization or Registered Charity?
A. The license will continue to be granted to you under the Apache License 2.0. You and any consumers of your work continue to enjoy exactly the same freedom as before.
Q. What does this mean to me as an independent software developer or small business?
A. If your annual gross revenue is less than 1M USD then the license will continue to be granted to you under the Apache License 2.0. You and any consumers of your work continue to enjoy exactly the same freedom as before.
Q. What does this mean to me as a larger business or enterprise?
A. If your your annual gross revenue is greater than or equal to 1M USD and you are consuming any of the libraries as a "Direct Package Dependency" as defined in the license then you must purchase a Six Labors Commercial Use License. If you have consumed the library as "Transitive Package Dependency" you are subject to the terms of that third party providing the software.
Purpose of this Discussion.
I'd like to encourage anyone from the .NET Community consuming our libraries to comment below. I want to see what unforeseen issues this change might present and gauge the communities thoughts.
As well known and respected peers in the Open Source community who represent consumers of our libraries I'd explicitly like to invite the following people to discuss the license changes.
@richlander (MIcrosoft) @sebastienros (Microsoft/Orchard CMS) @bergmania (Umbraco CMS)
Please note. If anyone provides commentary that contains variation of the term "bait and switch" they will immediately be banned indefinitely from the Six Labors organization.
Beta Was this translation helpful? Give feedback.
All reactions