OpenAI–What Happened?

This week, the tech world was shocked by the sudden and unexplained firing of Sam Altman, the now-former CEO of OpenAI.

OpenAI has been the darling of the tech industry for the last year. Its current fundraising goals would put it on track to be one of the biggest unicorns in the US. But here are a few reasons why OpenAI probably can’t live up to its own hype. The events of this past weekend only underscore them.

My video on this topic is here.

Technical Debt, or at Least Technical Debt-for-Equity

OpenAI made a big splash by releasing ChatGPT3 in late 2022, and followed with updates this year. But OpenAI did not invent the core transformer technology behind GPT–that was originally from a core concept by Google. That’s why so many companies have been training up their own models lately. The barriers to entry in LLM development right now aren’t about technology, they are about resources. OpenAI trained ChatGPT3 and 4 using a lot of data, a lot of money and a lot of compute cycles.

The problem with this is that ChatGPT has a thin first mover advantage. Each iteration of a model takes tons of resources to produce. If OpenAI continues to draft on existing tech, and keeps building new models, it will be in a never-ending race that will require immense capital and resources, without significant economies of scale. That’s not sustainable.

Lack of Transparency and Weird Organization

The spat between the company’s board and its investors is very weird indeed. In most companies, the investors control the board. Boards and investors usually don’t have spats, particularly not public ones. But OpenAI is no ordinary company.

OpenAI’s parent entity is a non-profit called OpenAI, Inc., with a for-profit subsidiary called OpenAI Global, LLC. That is a bizarre structure for a tech startup. Non-profits don’t have shareholders, they have a board of directors. In contrast, the board of directors of a profit company is elected by its shareholders. The structure of control of an LLC is what we lawyers call “flexible”–which means opaque and idiosyncratic. But it is usually run more like a for-profit corporation.

To see how this odd structure happened, you need to read between the lines. In 2015, the original contributors for the non-profit pledged about $1 billion to the project, but many did not fulfill their pledges. So, in 2019, OpenAI transitioned from a non-profit to “capped for-profit” by creating a subsidiary LLC with shareholder profits capped at 100 times any investment. Just for reference, a “capped-for-profit” is not really a thing in corporate law, but with an LLC, anything goes. OpenAI then got an investment from Microsoft, for $1 billion, into the for-profit subsidiary, along with a deal for access to Microsoft’s cloud computing services. It then announced its intention to commercialize its products. But the for-profit entity is controlled by the non-profit.

This transition troubled initial contributors, and generated criticism. It’s kind of a joke in the tech business today that OpenAI as a company name is beyond ironic. It’s not open at all. In fact, open source advocates have generally viewed Altman and OpenAI as trying to set a narrative that avoids transparency in AI. They are pushing for regulation, to forestall demands for transparency. OpenAI has justified its move away from transparency due to its need to compete–but that’s circular logic.

Good Old-Fashioned Over-Valuation

OpenAI’s latest funding round is set to value the company at $80 billion. That’s bigger than the market cap on lots of existing public companies, including Boston Scientific and Mercedes Benz. Could it be worth that much?

It’s probably fair to say that OpenAI is the only company making significant money on large language models at the moment. (Though GitHub’s Co-Pilot is in the running, too, it’s currently based on ChatGPT.) Most companies that have released LLMs have not monetized them directly. In fact, LLMs are probably difficult to monetize at a rate that will be profitable over time–at least not based on the current data and resource-guzzing tech.

In this year of tech business malaise, AI has been the only bright spot. The conventional wisdom for 2023 is that no company can raise money, except AI startups, which are swimming in investment dollars. As usual, when private investors jump on a bandwagon, they tend to fund some terrible businesses. OpenAI is the superstar of startups today, but superstars have not fared well in recent years, tending to burn out or fade away.

Sentry Launches Functional Source License – a new twist on delayed open source release

Congratulations to the Sentry team for this live release yesterday!

The Functional Source License (FSL) makes opinionated decisions about the variables in BSL, so that it is easier to reason about for both potential producers and consumers of FSL software. FSL is tuned for SaaS companies

From the blog for the Functional Source License release:

The FSL:

  • Grants a source-available license from day one for non-competing uses.
  • Grants a license under Apache 2.0 or MIT after two years.

This differs from BSL in that the change license is set to a common permissive license (for BSL, it is a choice of a GPL compatible license), the change date is set at two years (for BSL, it is 4 years or less), and contains a detailed license limitation targeted toward SaaS businesses (for BSL, the restriction is against production use, resulting in many Additional Use Grant variations).

The blog outlines the journey of Sentry in preparing and adopting this license.


Sam Bankman-Fried’s conviction is all over the news. Here is my video on the topic.

While the crimes SBF was convicted of bear jail time of up to 110 years, his sentencing is not scheduled until March 28, 2024, which is after his next federal trial is scheduled, on March 11, 2024. The next trial promises to be even more of a circus than the recent one, given it will involve allegations of bribery and campaign finance violations, not to mention bank fraud and securities fraud. So, it’s still unclear whether the second trial will go forward–prosecutors have until February 1, 2024 to decide–and if he is convicted, whether the first sentencing will be delayed so the two sentencings will be done together.

In the US federal system, judges are required to abide by sentencing guidelines. The crimes SBF was convicted of this week can carry a penalty of 7-10 years each. A federal judge has some leeway, including to order sentences for multiple counts to be served concurrently or serially. The guidelines allow the judge to take into account demonstration of remorse–which in SBF’s case seems non-existent. However, the guidelines for sentencing of fraud also take into account the amount of the fraud, and subsection 2B1.1(b)(1) of the guidelines only goes up to $550 million. So basically, SBF’s fraud is more than the guidelines ever anticipated possible. That means the judge might make an exception to go above the guidelines. SBF’s prospects are dire indeed.

Also, there is no parole in the federal system, though inmates can earn what is called “good time credit,” and as a result, federal prisoners tend to serve about 85% of their sentence. So by the time SBF gets out of prison, he will be a lot older, and with luck, wiser. But if he is convicted of additional crimes, he may be bouncing from one jail to another.

Once SBF is behind bars, we will probably get lots of marriage proposals–and VC term sheets.

Rumors of the Death of Open Source are Greatly Exaggerated

For my video on this topic, see here.

I detest prophecies of doom. I think, mostly, people make apocalyptic predictions to get attention, and are never held to account. If you think about it, all prophecies of the end of the world have been wrong, ipso facto. The same is true for open source.

Every time there is a development in the licensing landscape, it is heralded as the end of open source.

The doom pronouncements all seem to come after incremental changes, some actually fairly minor, and demonstrate a troubling tendency in our culture toward glorified panic. At least some of them are rhetorical devices, following Betteridge’s law:

Any headline that ends in a question mark can be answered by the word no.

Let’s take a stroll down memory lane.

These are just articles I found on one Google search! All of them are wrong, of course.

What is the end of open source? The end of open source is probably the end of software. That could happen. If you take the long view, programmable software itself will probably be a technology with a lifetime of about 100 years. (Feel free to hold me to that prediction, but I may be be long gone by that time.) What will be the end of software? No-code tools, deep learning, quantum computing? We don’t know. But one thing is clear, none of the harbingers of doom have any idea, either.

Long live open source!

AGPL In the Light of Day

Recently, Open Core Ventures posted a blog entry called “AGPL license is a non-starter for most companies.” It commented:

Companies fear the AGPL because of the risk of a developer combining code in a way that would require them to open source parts of their code base that were not intended to be open source. It restricts a user’s ability to adapt the code to their needs to the point where it gives exclusive commercial rights to the original copyright holder.

The blog made some interesting points, but I disagree with the conclusion, so I wanted to add some of my own perspective.

AGPL has come a long way. About a decade ago, I wrote an article called “AGPL–Out of the Shadows.”* That article identified some of the same issues with AGPL adoption mentioned in the OCV blog, but mentioned a budding trend toward increased understanding and acceptance. After all these years, it’s time for an update on how AGPL is used in the 2020s. Actually, AGPL has emerged the license of choice for commercial open source software (COSS) companies in application space.

When is a Ban not a Ban?

The fear of AGPL is still out there. Google still bans AGPL. Most companies don’t publish their open source usage policies, but Google does, so its policy is one of the few public data points about corporate open source policy, and lots of other companies pay attention to that. Lots of companies still place AGPL on their “stop” list, (see the example policy here) because they worry they don’t have the internal controls to comply with it. That’s a conservative approach, and there’s nothing wrong with being careful.

But the “stop” category in a license policy is not the same as a ban. Having worked with hundreds on clients on open source compliance in my law practice over the years, I’ve seen first-hand how this works. It means ad hoc human approval is needed to use software under the license. That approval does create friction in adoption. But what balances against that friction is a great product.

This has always been how copyleft licenses work. Copyleft is complicated. There is a non-zero price to understanding anything complicated. For GPL, the killer app was Linux. It took nearly 20 years for companies to calm down about GPL and adopt Linux. For AGPL, the killer app was originally MongoDB. (In the 2010’s, in my legal practice, almost every approval of AGPL software in a corporate “stop” list were for MongoDB.) Products drive adoption, not licenses. Users don’t adopt licenses, they adopt software. The license simply represents a tax–in the economic sense–on its use. In other words, the conditions of the license are the cost of using the software. And for years, AGPL didn’t have enough killer apps to make many corporate users develop compliance processes for its conditions.

So, the friction OCV described exists, but it’s not entirely about the license. It’s about the balance between the complexity of AGPL with the attractiveness of software products using it.

Applications Thrive as Open Source

What’s changed since 2016 is an explosion in COSS development. At OSS Capital, we have embraced that phenomenon. But we believe the licenses serve the products, not vice-versa. To us, open source development is a huge business advantage, and that advantage can be gained with any open source license.**

Since we started our fund, many excellent COSS businesses have chosen AGPL as part of their licensing and business strategy. At this moment, it’s probably fair to say that Grafana is the “killer app” of AGPL in the business world. But there are many, many startups choosing AGPL. And in this difficult economy, their success is truly amazing. That’s no accident, because open source adoption wins a lot of business during recessionary and inflationary periods. Below is a list of only some of the companies using AGPL very successfully from OSS Capital’s own network. If AGPL does not work, that’s news to all these companies.

So, why does AGPL work for all these companies, if it is so scary? First, AGPL is not really all that scary. As I alluded to back in 2016, the main problem with AGPL was that it was relatively new, and different from other open source licenses, and required compliance processes that most companies had never implemented. Over time, adopters have become less fearful about AGPL. Compliance processes have improved. Recent focus on software BOMs and security have hauled most companies into open source compliance, because the same tools usually track both needs. So these days, it’s easier to track AGPL code in an organization.

But more importantly, the rise in adoption of AGPL in COSS has tracked the rise of COSS in applications. That’s a relatively recent development. Open source originally thrived in the basic computing stack. Permissive licenses like Apache or MIT work great for infrastructure software. Copyleft, in general, is more problematic for IT managers adopting infrastructure software, because they need flexibility to make significant changes to integrate infrastructure code, and don’t want to wade into analyzing copyleft licensing requirements. Consider Confluent, Redis, Elastic (back in their Apache days)–the list goes on. All of those infrastructure tools grew up under permissively licensed cores.

But application space is different. From the use point of view, the copyleft compliance requirements in application space are less troubling than in infrastructure. Applications are usually stand-alone processes, not libraries or tools. That means the scope of copyleft requirements (one “Program”) is not so difficult to figure out. Also, most users of applications today are accustomed to using SaaS instead of installed software. That means if you choose copyleft, you need a network copyleft license, so AGPL is the only real choice.

CLAs and Loopholes

OCV, and many others, have pointed out a “loophole” that allows vendors of AGPL applications to grant alternative commercial licenses. But that “loophole” merely describes the limits of what an open source model can do. Copyleft licenses don’t limit or condition the use of software by its authors.

In privately funded business, AGPL is almost always used as part of a dual licensing strategy. That means the software is available under AGPL, but if you don’t want to comply, you can buy an alternative license from the vendor. In that case, vendors almost always use a contribution license (CLA) for contributions from the community. Otherwise, the vendor sometimes can’t sell alternative licenses, because the contributions are encumbered with AGPL conditions. For an explanation about how this works, see my video here.

There is a lot of FUD about CLAs, but at the end of the day, if a contributor doesn’t want to allow her contributions to an open source code base to be used in a vendor’s commercial products, the license allows her to fork the code as a pure AGPL project. But of course, that means someone has to fund the maintenance of that fork. Given private companies sink millions of dollars, not to mention years of their founders’ lives, into maintaining open core products, contributors often feel that signing a CLA is a reasonable quid pro quo for that commitment of capital and sweat equity. Those who object to CLAs, at the end of the day, mostly object to privately funded open source development as a general proposition. And that’s a personal choice for contributors.

For a COSS developer, the choice is between a permissive license, like Apache/BSD/MIT, and AGPL. Most in-between choices eventually migrate to one pole or the other. Infrastructure is mostly under permissive licenses, and applications are mostly under AGPL.

Don’t Believe Me, Just Watch

In any case, try out some of the great products that are thriving under the AGPL/dual-licensing model! The proof of the pudding license is in the eating using.

*That link shows the article as authored by the “Synopsys Editorial Team” but if so, they used a time machine and a LLM to write an article in exactly my style. But seriously, I wrote it, and as far as I know, I’m not on their staff. It’s pretty rare that anyone tries to take credit for my writing– most authors would not want to take the heat for the things I say!

**Well, not exactly. Non-standard or superseded licenses like Common Public License don’t work so well. But that’s about standardization, not substantive license terms. COSS businesses usually need to choose one of the “big 6”: AGPL, GPL, LGPL, BSD, MIT, Apache.