Foundation Selection

[alilleybrinker]

We've begun to consider the possibility of making the OmniBOR project part of an open source software foundation. As part of this, we'd like to enumerate our goals for such a transition, to help evaluate any possible candidate foundations for alignment with those goals.

Process

The process we'd like to follow for consideration of possible transition to an OSS foundation is:

• Identification of our goals for such a transition
• Identification of a Subcommittee formed from the Working Group membership which will explore options and report back to the full group (perhaps the "Subcommittee on Foundation Transition"?)
• Identification of a day/week meeting time where conversations on this topic may be held
• Reaching out to prospective foundations and scheduling meetings between their representatives and the Subcommittee
• The Subcommittee reporting back to the Working Group with recommendations on how to proceed

Possible Goals

The following is a draft list adopted from prior OmniBOR Working Group meetings. Not all of these goals are necessarily representative of a consensus of the group, but are at least example goals projects may have when considering transition to be under an open source software foundation.

• Establishing a clear governance model
  • OSS foundations generally have guidelines around leadership, decision-making, and participation for projects under their ownership.
  • Projects having opaque governance processes, or processes for becoming a contributor, can be a barrier to participation and stymie the inclusion of diverse voices.
  • That said, it's not clear that foundations are inherently good at this, nor that a foundation is required to establish such a governance model.
• Legitimacy
  • OSS consumers seem to generally open source software foundations.
  • Generally, consumers appear to expect that foundation-backed OSS projects will be sustained for long periods of time and may thus be more willing to build around foundation-backed OSS.
• Pathway to standardization
  • OSS foundations may have guidance or support for pursuing standardization of concepts under an existing standards-making body like the IETF, ISO, or ECMA.
  • That said, foundations and standards may be orthogonal concerns, and if we want to pursue standardization of OmniBOR we may be better off pursuing it directly.
• Associated legal entity
  • Open source projects may at times encounter challenges / limitations on collaboration due to a lack of an associated legal entity for the project.
  • At least one OmniBOR contributor has in the past encountered instances where an organization which wanted to collaborate on an open source software project was not able to proceed without a signed Memorandum of Understand (MOU) with the project itself, which required the project to have a legal entity which could be a signatory to such an agreement.
• Limit relicensing risk
  • OSS relicense risk has become a more prevalent concern in recent years. The conditions for relicensing are either that contributors to a project have signed Contributor License Agreements which transfer copyright ownership to the organization which maintains the software project (and thus permits them to unilaterally relicense), or that a project is under a permissive OSS license like MIT or Apache 2.0 and thus can be "forked" by its own main backing organization into a non-open-source license, perhaps then complicated by asymmetry of funding between the now non-OSS fork and any still-OSS fork which tries to continue in the spirit of the original project, as well as other possible intellectual property complications relating to trademarks or possible taint between the non-OSS and OSS projects. Ownership by a foundation helps limit this risk socially through (usual) lack of CLA's and ownership by an entity which is not (intended to be) competitive in any software market.

[alilleybrinker]

During the April 15th, 2024 meeting, some additional points around this were raised:

• @dpp raised that we may consider how the presence or lack of a foundation impacts the ability of government agencies to be involved in OmniBOR. He recalled Aeva raising some version of this issue in a prior meeting. We'll want to make sure we understand any limitations or considerations related to this.
• @ashleygwilliams found a US Department of Defense Frequently Asked Questions page which addresses involvement by DoD personnel in open source software projects. It seems particularly focused around code, not written contents, but is still relevant. Open Source Software FAQ (defense.gov)
• @alilleybrinker raised that the usual concerns with government involvement in standards and technology work is to avoid picking winners in any markets, but instead acting to support the general advancement of concepts in proceedings which respect the principles of open governance.

[alilleybrinker]

The items above are notes taken from Working Group meetings, but I'd like to interject now with some of my own thoughts.

---

Benefits of a Foundation

The key benefits of moving OmniBOR under the umbrella of an open source software foundation would be:

1. Having an affiliated legal entity for the project
2. Having an organization which can receive donations and disburse funding to support the development of OmniBOR

Let's address those in turn.

1. Having an affiliated legal entity for the project

Sometimes, open source software projects may want to have an associated legal entity, for the purpose of doing things like hiring people, signing contracts, signing memoranda of understanding, etc. At least in the US, in order to do this you need to be a legally-recognizable entity like an individual or a registered business. Today, the OmniBOR Working Group is a bunch of people who are coordinating and collaborating for the purpose of advancing the OmniBOR standard and implementations, but "the project" doesn't have a singular representative who could (or whom we should want) to become the legal stand-in for the project (this would centralize authority and go against the open governance goals the project has, as the "legal representative" of the project would wield a lot of power), nor do we really want the employers of any of the individuals involved to become the "owner" of the OmniBOR project. OmniBOR is purposefully bigger than and separate from the interests of any one individual or one company.

When your goal is to create an open and widely-adopted standard, you ought to have and maintain open governance, and having a singular person be legally responsible for deals associated with the project, or having a company in that position, especially where that individual or company has commercial goals for self sustainment, would run counter to the goal of open governance.

2. Having an organization which can receive donations and disburse funds to support the project

Money! It's important! While currently all participants in the OmniBOR project donate their time and effort to support the development of the specification and software for it, we can't assume all future needs of the project can be met by volunteers, or that we'd want to be limited solely to doing what volunteers are interested in doing. There are a variety of activities that the project may want to support in the future, including paying engineers to work on specific tasks, or paying for infrastructure to support the maintenance of the project, which require money.

Today, without a formal organization to receive money, we'd basically be in a peer-to-peer economy of, I suppose, sending each other cash for things? We don't really do this today, and this isn't actually a viable economic model for a project.

It's also possible in the future that individuals or companies may want to donate money to support OmniBOR. Today, it's not clear how they could do that other than perhaps funding developers to contribute, but that's only one way of engaging with the project and may not be what every possible supporter wants to do.

Having a foundation which can receive donations, and where donations to the foundation may themselves be tax advantaged for donators, can be really valuable!

Non-Unique Benefits of Foundations

I think a number of things which may seem like benefits associated with open source software foundations can actually be done independently of those foundations. For example:

1. Open governance
2. Antitrust policies
3. Standardization
4. Legitimacy
5. Limiting relicensing risk

So let's take those in turn:

1. Open governance

We can do open governance ourselves! Open governance essentially means that there are clear processes for how decisions are made and who gets to be a decision-maker, clear mechanisms for accountability, and clear mechanisms to become involved in a project.

Today, the OmniBOR project does not have explicit governance procedures, though we're becoming more mature in this over time. In general, many open source software projects go through a similar progression from very process-light governance when the group of participants is very small and decisions can consistently be made by consensus, to more process-heavy governance.

It's worth at this moment to also ask, "why have governance structures at all?" To this I'll basically point you to "The Tyranny of Structurelessness" by Jo Freeman and tell you to read it and come back.

In short: there is no such thing as "no structure" organizations, there's just "explicit structure" or "implicit structure," and implicitly-structured groups often benefit those who wield social power, and easily lead to unaccountable abuse of that power. This is bad.

I'm not going to pretend here that I have the exact right answer for how the OmniBOR Working Group should continue to evolve its governance. I do think some clearer processes for accountability, as well as clarity on things like access rights to infrastructure used by the project, would be helpful. The point here is solely that 1) we do need to have clear governance standards, and 2) we can develop those without requiring the involvement of an open source software foundation.

2. Antitrust policies

Hey, we actually solved this one recently! Turns out it's way better to take the policy of an existing group like the Linux Foundation, who have lawyers they pay and who know way more about antitrust law than any of us non-lawyers in the OmniBOR Working Group, and just use that policy yourself! It's even better if you don't try to edit the policy to "tailor it" because mucking around with legal language whose nuances you may not fully understand is failing to understand Chesterton's Fence in a way that can also get you sued.

We just added a reference to the Linux Foundation antitrust policy to the beginning of every Working Group meeting, and so far that seems to be working fine! We don't actually have to be part of the LF to do that!

3. Standardization

One of the open questions for OmniBOR is if we'd want to have the OmniBOR specification standardized by one of the known standardization bodies like the IETF, ISO, or ECMA. I'm not going to try to answer that here, but I also don't need to! The important thing is that this is a separate question from whether or not we should join an open source software foundation. We can pursue standardization independently of that choice, and since the processes for any of these groups are clear, public, and well-defined, it's not like we'd give up some secret sauce for becoming standard if we choose not to join a foundation.

4. Legitimacy

"Legitimacy" here means "people expect the project will be around long enough to be willing to integrate the concept / technology of OmniBOR into their things." Legitimacy is a difficult social question in the world of open source software, which does not have a single answer. It is the estimation that both software developers themselves and their managers place on the long-term viability of a project. Affiliating with a foundation can be one way to improve legitimacy, but I'd argue it's neither a necessary nor sufficient condition for legitimacy.

Projects can be part of a foundation and be dead in the water for other reasons, and projects can also achieve perceived legitimacy without being part of a foundation. At best, being under foundation might be taken as a proxy for "this thing is well-supported." But you can also more directly address risks of project abandonment, or relicensing, or capture by a specification corporation, or any of the other risks which may harm perceived legitimacy, directly through policy, compatibility commitments, and open governance.

5. Relicensing risk

This is a big one in recent discussions around open source software foundations. In short, there have been many high-profile open source projects over the past several years whose major backing company has "relicensed" to a non-open-source license. This relicensing can generally take two forms:

• The project's contributors have all signed a Contributor License Agreement which transfers copyright ownership of those individuals' contributions to the company overseeing the project.
• The project is permissively licensed under something like the MIT or Apache 2.0 license, and thus can be "forked" by its managing company to ensure that post-fork contributions to the project are now under the non-open-source license.

The difference here is in the licensing state of the pre-fork code. In the "everyone signed a CLA" case, even the old code can be relicensed to a non-OSS license, because the singular copyright holder has revoked the old license and issued a new, less-permissive license. In the "the project is permissively licensed" case, the old code remains under that more permissive license, but new code isn't, and if most of the contributions came from the company backing the non-OSS fork, then it may maintain the momentum of the project and the OSS version diverges, bitrots, and dies, or limps along and becomes less appealing in comparison.

OSS foundations have positioned themselves as the antidote to this licensing pattern, and have in multiple cases now staged loud forks of the relicensed projects to sustain them under a foundation-managed still-open banner. Terraform relicensed, so the OpenTofu project started under the Linux Foundation. Redis relicensed, so the Valkey project started under the Linux Foundation.

This is all well and good, and it's good to see that open source foundations have done this, but the ability to do this isn't unique to open source foundations. It's also worthwhile to distinguish between mitigating the risk of hostile non-OSS relicensing of OSS projects, and the ability to respond to a relicensing event (though they are related).

Mitigating the risk of a relicensing event can be done both through legal means, and through social means.

The legal means would be to license a project in a manner that it can't be relicensed. This is one of the benefits of "copyleft" licenses like the GPL; if a fork tries to become non-OSS, it's limited by the copyleft provisions; everything new they do which integrates the original code needs to be licensed compatibility with the GPL, or else it violates the license of the original code. This is said with the assumption that you don't have the strange case of "it's GPL but everyone signed a CLA to assign copyright," because in that case the single copyright holder could unilaterally relicense the code, because as the copyright holder the license doesn't bind them.

The social means of risk mitigation is basically the expectation of a company considering relicensing that such a relicensing would trigger the arrival of an active, well-maintained, still-OSS fork to serve as an alternative to their non-OSS offering. Essentially, it's the expectation of open source competition in the event of a relicensing. This is basically the risk that Hashicorp was trying to stymie by sending a Cease-and-Desist letter to the OpenTofu project recently.

This has been a bunch of background and analysis to basically make this point: you don't need a foundation to reduce relicensing risk, you need an active community, and (as discussed in the legitimacy section) a foundation is neither a necessary nor sufficient condition for an active community! An active community drives the "post-hoc" mitigation of relicensing risk. The choice of license can serve as a legal mitigation, though currently at least the OmniBOR Rust code is Apache 2.0 licensed so we don't mitigate the risk there.

Conclusion

This has been a bunch of analysis, but the key point I am trying to make is that a lot of what we might think we're getting out of a foundation can be had in other ways. I also worry that you take on a lot of baggage, both procedural and political / historical, when you join a specific foundation. I'm a big believer that process and governance is best grown slowly in a manner which has the joint consent of a project's participants, and worry that entrance into a foundation, and adoption of that foundations procedural rules, can cache against and stymie the interest of a project's current participants.

At the very least, I want us to be clear eyed about the true benefits we can achieve with a foundation specifically.