Contract Killer: License efficiency and Open Source Software

This is part of a regular series of Open Source fundamentals that I'll release and update on the regular.

Let’s talk about contract efficiency.

Say you work for a company and you want to license a piece of commercial software for your work. Depending on the vendor you might find yourself presented with a contract that has a lot of dusty corners and language that might seem off or in need of interpretation.

You work with your legal staff to review the contract and make sure that it’s appropriate for your work. Whilst working for Google, we once had a 10 month long negotiation with Stanford (this was in 2005, shortly after we had gone public) University’s IP transfer office regarding some software that was going to be pulled into what would eventually become the google maps street view project. That this was 10 months of our collective lives that we would never get back.

As Google evolved and started working with more and more groups in the academy, we would often negotiate with a project group to release their work as open source. This would often accompany a donation to the project team via our university relations group. The project groups in the universities were supported, open access was reinforced, and a lot of terrific work was done that moved computer science forward.

We even found it was often easier to work with multiple departments in a single university through open source software projects than to get them to cross the quad and work with each other, no matter the funding level. We didn’t have a beef with the university overhead either, which was often in the 10% to 20% range.¹

Every enterprise proprietary software agreement is different and demands scrutiny from legal staff. Open source licenses, by comparison, are static, historically reviewed, documents where most of the corners have been fully explored. The first thing a person in my position would do is find out who in legal has the ability to stamp their imprimatur on known licenses.

These fall into the IP, copyright, trademark or contracting counsels of a given firm.²

It's been my experience that having open source licenses considered as a whole and having some pre-approved means less work for the lawyers who are usually quite busy with those contracts that are their bread and butter. Open source licenses are a calm center that allows engineering and legal staff to get work done rather than probing what a clause might mean or imply.

Historically, companies would go through a Kubler-rossian stages of open source acceptance:

1. Denial: We do not use any open source software and will not use it!

2. Anger: What do you mean we’re using an enormous amount of code that wasn’t written here?

3. Bargaining: Well, can we do that and not have to worry about it? Who can we pay to not have to worry about this?

4. Depression: Well, I guess we’re using it, huh?

5. Acceptance: Wait, I guess it’s okay, and if we keep up with it, it’s an enormous advantage for us, or at the very least, we’re now competitive with others who use open source as we do.

If you give your engineers good guidance on how to use open source software, how to lay it out in your codebase, etc, then you have code that can be maintained and products that can be supported. And all that without losing a year of your life to delays and interminable negotiation meetings! What a bargain!

Your legal staff, meanwhile, has the comfort of knowing that if they have a set of blessed licenses and a smart way of approaching the dependencies of the organization, they won’t be surprised by the requirements set up by compliance Any good lawyer will tell you that confronting and dealing with these issues head on saves a lot of time in court, settlement talks or dealing with angry customers/clients.

A good open source policy/strategy doc can be a very smart thing for a company. These documents can range from the coarse “MIT, BSD are okay, as is the Linux kernel, and check with counsel/eng leadership on share-alike licenses.” to the exhaustive set of policies and guidelines like those the team and I shared from Google's practice.

Contract efficiency doesn’t just impact open source use. Microsoft rested on the
“Select” enterprise agreements with companies large and small for years, which allowed companies, universities and the rest to readily acquire and use their software under the auspices of the already negotiated agreements.

Similarly, the federal government has all kinds of vehicles to make procurement more efficient within the agencies. The GSA, Space Act and now FedRAMP processes are all in theory about making government more efficient and secure. There are also programs to make approaching and doing research for the fed more efficient and bring in more organizations that don’t normally work directly with the fed. I’m thinking about DARPA, the navy research funding processes and more.³

My friend Jen Pahlka has brilliantly written books and loads of articles on her substack about this sort of thing throughout her career which has focused on making government smarter and more efficient.

This is part of why groups that slap “add-ons” or “new” open source adjacent licenses have such an uphill climb for acceptance. When the SSPL came out, the authors knew that the Open Source Initiative rejecting it would mean that they’d have to socialize the license to the IP lawyers so that they could become comfortable with it. This is true of the other “source available”⁴ licenses.

Also, adding terms to an otherwise standard open source license makes that software no longer open source and thus no longer able to slide through without contract review. It’s also verboten in many licenses, like in section 7 of the gpl:

All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.

Or section 5 of the Apache license:

Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

Parenthetically, you’ve been able to license the source code for Windows, Solaris and the rest⁵ from those companies for going on 40 years now. Many corners of these formerly proprietary operating systems are themselves open source , or source available, as part of the code platforms supporting those operating systems. Imagine shipping a hardware driver without access to operating system fundamentals?

Where I’m going with this is that there’s some companies presenting these source available licenses, and add-on licenses as “open source” when they fail to match the open source definition and fail to secure OSI’s historical endorsement.⁶

What’s worse, is the commercial agreements presented to companies by ostensibly open source friendly companies have “anti-open source “ clauses. They try to bind the customer to never revert to the open source version of a proprietary codebase. There’s precedence for this sort of clause in commercial contracts, where you promise to not use a competitor's solution, etc. Contract lawyers look to strike that sort of thing when they review commercial contracts.

So, again for the bleacher seats: It’s okay to ship proprietary software, but you don’t get the benefit of open source licensing like contract efficiency and pre-approvals, without actually meeting the OSD and being open source.

I’m assuming this is well known within the companies using these licenses, and one of the reasons they’re trying to make the source available licenses a standard format is to bring that comfort to the customers' contract lawyers. It’s a smarter approach for enterprise sales efficiency, for sure.

I’ll wrap up by saying that one of the great benefits of open source licenses is that we know what they are and what they expect of those who produce, distribute, use and improve those codebases. It’s a big part of why software licensed under these open source licenses have uplifted the entire industry and made so much possible.

1. Some universities would attempt to increase that, but then funding would dry up.

2. For most companies, they’ll rely on an outside counsel, like Max Sill’s OSA or Matthews Surge.Law

3. I spoke with the pentagon and other agencies in the late 90s about this sort of thing. And in the 2000, and the 2010s, and the 2020s….. it seems like I’m stuck on repeat.

4. Mary Meeker reviews them here https://fossa.com/blog/comprehensive-guide-source-available-software-licenses/ Though I present that without endorsement :-)

5. Apple is a funny case, licensing MacOS to the clone makers until they shut that down, then basing IOS on the Mach Kernel and OS X on the next adoption of BSD…. er… something… Apple is funny sometimes.

6. Now the OSI isn’t prefect, and there’s some licenses they’ve approved that I think are inconsistent with the OSD , insert old man raging at cloud emoji here….