Employee Invention Rules and OSS Management: How the Requirements of Article 35 of the Patent Act and Article 15 of the Copyright Act Differ

Hello, I'm Noriaki Asato, Representative Attorney at LegalAgent.

Imagine that, during legal due diligence on an acquisition target, you ask the head of development for a list of the open source software (OSS) in use and its license terms, and all they have on hand is the package dependency file. Or imagine that the company has employee invention rules, but there is no record of which inventions by which people the rules were applied to. In that case, additional investigation becomes necessary just to explain that the company actually holds the rights.

Employee inventions and OSS rest on very different statutes, and the nature of the rights involved is also very different. What they have in common, however, is this question: for the core of the product, can the company explain the chain of title, meaning who created the technology or code, how it came about, and where the rights sit today, not merely through the formal date on which a set of rules was adopted, but through day-to-day operational records? The company should keep records running from the invention disclosure through the vesting of rights in the company and the grant of reasonable benefits. Contracts with contractors and the OSS register should also be managed so that they connect to the results of license review and pre-release checks.

The Chain of Title Examined in Due Diligence

In legal due diligence for fundraising or M&A, the ownership of intellectual property is examined not only by checking whether certificates or registry entries exist, but also from the substantive standpoint of whether the business can continue to operate. The items a seller should prepare are covered in Legal DD to Prepare Before a Startup Becomes a Seller. The focus is whether the transfer to the company of rights in source code, technology and know-how that contractors or side-job members worked on can be objectively confirmed.

The materials reviewed fall broadly into three categories. The first is materials relating to inventions. These include the list of patent applications, invention disclosure forms, the employee invention rules, the clauses in contracts and work rules on succession to the right to obtain a patent, and records of payment of reasonable benefits. The second is the intellectual property ownership clauses in service agreements. As discussed in Checkpoints for Reviewing IP Ownership Clauses, how the scope of deliverables, the exclusion of pre-existing assets and the scope of the non-assertion of moral rights are defined is checked by comparing the contract wording against the actual creation process. The third is a management register showing how OSS is used.

The fact that these three sets of materials are not fully in hand does not necessarily become an immediate obstacle to the transaction. However, if the company tries to get by with oral explanations alone, without objective evidence, this can come back as a price reduction in negotiations or as tougher terms in the representations and warranties. Putting employee invention rules in place, including ownership clauses in the template service agreement, and making OSS use subject to approval are three mechanisms grounded in separate statutes. In the practice of due diligence, however, they stand side by side as tools for answering one shared question: can the company explain its own chain of title?

The Definition of an Employee Invention and the Statutory Non-Exclusive License

The Patent Act defines an employee invention as an invention made by an employee or the like that, by its nature, falls within the scope of the business of the employer or the like, and where the act that led to the invention falls within the present or past duties of the employee at the employer (Article 35, Paragraph 1 of the Patent Act). "Employee or the like" here means an employee, an officer of a corporation, or a national or local public servant, and "employer or the like" means an employer, a corporation, the national government or a local government. Whether something falls within an employee's duties is understood to be determined not only by whether there was a specific order from the employer or whether the work was done during working hours, but by an overall assessment of various circumstances, such as the employee's position and job type and the employer's contribution.

If an invention qualifies as an employee invention and the employee or the employee's successor obtains a patent, the employer automatically acquires a non-exclusive license to that patent by operation of law (Article 35, Paragraph 1 of the Patent Act). This statutory non-exclusive license arises free of charge and is a strong right that can be asserted even if the employee assigns the patent to a third party. For many employers, however, simply being able to work the invention free of charge is not enough, and there are situations where acquiring the right itself is necessary. This is where the ownership structure set out in Paragraphs 2 and 3 of Article 35 becomes important.

Vesting the Right to Obtain a Patent in the Company and Reasonable Benefits

For a free invention (an invention that does not qualify as an employee invention), a provision in a contract or work rules stipulating in advance, before the invention is completed, that the employer will acquire the right to obtain a patent is void (Article 35, Paragraph 2 of the Patent Act). Read conversely, this provision means that for employee inventions, a contract, work rules or other stipulation can provide in advance that the employer acquires the right to obtain a patent. Where such a stipulation exists, the right to obtain a patent belongs to the employer originally, from the moment it arises (Article 35, Paragraph 3 of the Patent Act). Before the 2015 amendment, the principle was that the right first arose in the employee-inventor and was then transferred to the employer. To address practical problems such as the risk of double assignment and the need to obtain consents for joint inventions, the system was changed so that original vesting in the employer is recognized if it is stipulated in a contract or work rules.

This is a point that is easily overlooked when sorting out the rights in employee inventions. Even for an invention that meets the requirements of an employee invention, if the contract or work rules contain no stipulation under Paragraph 3 of Article 35, the right to obtain a patent arises, as a rule, in the inventor personally. The company can still acquire it through a separate assignment procedure or the like, but if it has not done so, the non-exclusive license under Paragraph 1 of Article 35 becomes the issue when the employee or the employee's successor obtains a patent. The mere fact that an employment contract exists does not move the right to obtain a patent itself to the company. It is important to place a clause in the employee invention rules or the work rules providing in advance that the company acquires the rights, and to keep a record of the basis for ownership for each individual invention. Where the right vests originally in the company under Paragraph 3 of Article 35, no further assignment procedure for the same right is needed.

In return for having the rights vest in the employer, the employee has the right to receive reasonable benefits from the employer (Article 35, Paragraph 4 of the Patent Act). Reasonable benefits are not limited to money. They can also include opportunities to study abroad, the grant of stock options, paid leave beyond the statutory minimum, and the grant of an exclusive or non-exclusive license under the patent (Japan Patent Office, "Overview of the Employee Invention System" (Japanese), checked July 11, 2026). Where reasonable benefits are set out in a contract or work rules, they must not be found unreasonable in light of the status of consultations held when the standards for determining their content were established, the status of disclosure of the established standards, the status of hearing the opinions of employees, and so on (Article 35, Paragraph 5 of the Patent Act). The Minister of Economy, Trade and Industry is to establish and publish guidelines on these factors after hearing the opinions of the Industrial Structure Council (Article 35, Paragraph 6 of the Patent Act). Guidelines setting out how the three-stage process of consultation, disclosure and hearing of opinions should be carried out were published as a Ministry of Economy, Trade and Industry public notice dated April 22, 2016 (Japan Patent Office, "Guidelines under Article 35, Paragraph 6 of the Patent Act" (Japanese), checked July 11, 2026). If there is no stipulation on reasonable benefits, or if the benefits provided under the stipulation are found unreasonable, the content of the reasonable benefits is determined by taking into account the amount of profit the employer is to receive, the employer's burden and contribution, the treatment of the employee, and other circumstances. If a dispute arises, the court decides (Article 35, Paragraph 7 of the Patent Act).

How Works Made for Hire under Article 15 of the Copyright Act Differ from Employee Inventions

For source code and documentation written by employees, ownership by the company cannot be explained using the same logic as for patents. The Copyright Act provides for works made for hire (works by a corporation) as a system separate from employee inventions.

For ordinary works, a corporation or other employer (a "corporation, etc.") becomes the author if the following requirements are met: (1) the work is made on the initiative of the corporation, etc.; (2) it is made by a person engaged in the business of the corporation, etc.; (3) it is made in the course of that person's duties; and (4) the corporation, etc. makes it public under its own name as author (Article 15, Paragraph 1 of the Copyright Act). For works of computer programming, in view of the common practice of not publishing the author's name, requirement (4) regarding the name under which the work is published is not required (Article 15, Paragraph 2 of the Copyright Act).

Where these four requirements (three for programs) are met, the corporation, etc. becomes the author unless otherwise stipulated in a contract, work rules or the like at the time the work is made (Article 15, Paragraphs 1 and 2 of the Copyright Act). Unlike employee inventions under patent law, if the requirements of Article 15 of the Copyright Act are met, the corporation, etc. acquires both the copyright and the moral rights of the author as the original author, even without a separate contract or work rules providing that the employer acquires the rights. The right to obtain a patent originally belongs to the employee personally unless there is a stipulation in a contract or work rules, whereas a work made for hire originally belongs to the corporation, etc. if the requirements are met, even without any stipulation in a contract or the like. In this way, patent law and copyright law have structures in which the rule and the exception are reversed.

That said, whether someone is "a person engaged in the business of the corporation, etc." under requirement (2) is determined based on the actual circumstances in addition to whether there is an employment contract. In addition to the name of the contract, the company should look into the content of the work and the reality of direction and supervision. Taking into account the nature of the compensation and other factors as well, it should check whether the person falls within "a person engaged in the business" under Article 15. Article 35 of the Patent Act and Article 15 of the Copyright Act are each assessed according to their own requirements.

Ownership of Rights in Work by Contractors

The "employees or the like" defined in Article 35, Paragraph 1 of the Patent Act are limited to employees, officers of corporations, and national or local public servants. Freelance engineers and employees of other companies that take on development work are, as a rule, not included among these employees. Accordingly, employee invention rules developed for internal use do not automatically apply to inventions made by contractors. Unless ownership of the right to obtain a patent is specifically provided for in the service agreement, the rights remain with the contractor's engineer who made the invention or with the company that engineer belongs to.

For copyright as well, the mere fact of placing an order with an independent contractor does not make the commissioning party the author. On the other hand, the company should not deny work-made-for-hire status across the board solely because there is no employment contract; it should check the requirements of Article 15 against the actual circumstances.

When commissioning outside engineers or designers to develop or create something, whether the intellectual property rights in the deliverables belong to the company should not depend on the internal employee invention rules or on work-made-for-hire treatment. Instead, the service agreement should specifically set out the terms of ownership and licensing. Because a contract with a contracting company does not necessarily bind the actual creators to whom that company has not yet secured the rights, the company should also confirm that the contractor has itself acquired the rights. The agreement should also make clear that the rights under Articles 27 and 28 of the Copyright Act are included in the assignment, and the scope within which the non-assignable moral rights of the author will not be exercised. The perspective of specifically defining the scope of deliverables, the exclusion of pre-existing assets and the scope of non-assertion of moral rights is covered in Checkpoints for Reviewing IP Ownership Clauses, and issues specific to software development agreements regarding acceptance, copyright and OSS are covered in The Basics of Reviewing Software Development Agreements. If the service agreement has no ownership clause, or if the line between pre-existing assets and new deliverables remains vague, the company will be unable to explain whether it can freely modify, redistribute or license the core parts of its product to third parties.

From Invention Disclosure to the Filing Decision and the Reasonable Benefits Process

To operate employee invention rules, the company should set up a procedure for reporting an invention to the company when it arises internally. The invention disclosure form records the inventors and the content of the invention. It should also allow the company to confirm the relationship between the invention and the duties that led to it, as well as the planned timing of any publication or sale. On receiving a disclosure, the company assesses the prospects of novelty and inventive step, the business value, and whether to file an application or keep the invention secret. As discussed in How to Start a Startup's Trademark and IP Strategy, the issues of loss of novelty and trade secret management that should be checked before publication mean that, from the invention disclosure stage onward, the company should check press release and trade show schedules in parallel with filing preparations.

When the company acquires rights in an invention, it should record the procedure by which the right to obtain a patent is acquired by the employer based on the contract or work rules (application of a stipulation for original vesting under Paragraph 3 of Article 35, if there is one; otherwise, an individual assignment agreement), and confirm the conditions for reasonable benefits and the procedure for granting them. Even where the company acquires the rights and keeps the invention confidential, reasonable benefits do not become unnecessary simply because no application is filed. Where the content of reasonable benefits is set out in a contract or work rules, the company should keep records of the status of consultations in establishing the standards, the status of disclosure of the established standards, and the status of hearing the opinions of employees (Article 35, Paragraph 5 of the Patent Act). This three-stage process corresponds exactly to the factors identified in the Japan Patent Office's guidelines, and the company should keep records so that it can explain the consultations and other steps it actually took. The mere existence of documents does not necessarily mean that the content of the benefits will be found reasonable (Japan Patent Office, "Guidelines under Article 35, Paragraph 6 of the Patent Act" (Japanese), checked July 11, 2026). The continuous record from disclosure through the filing decision to payment of reasonable benefits becomes the material for explaining the chain of title for each invention in due diligence.

Classifying OSS Licenses, Their Obligations, and the Treatment of Publicly Available Code

OSS licenses are broadly divided into permissive licenses such as MIT, Apache and BSD, and copyleft licenses such as GPL, LGPL and AGPL. However, whether obligations exist cannot be determined from these category names alone. Even among copyleft licenses, the conditions that trigger obligations and their scope differ from license text to license text, and whether obligations actually arise depends on how the software is used.

Most source code disclosure obligations under copyleft licenses are designed to be triggered by distributing copies of the covered work. If use is limited to internal use or modification and copies are not passed outside the organization, disclosure obligations premised on distribution may not arise. By contrast, Section 13 of AGPLv3 requires that, if you modify the covered program and your version supports interaction with users over a network, you must prominently offer those users an opportunity to obtain the Corresponding Source of that version free of charge. This differs from the explanation that network use itself is deemed distribution; the issue is that when software is provided externally as SaaS, an independent obligation to provide source can arise even in situations that would not constitute conveying copies under the GPL. Rather than assuming that the code of the entire SaaS is unconditionally covered, the company should check how deeply its code is combined with the covered program and the scope of the source that must be disclosed. For details, please check the definitions and Section 13 in the text of the GNU AGPLv3. The scope of obligations also changes depending on the linking method (static or dynamic) and whether the code has been modified. How to read the scope of use common to contracts for licenses from third parties in general is covered in Intellectual Property and Scope of Use to Check When Reviewing License Agreements, but normally OSS is used in accordance with the terms of the OSS license presented. In some cases, however, a dual license or similar arrangement may be available, under which the rights holder separately offers a commercial license.

There is also an easily overlooked misconception about code published on GitHub and similar platforms. Because copyright follows the principle that no formalities are required and arises at the moment of creation, the fact that a repository is public is a separate matter from whether use of the code is licensed. A limited permission under the platform's terms, such as viewing or forking, should also be distinguished from a general license for business use. For repositories without a license file, or code whose terms are unclear, one cannot conclude merely from the fact that it is public that copying, modification, commercial use or redistribution is permitted. The material published by the Information-technology Promotion Agency, Japan (IPA), "Could That Assumption Be a Risk? Five Prescriptions for Clearing Up Misconceptions about OSS," also cites as a typical misconception the belief that code found online is like royalty-free material and can be used in any way (IPA, "Five Prescriptions for Clearing Up Misconceptions about OSS" (Japanese), checked July 11, 2026). When adopting OSS, the company needs to verify, component by component, whether a license is clearly stated and whether its terms are compatible with how the business will use it.

The OSS Register and Approval Records

Operating a register in which OSS use is recorded each time a component is introduced reduces missed checks compared with taking an inventory all at once after the fact. The register should record the component name and version, and the URL of the package registry or repository from which it was obtained. In addition to the license type, it should record whether the component has been modified, the linking method, and whether it is used internally, distributed externally or provided as SaaS. It should also track whether notice obligations, such as including copyright notices or attaching the full license text, have been fulfilled, and whether source code must be provided. The OSPO Starter Kit (draft version) published by IPA on April 16, 2026 includes sample provisions for an OSS policy and operational templates for license compliance, and it is a useful reference when building an internal OSS management system (IPA's announcement (Japanese)).

As an approval flow, a practical approach is for the developer to enter the license and the intended use in the register before introducing a new OSS component, and for the legal or administrative department to confirm consistency with the business's plans for use before approving adoption. If a conflict with license terms is discovered after introduction, the company will be forced to scramble to replace the component or to decide whether it must disclose source code it never expected to disclose.

The evidence that should be checked before a release or before fundraising can be organized into the following three items. The first is records relating to employee inventions: invention disclosure forms, the clauses in contracts or work rules supporting succession to the right to obtain a patent, and records of payment of reasonable benefits. The second is a list of the intellectual property ownership clauses in service agreements and the status of rights transfer for each deliverable. The third is the OSS register and records of license review. These are also matters that should be kept in order on an ongoing basis, in parallel with the review of capital policy and contracts covered in A Legal Checklist to Review Before Series A.

Concrete actions that can be started on the next business day are to compile a list of inventions disclosed in the last six months and confirm whether the procedures for succession to the right to obtain a patent have been completed, and to ask the development team to take stock of the current OSS components. If there is no register yet, start by checking the licenses using the dependency files of the main repositories as a starting point. However, also inspect indirect dependencies and code that was brought in manually, check for omissions in extraction and errors in license identification, and proceed by supplementing the actual usage by hand. Building a legal framework that includes employee invention rules and OSS management is described on the Startup Legal and Fundraising Support page.

Frequently asked questions

Does code or an invention developed by an employee during working hours belong to the company simply because the company employs them?

Not necessarily. Unless a contract or employment rules provide in advance that the employer or the like will acquire the right to obtain a patent, the right to obtain a patent originally vests in the employee or the like who made the invention, even if the invention satisfies the requirements of an employee invention, and the employer or the like has only the statutory non-exclusive license under Article 35, paragraph 1 of the Patent Act (Article 35, paragraphs 2 and 3 of the Patent Act). For works, if the requirements of Article 15 of the Copyright Act are met, namely that the work is made on the initiative of the corporation or the like, by a person engaged in its business, in the course of their duties (and, except for works of computer programming, is also published under the corporation's name), the corporation or the like becomes the original author even without a contract. However, this determination is based on requirements different from those for patents, so the two cannot be explained with the same reasoning.

If we incorporate OSS published under the GPL, do we always have to disclose our own source code?

Not necessarily. Many disclosure obligations under copyleft licenses are designed to be triggered by the distribution of copies of the covered work. In forms of use that do not involve distribution, such as using the software only internally without modification, the same obligations may not arise. On the other hand, some licenses, such as the AGPL, also cover the provision of services over a network, so care is needed when offering the software as SaaS. The form of use and the license text need to be checked on a case-by-case basis.

At what stage should we set up an OSS register and an approval flow?

A system in which, each time a new OSS component is introduced, you record the component name, version, source, license and form of use (whether it is modified, distributed or provided as SaaS, and so on), and designate a person in charge of checking it before introduction, is less burdensome than taking inventory all at once later. In due diligence for financing or M&A, it is checked whether you can submit this register together with records of employee invention notifications and succession and a list of the intellectual property ownership clauses in your service agreements.