Five IP Mistakes That Derail Technology Start-ups Before Series A

Series A due diligence for technology companies has become significantly more rigorous over the past five years. Investors who once accepted founder assurances about IP ownership and freedom-to-operate (FTO) now engage specialized counsel to audit the entire IP chain of title before closing. What they find, with surprising regularity, is a set of recurring problems that are cheap to prevent and expensive to fix.

These are the five mistakes I see most often — and most consistently — in the embedded systems and software companies that come to guibert.law for pre-fundraising legal preparation.

Mistake 1: No IP Assignment Agreements with Founders and Early Engineers

The most fundamental IP mistake, and the most common. In the early days of a technology company, the founding team is typically a small group of engineers who trust each other completely. Formal legal agreements feel unnecessary and even insulting. So the code gets written, the firmware gets developed, the patents get filed — and none of the engineers sign an IP assignment agreement.

By the time Series A arrives, those engineers may have moved on, had a falling out, or simply be unreachable. The company cannot demonstrate a clean chain of title from inventor to company, which means the company cannot demonstrate that it actually owns its core technology. Investors will not close on a company with cloudy IP title.

The fix is simple and inexpensive at formation: every founder, employee, and contractor signs a Confidential Information and Invention Assignment Agreement (CIIAA) before contributing any work. The agreement should specifically address pre-existing inventions the individual wants to exclude — which is a legitimate carve-out — but it must be executed before the work begins, not after.

Mistake 2: Open-Source License Contamination

Embedded systems products typically depend on open-source components: an Real-Time Operating System (RTOS) kernel, a TCP/IP stack, a cryptographic library, a bootloader. Most engineers are aware that open-source licenses impose conditions. Fewer are aware of the specific conditions imposed by copyleft licenses like the GNU General Public License (GPL) and GNU Lesser General Public License (LGPL) — particularly in the context of firmware that will be distributed in a commercial product.

The GPL's copyleft provision requires that if you distribute a binary that incorporates GPL-licensed code, you must make the source code of the entire combined work available under the GPL. For a company whose competitive advantage is its firmware, this can mean a legal obligation to open-source the crown jewels. LGPL imposes similar requirements unless the licensed library is properly isolated through dynamic linking or equivalent mechanisms — which are more difficult to achieve in resource-constrained embedded environments than in desktop software.

By Series A, investors will conduct an open-source audit. Undisclosed GPL contamination in a product's firmware stack is a material finding that can require a complete re-architecture of the software — which is expensive, time-consuming, and sometimes impossible without delaying the product roadmap.

The fix: conduct a Software Bill of Materials (SBOM) dependency audit before you ship a single unit. Identify every open-source component and its license. Evaluate every copyleft-licensed component for license compatibility with your commercial distribution model. Where conflicts exist, either find a permissively licensed alternative (Massachusetts Institute of Technology License (MIT), Berkeley Software Distribution (BSD), Apache License 2.0) or structure your architecture to legally isolate the copyleft components.

Mistake 3: Misidentifying Inventors on Patent Applications

U.S. patent law requires that patent applications name the actual inventors — the natural persons who conceived the claimed invention. Inventorship is not about employment, equity ownership, or contribution to the project. It is about who conceived the specific technical ideas that form the basis of the claims.

In a collaborative embedded systems team, inventorship is often genuinely difficult to determine. The system architect may have defined the overall approach, but the firmware engineer who figured out the specific timing scheme that made it work may be the actual inventor of the patented claim element. Listing the CEO as an inventor because he is the CEO, or excluding a contractor who left the company because the relationship ended badly, is inventorship fraud — and it can invalidate the patent.

The fix is to involve counsel in inventorship determination before the patent application is filed, conduct proper inventor interviews, and document the inventorship analysis. It is also worth noting that a correctable inventorship error — one without deceptive intent — can usually be fixed. An inventorship error that was knowing and intentional is much harder to recover from.

Mistake 4: No Freedom-to-Operate Analysis Before Product Launch

An engineering team can build a genuinely novel product that nonetheless infringes existing patents. Patent claims cover specific technical implementations, and the claim scope of a patent is often broader than the title or abstract suggests. An embedded systems company that launches a product without a freedom-to-operate (FTO) analysis may be walking into a patent assertion campaign from a competitor or a non-practicing entity.

FTO analysis is not inexpensive, and it is not perfectly reliable — you cannot identify every relevant patent in every jurisdiction. But a targeted FTO analysis focused on the specific technical novel elements of your product, conducted before product launch, gives you three things: identification of patents you need to design around, identification of licenses you may need to obtain, and a documented good-faith effort that is relevant to the willfulness analysis if you are ever accused of infringement.

Series A investors increasingly require evidence of FTO analysis as part of their IP diligence. The absence of any FTO work product suggests the team was not thinking seriously about IP risk.

Mistake 5: Treating Trade Secrets as an Informal Concept

Trade secret protection is not automatic. It requires that the information be subject to "reasonable measures" to maintain its secrecy. Courts evaluate the existence of trade secret protection by looking at the practical security measures the company actually implemented: Who had access to the information? Were confidentiality agreements in place? Were access controls implemented? Were departing employees reminded of their obligations? Was the information marked as confidential?

Technology companies — especially early-stage ones — often treat their confidential information informally. Code repositories may be accessible to every employee regardless of need. Customer lists and technical specifications may be shared over personal email. Departing engineers may leave with full copies of the codebase on personal devices.

When a competitor hires one of those engineers and launches a suspiciously similar product six months later, the trade secret litigation outcome depends heavily on whether the company can demonstrate it treated the information as a trade secret before the misappropriation — not after.

---

Attorney advertising. The information in this post is provided for general informational purposes and does not constitute legal advice. Prior results do not guarantee a similar outcome. © 2026 guibert.law