Vacuum project is MIT licensed but includes a BUSL dependency (doctor)

[mriehl]

Hello there,

While investigating a panic in vacuum we found out that while the vacuum project has a MIT license it includes the pb33f/doctor library.

The pb33f/doctor library is BUSL licensed and explicitly states that it cannot be used on commercial projects without a license.

Is this intended? Since vacuum ships pb33f/doctor as a dependency I'm not sure what this mean for commercial projects.
Is there some sort of escape hatch where vacuum has a license to use doctor (or doesn't need one due to being open source) and therefore it's okay to redistribute it or something?

[daveshanley]

Hello,

This is intended yes. The doctor is a library that powers much higher level functionality inside vacuum and all other pb33f products.

I created vacuum as a free tool, however it does depend on a source available library. It cannot be extracted.

What this means for commercial products.

If you are shipping a commercial tool (charging money for it) that competes with any pb33f product, then we will need to discuss a license agreement (for an early preview, check out the doctor at https://pb33f.io/doctor/)

There are ways around this of course, one of them is to sponsor pb33f, or purchase a license to use the code in a competitive way.

There is no license required for any commercial business using the doctor internally for custom tooling, or releasing as an open source project.

All pb33f tooling is exempt from this requirement, which is why vacuum has an 'escape hatch' if you will.

[mriehl]

Thanks for clarifying!
What I can't quite derive is if vacuum itself is considered as pb33f competition.

If some org sells a service that does include openapi linting and uses vacuum for this purpose, is that fine (since it only indirectly uses doctor and the source isn't being extracted)?
Or would the use of vacuum already be considered competing with the doctor?

[daveshanley]

vacuum is not competing with the doctor or with pb33f, the doctor as a product is composed of all pb33f tooling, including vacuum - but has more power than just vacuum alone.

It's fine to use vacuum as part of a product that offers linting as a feature - it's really why it exists. So to answer your question:

"If some org sells a service that does include openapi linting and uses vacuum for this purpose, is that fine?"

Yes.

The source is not extracted and the doctor is being used to power vacuum in an approved way, even commercially. Using vacuum commercially, does not mean you need any kind of additional license to cover the BUSL license of the doctor (the library).

Using vacuum as an engine to power higher level commercial tooling is an approved use case and is exempt.

What is not cool however is to create an OpenAPI tool that specifically does linting and essentially just wraps vacuum, and then selling that tool. Even though it's still covered by the same clause, it would really, really piss me off.

If you want to use the doctor library directly - and not via vacuum in a commercially competitive way? Then we need to talk.

[mriehl]

Got it, thanks for the detailed reply!