Understanding Legal Issues for Open Source Software Start-ups

• 

  Joseph RuscioGeneral Partner
  Heavybit

Viewing Open Source Startups Through a Licensing and IP Lens

Open source software (OSS) is a vibrant and rapidly-growing space, and seemingly every technical team uses a significant number of OSS tools to underpin their infrastructure and build new products every day.

However, working with OSS, and in particular, building a startup around OSS, carries unique challenges, especially when comparing open source vs. proprietary projects. While there are many benefits of open source software for startups, these will generally only come to fruition if founders properly scope the unique challenges of building a business around open source–the earlier, the better.

In addition to the startup basics of understanding your business model and how to scale, OSS startups need to consider the impact of sharing their code with everyone for any purpose. They also need to put in place a robust community strategy that starts with building an initial group of users and ensures that the community user base continues to thrive. The health of a community can be an important indicator of the strength of its security as well as for whether a project can stay commercially viable for the long term. In addition, OSS startup founders need to think carefully when choosing the appropriate license and have a clear understanding of their startup’s rights and available protections for the intellectual property (IP) they’re building. All factors that can impact commercialization and revenue generation over time.

We asked legal and OSS community expert Amanda Brock, CEO of OpenUK, how to approach the task of building and scaling an OSS startup. Get the latest insights on licensing, IP protections, and how to scale OSS communities and startups to the enterprise at the DevGuild: Open Source event.

How Changes in IP and Licensing Policy Affect OSS Startups

Joseph Ruscio: In recent years, what has been the biggest change in open source software that startup founders need to be aware of today?

Amanda Brock: I'm not a developer, so I'm not going to focus on anything technical. I think the most significant things to be aware of are the ongoing changes coming down the line through governments and legislation–around security in particular–but which will relate to what we're becoming familiar with as “curation,” overall. By curation, I mean good technical hygiene and governance best practices for open source. And what we're seeing is policymakers and lawmakers trying to understand open source and perhaps only succeeding to different degrees.

The US and the UK seem to be following a similar path, which is quite sensible, and they are looking at putting liability around payment. So: Risk flows with payment and the end user is largely responsible for the environment they use the code in. That's not happening consistently across the world, and we're seeing Europe not quite get it right.

There's a lot of pushback going on from the open source communities and foundations around the CyberResilience Act (CRA), where the European Commission has tried to create a category of open source called commercial open source (COSS), which we all know doesn't exist. Because if something is only truly “open source,” anyone can use it for any purpose. And we're also seeing them trying to apply product liability to open source and other software even when not embedded in devices. And these are big issues for us that people have to be aware of because, over time, you have to meet those laws in how you manage things.

These kinds of things can impact your business. For example, a subscription model that is commercialized to include software for a price is going to incur liability in the future, whereas open source that's freely distributed with a model where you pay for services that don't include code is potentially not going to incur liability. This is an intentional move from the governments that really understand open source because they don't want open source developers to be liable.

I just spoke to someone who suggested we need to 'certify' coders. They looked shocked when I told them I’d fight that tooth and nail.

And the reason that the CRA is such a problem is that the Commission, despite having an Open Source Program Office for several years now, failed to understand what open source is. Really, the nuance they’re trying to focus on–that is, “COSS instead of commercial distribution”–it’s just something they get wrong. But I think that issue around subscription models is one that isn’t well understood. Honestly, I’m not sure this is the kind of thing that anybody has really thought about yet.

Right now, all of the open source organizations which work around Europe are pushing back hard on the CRA. And there's a general attempt in Europe to apply product liability laws, which I think is just not going to work. This is part of a theme that we've seen from Europe. I was in the room in 2019 where they talked about creating regulations on the “right to code.” So you'd have to be certified to code, which is anathema to the development community. It's a complete lack of understanding of how coding works and the basis of it, and the fact that today, the majority of code is open source and is created in a free and open way.

It's also something that governments struggle with globally. When you have contributors from all over the world, how can you impose such criteria in just one country?

I should mention, we’re not just seeing these issues across the European Union. I just spoke to someone from an organization that represents tech in the UK a few weeks ago, who suggested we need to “certify” coders. They looked shocked when I told them I’d fight that tooth and nail. It's a fundamental problem and there’s a real lack of understanding here.

And I think we have an issue that everybody in this space ought to understand. The issue is the scale at which adoption has happened…but that has not been matched with an understanding of how open source software works. So it's really important that everybody's business understands the situation regarding the regulation of commercialized open source, what their revenue models mean, and what they’re getting into. As time goes by, having a clearer understanding of the regulatory landscape is going to give founders a competitive advantage because this stuff is going to become more and more relevant. So taking time to get up to speed on these things is going to matter.

What to Know: SBOM and Trademarks

JR: Interesting. Considering the changes in OSS, especially how much adoption of OSS we see in modern software infrastructure, what do founders need to consider when thinking about technical dependencies vs. legal liability?

AB: I think there are a few different things to cover.

First, I think that as you create your business, one of the first things to think about is creating a software bill of materials (SBOM)–that is, a full list of components that make up your product–for your software, along with understanding your planned revenue generation, product development, and your overall business model. Some founders will tell you to start just by going off and building a product, but I personally disagree.

On the business side, I think you have to have some options on revenue generation–you have to be thinking about how you’re actually going to pay for that product development. But the requirements we're already seeing around an SBOM means that you have to be thinking about what you're building and your technical processes from the start. For example, if you're creating something and you’re hoping for mass adoption in the US with the potential to spread to other regions, you have to contend with concerns around security. (Bear in mind that security is a digital software issue. It's not just an open source issue.) But it’s worth thinking about an SBOM from day one so you understand your dependencies up front, and don’t have to go back and do it later.

I've been working in open source for more than 15 years now, and I’ve seen many situations where trademarks have been the only thing that people can rely on to protect their rights.

Third, I think you have to consider trademarks and ways to protect what you create. It's worth bearing in mind that you have to protect your rights and register your trademarks. They’re the only intellectual property you’re going to have to protect you. I've been working in and around open source for more than 15 years now, and I’ve seen many situations where trademarks have been the only thing that people can rely on to protect their rights.

There’s that almost-mythical story about the term “open source” itself not being trademarked, where Bruce Perens at the OSI was told not to register a trademark, and by the time the OSI tried to do it, it had become so generic a term that it wasn’t possible to trademark it.

So there's a lesson to be learned for everybody in open source from that, which is that you should protect that right. It's one of the things that creates value. Of course, you want to look at what value you have in your business in the long term, and you create value through ubiquity and adoption and open source as opposed to through your copyright. But you do have other IP that needs to be protected. To clarify, I'm not going to recommend that anybody go off and get patents for everything–that’s just not practical. But for those trying to create something around open source, your trademark is the one thing I would tell you to go and protect.

Tying Together Community Building with Business Growth

JR: How should OSS startup founders be thinking about community?

AB: I think you need to be focused on your community more or less from day one. It has to be very high up on your agenda. And I suspect that as we see more adoption of SBOMs, not purely from an altruistic perspective, but from a practical business perspective, you are going to see more assessments of which open source software to use, and which not to use. Having an SBOM in place is likely to positively impact that.

One of the things that comes up repeatedly is that code is more vulnerable to a switch from open source to proprietary licensing without a healthy community or where the community is largely from the sponsor company. So, I think if you can demonstrate a healthy community, you will have greater long-term adoption and more chances of generating revenue around your code. From a business perspective, it makes sense as over time I expect users will want to see this.

And from an innovation perspective, you want to build a diverse community and get as much engagement as possible. I've recently seen a number of organizations I've been mentoring who've been trying to move to open source. And although we talked about it right at the beginning, it took a few months for them to realize that you need things like a community manager or developer relations very quickly.

One of the things that comes up repeatedly is that code is more vulnerable to a switch from open source to proprietary licensing without a healthy community.

You need someone who's going to get your message out, go around the conferences for you, and engage in various social environments to create engagement, awareness, and contribution. You need to get to all the places where developers are going to be hanging out.

Ultimately, what you need to build is brand awareness, and brand awareness in the development community creates adoption...and that adoption is what generates revenue. Our model has shifted.

15 years ago when I started doing this, we were trying to sell the concept of open source to people who didn't use software. Now you're doing two things. You've got this distribution of the software and thanks to the repos like GitHub and Gitlab and easy routes to the people to adopt it...and then later, once your users decide they like your offering, there’s the opportunity to go in with your sales pitch. Although often there’s also a shift to inbound rather than outbound marketing that goes with this shift in model.

Scaling OSS to the Enterprise

JR: What do OSS founders need to keep in mind as they attempt to scale their startups to the enterprise?

AB: We have an entrepreneur-in-residence at Open UK, Matt Barker, who is the co-founder of Jetstack, who was talking about learning from his mistakes. He used a memorable turn of phrase–I think it may have been a quote from the author William Faulkner–about not being afraid to “kill your darlings.”

The quote was relevant to keeping focused on your core offering. Not being distracted by “too many products.” It can be tempting to want to boil the ocean–to try to make something that does everything. But it’s important to focus on one particular thing and do it well.

He talked about the earlier days of his career when he worked building out innovations in groundbreaking areas, but other people came along and created success in those areas. Because you need to be able to put a whole machine behind your creations to make them work, you need to have that community, you need to have the marketing and sales...all of those different things and invest over time. That makes it important to focus on one area and not dilute it.

I think that the startups that have done well have understood the skill sets of the people founding them–including their own limitations.

Founders need to keep that sharp focus on what they’re driving toward, even understanding that can change. Yes, you can start to build one thing and realize that there’s actually someplace else your focus should be. But you need to keep that focus on one core thing–a maximum of two things–at any point in time.

I think that the startups that have done well have understood the skill sets of the people founding them–including their own limitations. If you look at someone like Shannon Williams, who is not just a repeat founder, but a successful repeat founder, you can see that his co-founders and the teams he built had very different skill sets.

From day one, the founders of every successful company aren't always engineers. They're focused on the marketing and the sales and all the other stuff that needs to be built out so when the product is ready to “go commercial,” their team is ready to go to market.

Another great example is HashiCorp. And when you listen to Armon [Dadgar] discuss it, he'll often talk about how they never even thought they were going to be a business. He admits that from day one, they didn't think about what they were doing as a business, and they made decisions that they might have made differently if they had. But I think HashiCorp is also a great example of this kind of self-awareness founders need. When you look at Mitchell [Hashimoto] stepping down from the office of the CEO, that was really important. It’s really important to understand the skills that you need at different times in a business’ growth. Being a fantastic engineer doesn't automatically make you a fantastic people manager or a fantastic CEO.

Conclusion

Clearly, there’s much more to building a successful OSS startup than simply building a robust technical product. Get in-depth insights on licensing, trademarks, and protecting your IP as you scale your startup at the DevGuild: Open Source event.