Category: Uncategorized

FTX CEO SBF KO

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.

OpenAtom Foundation, and My Book in Chinese

I am excited to announce that my book Open Source for Business is now available for free download in Chinese.

Many thanks to OpenAtom Foundation, China’s first open source foundation, for preparing the translation and making it available. I gave a virtual talk at OpenAtom’s recent conference, and it is available here (start at 1:53).

Toward an Open Weights Definition

Today, OSS Capital is starting a project to collect community input on a definition of Open Weights. We have published our initial effort at https://github.com/Open-Weights/Definition.

Here is the TLDR:

It is critical for the industry to develop and standardize on “Open Weights” licensing frameworks. These frameworks should align closely with the Four Freedoms of free software but should be specifically tailored for Neural Net Weights (NNWs). Recently, my partner and the founder of OSS Capital, Joseph Jacks, posted about this issue, and there was significant interest.

We need a standard for Open Weights that recognizes the unique nature of NNWs and provides legal and practical guidelines for their use, distribution and sharing. This requires collaboration from the entire AI community, including developers, researchers, legal experts, and regulatory bodies.

Also, we do not believe that a definition of Open Weights needs to import subjects such as privacy, human rights, or clearance of data inputs into its licensing principles at this time. We know those are important topics, but they will take time to figure out. We are focused instead on the original idea of openness, and preserving the original goals of Freedom Zero of free software and the non-discrimination principles of open source. We encourage others to develop their own standards for restrictions and ethical licensing, and to participate in the legislative process to set the standards of society for limiting activity to proper use of AI, the information used to train it, and the information it produces.

Also, we applaud those communities who are working on their own definitions. At OSS Capital, we have committed to sponsor the Open Source Initiative’s efforts in this regard, and we hope our efforts will dovetail. But we believe time is of the essence, so we hope our effort will jumpstart collaboration.

We believe that this definition should be developed in the open, much like open source software itself. Therefore this definition and license will be published on GitHub and the community is invited to improve it.

As OSI, we are less concerned with the exact substance of the definition than making sure there is a definition everyone can trust.

Here are some things we considered when creating our draft definition.

  • Time is of the essence. We need a definition soon; developers and users alike are struggling because they don’t have one, and they need one, so they can make proper choices about which models to use.
  • Keep it simple. We are leaving questions like privacy and ethics to other initiatives. Those are important, but much more complicated, and will take time to work out. We are also not tackling the issue of clearing rights in training data.
  • Define both the licensed material and the license. We need to know not only license terms for licensees, but what needs to be disclosed by the licensor to make the licensed material open. This is, we think, the most difficult challenge for creating this definition.
  • Get community input. We welcome everyone to comment and make suggestions on GitHub. We hope to help the discussion but not control it.

If you’d like to contribute or open issues, please see our GitHub.

If you’d like to follow the project, you can watch the repository — instructions on how to watch a repo on GitHub.

You can engage in discussion here: https://github.com/Open-Weights/Definition/discussions