Intellectual Property in Swiss Employment Contracts, 2026

Before you sign

Your employer owns the software you write and the inventions you make as part of your job, even outside office hours. What you build on your own time, unrelated to your work, stays yours unless your contract takes it. And a non-compete binds you only if your job showed you clients or real trade secrets.

That is the law, and your contract can shift most of it. Below we go through the statutes, two Federal Supreme Court rulings, the IP section of a real collective agreement and a 2026 study for the federal economics office on how common these clauses are, and what each means for your code, your side projects and your next job.

Who owns the code you write at work?

For code, the rule is article 17 of the Copyright Act: where a program is created under an employment contract "in the course of discharging professional duties and in fulfilling contractual obligations, the employer alone shall be entitled to exercise the exclusive rights of use". In law you stay the author, because only a person can be one (art. 6). But copying, selling, licensing or publishing the program is up to your employer alone.

Software is the exception. For every other kind of work, copyright starts with whoever made it, even at work. The Federal Institute of Intellectual Property (IGE) puts it plainly: copyright in works such as "texts, diagrams or drawings belongs to the employee". An employer who wants those rights has to get them transferred, ideally in the contract, though the IGE notes that this can also happen by implication. Your architecture document is yours in principle. The service it describes is not.

Inventions follow the Code of Obligations (CO). Article 332 gives the employer every invention and design you make "in the course of [your] work for the employer and in performance of [your] contractual obligations", alone or with others, "whether or not they may be protected". A program as such cannot be patented in Switzerland, but the IGE notes that program-related technical inventions, such as an electronic control system, can be.

Both rules turn on the same test: was the work part of what you were hired to do? Neither article mentions working hours or the office, so code for your team's product, written on a Sunday on your own laptop, is still very likely part of your job. Some contracts say so outright, as Swisscom's does for inventions below. The real question is what your job is, and the space between "my job" and "my weekend" is where most disputes start.

Made at work, but not your task

For inventions, the law has a middle category. Say you were hired to build web front ends and, while debugging the build pipeline, you come up with a new way to schedule test runs. That was made "in the course of [your] work" but not "in performance of [your] contractual obligations". Article 332 handles it in three steps:

• The employer can claim such inventions only if it reserved the right in a written agreement, usually your contract.
• You must tell the employer about the invention in writing, and it must tell you within six months whether it wants it or releases it to you.
• If it keeps it, it must pay you "separate, appropriate remuneration", based on the invention's value, the employer's contribution, its staff and facilities you used, your own costs and your position.

That last point is one of the few rules here that no contract can remove: article 362 lists article 332 paragraph 4 among the provisions that cannot be changed to your detriment. The rest of article 332 can be reshaped by contract.

Software has no such middle rule. Article 17 of the Copyright Act needs both conditions, the job and the contractual duty, so code you write at work that is not part of your duties falls outside it. Unless your contract says otherwise, the copyright stays with you. The union syndicom, which organises ICT workers, reads the law the same way: by law, only inventions and programs developed "in fulfilment of contractual obligations" belong to the employer. That is exactly why employers write their own clauses.

What a real IP clause says

To see how employers fill those gaps, look at one that is public. Swisscom's collective agreement with the unions syndicom and transfair, in force since January 2024, has a whole section on intellectual property. The agreement runs to the end of 2026, or a year longer if neither side asked by June 2026 to renegotiate. It is in German; the translation below is ours.

The copyright clause reaches further than the law: it takes "all works", texts and diagrams included, and anything "in connection with" your area of tasks, which is wider than your contractual duties. But it still stops at your area of tasks, so an app with nothing to do with your job stays outside it. The invention clause copies article 332 almost word for word and spells out what the law leaves unsaid: it applies "regardless of the time and place" of the work, so an invention made at home counts too. And the agreement offers a way back: rights the company has no interest in are to be left to you by contract.

The same agreement also governs side jobs. Paid outside work, or work that could affect your performance, must be reported on a form and approved. Approval is given when there is no conflict of interest, your work does not suffer, the Labour Act's working and rest time rules are kept, and the side job does not take you out of Swiss social insurance.

Not every employer is this careful. In a 2020 resolution, syndicom's ICT sector complained that "more and more employers" ask staff to assign IP rights "far more extensively than the law establishes", including work done before the job started or in leisure time. That is the union's view, not a court's. But it tells you what to look for: wording that claims everything you create while employed, with no link to your duties, or anything you made before you joined.

How to keep a side project yours

Start from the test above. A side project stays yours if it is not part of your job and your contract does not claim it. Hours and equipment are not the legal test, but they are the evidence people argue about. The law also asks you to treat the employer's equipment properly (CO art. 321a), and article 332 counts the use of company "facilities" when it sets what an invention is worth. Code written on your own machine, in your own repository, at night, is simply easier to defend.

Two limits apply even to a project that is clearly yours. While you are employed, you "must not perform any paid work for third parties in breach of [your] duty of loyalty, in particular if such work is in competition with [your] employer" (art. 321a para. 3). A free weekend game is fine; a paid tool that competes with your employer's product is not. And what you learned in confidence at work, such as code, customer data or plans, may not go into the project at all (art. 321a para. 4).

The practical steps are simple, and the best time to take them is before you sign. List the projects you already own in an annex, with links to the repositories. If the IP clause has no link to your duties, ask for one. If your project is close to your employer's field, ask for a written release, the same way article 332 lets an employer release an invention. A short email does the job:

Before I sign: the IP clause in section 7 covers all works created during my employment. Could we limit it to work connected with my duties? I also maintain two open source projects, listed below, which I'd like to keep working on in my own time. Could you confirm in writing that they remain mine?

If your side project starts to earn money, the social security side is a separate question; our freelancing guide explains how AHV treats side income.

Open source, at work and after hours

At work, the code belongs to your employer, so your employer decides whether it is published and under which licence. That matters every time you send a patch upstream. If you sign off a commit with git commit -s, git's documentation explains that a sign-off may certify that you have the right to submit the work under the project's licence. Under the Developer Certificate of Origin used by the Linux kernel and git, you certify that "I have the right to submit it under the open source license indicated in the file". For code written on the job, that right is your employer's to give. Ask whether there is an open source policy, and get permission in writing if there is none.

The federal government goes the other way by law. Under article 9 of the federal act on electronic means for official tasks (EMBAG), federal authorities must publish the source code of software they develop or have developed for their tasks, unless third-party rights or security reasons rule it out. Anyone may use it, develop it further and pass it on, with no licence fees. If you write code for a federal office, open source is the default.

After hours, your contributions follow the side project rules: yours, unless the work is part of your job or your contract claims it. The grey case is a fix to a library your team uses, written on a Saturday. It is not your task as such, but it is close to it. If you would rather not argue about it later, mention it to your manager first.

Non-competes are common, and often too broad

A non-compete limits what you can do after you leave, which makes it the clause most developers worry about. The first figures for Switzerland came out in January 2026, in an OECD study for the State Secretariat for Economic Affairs (SECO). Employers said 16% to 24% of private-sector staff are bound by one. Among workers, 19% said they definitely were, and another 24% thought they "probably" were.

Clauses come in bundles: 53% of workers reported three or more. A quarter of the firms that use non-competes apply them to all staff, whatever their role. Around a third of workers with a non-compete said no compensation was foreseen. And a sizeable share of clauses set no duration or no area, which, the authors note, makes them highly unlikely to hold up in court. They also warn that workers often believe such clauses bind them anyway. So the useful question is not whether your contract has one, but whether it would hold.

When does a non-compete bind you?

The rules are in articles 340 to 340c of the Code of Obligations. The written form, the limits on scope and the ways a clause ends cannot be changed to your detriment by any contract (art. 362).

It must be in writing, signed by you, and it binds you only if your job gave you insight into "the employer's clientele or manufacturing and trade secrets" and using that knowledge "might cause the employer substantial harm". For many developers that second part is the weak point. In BGE 138 III 67, the Federal Supreme Court confirmed that the non-competes of two senior trainers at a Geneva training firm were invalid, because clients chose them for their personal skills rather than for the company. The court also said that a trade secret cannot be knowledge you could pick up at any firm in the same sector. Knowing React, Kubernetes or how payments work is your skill, not your employer's secret. Knowing its unreleased pricing engine, or being the person its key clients call, is a different matter.

It must be limited in place, time and subject, so that it does not unfairly hold back your career, and it may run for more than three years "only in special circumstances" (art. 340a). A judge can cut back a clause that goes too far, taking into account anything your employer pays for it. A broad wording does not make a clause void by itself. In BGE 145 III 365, a marketing assistant's ban on "any competing activity" across Switzerland for three years was held to be clear enough, and the case went back to the cantonal court. But the court added that a clause whose time, place and subject cannot be worked out at all has no effect from the start.

It need not be paid for. Swiss law requires no compensation. Germany is stricter: there, a non-compete binds only if the employer pays at least half of your last pay for each year it runs (§ 74 HGB). If you are moving from Germany, do not assume the same protection.

It can end early. Under article 340c, the clause lapses if your employer no longer has a substantial interest in it, if your employer dismisses you without you giving good cause, or if you resign for good cause the employer is responsible for. If you break it, you owe damages. Where the contract sets a penalty, paying it normally frees you from the ban, unless the contract says otherwise, though you can still owe damages beyond it. Your employer can force you to actually stop the competing work only if that was expressly agreed in writing and its interests and your conduct justify it (art. 340b).

Separate from all of this, your confidentiality duty outlives the job "to the extent required to safeguard the employer's legitimate interests" (art. 321a para. 4), with or without a non-compete.

What to ask before you sign

Read the IP clause and the non-compete as carefully as the salary. For the IP clause, check whether it is tied to your duties or claims everything you create while employed. For the non-compete, check whether your role really gives you client contacts or trade secrets, and whether it names a time, an area and a field. A clause that names none of these is unlikely to hold, but asking for a tighter one costs less than a dispute. Then send your list of existing projects and ask for the carve-out in writing.

Most employers will discuss this at the offer stage, when they want you to sign; our guide to tech interviews in Switzerland covers the rounds that come before it. If you are comparing offers, read the contracts side by side.

Open developer jobs in Zurich

When an offer arrives, ask for the full contract with every annex and any staff rules or collective agreement it refers to. That is often where the IP section sits, as it does at Swisscom.