Securing Open Source Software Act of 2022

A bill was recently introduced in the US Senate, entitled the Securing Open Source Software Act of 2022.

I don’t usually write much about pending legislation, because it often does not ever become law, or changes substantially before it becomes law. This bill is unlikely to be passed this year because of its timing. But it has a few interesting characteristics.

  • It is a bipartisan bill, introduced by Gary Peters (D-Mich.) and Rob Portman (R-Ohio, both members of the Senate Homeland Security Committee.
  • It defines both “open source software” and “open source software community.”
  • It focuses on requirements for software bills of materials (SBOMs), and security concerns, drafting on the Executive Order, from earlier this year, about software security Executive Order on Improving the Nation’s Cybersecurity (EO 14028).
  • It establishes “the duties of the Director of the Cybersecurity and Infrastructure Security Agency regarding open source software security” and requires the Director to regularly assess open source software used by the federal government. So it establishes a process, more than substance.

If I had to guess, I would say the bill seems likely to pass in some form, next year. If it does, it’s unclear exactly how it will interact with the recent EO. Also, improved security assessment is good for all software, not just open source — open source security breaches get a lot of press, but all software has potential security issues, and the government should be concerned about its use of proprietary software as well. Finally, to the extent new law establishes requirements for government, or even other customers of software, the private market is mostly ahead of these requirements already. Most software vendors know that customers are already very demanding regarding security requirements. The effect of new law could be to normalize those market demands in private sectors and government — but we will have to wait and see.

Victory for FireTek in the PyroTechnics Case

About a year ago, I wrote about a copyright case involving fireworks firing codes. This case did not get a lot of attention at the time, and it was yet another example of a plaintiff using copyright law as unexploded ordinance (if you will forgive the pun) to harass its competitors, rather than to protect works of authorship.

Fortunately, the Third Circuit recently vacated a prior injunction in the case, for lack of likelihood of success on the merits, and remanded to the district court with an order to to dismiss the claim with prejudice.

The court analyzed the copyright protection of both Pyrotechnics’ digital message format, and the digital messages created with it. The opinion linked above provides interesting detail on how the messages worked.

The court said, “Pyrotechnics’s digital message format is an uncopyrightable idea and the individual digital messages described in the [copyright registration] are insufficiently original to qualify for copyright protection.” Regarding the message format, it concluded:

Pyrotechnics admits that there is no way for the control panel to communicate with the field module without using the digital message format. Because there are no other “means of achieving the [protocol’s] desired purpose” of communicating with the devices, the digital message format must be part of the uncopyrightable idea and not a protectable expression.

Citing Whelan, 797 F.2d at 1236.

As to the messages using the format, the court said, “The digital message format provides rules for constructing messages with particular meanings, and individual messages are generated by applying those rules mechanically.” Because there was insufficient human creativity in creating the format, the messages were not protected by copyright. It further noted that even assuming the messages were creatively produced, there was no creativity in the structure, and ordering, because “using leading header bytes for synchronization and a trailing byte as a cyclic redundancy check are standard communication practices, not creative sequencing.” The court relied on its prior decision in Southco, Inc. v. Kanebridge, 390 F.3d 276, 282 (3d Cir. 2004) (en banc), regarding a numbering system for fasteners, from which the court drew many parallels.

Fighting a David vs. Goliath Copyright Battle

I got a chance to correspond with the owner of FireTEK. Here is what he had to say about the case:

How did you become interested in fireworks systems? How did you learn to engineer them?
The first time I was in the backstage of a fireworks display it was with my system. I started this project because someone asked me if I could do this kind of system to control fireworks, in 2009. I said no a few times, but he insisted, so I decided to try to do it. But then he decided he did not need the system anymore. Also, I had hired some people to do the work, but they quit. So I started researching and learning, and did almost everything myself, and then I became passionate about developing and innovating.

Even though the project started with a lot of problems, now I could see almost all the problems I had, and that helped me make a better product. For example, a main component went out of production and I was forced to find a replacement, but the replacement I found was even better. Because I could not afford someone to do the project, I was forced to learn myself. Even this copyright trial was a learning experience, and a good thing in the end.

Copyright cases can be complicated. What encouraged you to fight the claim?
I run a very small company in Romania. Maybe the plaintiff thought I would not be able to defend myself, but that was not true. This was a difficult and expensive case for me to defend. I was also concerned that, because I was outside the US, I would not get justice from a US court. I knew I had the law on my side, but I didn’t know whether that meant I would win. I kept going, though, because this is my business and I need to protect it.

What do you think tipped the case in your favor?
To be honest I thought it would be an easy win at first, from what I have read about copyright and compatibility. I don’t think the district judge understood the differences between my product and theirs. It seemed to me that the district court opinion mostly copied the plaintiff briefs. That opnion never mentioned my main argument under 17 USC 102(b) and US Supreme court decision in Baker v. Selden. Furthermore, the district court found the work equivalent to an object code and found fixation even though one of the authors clearly states it is “not source code that resides in a computer or in a microprocessor somewhere.” The deposit material for the plaintiff’s copyright was just a simple text created after infringement from memory of someone which was not even listed as author and which briefly describes the protocol.The judge in the appeal understood this. That opinion shows the judge studied it carefully. But I don’t think the district court understood it though I found that hard to believe.

After reading the district court opinion and some other rulings made against me, I was feeling as the main character “The Trial” by Kafka.

What advice do you have for small businesses fighting legal claims?
It will not be an easy fight, but if you know you are right, go to fight. Very important in my case was my involvement in the strategy, briefs, arguments, and of course learning from mistakes. You know your case better than your attorney, so you should read, understand and correct the mistakes your attorney may write in the briefs.

What is next for you in your business?
Even though I won this case my goal is not to get clients with cheaper compatible products. I try to innovate and convince them to buy my product because of all it offers. The compatibility is only an argument to convince the potential client to try my product, because I know they can not switch so easily to another product. It is like you have an entire company which runs a CRM software and you decide to switch to another one if it has some advantages but you find out the cost of the switch is much higher if there is no compatibility to migrate databases for example.

Congratulations to FireTEK for winning a battle against copyright maximalism, just in time for Independence Day!

New Jurisdictional Ruling in Vizio Case

On May 13, 2022, the US District Court of the Central District of California issued a decision in Software Freedom Conservancy v. Vizio.

For more about the initial complaint see my previous post. In brief, SFC had sued Vizio in California state court, alleging that a violation of GPL was a breach of contract, and seeking declaratory judgment and specific performance (release of source code). SFC is not the author of the GPL code at issue, and the authors of the code are not party to the suit.

The issue in the removal motion was whether there was federal jurisdiction, sufficient to shift the lawsuit from state court to federal court. Federal courts in the US have exclusive subject matter jurisdiction over copyright claims, and diversity jurisdiction over other claims that are between parties in different states, and where damages are sought in excess of $75,000. 28 USC § 1332. But SFC’s complaint was neither a copyright infringement claim nor a claim for damages. This neatly avoided federal subject matter or diversity jurisdiction. The court said, “There is no dispute that SFC’s complaint alleges only state law claims, and the Parties agree that the action is removable only if SFC’s claims are completely preempted.”

The remaining question was whether the state law claims were pre-empted by copyright law. Preemption is a legal doctrine that reserves certain kinds of matter to the exclusive regulation of federal law. Under 17 USC 301a, federal law clearly pre-empts all claims that are within the scope of copyright law. Here, however, the court said the state law claim pled by SFC was different from a copyright claim. Therefore, the court in this case did not take jurisdiction over the matter away from the state court.

To support its preemption argument, Vizio argued unsuccessfully (relying on MDC v. Blizzard) that all violations of license conditions should only result in copyright infringement claims. But that was converse logic. MDC was about what cannot be a copyright claim, not what must be one.

Through the Looking Glass

The parties’ positions were unusual, because defendants generally prefer defending contract claims to copyright claims. Open source enforcers almost always bring the actions as copyright claims rather than (or in addition to) contract claims. Copyright generally affords more generous remedies than state law contract claims, including the possibility of statutory damages. Also, injunction is often available as a remedy under copyright law, but rarely under contract. So, SFC v. Vizio is an anomaly, where the plaintiff argued for contract claims and the defendant argued for copyright claims.

Moreover, there is a history of open source licensing pundits theorizing that open source licenses are “not contracts.” It has long been my view that this theory was misplaced. (I think, originally, that theory was intended to avoid contract formation arguments under the law of the 1990s, which arguments were largely sidelined in 1996 by the ProCD case (86 F.3d 1447 (7th Cir. 1996). But I am reading between the lines there.) GPL2 famously says, “You are not required to accept this License, since you have not signed it.” But the existence of a contract depends on the facts surrounding contract formation, and not so much on what the document says. It is more accurate to say that open source licenses need not be contracts to be enforceable, because violating their conditions provides the basis for a copyright infringement claim, as clearly established in US law, mainly under Jacobsen v. Katzer. Contract claims are therefore usually a belt-and-suspenders tactic in open source enforcement.

The law has never clearly articulated the answer to the “license or contract” question, but Jacobsen v. Katzer suggested contract claims were possible, as did Artifex v. Hancom. So in sum, there is case law saying copyright claims are possible, but none saying contract claims are impossible.

Neither a Win Nor a Loss, Yet

Some open source advocates are celebrating, but that celebration is probably premature. This result does not mean the federal court is saying there is a valid state contract claim, or that the remedy sought is available, only that there is no basis for federal jurisdiction.

Assuming the ruling stands and the case goes back to state court, there are a few possibilities:

  • there is a state law claim for which the remedies sought are available
  • there is a state law claim but the remedies sought are not available
  • there is no sustainable state law claim

SFC still has a lot of bridges to cross–the highest and widest being the availability of specific performance as a remedy for breach of contract. Most legal commentators have long believed there is no basis for such a remedy under licenses like GPL, only damages for breach. And while injunctions are often available for copyright infringement, those injunctions are negative injunctions–orders to cease and desist using the infringed material. Specific performance, sometimes called a positive injunction, is a very rare remedy under contract law, and a court forcing a technology company to disclose proprietary information due to a breach of contract is virtually unheard of. Courts tend to order people to stop doing things, not to do them. The reason for this is deeply woven into our notions of civil liberty, granting courts only limited powers. Injunctive relief is an exceptional remedy, because it impinges on civil liberty. Courts can order you to go to prison (for crimes) or pay money (for torts), but they don’t usually order you to do much else. That’s in part because they don’t have the resources to police positive injunctions. When you read in the news about a court ordering someone to do something, it is usually part of a negotiated settlement or consent decree.

This begs the question of what will happen to open source adoption if SFC is successful. The resulting risk of everyone–not just authors–having authority to sue for enforcement of GPL may significantly disrupt the open source ecosystem. Back in the late 1990s, companies were extremely reluctant to use GPL code (like Linux) due to the perceived legal risks–which were in part trumpeted as FUD by anti-open-source actors like Microsoft. But over the years, the tech industry grew comfortable that the only risk of lawsuits was from authors, and most authors preferred informal enforcement to legal process. That process of acclimation took decades. A change in this assumption could cause companies to stop using the GPL software they have grown comfortable using over the years, and it’s not clear that would be a win for the open source ecosystem.

Crypto for the Rest of Us, Part III: Smart Contracts

Welcome to another installation of me teaching myself about crypto by writing about it! In past posts, I have discussed topics like Bitcoin mining and proof-of-stake. I’m not an expert on crypto, but I like learning about technology, and these posts are an attempt to share what I have learned at a level that is not too basic, but not too advanced, for readers who are curious, like me. Actually, this topic has a lot to do with contract law, so I am more comfortable writing about it than those prior posts.

The thing I hear repeatedly about smart contracts is that they are neither smart nor contracts. Let’s figure out why people say that, and whether it is correct.

What is a Smart Contract?

A smart contract is a transaction that executes automatically on a blockchain, according to a set of programmatic rules. The most commons kinds of smart contracts today are trading, investing, lending, and borrowing–financial transactions. Also, non-fungible tokens (NFTs) are created via a minting process embodied in a smart contract.

The term smart contract was coined by Nick Szabo in 1998. He wanted to apply the principles of distributed ledgers to executing transactions.

Not all blockchains support smart contracts. The most popular one that does is Ethereum. On Ethereum, smart contracts are executed via the Ethereum Virtual Machine (EVM). The EVM is isolated, in the sense that it has no access to network, file system or other processes on which the blockchain is running. That is important so that bugs in smart contracts cannot affect the entire blockchain, or other transactions.

Smart contracts, like any logic, are written in a programming language. The most common one is a statically-typed language called Solidity. Other languages, like Rust and Javascript, are used, but Solidity is specifically for smart contracts.

Are they Smart?

Not in the lay sense. The quintessential example of a smart contract, suggested by Szabo, is a vending machine. If you put in the money, and press a selection button, the snack drops down. That is not very smart, but it is automatic, and eliminates the need for a human to fulfill the transaction on the seller side.

Smart contracts are smart in that they are self-executing without human intervention. In contrast, traditional legal contracts are almost always promises to do things in the future, so they need to be performed by humans, and tracked, to be sure the parties actually perform them.

Actually, smart contracts are usually nowhere near as complicated as most traditional written contracts, which often have pages of terms and conditions. At this point, smart contracts contain rules that are “fairly rudimentary.” Here is an example of a simple smart contract:

https://solidity-by-example.org/app/ether-wallet/

This example creates an Ether wallet. As you can see, the language looks similar to C++. The first lines of the program name the license for the code, and the language it is written in. The program logic after that is quite simple. There are many other examples here.

Smart contracts work because the EVM can send a transaction from one account to another account, and that transaction can include binary data (the payload) and Ether (the cryptocurrency). If the receiving account contains logic (the smart contract), that logic is executed with the payload as input data.

To execute a smart contract requires the payment of a transaction fee, called a gas fee. (Because it’s Ether.) A smart contract that is more complex will cost more gas to execute. The maximum gas price is set by the creator of the transaction. If the authorized gas is insufficient, the transaction will not execute. If some gas is left after the execution, it is refunded to the creator.

You can see some examples of smart contracts on Ethereum here.

Are they Contracts?

Yes, but the bar for formation of a contract is pretty low. And smart contracts are usually not what lawyers call executory contracts. Under law, a contract is formed when there is an offer, acceptance, and consideration (an exchange of value). Once the contract is formed, the parties must perform the terms of the contract, and until they are done performing, the contract is called an executory contract.

Smart contracts are often touted has having the advantage of not requiring a third party to authorize them. But in fact, in most modern economies, traditional contracts do not require a third party to authorize them, exactly. Or perhaps only by implication, because parties perform contracts because of the threat of a third party’s involvement. If one party to a contract breaches, the other party can sue for damages, and a neutral third party (like a court or arbitrator) can enforce the contract, based on contract law. But most contracts are never litigated. So, while traditional contracts can be executed between the parties with no third party intervention, the more accurate accurate distinction is to say that smart contracts are concluded on the blockchain with no additional human effort.

Smart contracts happen immediately–or at least, as soon as the blockchain can process them. Of course, traditional contracts can be executed quickly, too. If you walk up to a fruit stand, hand over a dollar and take an apple, that’s a contract, and it executes immediately. But those kinds of contracts are not usually written in advance.

Unlike traditional contracts, smart contracts are transparent and irreversible, because they execute on a blockchain. Everyone can see the smart contract if they look at the blockchain. In contrast, the terms of traditional contracts are often confidential, and they can be amended or voided by the parties.

Also, traditional contracts are rarely pseudonymous. In fact, it’s important, in a traditional contract, to clearly identify the parties–which is why we include corporate names, addresses, and other identifying information when we define parties in a contract. That’s to help enforce the contract against the right person, if necessary. But blockchain transactions are by definition pseudonymous. The contracting parties do not have to know each other’s true identities. Depending on your viewpoint, this is a benefit or a drawback.

Smart contracts can stand on their own, or be paired with a traditional contract and execute only some of its provisions. For lawyers who are accustomed to traditional contracts, it may be easier to think of a smart contract as the execution of an escrow or a closing process. Money is paid upon the occurrence of a specific trigger. And like escrow agents, smart contracts need specific and unambiguous direction as to what is to be done to effectuate the transaction. And complicated instructions are generally not a good idea.

Like traditional contracts, smart contracts can suffer from ambiguity or “bugs.” Any program can fail to account for contingencies in the real world. But smart contracts are mostly quite simple, at this point. In comparison, traditional contracts are complicated, and the reason people hire lawyers to write them is that they need lawyers to consider the myriad things that can go wrong, and whether and how to account for them in the contract.

What’s Next for Smart Contracts?

First of all, they will not be replacing traditional contracts any time soon. But they may make inroads into replacing escrows or closing processes. However, pseudonymous contracting is probably insufficient for some transactions, such as when the parties have know-your-customer (KYC) requirements or require complex closing conditions.

The applications of smart contracts are likely to to expand over time. While today, smart contracts mostly involve payments and similar financial transactions, they are already being used for investment transactions, automated asset management, and self-paying loans. In the future, they might be used to establish pseudonymous digital identities, transfer assets such as land title, manage capitalization tables, verify supply chains, or conduct public elections.

It’s also likely that new blockchains will support smart contracts. The market for different blockchains and cryptocurrencies is highly competitive, and the additional functionality of smart contracts can help make a blockchain more popular.

More Resources

Here are some additional resources, if you want to learn more about smart contracts:

Crypto for the Rest of Us, Part II: What is Proof of Stake and Why Should You Care?

In a prior post I wrote about the basics of blockchain and proof-of-work Bitcoin mining. One topic omitted from that post was the alternative consensus mechanism, proof-of-stake. Last week, the EU turned down a proposal purporting to outlaw the use of proof-of-work cryptocurrencies in the EU. Also, Ethereum–the world’s second most popular crypto blockchain–is in the process of moving from proof-of-work to proof-of-stake. So this week, I am looking at the difference between these methods of consensus, and why proof-of-stake is likely to eclipse proof-of-work in the future.

Problems with Proof of Work

The main problems with proof-of-work are that it requires a great deal of power, as well as specialized computing equipment. Power requirements are an environmental problem, and specialized equipment is an access problem–particularly during a time when semiconductors are in short supply. If you want to know more about how proof-of-work mining happens, take a look at my last post.

But proof-of-work is also designed to have a limited throughput and pace. New blocks on Bitcoin are designed to be created about once every 10 minutes, and that means transactions take 10 minutes to happen. That may sound fast, but in the world of globalized currency exchange, it is not fast enough for everyday transactions.

These, and other concerns about proof-of-work, have led cryptocurrency communities to consider an alternative called proof-of-stake.

What is Proof of Stake?

Proof-of-stake is a method of reaching consensus on the validity of new blocks in a blockchain. Adding new blocks must happen via consensus because blockchains are distributed databases with no central authority to certify them. Proof-of-stake validates new blocks via a process known as staking. Staking is similar to voting, but because different validators can stake different amounts, voting power is not equally distributed among validators. In this way, it’s more like the way voting works in corporate shares than in democratic elections.

As with proof-of-work, proof-of-stake consensus is a two-step process. First, validators compete to propose a new block based on the transactions in the queue to be cleared. Then, once a validator wins the right to propose the new block, all the validators must reach consensus that the new block is correct.

In a proof-of-stake system, any validator can propose to add a new block to add to the blockchain, and must choose the amount of coins to stake. There is a minimum stake required, like an ante to play a round of poker. (Ethereum’s new proof-of-stake system will require a minimum stake of 32 ETH, which is about $3,000 as of this writing in March 2022.) The system chooses a validator at random to propose the new block, but the random choice is weighted by the amount of coins staked by each validator. This means those offering a larger stake are more likely to win the validating competition. The winning validator then proposes a new block to add to the chain.

All validators are responsible for attesting the blocks created by other validators. When the minimum required validators attest that the block is accurate, the block is added to the chain. (For ETH, the approval of 128 validators will be necessary to validate a new block.) The winning validator then adds the block and populates it to the nodes on the blockchain, and the system moves on to the next block.

Any validator who proposes a bad transaction or block would be slashed, meaning the validator would forfeit the stake. Also validators will lose their entire stake if they later attempt a 51% attack to the validity of the chain. This means validators have a high incentive to maintain the blockchain and protect its integrity. Validators can also be penalized for failing to fulfill their validating duty for other validators, but these penalties are relatively smaller.

Why is Proof of Stake Important?

Every technology needs a killer app, and for proof-of-work, Bitcoin was the killer app. But there are lots of cryptocurrencies these days, and each has its own rules and validation requirements. The killer app for proof-of-stake is likely to be Ethereum. Ethereum is different from Bitcoin in many ways. Ethereum is capable of executing smart contracts, and significantly, is the main blockchain on which NFTs are minted and sold.

Ethereum is currently mined via proof-of-work, but is in the process of transition to validation via proof-of-stake. It will do this as part of its lengthy 2.0 release process, and initial efforts to make the change have been ongoing for some time now.

Which is Better, Proof-of-Work or Proof-of-Stake?

Keep in mind that the purpose of each consensus paradigm is to create scarcity of the minted currencies, and ensure the integrity of the blockchain. That means the consensus requirements must provide incentives for participants to validate, and disincentives for validators to corrupt the blockchain. (For a tutorial on different consensus mechanisms, here is a good video.) Here is how the two methods compare:

  • Security. There seem to be differing opinions as to which method is more secure to avoid 51% attacks or spoofed chains. But most of the opinions I found say proof-of-stake is better, because the risks for validators of violating the rules are higher, so the expected costs of an attack will outweigh the expected benefits. Others call proof-of-work more secure. So, it seems the jury is still out on this point. Proof-of-work is battle-tested via its current use in Bitcoin and Ethereum. Proof-of-stake is at a more experimental stage, though some cryptocurrencies already use it.
  • Speed. Proof-of-stake is potentially faster. Blockchains like the one for Bitcoin are designed to create new blocks about every ten minutes. This is actually so slow, in computing terms, that it’s considered a reason why Bitcoin is not suitable for everyday transactions. Ethereum’s current proof-of-work pace is much faster than this, due to its different design, but all proof-of-work systems are limited by the time it takes to mine the block. Moreover, proof-of-stake architectures enable a technique called sharding, which allows the blockchain to be split into shard chains, each of which is capable of processing blocks in parallel. This increases the potential speed of proof-of-stake systems.
  • Environmental Impact. Proof-of-stake consumes much less energy. Staking doesn’t require the extensive computing resources of proof-of-work, which is specifically designed to be difficult and expensive to do.
  • Barriers to Entry. Proof-of-stake can be viewed as having lower barriers to entry, because the minimum stake is less than the cost of equipment required to successfully perform proof-of-work. However, each system favors validators with more resources, who are more likely to win the rewards for validation.
  • Concentration. Proof-of-stake can more easily become concentrated. Validators with the most can afford to risk more, and thereby get more rewards. However, proof-of-work has also become concentrated, as currently more than half the mining rewards for both Bitcoin and Ethereum are won by a few mining pools. So the relative level of concentration remains to be seen.

The EU Proposal

The EU recently considered a proposal to create a broad legislative framework for digital assets. The Markets in Crypto Assets (MiCA) proposal was a detailed plan for regulating crypto in the EU. Among many other topics, it sought to prohibit those in the EU from using proof-of-work currencies. That element of the proposal was highly controversial, given the two most popular cryptocurrencies still use a proof-of-work consensus. As soon as the proposal was made, cryptocurrency advocates started lobbying against it. On March 14, 2022, the EU Parliament voted against the proposal. However, EU is expected to create a revised proposal by January 2025.

Regardless of the ultimate success of a revised EU proposal, and whether it includes a ban on proof-of-work cryptocurrencies, the existence of this plank in the proposal shows that the winds are changing. Environmentalist criticism of the power requirements for proof-of-work have been eroding the reputation of cryptocurrencies, already tarnished for enabling illegal transactions such as ransomware. If Ethereum’s new proof-of-stake is successful, it seems likely to eclipse proof-of-work as the consensus mechanism of choice for new cryptocurrencies.

Blockchain for the Rest of Us

Blockchain and crypto get a lot of press these days, but most people still struggle to understand them. As with many technical topics, the blogosphere is little help to the curious reader.  Sometimes it uses analogies so abstract as to be useless, such as extremely complex math problems, or a highly complex computing process, which are glosses implying that the reader–or perhaps the writer as well–can’t understand the facts. Or sometimes it delves into so much detail as to be useless to most readers unless they already understand–a chicken and egg problem. This post is an attempt to strike a happy medium and explain how blockchain works, for people who are curious, but not technical experts. (Like me!)

To demystify blockchain, we need to understand a few concepts:

  • What is blockchain?
  • What are cryptocurrencies?
  • What is mining?
  • Why is the blockchain trustworthy?

What is Blockchain?

Accounting - Wikipedia
https://en.wikipedia.org/wiki/Accounting

A blockchain is a kind of ledger. Most people don’t use physical ledgers, like the one pictured above, these days, but your bank statement is a ledger. A ledger is just a sequential list of transactions. Ledgers are designed to be auditable, so they allow additions but not deletions or changes. Once a transaction (like a deposit or withdrawal) is recorded, it can’t be erased or changed — it is in the ledger forever. So, for example, if your bank makes a mistake and pays the wrong amount from your account, the bank will not erase that transaction. It will credit an amount back to your account in a balancing transaction.

A distributed ledger or decentralized ledger is just a series of electronic transaction records, each of which contains details like the amount transferred and the date.

But a blockchain is different from your bank statements because it is a chain–the transaction records are linked together in a sequence that cannot be changed, even if the storage location of the records is separated. Each transaction record is called a block. (Actually, each block usually contains multiple transactions, so this is a simplification.) Unlike a paper ledger, or even your bank statement, each block also contains a cryptographic pointer to find the previous block. That way, the chain can always be reconstructed from its pieces. Anyone who wants to verify the chain can do so by following the links back one at a time. If a link is not in the sequence, it’s not legitimate.

The pointer is created with a method called a hash. Hashes have all kinds of uses computing. In blockchain, a hash is a unique number (or series of characters) that is generated automatically based on the information in the block. It is like a fingerprint: If you have the fingerprint, and you have the block, you can tell easily whether the two of them match, and the fingerprint corresponds to the record.

Peer to peer network nodes

A decentralized ledger exists on various computers known as nodes. These computer nodes all work independently in a peer-to-peer network. A node often maintains a local copy of the entire blockchain since its beginning.

So in sum:

  • A blockchain is an electronic ledger
  • Each block in the chain is connected to the last one using a hash
  • It is decentralized because it exists independently on many computer nodes

How do Blockchains Work?

Most blockchains are permissionless and public, meaning they are not controlled by a central authority, like a bank or government, and all participants can access a copy of every transaction. That means all participants can verify the chain for themselves, without relying on a central authority. Even though blockchains are not encrypted, their information can still be secured. Bitcoin, for example, uses pseudonyms to identify parties conducting transactions, so their personal information will not be publicly available. But the pseudonymous information is accessible to anyone. You can find some examples here.

Here is an example of what you would see at the above link–the latest blocks and transactions for Bitcoin.

The key characteristic of public decentralized ledgers is that they can be trusted by participants without the need to trust a central authority, like a bank. This quality makes them extremely resistant to tampering, because all the copies stored across the network need to be attacked at the same time for an attack to be successful. As an analogy, suppose your identity was secured by a passport only, and anyone who had your passport could claim they were you. That would be a single point of failure in security. But in real life, many people know you, and you have multiple IDs, so even if someone stole your passport, you would be able to prove they were not you. For your identity to be truly stolen, there would need to be a vast conspiracy to remove most of the traces of your identity. Blockchains work like that. For the information to be corrupted, so many people would have to collaborate that it is highly unlikely to happen. In other words, they work by consensus, and with enough participants, consensus is quite reliable.

So in sum:

  • Most blockchains are unpermissioned.
  • Unpermissioned blockchains rely on consensus and transparency, instead of trust in a single authority, for legitimacy.

What is Cryptocurrency?

Blockchains have lots of uses, but one of the most popular is to legitimize and track private currency like Bitcoin.

Currency is a unit of value that can be exchanged for goods and services or saved for future use. Currency is fungible–one dollar is as good as another. The auditable and sequential qualities of ledgers, and their ability to make balancing transactions, work for currency because currency is fungible.

Currency is also scarce. Scarcity is a basic economic principle. Currencies don’t represent value if they have an infinite supply. If you could print up money on your computer printer, it would immediately lose all its value. No one would accept it for goods or services that have real-world value, because they could print up their own. In a way, currency is like a group hallucination. If we all behave as if currency has value, then it does. Once people lose confidence in the stability of currency, it loses value quickly, as in episodes of hyperinflation.

You have heard of cryptocurrencies like Bitcoin and Ether and Dogecoin. These are private currencies that are transacted on a blockchain. The blockchain is the method of making transactions, and the cryptocurrency is what is being transacted. A blockchain is not a cryptocurrency, any more than a bank ledger is money.

Unlike Dollars and Pounds and Rupees, cryptocurrencies are not usually authorized by a government. Government-authorized currencies are called fiat currencies, because the government uses its legal authority (fiat) to require that its citizens accept that currency to pay off debts. A currency meeting this requirement is called legal tender. The value of a fiat currency is based largely on the reputation of the government that issues it. While almost anything can be used as a currency — gold, stamps, or poker chips– a fiat currency is usually more stable, because the government works to manage its stability.

At least in the US, it is not exactly illegal to create your own currency. In fact, the US has a long history of private money. There are plenty of currencies issued by local governments, banks, or private citizens. These are sometimes called scrip or community currencies. Sometimes, scrip can be exchanged for anything of value, and sometimes, it can only be exchanged for specific things. A frequent flyer mile, for example, is a kind of currency that can be exchanged for airline tickets or other things of value, depending on what the issuing airline allows. Anyone can invent a currency. And anyone can invent a cryptocurrency.

But governments can issue cryptocurrencies, too, just like they do coins or paper money. At least one country (El Salvador) has adopted Bitcoin as its legal tender, and many countries are expected to create fiat cryptocurrencies in the near future. Some governments have banned private cryptocurrencies (like China), but even in the case of China, some expect a fiat currency to eventually replace the banned community currencies.

Also, not all blockchains are created for cryptocurrencies. Blockchains have many applications other than currency transactions. NFTs, for example, are managed on blockchains. Blockchains can be used for secure records of real estate deeds or voting in elections.

So, in sum, Bitcoin is a cryptocurrency, managed on a blockchain and not a fiat currency. But:

  • Currency is a generally accepted unit of value.
  • All cryptocurrencies are managed on blockchains, but not all blockchains are for cryptocurrencies.
  • There are many cryptocurrencies other than Bitcoin.
  • Not all cryptocurrencies are community currencies. They can be fiat currencies as well.

What is Mining?

This section discusses verification of new blocks for Bitcoin. Bitcoin uses a proof of work system to verify transactions. (Others, like Ether 2.0, use a proof of stake system.)

You have probably read that mining requires a lot of computing time and energy, but what exactly are those computers doing?

At a high level, Bitcoin miners compete to verify new transactions on the blockchain. The miner to first successfully verify a block wins a reward for doing the work. The reward is currently a fraction of a Bitcoin (and by design, will decrease over time until there is no remaining incentive). Currently, the reward for verifying a transaction is 6.25 bitcoins–which as of January 2022 was worth more than $260,000. Miners also earn transactions fees based on the size and content of the transactions.

But verifying takes a lot of work–though this is where the metaphor starts to wobble, because it is computer work, not work by people with picks and shovels. Because Bitcoin mining requires intensive computing work, that work is not sensible to do via your average desktop computer. You could mine on your home computer if you wanted to try, and used the right software (for example the open source CGMiner), but you would probably not win any Bitcoin, because another miner with faster equipment would likely win the competition instead of you. Also, your electricity cost would probably be greater than your yield. So, professional Bitcoin miners use special hardware, such as Graphics Processing Units (GPUs). A GPU is a kind of computer chip that was designed to process graphics, mainly for video gaming. But because of their fast processing power, they are now popular for number-crunching applications like AI and Bitcoin mining. At this point, due to the expense of mining, many miners work in pools, and split the proceeds.

How Does Mining Work?

Bitcoin miners compete to do the proof of work to verify each new block on the chain.

The bitcoin system resets the level of difficulty — how hard it is to verify a block–after each 2016 blocks, which happens about every two weeks. The system is designed so that a new block is expected to be created about every 10 minutes, but that is just an average target. Sometimes blocks are found more quickly, and sometimes less quickly, depending on how lucky the miners are. The current difficulty setting, and time to the next calculation, can be found here. (Difficulty is expressed in a format where the first two are the exponent and the next six hexadecimal digits are the coefficient.) Every full node re-calculates difficulty automatically and independently.

The puzzle Bitcoin miners are trying to solve, in order to win their reward, is to generate a number called a nonce that produces a hash within the difficulty tolerance set by the blockchain system. Nonce is an abbreviation for “number only used once.” A nonce is a 4-byte number. It is one of the inputs for the hash.

The most important quality of a hash algorithm is that if you use identical input, you will always get identical output. So, you can easily check to see if the input is the same input you expected, but you can’t tell from the hash what the input actually is. The fingerprint analogy holds up here — you can verify the identity of a person with a fingerprint, but fingerprints don’t tell you what the person is like; it’s an identity, not a blueprint.

File:Hash function.jpg
https://commons.wikimedia.org/wiki/File:Hash_function.jpg

The Bitcoin hash is done using a variant of the SHA-2 (Secure Hash Algorithm 2), developed by the National Security Agency (NSA). This kind of hash takes in data of any length, and spits out a 256-bit (32 bytes) hash value, which is usually represented as a hexadecimal (base 16) number of 64 digits. The SHA-2 family of algorithms are patented in US patent 6829355. The United States has released the patent under a royalty-free license. If you want to see how the algorithm works, take a look at the patent disclosure. It is a complex mathematical formula, but the algorithm isn’t secret. This is what most articles and blogs mean when they refer to “math puzzles” or “complex algorithms.”

And no matter how long your input is–one character or thousands–the resulting hash using SHA-2 will be 64 characters. Also, the SHA-256 algorithm is designed to produce output that will appear to be a random sequence. So, the only way to get the specific hash for specific input data is to perform the hash.

The implication is that the fastest solution to create a hash within the difficulty level is “brute-force,” or trying solutions at random. The SHA-256 algorithm cannot be reverse engineered. So brute force is what miners do. They make their computers generate and test as many different hashes as fast as possible, until they find a value that fits the difficulty target.

When Bitcoin miners compete to verify a new block, they use the following as input to create their hashes:

  • The new blocks on the blockchain for the 10 minute period to be verified
  • The hash for the previous block (which has already been verified)
  • The nonce, which is generated randomly

The puzzle is solved when the resulting hash value is less than or equal to the current difficulty target value. If a nonce doesn’t work to create a hash that meets that condition, the miner moves on to the next nonce–that’s why the nonce is only used once.

Professional miners submit thousands of hashes to the system per second. The more hashes they can submit in the 10-minute time period, the more likely they will win the reward. That means the miners with faster computers win more often.

The winner of the mining contest then updates the blockchain ledger by adding a newly mined block covering all of the newly verified transactions to the chain. The winning miner claims the block mining reward by adding it as a transaction on the new block. This reward come from new coins, whereas all of the other verified transactions on the block come from existing coins.

The system then moves on to the next block to be verified. This happens about every 10 minutes.

How is the Blockchain Validated?

Blockchain works because of three concepts: mining (scarcity), validation, and trust.

Validation is not the same as mining. Validation of the chain happens at two checkpoints. First, on input: when someone wants to makes a transaction on the blockchain, the transaction is sent to a node. Remember that the blockchain is stored on many independent nodes, and these nodes communicate with each other in a distributed network. So, when a transaction is sent to one node, that node shares the transaction with other nodes connected to it on the network. Those nodes, in turn, populate the transaction to other nodes in the network, until the entire network includes the same transactions.

A node validates the transaction to ensure it is in the proper form and adds the transaction to a transaction pool, which is like a clearing house where transactions await mining of the block that will include them. The pending transactions become part of a candidate block. Miners can choose to construct and mine a candidate block for some or all of the transactions in the pool, but the more they include, the higher their reward will be. (The way transactions are chosen to be included in candidate blocks depends on their age, size, priority and other factors, explained in the above link.)

When the mining proof of work has been completed, the winning miner transmits the new block to other nodes on the network. Each node validates the new block to ensure it is in the correct form, and that the winner produced a hash with the proper difficulty, and then adds it to the chain. The new block is then populated throughout the network.

Why is the Blockchain Trusted?

You may be wondering, at this point, what is the point of all this trouble. Mining via proof of work is not the same as trust–it is an incentive for maintaining the chain. It also creates scarcity for new coins. In other words, proof of work is an arbitrary task that is designed to be difficult to perform. This means new coins, created via mining, will enter the system at a regular rate.

But the proof of work, and the Bitcoin reward for doing it, is also an incentive for nodes to maintain the chain. Every mining node must maintain an entire copy of the chain. And because the reward for mining is in Bitcoin, the miners have an incentive to maintain the integrity of the chain. If the chain fails, their rewards will have no value.

How do all the nodes trust the new block? They trust it because it would be virtually impossible to mine a new block without doing the proof of work. While mining is hard, validating the mining is relatively trivial. The proof of work is how miners know they’ve spent enormous resources and reached consensus on a particular sequence of blocks, and are worthy of the reward they got.

The proof-of-work process has two important consequences. The first is consensus: all nodes in the decentalized network can easily agree on which blocks are valid, via their hash. The second is immutability: due to transparency, it is virtually impossible to fool an honestly run node into accepting any blockchain but the true one.

You may have read that blockchains are vulnerable to 51% attacks, which could happen if one party, or group of collaborating parties, control 51% of hash power of the chain. This kind of attack can lead to something called double spending, and other problems. But even if that occurred, anyone could identify the false transactions, and the price of Bitcoin would probably immediately plummet. For cryptocurrencies like Bitcoin, transparency is a deterrent to malfeasance, holding the purchasing power of Bitcoin as collateral for the integrity of the ledger.

In sum:

  • Transparency is why the blockchain is trusted.
  • Transparency and proof-of-work create the incentives to maintain a legitimate chain.

Long-Term Viability of Bitcoin

You have certainly read in the news that Bitcoin mining uses huge amounts of energy, and is therefore ecologically unsustainable. But there are other reasons why Bitcoin faces sustainability challenges.

Because the total number of coins is limited, the incentives to mine will eventually dwindle. As the difficulty gets harder and the rewards lower, only an astronomical and sustained increase in speculative value would provide enough incentive to mine. So it’s likely that, eventually, that incentive will fail. When the mining incentive fails, the incentive to maintain the chain may also fail, and transactions will likely become too slow to be of use.

Also, in practice, Bitcoin has become less decentralized than it appears. At this point, a small number of mining cooperatives do most of the mining. The top 0.1% (about 50 miners) control nearly 50% of mining capacity. Control of the blockchain is in effect becoming centralized, and that centralized control is not transparent. As difficulty increases, this centralization will likely continue. This does not necessarily mean that the chain is likely to be corrupted, but it does tarnish the ideal of Bitcoin as a currency run by a community.

Also, the original lure of anonymous trading is waning. Anonymity has made Bitcoin notorious for illegal activity like ransomware and drug trades. As illustrated by the FBI’s recent seizure of Bitcoins, pseudonymous trading is not a failsafe to achieve true anonymity. As a pseudonym “becomes enmeshed in the public web of transactions, maintaining anonymity takes more operational security than most users can manage.”

Adding all this up, Bitcoin is likely to lose utility and value over time. In other words, the design is not truly scalable or sustainable. Perhaps owning Bitcoin will become, over time, more like owning rare coins than owning currency. But when that happens to Bitcoin, there will be many other cryptocurrencies standing ready to take its place.

In sum:

  • Bitcoin has a lifespan, and unlike traditional fiat currencies, that lifespan is designed to be finite.

Do You Want to Know More?

I hope this article has helped you understand more about crypto and blockchain. If you have suggestions or corrections, please contact me.

If you want to know more, here are some of the best resources I found when researching this topic:

  • Coinbase’s Crypto Basics.
  • The Federalist Society’s video on Bitcoin mining and on Bitcoin in monetary policy .
  • Here is an example of a block, showing the nonce, the transactions it covers, and other details.
  • Patrick Boyle’s video on legal tender and private money. I highly recommend Boyle’s videos on finance and economic topics.
  • O’Reilly’s Mining and Consensus. This contains a wealth of detail about how validation and mining work.
  • David Rosenthal presentation on the future of cryptocurrency. This presentation is very detailed, but extremely insightful on the sustainability of Bitcoin and other non-permissioned blockchains.
  • Is blockchain “open source”? Not exactly, although all blockchains use open source software elements. (That link goes to an article on this topic that I co-wrote a few years ago on this topic, when everyone seemed to be asking me this question.)

Twelve Months of Open Source in 2021

With year two of the COVID era drawing to a close, here is a look back on some of the most interesting open source developments of 2021. Let’s hope the new Omicron wave of working from home creates some amazing new projects — and ends soon.

  • January – Open source developer and open standards advocate David Recordon is named the White House Director of Technology by the transition team of incoming President Joe Biden.
  • February – Mars becomes the second planet on which Linux is the dominant operating system.
  • March – The community wars on with no resolution over the role of Richard Stallman in the FSF and GNU projects. Stallman was expected to resign over his comments about the Jeffrey Epstein scandal, but later refused to step down. Several members of the executive team resign in protest. The credibility of FSF is eroding.
  • April – Google wins its epic battle with Oracle over copyright and APIs in the US Supreme Court, and software developers everywhere breathe a sigh of relief. Because without free rights of re-implementation, many open source projects could probably not exist.
  • May – The US Government issues an executive order recognizing the importance of the software supply chain to national security and prosperity. It implies an endorsement of open source development: “The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors.”
  • JuneA Huawei dev is shamed for useless Linux contributions he submitted to meet a work performance goal. It’s telling that open source contributions have become part of corporate performance assessment. This happens on the heels of the scandal over University of Minnesota students intentionally submitting faulty patches to Linux for a research project.
  • July – Weirdness follows the Audacity handover, when two forked projects, created in a froth of overreaction to the transfer of the project to Muse, start warring with each other, and bad behavior ensues.
  • August – Sexy Cyborg, a YouTube influencer, metes out her own style of GPL Enforcement. This video shows her shaming a large corporation about GPL violations. Don’t let the scanty clothes fool you; she’s a savvy tech commentator.
  • September – Oracle adjusts licensing for OracleJDK, allowing limited free use, and tweaking the licensing differential between OracleJDK and OpenJDK (and the community-supported fork of OpenJDK stewarded by the Eclipse project). The new license for OracleJDK now allows free internal use, including for developing and testing applications, and distribution “provided that You do not charge Your licensees any fees associated with such distribution or use of the Program, including, without limitation, fees for products that include or are bundled with a copy of the Program or for services that involve the use of the distributed Program.” For most companies, this only kicks the can down the road on the decision to use OpenJDK, or pay the piper.
  • October – SFC sues Vizio for GPL Violations, in a lawsuit that attempts to rewrite the rules of open source enforcement, by initiating a non-copyright claim in state court without the participation of the software authors.
  • November – Trump’s Truth Social, having run afoul of AGPL before it even launched, tries to fix the license violation, but seems unclear on the concept.
  • DecemberLOG4J is involved in a major security breach. Open source software security breaches always get a lot of press, out of proportion to proprietary software security issues–which doesn’t mean to say they aren’t a danger. The real problem, of course, is lack of a sustainable model to keep the open source software updated and secure.
  • All Year – Commercial Open Source Software continues to be awesome. Just a few examples of companies that are prospering and moving forward: Redis, Grafana, Starburst. For a rundown of the big deals, check out the ongoing news about financings, acquisitions and IPOs at COSS Community.

Happy New Year, everyone!

Open Source Compliance for SaaS Vendors

After a few inquiries about this topic, I thought I would share some suggestions for best practices for SaaS vendors. Open source compliance for SaaS vendors is not difficult, but there are a few important nuances to keep in mind.

As a baseline, SaaS is not a high-risk business model for open source compliance. That is because most open source licenses do not have any conditions for SaaS server-side use. Generally, running software that powers a SaaS offering is not distribution, and most compliance conditions in open source licenses are triggered by distribution. (For more on that topic, see here.)

But that doesn’t mean SaaS vendors can simply abdicate responsibility for open source compliance processes. Here are a few reasons why SaaS vendors need to pay attention to open source compliance.

Client Side Software

While most software in a SaaS platform runs on the vendor’s servers, some software always runs on the user’s computer. This is sometimes called “client-side” software, because it runs on the client computer (the user’s computer) instead of the server computer. This software is pushed out to the client computer by the server, but it actually executes locally.

The best way to understand this is to look at the software. If you are using the Chrome Browser, for example, you can press Control-U or right click and chose “view page source.” There, you will see a lot of software code. Right now, as I am writing this in WordPress, the code for this authoring page is about 3,000 lines. But most of the software enabling me to write my blog is running on the WordPress.com server.

Client side code is particularly helpful for tasks like validating an entry in a form (such as a date or address) or executing simple logic on a web page (such as asking for more data if the user gives certain answers to questions). These small tasks need not ping the server and slow down processing.

One interesting thing about this client code is that it is almost always “high level” code or “scripting language” code delivered in source code format. Mostly, it consists of HTML (the scripting language for web pages), Javascript (a procedural language particularly useful for web pages) and CSS (a formatting language for web pages).

The great thing about scripting code is that it is already in source code form, so even if it is provided under a copyleft license like LGPL,(1) there is usually no need to offer additional source code.

The hidden issue, however, is that programmers usually strip licensing notices out of HTML/CSS/Javascript before sending it to the client device. That is done so the page will load faster.

So, the challenge is how to deliver notices for that code. Keep in mind that whenever you distribute software under a copyleft license like LGPL, you must not only make source code available, but you must also deliver a copy of the license. So the question is: where do you put those notices? That can be a head scratcher. One approach is to include, on the dashboard for your SaaS system, a page with the notices and links to the licenses.

But is that compliant? Clearly, most open source licenses were not written for client code. So it can be unclear where to place the notices in order to comply with the license terms. In fact, most open source notice provisions were written long before the advent of the web, and they assume that notices will be delivered in an installation folder — which only works for software in standard computing environments like Linux or Windows.

For example, the license notice requirement for LGPL 2.1 says you must “distribute a copy of this License along with the Library” and MIT requires that “this permission notice shall be included in all copies or substantial portions of the Software.” So, it seems at least plausible that notices on a separate web page are sufficient, but every license has its own language to describe where notices must be delivered.

One more nuance here: Programmers also often modify client side code in production environments to strip out “white space.” So, for example:

<script id=’wp-media-utils-js-translations’>
( function( domain, translations ) {
var localeData = translations.locale_data[ domain ] || translations.locale_data.messages;
localeData[“”].domain = domain;
wp.i18n.setLocaleData( localeData, domain );
} )( “default”, { “locale_data”: { “messages”: { “”: {} } } } );
</script>

Would become the far less readable:

<scriptid=’wp-media-utils-js-translations’>(function(domain,translations){varlocaleData=translations.locale_data[domain]||translations.locale_data.messages;localeData[“”].domain=domain;wp.i18n.setLocaleData(localeData,domain);})(“default”,{“locale_data”:{“messages”:{“”:{}}}});</script>

But when you right click and view the code, or when you view it in nearly any development tool, the tool automatically inserts white space for readability. So this is generally not considered a compliance problem. The user has perfectly feasible access to the software in the “the preferred form of the work for making modifications,” which is what LGPL requires. (See definition of Source Code here.)

Network Copyleft and Similar Licenses

Another potential issue for open source compliance in SaaS is network copyleft licenses. A handful of licenses still have compliance conditions in the absence of distribution. This issue applies to server-side code. The most common of these licenses is AGPL, which says:

“13. Remote Network Interaction…if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.”

AGPL Section 13, sometimes called the “Network Copyleft” provision

This means that if you use the software in such a way that a user can interact with it over a network, and you modify the software, you must make your modified source code available. In a way, this treats SaaS similar to distribution under GPL. And while there are still no source code sharing conditions if you don’t modify the software, it can be hard to keep track and trigger a new compliance review if the software is modified in the future. So most companies are extremely hesitant about using AGPL software in a SaaS platform.

AGPL is not the only network open source license out there, only the most common. Some others, for example are:

  • Server Side Public License
  • Open Software License
  • Non-Profit Open Source License
  • Artistic 2.0
  • Apple Public Source License
  • RealNetworks Public Source License
  • Reciprocal Public License
  • Honest Public License
  • Academic Free License [Note: this license is permissive. The others are copyleft.]

Most of these licenses are rarely used, and when they are, some — notably Artistic 2.0 — are dual licensed under GPL, meaning their network requirements are easy to avoid.

Most companies that have open source compliance policies “red light” these licenses and will not use them in SaaS development. So that means, at a minimum, you must still keep track of license terms and apply your compliance polices to SaaS software.

Distribution is Inevitable

Finally, an important reason to keep an eye on open source compliance, for server side code in a SaaS platform, is that SaaS code almost always gets distributed–someday. While the thrust of software sales today is toward cloud deployment, there are many reasons the deployment of software regresses to on-premises distribution. For example:

  • Your company sells off the division that sells the SaaS.
  • Your customer requires a local copy on its own server:
    • Due to regulatory requirements (e.g. in highly regulated businesses like finance or health)
    • Because of security concerns
    • To avoid privacy issues arising from cross-border data movement
    • Because AWS does not maintain a local hub
  • Your company productizes an internal SaaS tool.

…and so forth.

Because any of these things could happen, you should ensure that you can distribute the software in a compliant manner, when you need to. So, you should avoid integrating GPL (or AGPL) and proprietary code in a way that could not be distributed in compliance with the open source license. This, in turn, means avoiding the use of GPL libraries (like MySQL)–or at least having a replacement at hand.

No Customer Risk

One question that sometimes comes up in commercial negotiations for SaaS vendors is whether a customer of a SaaS vendor can be “infected” by open source code. In short, the answer is no.

A pure end user of code cannot incur liability for violating an open source license. Open source licenses can be violated only by re-distributing software — or in the case of network licenses like AGPL, by modifying it and making it available to others as a service. In fact, GPL2 specifically says “Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted.”

In contrast, if the vendor is distributing software to a customer for the customer to provide its own SaaS to others, customary open source diligence is appropriate. But this isn’t a SaaS deal, of course. It’s a distribution deal.

So, end user customers of SaaS need not conduct diligence into open source licensing issues. If, for example, the SaaS vendor is using modified AGPL code to provide its service to the customer, then the customer may have a right to receive source code from the vendor. But that is a benefit, not a problem. In other words, the purpose of due diligence is to reduce the user’s risk, so even AGPL is not the user’s issue.

An update: take a look at Kyle Mitchell’s follow up on this post. Client side Javascript code doesn’t have a binary form, exactly, but when deployed in actual practice, it is not exactly source code, either. It can take intermediate forms that would not be considered source code, for purposes of licenses like GPL. Point your engineers to that post!

SFC Files GPL Enforcement Suit Against Vizio Advancing Novel Legal Theories

Software Freedom Conservancy filed a lawsuit in late October 2021 against Vizio, claiming violation of the GPL and LGPL with respect to its SmartCast TVs. The complaint is here. The complaint is styled first as a claim of breach of contract, and then a claim for declaratory relief.

Lawsuits to enforce GPL are still quite rare, and among them, this one is radically different in its legal structure from those that have come before. In fact, it conflicts with much of the conventional wisdom about enforcement of licenses like GPL, even principles previously enunciated by the Software Freedom Law Center and the Free Software Foundation–who have had their disagreements with Software Freedom Conservancy in the past.

Some of the novel legal arguments include:

  • Breach of Contract and Specific Performance. In the past, almost all community enforcement of GPL has been pled as a claim for copyright infringement. This complaint asks for an order for Vizio to release the source code for the product, which is the main license condition of GPL and LGPL. However, compelling a defendant to comply with a license condition is not a remedy under copyright law. In contract law, any claim for relief other than money damages is a request for specific performance–which is a very rare remedy in contract law.
  • Claim Brought in State Court. As a corollary, almost all claims to enforce GPL in the past have been brought in federal court, which has exclusive jurisdiction over copyright claims in the US. The complaint was filed in Orange County, California. State court lawsuits yield less predictable and consistent outcomes than federal courts–and perhaps more likely to take an unexpected view of novel legal theories.
  • No Author as Plaintiff. The complaint is brought on behalf of SFC as a plaintiff, based on its purchase of Vizio TVs. This is the opposite of past enforcement actions, brought by the copyright owners (and authors) of GPL software. The complaint cites a huge list of GPL code, including the entire Linux kernel, Busybox, coreutils, BASH, and others. None of the authors of these software packages is named as a plaintiff in the suit.
  • Focus on Consumer Electronics. This is no a surprise, but it is worth noting. Consumer electronics have always been the highest risk sector for GPL enforcement. The SFC press release regarding the case emphasizes consumer rights, touching upon allegations of planned obsolescence and the environmental impact of having to replace devices instead of updating them. SFC had previously announced its intention to use its new funding to focus on embedded software and IoT.
  • Declaratory Relief. The request for declaratory relief asks the court, essentially, to declare that the GPL and LGPL are enforceable and have been violated by Vizio. Even if GPL were deemed a contract, it would be a contract between the licensor (i.e. code copyright owner) and the licensee, so SFC appears to be suing based on a theory that it–and everyone–is a third party beneficiary of the contract. This theory is extremely novel. Given the code authors are not parties, this is an end run around the standing requirements for copyright claims.

In sum, the complaint is an effort to re-write the rules of GPL enforcement. While many commentators are hailing it as a boon for free software, it could backfire. Most companies who have adopted GPL software for their products over the last 25 years have done so based on the comfort that enforcement is mostly done informally, and by authors–and that injunctive relief forcing the release of source code has never been ordered as a remedy. This comfort took many years to develop. During the 1990s and 2000s, many companies adopted GPL software with great hesitation, due to fears about the possibility of such remedies. At that time, these fears were mostly fueled by FUD promulgated by anti-GPL companies like Microsoft. But if this new means of enforcement is successful, the fear may re-ignite, and adopters may react by moving away from open source software.

Also, if any member of the public can enforce the GPL, there is a potential for multiple and conflicting lawsuits for each alleged violation–including trolls who do not have the interests of the community at heart, and–as in this case–organizations who do not necessarily have the support of the authors of the software.

At this early stage the result is hard to predict, but it seems unlikely that SFC will be able to succeed on such a great number of novel legal theories. Such a case could be complex, long and expensive. Also, most GPL enforcement claims do not result in substantial litigation, and are settled quickly– often just after the initial complaint. But if not, this lawsuit has the potential of making some very unprecedented law, and substantially disrupting expectations about GPL enforcement.

An update: Vizio moved on November 29, 2021 to remove the case to federal court, alleging preemption. SFC issued an outraged blog post. Neither is remotely surprising.

And I cannot help observing something about this statement from the SFC:

We believe in complete transparency of the copyleft compliance process, and so encourage everyone to read the filings. We’ve even paid the Pacer fees and used the Recap browser plugin, so that all the documents in the case are freely available via the Recap project archives.

According to my calculations, the PACER fees for that document for SFC are somewhere between zero and 80 cents. Here is more about PACER fees and how RECAP (which is very cool) works.