Confusing language re: "depends on" in FAQ

[davidwhitney]

Hey folks - very much a fan of this initiative.

With Polly's recent announcement of adopting the OSMF (personally extremely supportive) I ended up in an open-to-interpretation discussion with a friend about the virility of the OSMF to consumers of their own framework project that depended on Polly.

Here is the specific scenario:

• Framework A supports resilience using the .NET package Polly
• It takes a dependency on Polly from NuGet

... some time later ...

• User creates a project that uses Framework A
• Polly is implicitly package restored

To use the resilience feature in their framework, the users themselves interact with Polly APIs (they make use of Poly syntax to define policies), this led to two competing opinions regarding if the end-consumers of Framework A were in scope of the OSMF.

Their take:

• Because this is not a silent, encapsulated dependency, the framework requires user code to "depend on" the Polly library, as such, all users of Framework A are now in-scope of this requirement, and as such I'm obligated to fork / recreate that functionality elsewhere.

My take:

• There are two example on the OSMF that directly contradict this and place the end users out of scope.
• https://opensourcemaintenancefee.org/consumers/faq/#q-if-i-use-a-project-and-that-project-depends-on-other-projects-do-i-need-to-pay-all-of-them - this one, that explicitly says "No. You only pay the Maintenance Fee to the projects you directly reference."
• https://opensourcemaintenancefee.org/consumers/which/ - this page, that uses package references as the guidance.

Unfortunately, I think the conflation of different uses of the word "reference" introduces ambiguity into the mix here and leads to a potentially uncharitable read that brings what I would characterise as indirect usage into scope.

So, questions to the floor:

1. Is the intent to bring this category of usage into, or out of scope?
2. If the intent that this category of usage is out of scope, can we tighten up the language in the FAQ to help cover it?

I would suggest something like:

Q. "What counts as referenced?"
A. Any packages you directly add, libraries you download and explicitly add, or dependencies you take directly are referenced dependencies. Packages, libraries or code that is a dependency-of-a-dependency that may get added or referenced as a side effect, peer-dependency or ride-along component are not the explicit target of this fee.

The ImageSharp EULA does a good job with a definition of: "Transitive Package Dependency" shall mean any Work in Object form that is installed indirectly by a third party dependency unrelated to Six Labors."

This is obviously related to a previous discussion here: https://github.com/orgs/opensourcemaintenancefee/discussions/12 - but focused on making the FAQ slightly clearer rather than amending the EULA. I appreciate that trying to work out how people can't pay is a mildly against-the-spirit of the initiative line of discussion, but it feels like this ambiguity distracts from the intent.

Thanks!

[martincostello]

Thanks for articulating the above @davidwhitney - +1 for some sort of clarification being made here.

My personal read of the scope is the same as David's (direct dependency, not transient).

• If that's not what's intended it might lead projects to try and adopt OSMF on a basis they didn't intend
• If that is what's intended, then users get their questions answered directly by the FAQs, rather than semantic debates happening in projects trying to adopt OSMF with project contributors stuck in the middle.

[robmen]

Your understanding is correct. To use C# terminology, "reference" aligns with PackageReference not using. But, I can see (now) how the current wording could be interpreted to mean both. Let me see if I can clarify the existing question or if I need to add a second, as you suggest.

[davidwhitney]

Thanks <3

[robmen]

No, thank you! Once I saw the "fuzziness" in the "reference" and "depends upon" terminology, I saw it in several places. I tightened up the FAQ answer and decided to lean heavily on the Which projects do you pay? to provide concrete examples and hopefully clear up any confusion on this front.

[rob-johnson-1978]

I just wanted to throw something into the mix here. Rob kindly reached out to me on social media, more regarding how our legal department might gain some clarity on the situation, and I spotted this thread.

Where I'm a little lost is this type of scenario:

• It's 2027, Polly switched to using OSMF in November 2026
• I have a .NET program
• I add the latest Microsoft.Extensions.Resilience because I need the latest (for reasons)
• That package has a dependency on the latest version of Polly
• Unfortunately that version has a defect in it which materially affects my application
• I discover this and, due to some time constraint or other, have to deal with that immediately
• I add a direct <PackageReference /> to the previous version, which doesn't have the defect, but which is a post-November 2026 version
• I now need to pay for Polly as per the terms of the EULA

As per David:

I appreciate that trying to work out how people can't pay is a mildly against-the-spirit of the initiative

And I agree, and feel somewhat awkward and ungrateful jumping into this conversation.

But my concern is not paying, it's a lack of clarity about when payment might be expected. And our legal dept have already tripped up once on this because they saw "the license isn't changing" and assumed "so we don't have to pay". Now I've pointed out to them that isn't true they're onto their second round of investigation and chin-stroking about the matter.

(It's not lost on me either that this process will cost more than $20).

So whilst this discussion is about clarity in the FAQs, I also feel like, fundamentally, hanging the legality of using a package on "depends on" is a footgun waiting to happen.

Not sure what the answer is to that though. But my personal opinion is that transitive dependencies should count. If I built a wrapper around NServiceBus (I obviously wouldn't 🙃 but I could) and released that, whoever used it would have to pay Particular. Because why is it any different, just because it's a dependency?

[iancooper]

Indeed, this trigger occurs when simply trying to resolve conflicting transitive dependencies between two direct dependencies. If my direct dependencies project Foo and project Bar both depend on project Baz, but bring in different versions, my resolution is to import the version explicitly at my project's level.

In this case, simply managing that transitive dependency issue would trigger the license fee.

However the intent around transitive dependencies is framed,they are likely not really excluded.

That creates the situation that you will need to fork a downstream to prevent costs accumulating, if that downstream introduces the OSMF, or replace the downstream (AI reverse engineering) in your own project.

This of course undermines an ecosystem as it discourages projects from sharing or relying on others. The risk that they could introduce the OSMF would be too high for a FOSS project.

Certainly, this will force us to fork downstream dependencies that we use, and consider a "no external dependencies without forking" policy.

[robmen]

@rob-johnson-1978 and @iancooper both raised transitive versioning conflicts:

If you need to adjust the version of a transitive dependency, use transitive pinning That will not add a direct dependency.

@rob-johnson-1978 also raised a few additional things:

1. I think "the license isn't changing" is probably doing a disservice here. I understand what they meant in the announcement but it would probably be better spelled out that "the source code license isn't changing". That is an important facet of the change but subtleties are being lost on the internet and social media. Surprise, surprise.
2. I agree that "depends upon" was also not strong enough and it is no longer used on the site except for in the FAQ question text where direct and transitive dependencies are now spelled out. This is a huge improvement in the site based on this thread.
3. No, direct direct dependencies are the only option and its summed up with this from the FAQ: Your relationship is with the projects you directly choose to use. The goal is to create the smallest feedback loop possible. You choose the project, the maintainer maintains the project.

Is it possible for others to create "man-in-the-middle" projects simply to avoid the OSMF? Yes. Will it happen? it could. If it does, we'll have more data to suggest that "zero cost" is what truly matters. If so, maintainers can adjust. At this time, that's not what I'm seeing. But it is still very early.

[iancooper]

I note that Central Transitive Pinning only lets me override it in my Directory.Packages.props file; it does not know which version to choose otherwise: https://blog.ostebaronen.dk/2024/11/transitive-pinning.html

To help with this, I suggest that you be clear that the central package reference, which is not in the .cproj file, does not trigger a dependency for the OSMF, i.e., the presence of a reference in Directory.Packages.prop would not trigger the OSMF.

[Arithmomaniac]

Just to be crystal clear: Microsoft.Extensions.Resilience does fall exactly into @davidwhitney's scenario of

the users themselves interact with Polly APIs (they make use of Polly syntax to define policies)

They are not purely transitive.

A related question: once I've pulled in Polly transitively, am I "home free" to use it as much as I want just because I have no PackageReference, if indeed the using doesn't count in order to support the scenario of using MER)?

c.f. dotnet/extensions#7719

[iancooper]

I note your reply here Rob: I note Rob's reply here on adjusting the FAQs around how to handle dependency versioning issues.

#22 (comment)

This is useful clarity as to intent of the author.

But the EULA simply talks about usage and has no indication of direct or transitive. The EULA simply cares about usage of the binary.

Now, perhaps the consumer is not asked to agree to the EULA transitively and so can claim that they never agreed to it, but that feels like the kind of issue that makes procurement and legal teams very twitchy.

I note that the Polly announcement just referred to usage, not to direct dependency over a transitive dependency - agreeing with the EULA but muddying the water for users of Polly.

I accept that this may be the first "big" library, used mainly as a transitive dependency, to test the OSMF, but there is a lot of "grey" here.

Much of it seems to be being brushed under the carpet as "it's only $20." But there is no guarantee that next month it's not $2000. The only constraint is the price point at which a maintainer may feel that a fork would succeed. And there is no guarantee that I get anything for that, other than a binary.

[iancooper]

I think it's also unclear for folks using the OSMF with a EULA whether that triggers the EU CRA.

My assumption would be that the OSMF, by charging for binaries, falls firmly into commercial activity and would mean that orgs like app-vnext would need to comply, although likely with the lighter touch arrangements.

This means that some assertions about what you receive in response to the OSMF payment may change.

Unless of course app-vnext chooses not to charge the OSMF in the EU, or chooses to comply there.

[rob-johnson-1978]

the kind of issue that makes procurement and legal teams very twitchy

This is the most of my professional problem. Rightly or wrongly. As I said to Rob M on X, I think we might end up being told to drop it. Which is fine. As is starting to charge for it. Because who cares either way if it's just business?

My personal problem is that I actually do care - I want OSS in .NET to thrive. And (again as I said to Rob M) I will do what is within my power to influence our Legal and Enterprise Architecture dept to concede that we should just get on and pay. But this "grey" isn't making it easy - any sort of "debate", to them == risk.

[robmen]

Cool. I think I see four points.

1. On direct vs. transitive dependencies. The site is now explicit, the OSMF applies to direct dependencies, not transitive dependencies. That is and always was the intended interpretation of the OSMF EULA. If there is a specific legal issue with the EULA, I’m very interested to understand it.
2. The EU CRA is a different issue. The FAQ already discusses the current understanding. The CRA is new and we’ll continue to watch as it develops.
3. On the possibility that a maintainer could change the maintenance fee and what the maintenance fee buys, that isn’t a "grey" area. That is how the OSMF works. The source code remains Open Source, so if you don't want to pay the maintenance fee, you can build it yourself.
4. And I do understand the procurement pain. New processes can be hard for some organizations. All I can do is try to make everything as clear as possible. If there are specific ambiguities in the site, I want to fix them. But I need specifics.

[iancooper]

If there is a specific legal issue with the EULA, I’m very interested to understand it.
The EULA just talks about usage. It doesn't define what that means. I don't believe that the FAQ helps. The EULA is the contract, not the FAQ.

[iancooper]

The EU CRA is a different issue. The FAQ already discusses the current understanding. The CRA is new and we’ll continue to watch as it develops.

I would assume that the.NET Foundation becomes an Open Source Steward under EU CRA, which impacts projects like Polly anyway.

But I'm not sure if a EULA associated with a payment makes you commercial; that would seem to be the grey zone.