[00:28:03.00] Yeah, and that’s a really big question. I’ll try my best to give you sort of a concise answer, maybe in the context of how we’re building out the firm… And maybe I’ll just constrain that first to functional portfolio partners that are focusing on two really core things that we believe are very fundamentally different in commercial open source software companies, as compared to proprietary closed source software companies.
If you look at legal, which is obviously Heather’s domain - she’s extremely knowledgeable and has just deep, deep experience for a couple decades, the legal side of open source in the business context is one of the most non-standardized, hairy, polarizing, complex and error-prone topics and areas in the industry. That’s probably the first functional part of a company that I can talk about where things are really fundamentally different.
If you consider a proprietary or a closed source software company approach to licensing, it’s pretty simple, it’s pretty straightforward. You flesh out what you want to build - a design doc, or an idea, or a napkin, or you go through whatever product development methodology that gets you to understanding what needs to be implemented, and then you go and build it, implement it… And then you work really hard to get early design customers or companies to agree to use your product and give you feedback, and you probably sign different agreements to make sure that confidentiality is maintained - it’s quite a costly process, from a sort of first highly valued customer, to the tenth and the twentieth and onwards. It requires lots of manual effort.
With the licensing side of that though, as it’s a proprietary company, you don’t really think through too many complexities in terms of the customization of a license, or the nuances of open source licensing. In fact, if you could actually look at one example where we have a huge number of startups getting created - in fact, mostly software companies - and look at how licensing is standardized there, it is actually in fact standardized, and I’ll pick on one really great organization, and I’m not gonna say anything bad, I think they’re doing amazing things… This is Y Combinator, the YC incubator program in Silicon Valley.
What Y Combinator has is a sort of set of standard legal documents that they have sort of distributed out to their incubator companies, companies that get enlisted in Y Combinator, and they actually do have one for a sort of standard subscription agreement for access to software, that their startups go and license and sell to customers. And it’s really valuable - it sort of short-circuits the cost and complexity of hiring a lawyer, and drafting a custom agreement, and figuring out exactly what terms you want to implement… Because all those things are pretty standardized, Y Combinator just says “Hey, use this template subscription SaaS software agreement”, whether it’s an actual SaaS offering delivered over an API, or whether it’s on a cloud provider, or you’re gonna ship a custom proprietary binary to someone… Whatever it is, just use this license. And it’s really helpful, it’s extremely useful for the companies in Y Combinator, because it just gets them going without any friction. There’s really no need to hire a lawyer, and you can often times just get customers to look at that, and it’s something that the industry has sufficiently agreed upon as terms that aren’t super-complex and onerous.
[00:32:04.04] So that’s one dimension. We have sort of the standardization of licensing for proprietary closed source companies that are building software-based products. Y Combinator produces something like – I think it’s on the order of 600 or so startups per year, so that’s quite a good reference point.
On the open source side of things though however, the complexities are astronomical. You first have to take into account when you open-source a piece of software, which license you’re gonna choose. Do you choose Apache? Do you choose BSD? MIT? GPL? MPL? Affero? Which version of the GPL do you choose? What copyleft constraints are you interested in protecting? There’s a vast array of choices there. However, we’ve sort of standardized on the open source licensing aspect, quite a lot of industry agreements around Apache 2.0 being really valuable. The Cloud Native Computing Foundation actually encourages – I don’t believe it’s a hard requirement, but they strongly encourage new projects to use the Apache 2.0 license. We also have quite a lot of industry standardization around the MIT license, and around MPL 2.0, which is great, which Heather on our team helped write and was on the team that implemented the Mozilla Public License version two… And then we also have quite a lot of industry agreement on the trade-offs and the constraints and the reasons why say Apache 2.0 is a really good license to standardize on.
So let’s say you’re a startup and you say “Okay, great, we’ve got a new project, we’re going to release it as an Apache 2.0 licensed piece of code, we’re gonna open up the repo and call it a day”, and that’s a pretty fast decision. However, when you want to build a product around that commercial open source company, that sort of builds on that Apache 2.0-based project, you run into all kinds of complexities. It’s not a simple matter of saying “Okay, we’ve got 20,000 companies using this open source project, and we want to go and use the Y Combinator (I’m not picking on Y Combinator, but…), we’ll just bolt on the Y Combinator terms of service, and IP, and warranty, and indemnification, and trademarking, and all the sort of template terms - we’re gonna just bolt on that agreement to our open source license, and maybe hold back some code in a private repo and just distribute that to customers.” That would not work, for a myriad of reasons.
What we see with commercial open source licensing in these commercial open source companies, what we’ve observed - and Heather has been very close to this - is there are actual full-time legal teams, typically headed up by a general counsel, which is a similar role in proprietary software companies… But what they do is basically they spend a huge amount of energy and effort, case-by-case, relative to the project that a company is based on, and they write custom agreements from scratch. The cost and complexity of writing those custom agreements for the commercial proprietary bits on top of the open source project are very nuanced and tailored to what kind of product they’re building, and how they’re going to market, and what transaction volume looks like in terms of the size of the customer base, how large the deals are, how strategic customers are, what needs the customers have in terms of the indemnification side of things, and multiples, and the warranties… There’s just a huge [unintelligible 00:35:48.26] of legal customization that goes into those agreements. They’re often called Master Software License and Service Agreements (MSLSAs).
This is one of the things that we’re kind of scratching on and working on… You mentioned Commons Clause, which caused quite an uproar and a lot of excitement in the industry, which Heather did author…