Patent encumbrances on Falcon?

Question

Does anyone have any hard evidence what exactly are the terms and conditions of the patent license that Dr. Whyte / OnBoard Security has pledged to provide to any prospective implementers of the Falcon cryptosystem?

I was only able to find the following IP Statement, which only says that the terms (whatever they are) will be royalty-free and fulfil so-called "RAND" criteria, the Wikipedia page on which cites several articles^[1],[2] arguing that this scheme is *absolutely not* a subset of libre, even when it is royalty-free (gratis). Really, this is a question of whether the Falcon cryptosystem is "open source" at all, or only "source-available freeware"!

I, William Whyte, am the … authorized representative of the owner, OnBoard Security, of the following patent(s) and/or patent application(s): US 7308097 B2 (“Digital signature and authentication method and apparatus”), and do hereby commit and agree to grant to any interested party on a worldwide basis, if the cryptosystem known as Falcon is selected for standardization, in consideration of its evaluation and selection by NIST, a non-exclusive license for the purpose of implementing the standard[,] without compensation and under reasonable terms and conditions that are demonstably free of any unfair discrimination.

I further do hereby commit and agree to license such party on the same basis with respect to any other patent application or patent hereafter granted to me, or owned or controlled by me, that is or may be necessary for the purpose of implementing the standard.

…

–Page 20, NIST Post-Quantum Cryptography Selected Algorithms 2022, Digital Signature Algorithms - Falcon - IP Statements

The above doesn't look like terms or conditions of a patent license to me; it looks like a binding pledge to provide a patent license under under-specified terms and conditions in the event it's selected for standardization (which it actually was). But I can't seem to find the follow-through document actually specifying these T&C anywhere on Google. Even the PQClean LICENSE document for Falcon doesn't have anything less ominous than what I've said so far.

The reference implementation was published by the patent holders under the MIT license, but that license is ambiguous on patent rights, and when I asked the Falcon Project whether this was meant to include an implied patent license, the response I got declined to clarify, citing the vagueness of NIST's direction on the matter.

I want to reiterate that it's not obvious to me that the T&C finally offered in fulfilment of this pledge will necessarily be libre; the only guarantee I can see is they'll be gratis. (The patent license's associated T&C will also be “free of unfair discrimination”—but that's cold comfort if everyone's subjected to the same, subjectively-unreasonable terms!)

Remember: this issue *cannot* just be sidestepped with a clean-room implementation from the public spec, because the threat here is one of patent, not copyright. The patent license terms are something even a clean-room implementation will be subject to, even if the patent license terms ("RAND" though they may be) aren't OSI-approved, for example. Not even an implementation written by Richard Stallman himself would be free of these conditions!

I'm sure it's "probably fine", but this just feels very weird to me and I'd feel much more comfortable if I could actually find the terms of this patent license in writing somewhere.

Answer 1

There is a new digital signature algorithm incorporating a patented method, with a reference implementation released under MIT. The inventor, who has transferred the patent to a holding company of which he is CTO, has undertaken that if the algorithm is selected as a standard, which it since has been, the patent will be generally licensed on "reasonable and non-discriminatory terms", with no licence fee payable, though this has not yet happened.

You want to know if it's currently safe to write your own implementation. You have approached the author and asked, and received a less-than-unambiguously-positive reply.

Previous patents licensed on RAND terms in pursuit of a standardisation process have in some cases required a per-seat licensing fee, so there is definitely nothing in "RAND" that requires licensing on terms that would allow safe embodiment in free software. We can therefore disregard any undertakings to release on RAND terms when considering your question.

You point out that the reference implementation is released under an MIT licence, and that some argue that the language of MIT implies a patent licence. Firstly, that point is not universally accepted. Secondly, it's not at all clear that the legal entity who licensed the copyright in the code is the same legal entity that controlled the relevant patent at the moment of code release (a requirement in order to benefit from both implicit and explicit patent licence clauses in free software licences).

Moreover, some have argued that releasing free software that embodies one (or more) of your own patents not only licences, but extinguishes, those patents, so I imagine that standards-track patent holders are pretty cagey about releasing code that might have the effect of completely destroying a potential business model. (Full disclosure: I wrote that article, but I did not give the talk on which it is based.)

So I think the argument that, right now, you can safely embody that patent in free software is dangerously weak, and I would certainly not rely on it.

Answer 2

I fundamentally believe that this question is off topic here, because it asks for clarification of specific RAND terms of a patent license related to Standard-Essential Patents (SEPs). This is nothing that this community can answer.
But then the discussion around this question moved into the more generic direction, if an OSS developer would be liable for patent infringement merely by developing and publishing source code related to the patented method. This is what I want to discuss below.

Source code does not infringe software patents, because it is just a human-readable step-by-step description of a method/procedure. The patent document itself is also just a description (which b.t.w. is in public domain), and distributing the patent document itself certainly does not constitute patent infringement. In USA, source code might even be protected by the First Amendment.
In order to infringe a software (method) patent, you have to perform the method itself. For that it is necessary to take the source code description, translate it into computer-executable code (my means of a compiler or interpreter) and run it on one or more computer(s) and/or networks, as the case may be.

Imagine Bob is looking for software related to a patent-encumbered encryption method. He downloads a ZIP file made by Alice with some source code, unzips the file to create the entire code structure on his hdd, then inspects the code. He finds that it is not suitable for his purpose and therefore does not run the code. Under the theory that creating and storing patent-encumbered source code on a computer-readable medium constitutes patent infringement, Bob would clearly be infringing the encryption patent without even having encrypted one single byte of data. Do you see, to which absurd situations this thought process leads? (This example is not mine, it is mentioned on several other webpages.)

As long as you are not aware of any patents, the 'non-infringement disclaimer' which is part of most OSS license terms, is a way to protect you from liabilities. One should however not knowingly create source code that implements a patented method. If you look at Global-Tech Appliances v. SEB it shows that -in order to avoid induced infringement- software developers should never search or read patents and should never try to assess if their code is infringing a specific patent. This is what I always recommend. The Debian project also recommends this here under the headline 'Are you suggesting that it is better for developers and contributors not to read patents? If yes, why?'.

Apparently, the OP is aware of some patents, so the above paragraph does no longer help.

If you become aware of patents, which might possibly be infringed by executable software created from your published source code, then an approach like the one of LAME could reduce your risk (see Section 6. of the FAQ). Note: At the time when the patents were valid, many LINUX distros did not include LAME on their CDs/DVDs to avoid risks, however they often included How-To's to help users install it.

In big OSS projects it is often unclear which contributing developer is responsible for a specific part of the software that the patentee might identify as infringing. And the damages, which the patentee can attribute (and possibly recover in court) from such a developer are not worth the effort of going to court and paying the lawyers. Therefore it is unlikely that an individual developer contributing to a big project will face a risk. Unified Patents shows that defendants in OSS cases are mainly big-tech companies.

IANAL and this is not legal advice. And this might be highly dependent on the jurisdiction.