Open Source: Payments and Responsibilites?

Should open source developers get paid? If so, how? What about the many other issues open source represents? How could payments relate?

Thomas Stringer is a software developer who wrote a blog article reflecting a growing attitude about the unsustainable stance we have in the Open Source Software (OSS) community, available here

This attempts to describe where we are, stopping short of providing real solutions. Even with that in mind, I think it oversimplifies a very complex and dangerous subject.

I wrote an article a while back about the potential patent land mines we might “stumble over” with OSS. I won’t regurgitate that here, except to summarize that there is no protection when you grab the code from an OSS project (especially one that uses the MIT license) from inadvertently violating someone’s patent.

There is also the issue that Thomas was focused on with his blog article about fair compensation for developers of OSS code.

But even these two observations taken together ignore other serious issues, including accountability.

When a company develops software, they typically are responsible for having some process that establishes requirements and are basically held accountable to various stakeholders (customers, regulators, etc) for how well the software conforms to the requirements, societal norms, regulations, etc.

When we adopt an OSS package, we are still held to the same “standard” as our own code but without (usually) a true understanding of what we adopted. And if there is an issue, there is no one in the OSS community that is held accountable.

In fact, this verbage from the OSS MIT license makes that very clear:

'THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.'

The popular Apache license isn’t any better from this perspective:

'Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.'

Wow… Kind of makes you wonder why any company would take the risks associated with that?

And yet, I have to admit there is a very valuable mechanism at play to leverage OSS contributor’s passion.

There are contributions from individuals, from small and large companies, and even from large groups of companies represented in the vast array of OSS packages. And, as Thomas points out, a lot of these packages require the use of many dependencies (which are also OSS packages each of which are provided under similar licenses). Each of those dependencies can in turn require the use of even more dependencies.

The net result is that, without a great deal of study on behalf of the company that is adopting the root OSS package, there isn’t much cognizance of many risks that are also being adopted.

I am already on record about the potential patent risks here, but we don’t have to think too deeply to appreciate other important risks we are absorbing. These include the potential for security and privacy issues, the potential lack of support (or inadequate support) from the community providing the OSS package(s), and the lack of proper function - just to name a few.

Even here I am oversimplifying because the conversation requires including the use case for the OSS package. Is this a tool that isn’t actually used directly in the product but supports the creation, operation, or maintenance of the product? Examples of this might be container management and deployment software. Here, the companies normal testing and quality assurance process might uncover issues caused by the OSS before the customer is exposed.

On the flip side would be most of our OSS packages that include things like operating systems, networking software, and a myriad of other packages directly effecting the execution of the product itself.

In his article, Thomas was groping for ways of approaching getting the contributors some reward while also point out that there wasn’t a perceived solution to handle the myriad of dependencies and their contributors. I am speculating that working towards a solution for reward has to also work towards a solution for accountability.

Clearly these OSS licenses represent risks. In addition to the ones stated, they impose (in some cases) restrictions for how the package may be used and distributed. Violation of those restrictions brings with it another set of risks.

Want to get more subtle? When our business enters into business relationships with entities (investors, partners, customers, etc), frequently we are imparting a sense of our “intellectal property” (IP) that is used as a basis for the entity’s decisions for how to do business with us. This IP is, in part, implying a certain “barrier to entry” for competition.

What if that IP is bit illusory in the sense that the technology being demonstrated and/or offered for sale is but a thin layer of code conjoining a host of OSS packages. How serious is that barrier to entry?

Roll back the clock many years ago where developing a custom, real-time collaboration tool with video, audio, messaging, etc. resulted in a product with a significant barrier to entry. Now, not so much.

Build a custom AI based chat bot or service. Does that have enough significant IP to represent a barrier to entry? Probably not if it was based on an open source model with associated “glue” packages like LangChain, etc. This stuff can now be done in a few lines of code, therefore representing little to no IP - even though there is a ton of investment money chasing them.

We see that, if we base our product on OSS, then we might have issues with:

• product reliability, performance, liability, privacy, security
• patent infringement
• lack of ability to get proper OSS support
• lack of enough internal understanding to support
• insufficient competitive barrier to entry (IP)

Those issues are in addition to Thomas’s concern that we should be paying these contributors for their work.

My problem here is that when we draw a parallel to paying our own employees, we know in that case we have to accept all of the risks as well as benefits with building and owning the code. While in the OSS case, we accept all of the risks (because we have no choice) but with none of the benefits. We are saving significant development expenses, so in theory have money to throw at risk mitigation (at least in part). But we still won’t own the IP.

If we start paying for OSS, then it should be under an umbrella that somehow uses the money for risk mitigation.

On that note, it was interesting when we saw OpenAI this week offering to compensate for issues associated with them contributing to copyright violations - sort of a step in that direction. This was potentially smart defensive move since will we be able to afford to use HuggingFace open source models where we assume all of the copyright risk ourselves, or maybe pay OpenAI to absorb it?

Anyway, more likely HuggingFace will jump on that idea in some form as well.

Extending that idea, what if we had a consortium umbrella of some type that:

• Accepted contributions and vetted them
• Based on that vetting process, stood behind the contributions legally and provided support
• Paid the contribitors (and held them accountable as well)

HuggingFace is showing that an organization with an open source philosophy can raise a ton of money. They are just currently centered around a very niche subject and are not currently accepting accountability even within that niche subject.

Their idea could be expanded or replaced by a broader concept related to all of what we consider OSS today, with the acceptance of responsibility/accountability added to the mix. That would essentially eliminate the current licenses OSS used today.

This would be a very expensive undertaking, regardless how you slice it. That is one reason we have products that were created from open source but are sold under a supported, commercial license. Some of our very large OSS packages live in that world, with still far too many companies opting to use the “free” OSS version while ignoring the issues that come with that approach.

The discussion of paying OSS developers really needs to include resolution of these and other OSS issues as well.