Redistribution of OSMF libraries - what are the intentions?

[bilbothebaggins]

Note that I am sympathetic to the idea behind this project. I am just thoroughly confused as to how well all this was actually thought through?

The OSMF terms are formulated as an "End User License Agreement".
My reading would then be that each and every user of software that contains libraries under OSMF would be required to pay the Fee.

( Also supported by answers in https://github.com/orgs/opensourcemaintenancefee/discussions/6#discussioncomment-13781947

3. Are "library-using-product" users required to pay the fee? Following on from (2), my read would be "yes", but only if they're "revenue-generating Users".

Your assessment is correct. Exactly correct.

As a counter point, the website https://opensourcemaintenancefee.org/consumers/which/ states:

... To be clear, you do NOT need to include the projects your projects depends on, only the projects you directly use. ...

Lets go with the first interpretation for now. (because personally I cannot read the EULA in any other way.)

)

I am employed by a company that sells/licenses for-profit software. It is normal to pay fees for commercial development libraries, entailing full support and legal coverage of redistribution.

The normal business case is that our customers will buy/license the software from us, and by doing so all license compliance tasks are covered. (As long as they do not re-distribute the software, which is not done normally.)
Specifically, while they may fall under the terms of a "trivial" third party End User License Agreement, we would never distribute software (indeed not get it accepted by corporate customers), that contains multiple third party library components that require the customers themselves to establish a payment relationship with the third party supplier. (*note a)

Yet, this is, unfortunately, the only way I can read the OSMF EULA - and it seems to be intended?

I got here via the https://github.com/json-everything/json-everything project. So, using these libraries (via their nuget binaries) will not only require my company to pay 50USD per month to use it in one part of one application -- (Which is, IMHO, bad enough for adoption.)

-- If we distribute that software, each and every customer company (User) will themselves be required to sign up to the Github Sponsor of that project and pay a monthly fee in perpetuity as long as anyone in their org is using our software. Is this indeed the idea?

I fail to see how this model is supposed to scale in the context of commercial software.

Edit: I only watched the vid from last year after writing this up, and interestingly enough Rob Mensching talks about "users of the project -- that is if you are a developer/org in a setting where you use "the project" (as demarcated from "the source code") to generate revenue, then you should pay. This idea makes a lot more sense, as it would not include End Users of composite software. However, as outlined above, I fail to see how the EULA in it's current state reflects this idea. (See also comment https://github.com/orgs/opensourcemaintenancefee/discussions/3#discussioncomment-15715420 )

I am grateful for any insights, thanks.

---

(*note a) Yes, some parts that relate to software, like the OS or an RDBMS may need to be licensed by the customer, but these are well understood today and normally entail significant costs that warrant the management/procurement overhead.

[robmen]

The FAQ does try to answer your question directly.

Q: If I use a project and that project depends on other projects do I need to pay all of them?

No. You only pay the Maintenance Fee to the projects you directly reference. Your relationship is only with the projects you choose to use. The maintainers of those projects may choose to depend on other projects and, if so, there is a relationship between the maintainer and the next-level of dependencies. And so on, and so on. In the end, the dependency choices other maintainers make do not impact your Maintenance Fee, even though they will impact your product.

A lawyer wrote the EULA, so the terms used in the EULA are legal, not layman's. Also, I'm not a lawyer, so if you still have legal questions, you need to ask your lawyer, not me. ')

But the intent of the EULA is to only require the direct use of a project to pay the fee. Hopefully, that allays your concerns.

[bilbothebaggins]

the intent of the EULA is to only require the direct use of a project to pay the fee

Thanks for this clarification. Good to hear that is indeed the intent.

How does this square with what you wrote in 2025 as answer to the topic of Briefcase:

3. Are Briefcase users required to pay the fee? Following on from (2), my read would be "yes", but only if they're "revenue-generating Users".

Your assessment is correct. Exactly correct.

Briefcase is not a library where I would "direct"ly use the WiX project as a third party dependency, but rather (self described) a tool, so the "end user" would not interact with The Project, now would they?

[bilbothebaggins]

I have looked around a bit more, and it appears others think that one could see the EULA is an exclusive agreement between the entity downloading and interacting with the development libraries.

I mean, indeed, as far as I can tell, the "redistribution angle" was/is not relevant for the WiX toolset, because the WiX toolset is not something one would typically re-distribute. (But: see Briefcase)

Still, I am very skeptical and I definitely see inconsistent statements in the discussion here, in the homepage and in the FAQ. (Even if I were to grant that the EULA is legally clear.)

For example, the homepage states:

"To be clear, you do NOT need to include the projects your projects depends on, only the projects you directly use."

What is that even supposed to mean within a package ecosystem like nuget? When I use facy-lib-42 for my app and that lib in turn references json-everything (or wix), I still directly download the Binary Release covered by the EULA myself. And I would be presented with the EULA; would have to accept it. -- But, I would typically not interact with the project in any other way (like opening tickets).

On the other hand, Briefcase includes WiX in a way that does not require a user of the tool to ever interact with, or accept, the EULA. Indeed, users of that tool could not even be aware of the fact that WiX is involved in any way. Yet, @robmen wrote back in July 2025: "(Briefcase users required to pay ... "yes", but only if they're "revenue-generating Users".) -- Your assessment is correct. Exactly correct.".

Also, for example, the nuspec files declare the license as the OSMFEULA.txt and not as the actual OSI license the project's source code is under.

This generates problems when using license compliance toolkits to verify licenses - instead of the well understood OSI license, the package is reported under a different license. But then again, that may be intentional, as any user scanning the nuspec would potentially fall under the OSMF obligations anyway.

Disclaimer: It should be clear that I am Not A Fan™ so far, not because I am not sympathetic to the goals of the OSMF, but because I think:

• The legal text of the EULA, even together with the available FAQ, even after asking here, is IMnsHO extremely unclear.
• Within the context of larger organizations, the overhead for a well-organized development team to internalize the source code and just build the .NET lib themselves seems to be significantly less than to push the OSMF EULA both through the corporate OSS office and the procurement process.
• Which means, unless it is an intrinsic goal to directly support a project (for whatever reason), it is actually easier, cheaper and less legally risky to just build the sources yourself.

[robmen]

You're very much on target here so I'll just add a bit of additional context to each of your points and I think you've got it.

one could see the EULA is an exclusive agreement between the entity downloading and interacting with the development libraries.

Yes. I think this answer on Stack Overflow understood the license exactly correctly:

Despite being called an "End-User License Agreement", from the text it seems quite clear to me that it applies to a "User" (developer of an application based on the project) and not to an "End User" (consumer installing and running that application).

the "redistribution angle" was/is not relevant for the WiX toolset, because the WiX toolset is not something one would typically re-distribute

That is not correct. There are several NuGet packages in the WiX Toolset that are very much intended to be referenced by applications like "normal" NuGet Packages. For example: WixToolset.Dtf.WindowsInstaller. I tried to take all cases and all OSS ecosystems into account.

On the other hand, Briefcase includes WiX in a way that does not require a user of the tool to ever interact with, or accept, the EULA.

That was not my understanding of how Briefcase worked. As I understood it, Briefcase required its users to manually download and install the WiX Toolset. Thus, Briefcase users were directly exposed to the WiX Toolset EULA. If you read my full comment, I explore an alternative in which Briefcase does not do that and instead includes the WiX Toolset binaries.

...the package is reported under a different license. But then again, that may be intentional, as any user scanning the nuspec would potentially fall under the OSMF obligations anyway.

Yes! Exactly correct. It is important that consumers recognize the license of the package they are choosing to use. NuGet does not do a great job of presenting the license to users, especially when it changes. In fact, I think it was on a Reddit thread where I made a half-serious joke that we'll know the OSMF has "made it" when it is assigned an SPDX identifier. :)

The legal text of the EULA, even together with the available FAQ, even after asking here, is IMnsHO extremely unclear.

I find this comment curious because, from your comments above, it seems to me that you've come to understand the OSMF very well.

Within the context of larger organizations, the overhead for a well-organized development team to internalize the source code and just build the .NET lib themselves seems to be significantly less than to push the OSMF EULA both through the corporate OSS office and the procurement process.

That is entirely possible. One of the goals of the OSMF is to help businesses (and procurement teams specifically) recognize that they have implicit vendor relationships across all the OSS projects they depend on, and that they should understand the business continuity implications of each dependency. Taking on the maintenance burden by forking an OSS project is a valid way to address the business continuity issue.

Note: I've also found that when procurement teams do the cost-benefit analysis, many find that paying the very small maintenance fee is much more economical than forking the project. And continuing to streamline the procurement process remains a high priority for the OSMF.

Which means, unless it is an intrinsic goal to directly support a project (for whatever reason), it is actually easier, cheaper and less legally risky to just build the sources yourself.

It may be easier and cheaper to fork a project and maintain it yourself. But the "less legally risky" claim does not hold water. If you pay the maintenance fee, you are compliant with the OSMF and can rest assured that you are doing your part to sustain the project you depend on.

[bilbothebaggins]

The legal text of the EULA, even together with the available FAQ, even after asking here, is IMnsHO extremely unclear.

I find this comment curious because, from your comments above, it seems to me that you've come to understand the OSMF very well.

I, personally, as a developer exposed to licensing and legal issues, have come to appreciate the intentions of the OSMF.

That does not mean that I think the EULA text (vs. the FAQ, vs. other statements) is clear.

Especially the re-distribution angle (see separate comment by @Piedone ) is under-specified.

Also, I've had the "pleasure" to interact with a few licensing/legal teams of large OEMs over the last few years, and those seemed like quite the paranoid bunch - I wouldn't bet a penny that the OSMF would be approved there, if we reported an OSMF covered library in our end-user product. But then again, I've come to the conclusion that we don't need to report it in our OSS license documentation, only the original MIT license needs to be reported.

[robmen]

I agree that legal teams can sometimes be challenging. But the WiX Toolset has had the OSMF in place for almost a year now, and there have been zero legal questions about the EULA from over 200 companies of all shapes and sizes. This surprised me, and is the fundamental reason I'm reticent to change the EULA based on non-legal feedback.

[Piedone]

Also coming from json-everything (json-everything/json-everything#1011), our main issue at Orchard Core, a fellow .NET Foundation project that uses JsonPath.Net, is that there's a discrepancy between the EULA and the FAQ about transitive use. The EULA, unlike the FAQ, is not telling you that you're a User only, and thus actually only covered by the EULA, if you're a direct, NuGet-referencing user of the packages. The EULA doesn't exclude indirect/transitive users.

Can that be included?

[robmen]

I am not a lawyer, but my understanding is that all terms in the EULA are defined and mean what we intend them to mean (i.e., they are in line with the FAQ).

Of course, I look forward to incorporating any legal feedback should that happen.

[Piedone]

Everything can be defined in any way indeed, but it needs to be part of the EULA or its explicitly referenced, included exhibits. The FAQ as such is an independent document, as it's not distributed with the EULA in the projects that use it.

[AraHaan]

Plus I would like to also state this:

• in the EULA for the OSMF due to the definition of User not being clear that if one was to take it to court for example to argue something, due to the definition of User in this case not being well-defined (like in C++ code sometimes) that it could mean:

• the end user installing the application that depends on the code with the OSMF dependency.

• the developer of the application.

• or both.

In the eyes of the people there in a courtroom.

Again all of the above is an example that has not happened yet (that I know of).

[robmen]

No legal review has suggested that the person using an application that depends on software that uses the OSMF EULA is "the User" described in the OSMF EULA. If you have a lawyer who interprets the OSMF EULA differently, I'd be interested in their feedback.

[bilbothebaggins]

No legal review has suggested that the person using an application that depends on software that uses the OSMF EULA is "the User" described in the OSMF EULA. If you have a lawyer who interprets the OSMF EULA differently, I'd be interested in their feedback.

Yet, we have several non-lawyers raising exactly this point, namely that The User seems ambiguous to them.

So, either for a law professional, this is all clear cut and we're just overreacting, or the legal reviews did not take this into account.

As said before, I unfortunately cannot provide a legal insight (wrong jurisdiction, no legal dept here).
All I know is the paranoia of the OEM's we're dealing with. :-)

[Piedone]

The ImageSharp license does definitions well: https://github.com/SixLabors/ImageSharp/blob/main/LICENSE. It's clearly spelled out what's a transitive dependency and what's a direct one.