Replies: 5 comments 16 replies
|
My understanding is that based on the OSMF, this is not the case: Q: If I use a project and that project depends on other projects do I need to pay all of them?
|
|
But the silence of the project owners is troubling. |
|
@joelhulen @carlfranklin Care to weigh in here? |
|
@iancooper, thank you for all of your support over the years. I hear your concerns loud and clear. We are taking your and others' concerns very seriously and are evaluating the concerns raised (which versions are impacted, clarity around direct referencing vs. Polly being pulled in as a dependency by other projects, edge cases like you mentioned, etc.) @carlfranklin has spoken with the OSMF people, and I think he might have some more clarity, but we're going to meet internally ASAP to consider the best path forward. |
|
Polly with OSMF just does not make any fucking sense.
This makes no sense sorry. Most people use Polly because of the Microsoft lib. You would gain nothing. Just look at Downloads per version and you will see that most downloads come directly from Microsoft or aspire packages.. |
|
I agree on the confusion here. I intended to follow: https://learn.microsoft.com/en-us/dotnet/core/resilience/http-resilience?tabs=dotnet-cli to introduce resilience to our HTTP pipeline. Lots of this documentation here directly links to Polly documentation and in some cases uses Polly classes and objects. I can easily see this being very confusing for compliance teams to reason about. Source code will end up with Some Wording suggests that we're ok so long as its not a |
|
Let's also be clear: the OSMF is a license fee, no matter how you dress it up. It is dishonest to suggest otherwise. |
|
We are going to create a fork under BrighterCommand, called Fences, and invite contributors and maintainers unhappy with the OSMF licensing direction to join us there. |
|
Another problem I see is the attempt to retroactively apply this license-fee (which it is), to all versions of the library (at least I don't see any attempt at clarifying the situation), which clears throat could lead to all kinds of legal problems. |
|
An interesting conversation, for sure. Let me address @iancooper's original post. As has been noted, users of Microsoft's resilience tools are not required to pay at all. Also, your organization has to make over $20,000 profit per year in order for you to pay the $20/month fee. This is hardly a tax you have to pass on to your users. If so, we are talking pennies, most likely. It is also hardly a reason to fork, which introduces many more problems than a $20 fee would alleviate. It is not a license. It is a fee so that App vNext can afford to pay those who maintain it, test and accept pull requests, upgrade when new versions of .NET come out, and write new functionality into Polly. Being in the enterprise infrastructure category, those who are using Polly in the enterprise are most likely making much more than $20,000 a year on their software. We see this as a reasonable drop in the bucket to help Polly stay up to date. That said, we expected pushback. Perhaps we can make the language more clear. |
|
I'm on vacation. We'll pause until you can create more clarity about how you see this working. I think the OSMF is a good concept, but once more mission critical projects try to use it, needs more diligence than it has had, to understand its ramifications and perhaps to refine how it works. |
|
I think 1.2% ((20 * 12)/20000) of a companies revenue for the use of this library is crazy. With the amount of projects adding OSMF we're talking upwards of 5% of the revenue on projects that previously were just OSS. On my tasks for this week was implementing Polly into our HTTP pipeline but I just ran straight first into this and it has stolen all my motivation. |
Uh oh!
There was an error while loading. Please reload this page.
Over at @BrighterCommand we have been a strong supporter of Polly since practically V1. I had early conversations with @reisenberger about the project. We built Polly into Brighter because I wanted to work with other projects in the ecosystem to strengthen it, not reinvent what others specialize in.
We were excited when ASP.NET adopted Polly, despite the downstream pain of strong-naming, which we bore so Polly could seize the opportunity.
Unfortunately, the introduction of a license- and make no mistake, the OSMF is a license because it charges for commercial usage- now creates a cost to every Brighter/Darker user starting in November. A cost for which our users pay, and from which our project obtains no revenue. Not that we would want revenue, as we continue to believe in FOSS.
A similar situation exists for ASP.NET users. It was a huge win for the .NET community when ASP.NET took an OSS project into its core offerings. Now, they will be charged for using ASP.NET, not by MS, but by the maintainers of this project.
This situation is unacceptable because it lets this project profit from others' labor. Others continue to support FOSS. I understand this project may feel it can't continue without the OSMF; perhaps it should have raised that issue.
However, that puts us in a delicate position. We don't want to force our users to be charged, because we use Polly.
As a result, we will need to fork Polly and offer an alternative version of it as FOSS. This will let us keep shipping without forcing our users to pay OSMF a third party. Once we fork it, we will obviously allow others to use our fork.
We may then use AI to reverse engineer and produce a new version compatible with existing test suites, but that remains a possibility.
I'm exceptionally disappointed by Polly's stance here. We championed this project long before anyone had heard of it. For this project to then decide to profit from our users is exceptionally disappointing.
All reactions