Protecting Software and Mobile Apps: Copyright vs Patents and Contracts with Developers

This guide walks through the main tools you have at your disposal – copyright, patents, trade marks and, crucially, contracts with developers. It is written with Romanian founders and programmers in mind, but in a way that is aligned with EU law. You will find references to the main legal texts and official institutions, such as Law no. 8/1996 on copyright and related rights, Directive 2009/24/EC on the legal protection of computer programs, Law no. 64/1991 on patents, ORDA’s National Register of Computer Programs (RNPC) and OSIM (the Romanian Patent and Trade Mark Office).

1. Legal framework in Romania and the EU: what protects software?

Under EU law, computer programs are primarily protected by copyright, not by patents. This is set out in Directive 2009/24/EC on the legal protection of computer programs, which requires Member States to protect computer programs as literary works under the Berne Convention. Romania implemented this framework through specific provisions in Law no. 8/1996.

Key pillars you should know about are:

• Copyright – protects software as an “intellectual creation” (the code, preparatory materials, documentation). It arises automatically once the work is created, without registration.
• Patents – protect technical inventions that are new, involve an inventive step and are industrially applicable, under Law no. 64/1991. Computer programs “as such” are excluded, but some computer-implemented inventions can be patented if they provide a technical effect.
• Trade marks – protect your app name and logo, through registration with OSIM or the EUIPO for EU-wide protection.
• Trade secrets – protect confidential know-how, algorithms and business information, provided you actually treat them as confidential (NDAs, restricted access, internal policies).
• Contracts – tie all of this together by defining who owns which rights, who can use the code, and on what terms (employees, freelancers, agencies, clients, investors).

For Romanian businesses, the practical “triangle” is: Law no. 8/1996 for copyright, Law no. 64/1991 for patents and the ORDA/OSIM practice on registration and enforcement.

2. Software as a copyright-protected work

2.1. What is protected?

Law no. 8/1996 explicitly includes computer programs among the works protected by copyright. Special provisions define the scope of protection for programs, in line with EU law: protection covers the expression of a program in any form – source code, object code, preparatory design material (technical specifications, flowcharts), and related documentation and manuals – but not the underlying ideas and principles.

This mirrors Article 1(2) of Directive 2009/24/EC, and has been confirmed by the Court of Justice of the EU in the well-known SAS Institute v. World Programming (C-406/10) case, where the Court held that the functionality of a computer program, the programming language and data file formats do not constitute a form of expression protected by copyright.

For you, this means:

• If someone independently implements the same functionality using different code and design, that alone is not copyright infringement.
• If someone copies your source code, distinctive architecture, or documentation, that can be copyright infringement, even if they tweak names and formatting.
• UX / UI components can also be protected where they reflect original creative choices – but not generic patterns or standard layouts.

2.2. When does copyright arise? Do I need registration?

Under Law no. 8/1996, an intellectual creation is protected from the moment it is created in a concrete form, even if unfinished, and regardless of whether it is made public. There is no requirement to register the work with any authority for copyright to exist.

So, when your code, diagrams, or documentation move beyond a mere idea – i.e., they exist in files, repositories, or other fixed form – copyright protection kicks in automatically. You can strengthen your position with good evidence (version control history, internal records, e-mails), and, optionally, registration with ORDA’s National Register of Computer Programs.

2.3. ORDA and the National Register of Computer Programs (RNPC)

The National Register of Computer Programs is administered by ORDA and governed by Chapter III of Government Ordinance no. 25/2006. For certain categories – such as software producers and distributors introducing programs into commercial circulation – registration or inscription in the RNPC is mandatory, according to Article 17 OG 25/2006.

For startups and software companies, registration has two main functions:

• Evidence – it creates strong proof of the existence and content of your program at a particular date, which can help in court in case of plagiarism or disputes.
• Compliance – if your business qualifies as a “producer” or “distributor” within the meaning of OG 25/2006, you should review whether RNPC registration is mandatory for your activity.

The procedure and forms (F1, F8, etc.) for producers, distributors and lessors are described in detail on the official ORDA RNPC page and on the e-guvernare portal.

2.4. Author vs. rights holder: who “owns” the software?

By default, the author is the natural person who created the work (the programmer, designer, technical writer). Authors initially hold both moral and economic rights. However, for computer programs created in an employment context, Romanian law contains a special rule: in the absence of a contractual provision to the contrary, economic rights in programs created by employees in the course of their duties or following the employer’s instructions belong to the employer. This is the effect of Article 74 of Law no. 8/1996.

In other words:

• For employees, the employer is (presumptively) the economic rights holder over software created within job duties.
• For freelancers, PFA/SRL contractors or agencies, this presumption does not apply. They remain owners of the economic rights unless there is a written assignment (transfer) or licence.

This distinction is critical in practice, especially for startups relying on freelancers or development agencies in the early stages.

3. Economic and moral rights in software

3.1. Economic rights: exclusivity over exploitation

Economic rights give the holder the power to decide how the software is used and monetised. For computer programs, these rights include, in particular:

• Reproduction – any copying of the program, including installation, loading into memory, running and storing it.
• Adaptation / derivative works – modifying the program, creating new versions, extensions, integrations or derivative modules.
• Distribution – sale or other transfer of copies of the program, on physical media or as downloads.
• Rental / licensing – granting temporary rights of use, such as SaaS subscriptions, perpetual licences or OEM deals.
• Communication to the public – making the program available online so that users can access it from a place and at a time individually chosen (typical for SaaS platforms).

These rights can be transferred or licensed. In a classical “product company”, the startup tends to own the economic rights and grant licences to customers. In custom development projects, the client often expects to receive at least a broad licence, and in many cases a full assignment over the bespoke code.

3.2. Moral rights: the personal link between author and code

Moral rights attach to the author as a person and are, as a rule, non-transferable. They typically include:

• the right to be recognised as author (right of attribution);
• the right to decide if and how the work is made public;
• the right to the integrity of the work – to object to modifications that prejudice the author’s honour or reputation.

Even when a company acquires economic rights, the programmer remains, in principle, the author in the moral sense. In software practice, most disputes involve economic rights (who can use and change the code), but moral rights can become relevant if, for example, a developer’s name is removed from credits in breach of an attribution agreement, or code is modified in a way that publicly damages their reputation.

4. Patents and computer-implemented inventions

4.1. When can software-related inventions be patented?

Under Law no. 64/1991 on patents, an invention is patentable if it is new, involves an inventive step and is susceptible of industrial application. At the same time, certain subject-matter is excluded, including computer programs “as such”. OSIM and legal commentary emphasise that software per se is not an invention, but a technical solution implemented by software can be patentable if it produces a technical effect beyond normal computer interactions.

Guidance materials used in Romania, including university-OSIM training texts, underline that “computer programs, as such, are not considered inventions” under Article 7 of Law 64/1991 and the implementing regulation.:contentReference[oaicite:0]{index=0}

Examples where a software-related patent may be considered:

• a new compression algorithm that enables significantly better performance on limited hardware;
• a control system for industrial machinery where the software and hardware interact in a novel way to achieve a technical effect;
• a security protocol implemented in software that solves a technical problem in networks in a non-obvious way.

By contrast, typical mobile apps (marketplaces, productivity tools, standard SaaS platforms) often revolve around business logic and user experience rather than technical inventions in the patent sense, and are usually not good candidates for patents.

4.2. Pros and cons of pursuing patents

Potential advantages:

• Patents provide an exclusive right over the technical solution itself, not just a particular code implementation.
• A patent portfolio can significantly increase company value in the eyes of investors and acquirers.
• Patents can be licensed to third parties as a separate revenue stream.
• Patents can be used both offensively (to stop infringers) and defensively (to negotiate cross-licences).

Limitations and drawbacks:

• High costs (OSIM and EPO fees, patent attorney work, translations, annuities).
• Time-consuming: it may take several years for a patent to be granted.
• Disclosure: the patent application is eventually published, revealing technical details to competitors.
• Not every clever algorithm is patentable – the bar for “technical effect” and inventive step can be high.

In practice, for many Romanian software startups, the core protection strategy is still built on copyright + trade marks + contracts + trade secrets. Patents are worth considering especially in deep-tech areas (AI algorithms with technical effects, networking, cybersecurity, low-level system optimisation) and should typically be evaluated with a specialised patent attorney.

4.3. Service inventions and employees (Law no. 83/2014)

Where software leads to a patentable invention that is created by employees, Law no. 83/2014 on service inventions becomes relevant. It regulates when an invention is considered a “service invention”, who owns the rights and how the inventor-employee is rewarded. Article 4, for example, gives the employer the power to classify an invention as a service invention, and Article 8 provides that, if the employer owns the invention, it is entitled to file a patent or utility model application and must compensate the employee appropriately.:contentReference[oaicite:1]{index=1}

For tech companies with R&D activity, employment and IP policies should explicitly address service inventions and link them to patent filing strategies.

5. Copyright vs patents – choosing a protection strategy

5.1. Side-by-side comparison

5.2. Typical scenarios

Scenario A – consumer mobile app (marketplace, social, lifestyle)

Here, protection is mainly via copyright (code, design, content) and trade marks (name, logo). Contracts with developers and clients are critical. Patents are usually not viable because the innovation lies primarily in UX, business model and execution rather than in a technical invention in the patent sense.

Scenario B – SaaS with a novel optimisation algorithm

If your SaaS product uses a genuinely new algorithm for routing, caching, compression, or resource optimisation with measurable technical benefits, you might combine copyright with a patent. The code is protected by copyright; the algorithm as a technical solution may be patentable, preventing others from implementing it even with different code.

Scenario C – industrial control system or IoT platform

Where software is tightly integrated with hardware and controls industrial processes or devices in a new way, patents become more relevant. A well-designed IP strategy may mix patents (for core technical inventions), trade secrets (for implementation details not disclosed in patents) and copyright (for code and documentation).

6. Contracts with developers: who really owns the code?

No matter how strong the law is on your side, in real life everything comes down to contracts and evidence. A good IP strategy for a software startup starts with a simple question: If I have a serious conflict with my developer tomorrow, can I continue to use, modify and licence the app without legal risk?

6.1. Employees vs freelancers vs agencies

Employees

For computer programs created by employees as part of their job or following the employer’s instructions, Law no. 8/1996 presumes that economic rights belong to the employer. Nevertheless, you should not rely only on this presumption. Employment contracts and job descriptions should clearly state that software, documentation and related IP created in the course of employment belong to the company, and clarify the boundary between company projects and personal projects.

Freelancers and PFA/SRL contractors

For non-employees, the default is the opposite: the developer retains economic rights unless there is a written transfer or licence. If you pay a freelancer to build an app but your contract is silent on IP, legally they likely own the code and you only have an implied, limited licence to use it. This is a red flag in investor due diligence.

Development agencies

Agencies typically reuse internal frameworks, libraries and infrastructure across projects. Contracts often distinguish between:

• the agency’s background IP (reusable frameworks, libraries, generic modules), which remains with the agency and is licensed to the client; and
• the project-specific deliverables (custom code, configurations, branding), which may be assigned or exclusively licensed to the client.

As a client, you want the right to run, modify and extend your product without undue dependence on a single vendor. As an agency, you want to protect your reusable components and avoid “giving away” your entire tech stack.

6.2. Essential IP clauses in development contracts

Well-drafted software development agreements (with employees, freelancers or agencies) should cover, at a minimum:

• Detailed definition of deliverables – what exactly is being created: source code, object code, documentation, design assets, deployment scripts, infrastructure templates, test suites, etc.
• Assignment vs licence – whether economic rights are fully assigned (transferred) to the client, or whether the client receives a licence only. Key parameters:
  • scope (what uses are allowed – internal, external resale, SaaS, white-labelling);
  • territory (Romania, EU, worldwide);
  • duration (limited, perpetual);
  • exclusivity (exclusive or non-exclusive).
• Remuneration for IP – for assignments, it is safer to state clearly that the agreed fee includes consideration for IP transfer, to avoid future claims that the assignment was gratuitous or invalid.
• Right to modify and create derivatives – the client should be allowed to modify the code, create new versions and integrate it with other products, ideally without needing further consent.
• Open-source and third-party components – the contract should address:
  • what types of licences are permitted (e.g. permissive like MIT/Apache vs strong copyleft like AGPL);
  • who is responsible for checking compatibility with the client’s business model;
  • who bears the risk if a third party alleges licence violations.
• Confidentiality and trade secrets – NDAs and confidentiality clauses should cover source code, architectures, business logic, client data and any non-public information.
• Warranties and indemnities – the developer should warrant that the deliverables do not infringe third-party rights (to the best of their knowledge), and indemnify the client against certain claims, within reasonable limits.
• Exit and handover obligations – on termination, the developer should be required to hand over code, documentation, credentials and assist in transition for a defined period (often against fees).

6.3. Inventions and patents in contracts

If R&D activities may lead to patentable inventions, contracts and internal policies should also address:

• employee obligations to notify inventions related to company activity;
• who decides whether an invention is a “service invention” and who files patent applications (linked to Law no. 83/2014);
• how employee-inventors are rewarded if the patent is exploited.

7. Open-source software and third-party components

Modern software relies heavily on open-source libraries and frameworks. This is not a problem per se – EU policy actually encourages open-source – but it can become a serious IP and compliance risk if licences are ignored.

Key points for founders and tech leads:

• Know your licences – permissive licences (MIT, BSD, Apache 2.0) usually allow integration into proprietary software with light obligations (e.g. preserving copyright notices). Copyleft licences (GPL, AGPL) can impose obligations to publish source code of derivative works or of network-facing components.
• Align licences with your business model – if your plan is to offer a closed-source SaaS platform, incorporating AGPL components in the server-side code without complying with the licence terms can be incompatible with that goal.
• Maintain a Software Bill of Materials (SBOM) – document which open-source components you use, their versions and licences. This is also increasingly requested in security and compliance audits.
• Include open-source clauses in contracts – require developers to document all third-party components and ensure that licences are compatible with your intended use.

From an investor’s perspective, uncontrolled use of copyleft components in core proprietary code can be a significant red flag, as it may limit exit options or trigger legal risks.

8. Common mistakes and how to avoid them

8.1. No written agreement with developers

One of the most frequent and dangerous mistakes is launching a product based on code written by friends, freelancers or small agencies without any written agreement on IP. This can lead to situations where:

• a co-founder or freelancer leaves and claims ownership of the core code;
• there is no documented chain of title for IP during due diligence in a funding round;
• clients or investors discover that the company does not actually own or control the software it sells.

Even a simple, well-structured development agreement that addresses IP can prevent most of these problems.

8.2. Confusing “right to use” with “ownership”

Law no. 8/1996 includes a specific presumption for software use contracts: unless otherwise agreed, a software user only receives a non-exclusive, non-transferable right of use. Paying for a licence or subscription rarely means owning the software. Similarly, paying an invoice from an agency does not, by itself, mean that IP has been transferred.

Always read the contract: if it talks about “licence”, ask whether you need an assignment (transfer) instead for your business model. If there is an assignment, make sure it is clearly drafted and signed.

8.3. Ignoring formalities like RNPC and trade mark registration

While copyright does not require registration, some formalities play a strategic role:

• Registration in the RNPC at ORDA can both fulfil legal obligations for certain producers/distributors and provide strong evidence in case of disputes.
• Trade mark registration of your app name and logo with OSIM or EUIPO protects you against copycats using confusingly similar brands and is often a must-have for scaling.

8.4. Misalignment between legal documents and reality

Sometimes contracts exist, but practice contradicts them. Examples:

• developers use personal repositories for company projects and mix personal and company code;
• co-founders reuse code from previous employers without permission;
• teams rely on shared credentials and lack access control, making it hard to prove who did what.

A healthy IP setup is not just about contracts; it also requires processes (access control, code review, documentation) and culture (team awareness that IP matters).

9. Practical checklist for founders and developers

To translate all of the above into action, here is a practical checklist:

1. Map your IP: list all key software components (backend, frontend, mobile apps, infrastructure scripts, ML models), who created them, under what status (employee, freelancer, agency, co-founder) and when.
2. Review existing contracts: check employment contracts, contractor agreements and agency MSAs for:
   • clear IP clauses (assignment/licence);
   • coverage of updates, bug fixes, new versions;
   • open-source and third-party licence language.
3. Plug gaps: where contracts are missing or unclear, consider signing IP assignment or addendum agreements and updating templates for future hires and contractors.
4. Establish an open-source policy: define what licences are allowed, approval processes for new dependencies and how to track them (SBOM).
5. Consider ORDA RNPC registration: especially if you are a software producer/distributor introducing products into the market, review obligations under OG 25/2006 and consider registering key products in the RNPC.
6. Assess patent potential: if you suspect that your technology has a strong technical component (e.g. new algorithms, protocols, control systems), obtain a preliminary opinion from a patent attorney on patentability in Romania/EPO.
7. Protect your brand: file for trade mark protection for your app name and logo; check for prior rights to avoid conflicts.
8. Document everything: ensure that repositories, commit history, design documents and technical decisions are stored and accessible. This is essential for proving authorship and defending against infringement claims.
9. Align co-founders: sign a founders’ agreement covering IP contributions, vesting, and what happens if someone leaves.
10. Review regularly: revisit your IP strategy and contracts at least annually or before major events (funding, launch in new markets, acquisition).

10. FAQ – protecting software and mobile apps

11. Sources and further reading

• Law no. 8/1996 on copyright and related rights (Romania).
• Directive 2009/24/EC on the legal protection of computer programs (EU).
• Law no. 64/1991 on patents and OSIM resources on inventions and computer-implemented inventions.
• Law no. 83/2014 on service inventions (employees and inventions).
• ORDA – National Register of Computer Programs (RNPC) and information under OG 25/2006.
• CJEU, Case C-406/10, SAS Institute Inc. v World Programming Ltd – on what aspects of computer programs are protected by copyright.
• Specialist blogs and guides on registering software with ORDA and managing software IP in Romania (for example, practical step-by-step articles on RNPC registration and software copyright).