Consideration for BSL

[ericnewcomer]

My company manages a software project that is deployed in virtually every country, is used heavily in public good interventions, and currently carries a DPG designation with a required OSI license.

We see, and fully appreciate the desire to restrict DPG designation to open source projects that employ an OSI approved license. That said, we’d very much like to open a discussion for the consideration of licensing models which promote investment in open source projects so long as they do not restrict their use toward the public good and that they convert to an OSI license over time. Those following the Open Source movement have surely noticed the increased usage of such licenses. These licenses even have the support from a founder of the Open Source movement, Bruce Perens. Mr. Perens is also a co-founder of the OSI which the DPGA rightly aligns itself with. One of the most prominent forms of this model is the Business Source License (BSL 1.1) which Mr. Perens himself has helped to refine. In his words referring to the BSL..

In general, I approve of schemes which allow people to make money from creating Open Source, even when the cost is that the software doesn’t become available to the community under a full Open Source license for some time. Making Open Source shouldn’t mean you wear a hair shirt and live on handouts…

https://perens.com/2017/02/14/bsl-1-1/

The BSL has been popularized by projects such as MariaDB, CockroachDB, Materialize, and Sentry. The cliff’s notes version of the BSL is that it is an OSI license with a carve out for a narrow use case to ensure that the project maintainers can stay in business. That carve out also must expire within a specified time. The key here is that the BSL is effectively no different for all of the use cases that should concern the DPGA. The software can even be used commercially before the conversion date.

Sentry, who we’re a huge fan of, has written at length about their decision to switch from a straight OSI license to a BSL license. If you were to use the BSL version of Sentry today, you would effectively have all the rights of their OSI license. The only difference is that the BSL precludes you from using Sentry to spin up a Sentry-like hosted product and compete directly with them. Clearly, not something that would affect its value as a DPG. Obviously, without this protection, the incentives for Sentry to invest heavily in the product would be significantly harmed. In turn, this would harm the viability of the public good derived from their work. I believe Sentry deserves a place on the DPG registry. We use them extensively to monitor the smooth operation of many critical applications in the international development context and their BSL license of course allows for this without cost or concern. We get full use of the software, they get to stay in business and keep improving it, we get those improvements at no cost. Everybody wins.

We’d also like to call attention to a paper written this year that specifically discusses DPGs and how the BSL would go a long way toward ensuring long-term investment in these projects. In their words..

Appropriate licensing approaches that preserve the publicness of DPGs can go a long way in the adoption and diffusion of sustainable digital innovation cultures. The Maria DB Foundation’s open source Relational Database Management System deploys a unique Business Source License (BSL). Users have complete access to the source code and can modify, distribute, and enhance it.

https://sdgs.un.org/sites/default/files/2022-05/2.1.1-45-Gurumurthy%20-Digital%20Public%20Goods.pdf

I know this is a bit long winded, but this is something that we’ve put a lot of thought and consideration into and feel strongly that this model would be of great benefit to the DPGA. Put plainly, if our business cannot protect itself against companies springing up to compete directly with us using our own software (which is a real thing that happens to us), we would be incentivized to halt our public work in favor of closed projects. The public good only stands to lose in this scenario.

Not only do we feel the DPGA should be welcoming of the BSL (which again, requires an OSI license internally), it should consider the fact that encouraging its adoption would also be supporting the most viable funding model available for international development.

[downeymj]

Unfortunately, proprietary software licenses such as the Business Source Licenses are not open source because they restrict the freedom of people to use that software for any reason (see OSD6, "No Discrimination Against Fields of Endeavor"). As a result, proprietary software does not meet the baseline nature of Digital Public Goods laid out by the UN Secretary-General (p.23) in the UN's Roadmap for Digital Cooperation.

With respect to the BSL specifically, a license which explicitly tells people "you can have these freedoms only when we say so, and namely when we can no longer profit off from an unbalanced power-dynamic relationship" sends shivers down my spine as I hear its echoes of old neocolonialist practices that SDGs are designed to help people overcome; I couldn't imagine a world where that type of relationship was encouraged. On the contrary, free and open source licenses—specifically copyleft licenses—are far better-suited to ensure symbiotic relationships among everyone adopting and creating digital public goods by both maximizing freedom and mitigating the free-rider problem through reciprocity. (For a deeper exploration of that idea, see "Copyleft Won't Solve All Problems, Just Some of Them" from Software Freedom Conservancy.)

---

* The irony is not lost on me that I write this comment on a proprietary software platform that stands publicly accused of abusing copyleft licenses, but that discussion is best left elsewhere.

[rowanseymour]

I have to say it's disappointing to read what seems to me, rigid ideology about what is open source, and a refusal to engage with the realities of what is happening in the world of open source.

they restrict the freedom of people to use that software for any reason

The licencing of a product like Sentry only restricts the creation of a competing business using the latest code. Sentry don't get donor handouts. If I can take the codebase and run a competing platform which undercuts them because I'm not investing in software development, then one of two things happen: Sentry goes out of business, or they stop making their code open source. The public either gets the Sentry codebase with this one restriction they need to keep their business viable, or it gets nothing.

"you can have these freedoms only when we say so, and namely when we can no longer profit off from an unbalanced power-dynamic relationship" sends shivers down my spine as I hear its echoes of old neocolonialist practices that SDGs are designed to help people overcome

I don't think this kind of extreme rhetoric is helpful to anyone. Again, Sentry doesn't get donor handouts. What you're describing as "profit off from an unbalanced power-dynamic relationship" is a project maintaining itself by having paying customers. I don't see how that is in any way "neocolonialist", but creating dependency on donor funding isn't.

On the contrary, free and open source licenses—specifically copyleft licenses—are far better-suited to ensure symbiotic relationships among everyone adopting and creating digital public goods by both maximizing freedom and mitigating the free-rider problem through reciprocity.

This is a model that certainly works for some projects. When I was a developer on the OpenMRS project, my and others salaries were paid by donor money and it didn't really matter what anyone did with the codebase. But if you're a SaaS business that relies on paying customers, it's not such a great model, and the experience of Sentry and others is that it doesn't work. We currently use a copyleft licence. We've lost customers to competitors who have taken our codebase and just reskinned it. There is no incentive for competitors to invest in development and we are disincentivized from making the product more open.

We're coming at BSL as a potential solution which can keep our business viable and allow us to be more open. We can invest time in producing something which is easy for anyone to setup and run themselves, without worrying that we're making it easier for say AWS to take it and put us out of business. All we're asking for is a reasoned discussion why such a model currently precludes a project from being considered a public good.

[ThatOneCalculator]

The BSL is neither open source nor for the public good. There's ways to monetize FOSS that don't involve stripping freedom from people.

[ericnewcomer]

I can't think of a single instance where Sentry's license does not serve the public good. I challenge anybody here to find one.

[nicpottier]

Let's have a thought experiment.

Say Sentry, which owns the copyright for their platform, decided to only release their changes to the public on a yearly basis under a standard OSI license, say MIT. They are in the right to do this as they own all copyrights (and nobody contributes to their platform). They are also continuing to release a great platform under a very permissive license with yearly updates.

Would Sentry then be considered a public good?

[rachellawson]

That's the thing with OSS projects, they can be used in any way, by anyone. The moment that is restricted, it's not open source software. If, for example, AWS (or any similar service) was to start offering the software in competition with a current provider, that is an overall good for the end user.

If you want to restrict usage, then it might be Digital Public Infrastructure (DPI) but it's not a Digital Public Good (DPG).

As far as adding BSL to the DPG Alliance, it's a big no from me.

[rowanseymour]

The moment that is restricted, it's not open source software.

I keep seeing this repeated like an article of faith but that's literally just one definition of open source. It's certainly a definition that can work for projects kept viable by donor handouts, but it's a definition that hasn't worked for projects maintained by paying customers, and thus we see even co-founders of the OSI like Bruce Perens arguing that it's not a helpful definition.

If, for example, AWS (or any similar service) was to start offering the software in competition with a current provider, that is an overall good for the end user.

To me this is a short-sighted view that discourages investment in projects. Nobody is going to make their codebase open and continue to invest developer hours into it if they think AWS can take it all for free tomorrow and put them out of business. Again, outside of the world of donor funding, it's completely developer hostile.

It is possible to have a discussion about whether this definition of open source is actually good for initiatives like the DPGA? Does anyone have a response to the though experiment proposed by @nicpottier above?

[ericnewcomer]

I'd very much like to hear somebody address the scenario above from @nicpottier.

[downeymj]

It is not necessary for any of us here to rule on the status of the Business Source License as open source or proprietary; indeed, we need look no further than the text of the license itself as written by its authors:

The Business Source License (this document, or the “License”) is not an Open Source license.

Nor does it seem that those authors ever attempted to put forward their license for review by the community review committee as part of the Open Source Initiative's process for evaluating licenses for alignment with the standard Open Source Definition. (I just went back through the mailing list archives to confirm this.) I suppose there is nothing precluding that from happening, although one might imagine the authors' language above would create a high threshold to overcome. I think the effort would probably be especially thwarted by the fact that the BSL exists for the very reason to serve as a license before software is later licensed under an Open Source license. (If the BSL were an Open Source license, it would already be what it exists to become in later years.)

As far as changing the Open Source Definition, I would suggest that is somewhat out of scope for the DPG Standard issue tracker, but over the past few decades there have been a few instances of lobbying to allow field-of-use restrictions and nothing would prevent motivated individuals from attempting to do so again. Based on historical precedent, the two most obvious routes seem to be either (a) work within the existing OSI community standards and governance processes to build consensus to change the OSD, or (b) attempt to establish a competing standard that reaches the universal level of adoption that the OSD has achieved over the years. However from my observations, both strategies seem to have been soundly rejected by the existing communities of governments, corporations, organizations, and individuals that rely on a universally-accepted standard focused on preserving the freedoms of technology users.

[rowanseymour]

Nobody is asking the DPGA to rule on whether the BSL should be considered an OSI licence. There are two things we've been hoping to discuss here:

1) Can BSL with it's very narrow carve-out be considered a public good 2) Can a BSL product after it's specified conversion date (which is literally now an OSI license) qualify for the registry

We believe both of these are true, but if we can't agree on the first, surely we can on the latter?

[rachellawson]

I think I can answer those two questions for you:

1. Any product can be considered a "public good". That doesn't necessarily require review by the DPGAlliance. To receive a positive review by the DPGA, however, requires the product to meet the very clear standards it sets out.
2. Again, meet the agreed standards and the product may receive a positive review and be added to the list. If, at the end of the period that the product has been licensed under BSL, it is then released under an OSI approved licence, I see no reason it couldn't be approved by the DPGA.

Remember - the DPGA themselves follow the good practices laid out in the Principles for Digital Development and build upon recognised standards - and, in the field of what is open source, those standards are defined by the OSI.

[webmink]

1. Can BSL with it's very narrow carve-out be considered a public good

That "very narrow" framing indicates you probably don't fall within its reach. For those public entities and persons who do fall within it, it is not "narrow", it is exclusionary.

In addition, since the BSL has not been subject to open public review and subsequent consensus identification within the generally accepted process for that to happen, its terms will need to be legally reviewed before the software is used by most entities. That also tends to be exclusionary for those without the resources to retain advisors.

Thus it seems unlikely to rise to the standard necessary to be considered a public good.

2. Can a BSL product after it's specified conversion date (which is literally now an OSI license) qualify for the registry

Since in most cases the version of the software that is subject to an OSI-approved license would be unmaintained, out of date and possibly subject to unresolved exploits, I suggest this seemingly easy question may not have the obvious answer.

[ericnewcomer]

While I feel we'd all be better served to consider this, it's clear there is no appetite to fully evaluate how this might be a good thing -- specifically around reducing the dependency on donor funding. That said, I can appreciate that a line must be drawn somewhere, and drawing it at strict OSI is a perfectly reasonable place for this project to draw it.

Here's to hoping the broader community reconsiders this in the future when the time is right.

Thanks for the quick responses!

[ThatOneCalculator]

While I feel we'd all be better served to consider this, it's clear there is no appetite to fully evaluate how this might be a good thing -- specifically around reducing the dependency on donor funding.

Cope and seethe with your "profit incentives" :rofl: