Intellectual Property Lawyers for New Mexico

Here’s how I’d approach structuring an Employee IP Agreement if your goal is to protect your company’s intellectual property without running into enforceability issues under U.S. law. Covering Core IP OwnershipCovering Core IP Ownership First, start with a “work made for hire” clause. It’s a good foundation, but it’s not enough on its own. Under U.S. copyright law (17 U.S.C. § 101), only certain types of work qualify as “made for hire,” and many employee-created assets may fall outside that definition. So you’ll want to pair it with a present-tense assignment clause. Be specific here. Use language like “the employee hereby assigns” rather than “will assign.” That slight shift matters. It ensures the company owns the rights immediately when the work is created. Also, define “intellectual property” broadly. Don’t just list patents or source code. Include software, algorithms, documentation, trade secrets, databases, and anything tied to your business. The scope should clearly include anything created during work hours, using company tools or systems, or connected to your current or future business operations. Disclosure and Documentation You’ll want to require employees to promptly disclose any inventions or creative works they produce. Put it in writing. This gives your company the chance to evaluate whether the work is covered under the agreement. It’s also a good idea to require them to maintain proper documentation. Accurate records can make a real difference in patent filings or if a dispute ever comes up. Pre-Existing IP and Legal Carve-Outs There should be a section where employees list anything they’ve developed or own before joining the company. If they don’t list anything, the agreement should include language confirming they’re representing that no such prior inventions exist. This prevents claims down the road that something developed during employment was actually theirs from before. Now, depending on your state, you may need to include statutory carve-outs. California, Illinois, and Washington all have laws that limit how far IP assignment clauses can go. For example, in California, you’re required to carve out inventions developed entirely on the employee’s own time, without company resources, and unrelated to your business (see California Labor Code § 2870). Without that carve-out, your entire assignment provision could be thrown out. Confidentiality Obligations Make sure there’s a strong confidentiality section. This should cover source code, technical documentation, designs, product plans, customer lists, financial data, and anything else proprietary. Make it clear that the obligation continues even after the employee leaves. You’ll also want to require that all company property and digital assets are returned at the end of employment, including devices, credentials, and files. Ongoing Cooperation and Enforcement Mechanisms Include a clause requiring employees to cooperate in IP protection efforts even after they leave. That could mean signing patent paperwork or providing testimony if needed. To make that enforceable, add a power of attorney clause. This gives the company the authority to act on the employee’s behalf if they’re unwilling or unreachable. It’s a simple way to prevent delays when you’re trying to secure or enforce rights. It’s also smart to include a waiver of moral rights where allowed. This is especially useful for creative works and software. It gives the company full freedom to modify or use the work without needing future approval. Legal Remedies and General Terms Be clear that the company can pursue equitable relief, like an injunction, if there’s a violation. Sometimes monetary damages aren’t enough to prevent harm. Include a severability clause so that if one part of the agreement is invalidated, the rest still stand. Don’t forget to specify the governing law and venue for any disputes. As for restrictive covenants, keep in mind that non-compete clauses are unenforceable in California and heavily restricted elsewhere. Non-solicitation clauses may still be allowed, but they need to be narrowly written. You should have your legal team confirm their enforceability based on your state. Finally, think about consideration. For new hires, the job offer itself usually counts. But for existing employees, you’ll likely need to offer something extra, like a bonus or promotion, to make the agreement stick.

You will need a design patent

Hi. If the Creative Commons License that you mentioned (CC BY-NC 4.0) does not allow for commercial usage, using that content commercially would violate the license. If you tranform the work sufficiently, you could potentially use it without violating the terms of the license.

When you're reviewing a Developer Agreement, it’s really important to make sure it covers the basics while also protecting your rights and interests. Here’s a breakdown of what you should look out for in plain terms: Hello! My name is Dolan and I am happy to help. First off, the agreement should clearly describe the scope of work (often called the "SOW") This means it needs to explain exactly what you're expected to do, including the features or functionality of the app, the timeline for delivery, and any milestones. Make it specific. It has to be clear what is defined as intellectual property and then who owns it. Compensation is another big one. The agreement should spell out how much you’re being paid, whether it’s a flat fee, hourly rate, or based on milestones. I Confidentiality clauses are pretty standard, but you’ll want to make sure they don’t go overboard. Termination clauses are also super important. These should say under what conditions either of you can end the agreement. Make sure that if the company decides to end things early, you’ll still get paid for the work you’ve done up to that point. We can always draft these things for you or look over what you've drafted. Best of luck! Dolan

You might think that because you wrote the code, you have the right to share it, but that’s not how developer agreements usually work. In Washington State, these contracts are enforceable, and they can absolutely stop you from sharing or reusing code you created during a project. It really comes down to ownership, and under most contracts, that ownership belongs to the company, not you. Let’s Talk About Who Owns the Code When you sign a developer agreement, you’re usually agreeing to one of two things: either it’s a “work-for-hire” deal or you're assigning your intellectual property rights. Either way, the result is the same. The company owns whatever you build for them. Since they own it, they get to decide what happens to it. Even if you’re the one who wrote every line, that doesn’t mean you have the right to reuse or share it if you’ve already signed those rights away. This kind of setup is standard in the tech world. Companies need to protect their IP, especially when it includes competitive advantages or trade secrets. That’s why they ask developers to assign rights and agree to keep things confidential. What About Washington State Law? Washington does offer some protection to developers, but it’s limited. There’s a statute, RCW 49.44.140, that says employers can’t claim ownership of inventions you created entirely on your own time, using your own resources, and completely unrelated to their business. That sounds helpful, but here’s the catch. It only applies if you’re an employee, not an independent contractor. And even then, the second your work overlaps with their business or involves any company resources, the protection probably doesn’t apply. So if the code you’re writing is part of a contract, or even just loosely connected to the company’s business, then the company likely owns it. Why This Matters If you violate the agreement, you’re not just risking a slap on the wrist. The company could send a takedown notice to GitHub, file for an injunction, or even sue for breach of contract or copyright infringement. If the code includes anything proprietary, like business logic or algorithms, they might also go after you for trade secret misappropriation. And beyond the legal problems, there’s your reputation to think about. Word travels fast in development circles, especially in local communities. Getting labeled as someone who mishandles IP can make future contracts harder to land. How to Protect Yourself The good news is that you still have leverage before you sign. A lot of companies start with broad IP assignment language, but they’re often open to carving out exceptions. You can ask to include a “prior inventions” schedule that lists tools, frameworks, or libraries you already created. That way, you can keep using your own work in other projects. If open-source contribution is important to you, say so upfront. Some companies will allow developers to contribute non-proprietary or generic components to open-source projects, especially if those contributions don’t compete with their business. Just make sure it’s all clearly spelled out in writing and approved in advance. You might also negotiate a time limit on confidentiality terms. The company will likely want to own the core project code permanently. That doesn’t mean you can’t eventually talk about general techniques or patterns you used, especially after some time has passed. Smart Moves Before You Sign Before you agree to anything, take a moment to list any existing code or tools you plan to use. Try to get those explicitly excluded from the IP assignment, or at least confirm that you’ll retain the right to use them elsewhere. And again, if open-source is part of your career plan, be upfront. Get language in the contract that allows you to publish select components with written approval. If you develop a useful utility during the project and think it might have broader uses, talk to the company before the contract ends. See if they’d be open to letting you open-source it or license it back to yourself for use in future projects. When It’s Time to Bring in a Lawyer If all this feels high-stakes, and it often is, consider having a tech-savvy attorney take a look. A good lawyer can help spot overly aggressive clauses, suggest better language, and help you protect both your rights and your long-term goals. This is especially important if you’re actively contributing to open-source or if you’ve built up your own libraries over time. A little legal help now can save you a lot of trouble later.