Can someone patent your open hardware design?

This note is general information about how patents interact with open hardware. It is not legal advice, and patent law differs from country to country.

People who publish hardware ask this question a lot, usually after seeing a crowdfunding page for something that looks a lot like their board. The good news is that publishing does real work for you. The less comfortable part is that it only protects what you actually published, and only if someone checks.

What makes a published design prior art?

A design becomes prior art when it was publicly available before a patent application's filing date and disclosed the invention clearly enough for a skilled person to reproduce it.

Patent systems only grant rights to things that are new. In the United States, 35 U.S.C. 102 treats anything "described in a printed publication" or "otherwise available to the public" before the effective filing date as prior art. The European Patent Convention has a similar rule in Article 54: anything made available to the public before the filing date is part of the state of the art.

A tagged release on a public repository, a project page with schematics, or a build guide on a blog can all qualify. Three things decide how useful it is:

1. A provable date. Commit history helps, but a tagged release, an archive snapshot or a published PDF is easier to show to someone outside your project.
2. Real detail. A photo of a finished device shows much less than a schematic, a board layout and a bill of materials.
3. Public access. Files that sit behind a login or in a private repository may not count.

So can someone patent a copy of your board?

Not validly, if your earlier release discloses exactly what they claim.

The weak word in that sentence is "validly." Patent examiners search patent databases and journals first. Hardware repositories and maker forums are harder to search, so an examiner may never see your files, and a patent can be granted that should not have been.

A granted patent is presumed valid until someone challenges it. In the US that can mean post-grant procedures at the Patent Trial and Appeal Board; in Europe it can mean an opposition at the EPO within nine months of grant. Both cost money and time. Your release still matters, because it is the evidence, but it does not remove a bad patent on its own.

Which parts of your project are still open to patents?

Anything you did not disclose, and any genuine improvement on what you did disclose, can still be patented by someone else.

This catches people out. Suppose you publish a motor controller and someone else works out a new way to cool it. If your files never showed that cooling method, it is new, and they may be able to patent it. The same goes for:

• a new use of your device in a field you never mentioned,
• a manufacturing process you used but never wrote down,
• a firmware algorithm you shipped as a binary only,
• a combination of your design with another product.

The practical fix is boring: document more. Publish the source for firmware, explain the processes you rely on, and describe the variations you tried. The Open Source Hardware Definition asks for design files in the preferred format for making changes. That rule exists so others can build on your work, and it also gives your work stronger value as prior art. Our guide to publishing an open hardware project covers what to put in the repository.

Does publishing first cost you your own patent?

In most of the world, yes; in the United States, you get a one-year grace period after your own disclosure.

Under 35 U.S.C. 102(b)(1), a disclosure made by the inventor one year or less before the effective filing date does not count as prior art against that inventor. Europe works differently. The EPC requires absolute novelty, so if you publish before filing, your own publication can block your European patent.

Many open hardware projects never want a patent, so this rarely matters. It matters when a university, an employer or an investor is involved and expects to file. Ask before you push the first public commit, because the order cannot be undone.

Do open hardware licenses deal with patents?

Some do: the CERN-OHL v2 family includes a patent license from each licensor covering their contribution, while Creative Commons licenses expressly exclude patent rights.

Patent terms in a license work between the people who share the design. If a contributor holds a patent on part of what they contributed, a patent clause stops them from suing people who use that contribution under the license. It does nothing against a stranger who files a patent and never touched your files.

If patents are a concern for your project, that is one more reason to prefer a hardware license over a documentation license. The license comparison lists which licenses mention patents, and the license chooser takes about a minute.

What can you do to make your release harder to patent around?

Make each release public, dated, detailed and easy to find.

1. Tag releases and attach the production files and a PDF of the schematic.
2. Write a README that explains how the design works, with the important choices spelled out in words.
3. Describe alternatives you considered. A sentence such as "the same circuit also works with a 3.3 V regulator" discloses that variant too.
4. Keep firmware source in the same repository as the hardware.
5. Archive important releases somewhere independent of your hosting platform.

Some projects go further and publish a short technical write-up of each new idea, a practice often called defensive publication. It costs an afternoon and gives a clear, dated description an examiner or lawyer can point to.