On Thursday, Dec. 16, FOSSA teamed with leading open source licensing expert Heather Meeker for the webinar “Truth Social, AGPL, and OSS License Compliance.” During the webinar, Heather discussed the AGPL’s unique provisions around network deployment, how the AGPL compares to the GPL and LGPL, and more.

Heather also tackled several hot topics in the open source world related to the AGPL, including the ongoing license controversy surrounding Truth Social, Google’s AGPL policy, and more. In this blog, we’ll highlight Heather’s key insights on those topics. Stay tuned for additional posts from the webinar, including a deep dive into the AGPL.

About Heather Meeker: Heather is one of the world’s foremost legal experts on open source software licensing and compliance. She’s authored the go-to book on the topic, Open Source for Business, and is a General Partner at OSS Capital.

WATCH ON-DEMAND: Truth Social, AGPL, and OSS License Compliance

The Truth Social License Compliance Controversy

Truth Social, a planned social media site of the Trump Media and Technology Group, has been in the news over the past months itself for allegedly violating the terms of the AGPL. But because of the AGPL’s unique provisions related to network deployment — and the fact that Truth Social has made some source code available since initial reports of non-compliance — this isn’t a cut-and-dried case.

Question: Can you explain the license compliance controversy surrounding Truth Social? How have recent developments changed the situation? And what are the legal takeaways?

Heather Meeker: “The first development was that the Mastodon project and some others in the open source community observed Truth Social appeared to be using Mastodon to run its platform. And even though Truth Social hadn’t launched yet for general availability, it was available at least to some extent. That’s one important takeaway: It doesn’t matter whether a program is in Alpha or Beta or GA — if you are making software available to anybody, then you have potentially triggered the source code sharing requirements.

Another interesting point is that people in the open source community were able to tell that Truth Social was using the Mastodon software even though Truth Social hadn’t officially launched. This is an important reminder that it’s way easier than you may think for people to tell that you’re using a certain software component, even behind your firewall. Security by obscurity doesn’t work to avoid open source compliance.

The next major development was that Truth Social published some source code — but what they published was reportedly the unaltered Mastodon code. That was an odd move because AGPL’s source code sharing condition doesn’t get tripped unless you actually modify the code. So there was not a world in which that publication would constitute compliance with AGPL. Either the code wasn’t modified and there was no requirement to disclose source code, or it was modified and what they published was not the corresponding modified code.

So, that action probably did not solve the problem, but I also haven’t seen complaints about it, perhaps because the groups that originally lodged complaints might not have as much visibility into exactly what form of code the platform was using.

Another important lesson: If you’re an IP lawyer and you’re working in the world of IP controversies, it is not normal for people to litigate situations like this in the press. From a legal perspective, Truth Social had allegedly violated the AGPL and was engaging in copyright infringement. But the majority of communication took place through open blog posts and so forth. Apparently, there were some direct communications, but in the world of open source, people will think they’ve found a license violation and immediately publish something about it on Twitter or some blog post. This is not the normal way things work in an IP controversy.

So, you have not only the legal questions to deal with, but also a significant aspect of being shamed, or reputational damage, because you have violated a license.”

Google’s AGPL Policy

Google’s strict prohibition of AGPL-licensed code is one of the more well-known and highly publicized examples of an OSS license compliance policy in action.

But, broadly speaking, is“Never AGPL” a reasonable policy for other companies to adopt?

Meeker: “I think that it’s a good baseline rule for most companies because they may lack the expertise to figure out a more nuanced answer.

‘No AGPL’ is a good basic rule, and I say that because AGPL is not an extremely widely used license. You can mostly avoid using code under AGPL, and you’ll generally be able to find a substitute for anything that is only available under AGPL.

With that said, I don’t recommend considering these questions in a vacuum. It’s more useful to come up with a rule, keeping in mind that there will always be possible exceptions to the rule, and think about how you are going to react to those exceptions.

So, yes, I think it’s a good rule for most companies — assuming they’re developing proprietary software in the first place. But when a question comes up because someone wants to use some AGPL-licensed code, then you have to get smarter about how you’re going to answer the question. And, if you’re going to allow use of AGPL-licensed code, how are you going to make sure you can comply with the license’s requirements?

Part of this is a question of internal processes. Most license compliance reviews happen when you ingest the code for the first time — there’s often no trigger of an additional review when you modify it. But if you modify the code, you might suddenly need to make available your updated source code.”

How do you handle potential disruption to developers and development workflows caused by a “Never AGPL” policy?

Meeker: “There is some popular software covered by AGPL, and that’s an important part of this conversation. MongoDB was a prime example of this, but they moved away from AGPL and created their own license. Today, one of the hottest AGPL-licensed applications is Grafana. But Grafana is dual-licensed, meaning you can pay for a commercial license and not be bound by the AGPL. AGPL is a popular license for dual-licensed software, so often there is a commercial resolution to a compliance problem. But that may not be true for all AGPL software.

Ultimately, I still think ‘No AGPL’ is a perfectly good rule for most private companies developing proprietary software, at least to start with, but they just have to be shrewd about what to do when they have an exception.