If your company has people who create programs, scripts, applications, or digital tools as part of their work —even if their contract says nothing about "software development"— that creation is probably already yours. A June 2026 Supreme Court ruling made clear that Law No. 17,336 vests ownership of the rights over the program in the employer from the moment it is created within the scope of the employee's duties. To exclude that rule, the worker needs something that rarely exists: a written agreement stating the opposite. If your company does not have that clause —neither for nor against— the law works in your favor.
What happened
The Fourth Chamber of the Supreme Court rejected the cassation appeal on the merits filed by a former worker of an energy-sector company in Case No. 20,303-2026. The plaintiff had provided services to the company between 1999 and 2021 —from 2007 as head of the dispatch and distribution service— and during that period developed a computer program designed to support the logistics management and maintenance control of the company's equipment. When the program was disclosed, the employer appeared as the owner. The worker claimed ownership, arguing that his employment contract did not expressly include software development among his duties.
Both the first-instance court and the Santiago Court of Appeals rejected the claim. The Supreme Court confirmed that view and, ruling in chambers (en cuenta), rejected the appeal for manifest lack of merit (article 782 of the Code of Civil Procedure).
The core of the reasoning is article 8 of Law No. 17,336 on Intellectual Property: its second paragraph vests in the employer the ownership of the rights over computer programs created by its workers in the exercise of their employment duties. That ownership rule does not require the contract to mention software development; it is enough that the work was created "in connection with" the employment relationship. To exclude it, the law requires a written stipulation to the contrary.
The Court added that even if the program were deemed to have been created outside the employment context, the final paragraph of the same article 8 establishes that programs produced "to order" of a third party are deemed assigned to that party, unless there is a written stipulation to the contrary. Two different routes within the same rule; both lead to the same result.
What it may mean for your company
This ruling has implications that go beyond the energy sector. Today, virtually any organization has employees who, in the exercise of their duties, create some kind of digital tool: a macro that automates reports, a script that integrates systems, an internal dashboard, a management application, an inventory control module. If those tools were developed "in connection with" the employment relationship —which includes working time, use of company resources, or solving operational problems— the ownership rule of article 8 of Law No. 17,336 operates in your favor.
However, there are situations in which that advantage can turn into risk:
The worker who leaves and claims what they created. If someone developed a system during their employment and, upon leaving, claims they did it in their free time or with their own resources, the burden of proving that context falls on them. But if your company has no documentation showing that the tool was created in the exercise of employment duties, the litigation can become uncertain and costly, even though the law favors you.
The contract that said nothing. The good news is that the contract's silence does not harm the employer. The bad news is that it does not actively protect either: if the worker manages to prove the existence of a written stipulation to the contrary —a project agreement or other document in which the company recognized in writing that the worker held rights over the work— that ownership gives way.
The external developer or contractor. Article 8 also covers programs created "to order": its final paragraph deems them assigned to the party that commissioned them, unless there is a written stipulation to the contrary. If you work with vendors or freelancers who develop tools at your request, the law operates in your favor. But absent a well-drafted contract, that deemed assignment can become a point of dispute when circumstances change.
The ruling confirms that the legal rule is a useful safety net, but it does not replace a preventive documentary architecture.
What would happen if the person who built your key system leaves the company and claims ownership of it? Schedule a review of your employment and technology services contracts to get ahead of that scenario.
What you can do
- Audit the employment contracts of technical staff. Review whether the contracts of people who might create software —engineers, analysts, systems coordinators, even administrative staff who develop their own tools— contain explicit intellectual property clauses. An express clause eliminates uncertainty and discourages litigation.
- Review agreements with development vendors and contractors. Any technology services contract should expressly state that the works and developments belong to your company, together with a broad assignment or transfer-of-rights clause.
- Document the creation of internal tools. Keep records that demonstrate the employment context of the creation: emails, meeting minutes, project tickets, corporate repositories, internal communications. That documentation turns the legal rule into an argument that is hard to rebut.
- Include intellectual property clauses in onboarding processes. When hiring staff who may generate intellectual creations —which today applies to almost any role— sign rights-assignment agreements from the first day of the employment relationship.
If any of these points raises questions, a 30-minute diagnostic session is enough to size up your intellectual property gaps. Schedule here.
If you want to review whether your company's contracts are well structured to protect the software and digital tools your teams generate, schedule a meeting with our team.
This alert is informational and does not constitute legal advice. For analysis specific to your situation, consult a lawyer.