Polkadot patent scope: Crates


This is not a thread to solicit objections to, or complaints about this patent. I am a supporter of patent systems in general, and the idea of software patents in particular. Of course patent systems can be improved - this is not about those issues.


Is there any authoritative (binding) guidance on the scope of the Polkadot patent, expressed in terms of rust crates. Specifically:

I’m not sure of the correct or best way to frame the questions/issues. Here are some attempts to frame this in the form of questions:

  • Which crates are considered to contain elements of an embodiment of the elements/parts of the patent?
  • Which crates would open the door to patent holder(s) being able to make an infringement claim?
  • In terms of the Rust crates, what constitutes use of the patent?

Of course, not using any of the aforementioned crates would not immunize/indemnify you from an infringement claim.
You do have to study the patent to ensure your code does not implement ideas that infringe on the rights of the patent holders.

However, it can be useful to have and unambiguous statement that certain crates do not contain elements of an embodiment of the patent.
It would also be useful to know if certain use cases are considered out of scope of the patent, e.g. any permissioned/permissionless chain use case is in-scope/out-of-scope, etc.

The Polkadot patent


The following are threads that are likely relevant to topics or questions that could be construed as related to, but off-topic in, this thread. Please consider posting in one of these:

Apache 2.0 was chosen for Substrate’s FRAME because it is a permissive open source license which allows people to build commercial, for-profit products with it, while keeping their source code and other intellectual property private and patented.

A community member suggested in a DM that the patent might be purely defensive in nature. I’m skeptical for the following reasons:

  1. This page explicitly cites the patent, and there is no suggestion that the rights were sought for defensive reasons:
    Polkadot Consensus Part 1: Enhanced Economic Security via NPoS
  2. There is the Google Open Patent Non-Assertion Pledge model (creative commons licensed), and that has not been adopted. IIUC this would still allow for some patent rights to be asserted, but it would potentially clarify some use cases:
    Open Patent Non-Assertion Pledge - Google
  3. There is the Crypto Open Patent Alliance, and that has not been joined. This too would appear allow for some patent rights to be asserted, but it would potentially clarify some use cases. There are mentions of an Exhibit C, which is absent from the online PDF I was able to find, so this is a little murky:

Has anyone launched a DOT alternative, say using NPoS, built on Substrate, and seen no objection from Parity?
That would seem to be the purest test of the patent position of Parity.

1 Like

I do not speak for Parity, and IANAL, but one agument for defensiveness would be:

  1. “The European Patent Convention (EPC), Article 52, paragraph 2, excludes from patentability … programs for computers”. Asian nations have “interesting” views on software patents of course.
  2. “Patents are territorial rights. In general, the exclusive rights are only applicable in the country or region in which a patent has been filed and granted, in accordance with the law of that country or region.” (WIPO)

I’d naievely think US blockchain patents should only pertain to the US market, and so enforcement action should discuss active pursute of the US market, which then invites the US SEC down upon you. Afaik these projects chase away the US market specifically so they do not antagonize the US SEC.