Software copyright lawyer: source code, websites and apps
When you need a software copyright lawyer, the practical question is who owns the code, website, application, interface, documentation, components, plugins, libraries, design and connected deliverables. In IT projects, conflict often appears after launch, when the client asks for source-code access, the agency invokes reusable components and the developer argues that certain parts are internal know-how.
For IT companies, agencies, freelancers and startups, source-code ownership is not solved only through technical access to a repository. The development contract, actual contributions, licences for third-party components, handover of deliverables, reuse rights and the difference between licence and assignment all matter.
This page deals with copyright in software, websites, applications and source code from a business-facing legal perspective. The purpose is to decide practically which rights exist, who may exercise them, what must be delivered and how to manage the conflict between client, agency and developer.
Quick contents
Why source-code ownership should be clarified early
In software projects, the legal conflict rarely appears as a simple question. It is usually a mix of delayed delivery, incomplete features, source-code access, refusal to hand over, reuse of components, additional costs and uncertainty regarding copyright in the code.
A website or application may include custom code, templates, open-source libraries, commercial plugins, design, texts, databases, graphics and documentation. Each component may have a different legal regime. It is therefore not enough to ask “who owns the website?”. It must be checked what exactly is being discussed.
For a broader perspective on protection of creative assets, the parent page on copyright lawyer Bucharest covers evidence, contracts, licences, assignments and online infringements.
Typical situations where code ownership becomes disputed
Ownership becomes disputed when the project is delayed, the collaboration stops, the client wants to migrate to another supplier, the agency refuses to deliver source code or the developer invokes reuse of proprietary components. In such cases, the contract and repository must be read together.
- the client paid for the application but does not have full access to source code;
- the agency used libraries, templates or its own modules in the project;
- the developer worked without a clear assignment or licence agreement;
- several contributors made commits, but their rights were not regulated;
- the website is delivered, but components, theme, design and plugins have different legal regimes;
- the startup seeks investment but cannot prove the chain of rights over the code.
When you need this
You need legal assistance when you develop, order, deliver, take over or exploit software, websites, applications or source code and need to clarify rights. The situation may be preventive, before contract signing, or contentious, after the project is blocked.
The service is useful for IT companies, digital agencies, freelancers, startups, corporate clients and investors who need to know whether rights over code and components are sufficient for use, modification, scaling, sale, financing or migration to another supplier.
- you are about to sign a software development contract with copyright clauses;
- the client requests source code, but the contract is unclear;
- the developer or agency wants to reuse components from the project;
- there are several contributors and it is not documented who created what;
- the startup is preparing investment, exit or IP due diligence;
- the IT project is blocked and it must be decided what is delivered and paid;
- there is risk of unauthorized use of code, themes, plugins or design.
In these situations, copyright should be analysed together with the contract, deliverables and technical evidence. A generic answer about software is not enough; the contractual structure and project chronology matter.
Software copyright lawyer: what I check / what I do in practice
In a software copyright lawyer file, I first review the contractual relationship: who commissioned, who developed, who coordinated, who contributed and what was promised as a deliverable. I then analyse clauses on IP, source code, licence, assignment, access, reuse, open source, confidentiality and termination.
I also review technical documents with legal relevance. The repository, commit history, issue tracker, testing reports and acceptance documents may show what was created, when and by whom. Not every technical detail is legally relevant, but some may decide the dispute.
For websites, I review design, theme, texts, photographs, plugins, custom code, accounts, domain, hosting, licences and admin access separately. A website is not one simple legal object; it is a package of components.
- I identify the parties, roles and contributions;
- I review ownership, licence and assignment clauses;
- I separate custom code from reusable or third-party components;
- I analyse access to repository, source code, documentation and accounts;
- I review deliverables, acceptance and completion criteria;
- I determine what may be reused and what remains exclusive to the project;
- I prepare clauses, notices, negotiation positions or litigation strategy.
What I check in a software project
In a software project, I check both the contract and the technical traces of contribution. I do not perform a technical code audit, but I review the documents that show who created, who delivered, who has access, which rights were transferred and which components may be reused.
- development contract, annexes, specifications and change requests;
- repository, commit history, branches, release notes and acceptance documents;
- IP, assignment, licence, reuse and confidentiality clauses;
- rights over custom code, standard components, libraries and plugins;
- access to source code, environments, documentation, keys, accounts and deliverables;
- contributions by employees, freelancers, subcontractors or agencies;
- risks regarding open source, third-party components and integrated creative materials.
Where risks and common mistakes appear
The main risk is the absence of a clear rights clause. The contract describes features, price and deadlines, but treats IP in one general sentence. When the project ends or becomes blocked, the parties discover that they do not know who may use, modify, transfer or reuse the code.
Another risk is access. The client may have a functioning product but no repository, keys, documentation or ability to continue development with another supplier. On the other hand, the developer may have a legitimate interest in protecting generic components, internal frameworks or know-how, if these were not transferred.
In projects with several contributors, the risk appears in the chain of rights. If developers, subcontractors or freelancers did not transfer rights to the agency or company, the final beneficiary may have a vulnerability in due diligence, investment or litigation.
Common mistakes in software and website projects
A frequent mistake is assuming that payment for the project automatically means full ownership of the code. In reality, the contract should say whether the beneficiary receives an assignment, a licence, source-code access, modification rights, reuse rights or only the right to use the application.
- custom code is not separated from reusable components;
- open-source licences or plugins are not reviewed;
- the repository is on the developer’s account, with no access rules;
- contributions by several developers are not documented;
- acceptance of deliverables is ambiguous;
- there are no clauses on documentation, keys and deployment environments;
- the client confuses website delivery with full transfer of IP.
How we work
We work in stages. We start with the contract and project chronology. Then we review deliverables, repository, access and contributions. The purpose is to translate the technical situation into a legal position: which rights exist, what is missing, what can be requested and which risk must be reduced.
If the project is preventive, we draft or negotiate clauses on code, licence, assignment, reuse, open source, access to source code and delivery of documentation. If the project is contentious, we build the file on contract, technical evidence and communications.
- we analyse the contract, annexes and specifications;
- we identify custom code, reusable components and third-party components;
- we review repository, access, commits and documentation;
- we clarify the difference between licence and assignment in the project;
- we regulate source-code, keys, accounts and deliverables handover;
- we prepare notices, addenda, clauses or negotiation positions;
- if needed, we build the litigation or IP audit strategy.
What happens after the initial review
After the initial review, we determine whether the issue is contractual, evidentiary or operational. Sometimes source-code access must be negotiated. Sometimes an addendum on rights is needed. In escalated conflicts, a position must be prepared that connects the contract with the repository, deliverables and chronology.
If the project is ongoing, the recommendation may be to clarify rights before final delivery. If the project stopped, the focus moves to handover, access, remuneration, reuse and possible claims. If there is litigation, technical evidence must be translated into legal arguments.
Documents that help from the outset
For the first review, both legal and technical documents are useful. It is not necessary to send all code at the beginning, but there should be a clear view of the contract, deliverables, access and contributions.
- development contract, annexes, specifications and offers;
- clauses on IP, source code, licence, assignment, open source and confidentiality;
- repository, commit history, branches, release notes and issue tracker;
- handover, acceptance, testing, bug-report and progress documents;
- contracts with developers, freelancers, employees or subcontractors;
- licences for libraries, plugins, themes, templates or commercial components;
- correspondence regarding access, handover, delays, modifications and refusals.
A short statement of the objective also helps: you may want full transfer, a licence to use, access to source code, continuation of the project with another supplier, investment due diligence or defence in an existing conflict.
Technical documents that matter legally
In software, some technical documents have real legal value. They can show who contributed, what was delivered, what was accepted, what remained incomplete and what access each party has.
- repository, commit history, pull requests and issue tracker;
- functional and technical specifications;
- handover, acceptance or refusal documents;
- release notes, changelog, testing reports and bug reports;
- administration, deployment, account and access-key documentation;
- third-party component licences and library records;
- contracts with employees, freelancers or subcontractors.
Licence, assignment and ownership in software projects
The difference between licence and assignment is essential in software. Through a licence, the client may receive a right to use the code under certain conditions, without becoming owner of all rights. Through an assignment, certain economic rights may be transferred, but only within the agreed limits.
In practice, the parties need a solution adapted to the project. Sometimes the client needs broad ownership over custom code. Sometimes a licence to use is sufficient, while the developer keeps reusable components. In other cases, the agreement combines assignment for project-specific deliverables with a licence for standard modules.
If the dispute concerns delivery, SLA, acceptance or escrow, the page on IT & tech disputes may also be relevant. For digital content and platforms, the article on copyright for online creators may provide useful context.
Client, agency and developer: where the chain of rights breaks
In many projects, the client contracts with the agency, the agency contracts with the developer, and the developer uses proprietary or third-party components. If each contract does not transfer or licence sufficient rights to the next level, the final client may receive a functional product but an incomplete legal chain.
This is why ownership analysis must cover the entire chain: who created the code, who paid, who received rights, who may modify and who may reuse components in other projects.
Frequently asked questions
Who owns the source code in a software project?
It depends on the contract, contributions and IP clauses. Payment for the project does not automatically mean full transfer. The agreement must be checked for assignment, licence, source-code handover and rules on reusable or third-party components.
What is the difference between licence and assignment in software?
A licence allows use of the code within certain limits, without full transfer of rights. An assignment is aimed at transferring certain economic rights. In software projects, the solution may be mixed: assignment for custom code and licence for reusable modules.
Does the client have a right to the repository and source files?
It depends on the contract. Technical access should be regulated separately: repository, documentation, keys, environments, accounts, builds and deliverables. If these are missing, the project may be difficult to continue with another supplier.
What happens with open-source components or plugins?
They should be identified and checked separately. Some components may be used freely under certain conditions, while others have restrictions. The contract should say which components are third-party, what licences they have and who is responsible for their use.
How are contributions by several developers documented?
Through contracts, repository, commit history, issue tracker, handover documents and internal rules. If several contributors worked on the project, the chain of rights should be clarified for each relevant contribution.
Initial discussion for software copyright issues
If you have a software project, website, app or dispute regarding source code, the first useful step is to organise the contracts, repository, deliverables and contribution chronology.
The initial review focuses on who contributed, what was delivered, which rights were assigned or licensed, which components may be reused and what risk exists between client, agency and developer.
Final note
The information on this page is general. In copyright for software, websites and source code, the decisive elements are contracts, repository, contributions, source files, licences, deliverables and chronology. A responsible conclusion can be given only after reviewing the concrete documents.