Open-source contribution by employees.
1. Introduction
Open-source contribution by employees refers to the participation of employees in developing, modifying, testing, documenting, maintaining, or distributing software under an open-source licence, either as part of their employment or in their personal capacity.
Open-source software is software whose source code is made available under a licence that permits specified uses, modification, and redistribution, subject to the licence's terms.
Examples include employees contributing code to Linux, Apache projects, Mozilla, Python libraries, or GitHub-hosted projects.
The main legal issue is determining who owns the contributed code, whether the employee is authorised to publish it, and whether the contribution complies with the open-source licence and the employer's policies.
For example, an employee working for a software company may independently improve a public programming library on weekends. Even though the contribution is unpaid, questions may arise if the employee used company equipment, relied on confidential company information, or created the improvement within the scope of employment.
Open-source contributions can benefit employees, employers, and the wider technology community. However, they can also create disputes involving copyright ownership, trade secrets, patents, employment contracts, licence obligations, and commercial interests.
2. Legal framework in India
Several Indian laws are relevant to employee contributions to open-source projects.
A. Copyright Act, 1957
Computer programs are protected as literary works under the Copyright Act, 1957.
Section 17 addresses first ownership of copyright. Under its general employment-related rule, an employer is ordinarily the first owner of copyright in qualifying works made by an employee in the course of employment under a contract of service or apprenticeship, subject to statutory exceptions and agreements to the contrary.
However, not every piece of code written by an employee automatically belongs to the employer. Relevant factors include the employee's duties, the circumstances in which the code was developed, contractual terms, and the applicable statutory rules.
B. Indian Contract Act, 1872
Employment agreements, confidentiality agreements, intellectual property assignments, and open-source contribution policies may create contractual obligations.
An employee who breaches a valid contractual obligation may face contractual remedies, subject to the terms of the agreement and applicable law.
C. Patents Act, 1970
An open-source contribution may involve patentable inventions or technology covered by existing patents.
Publishing code under an open-source licence does not necessarily resolve every patent question. The employee and employer should consider patent ownership, any applicable licence grants, and the project's contribution policy.
D. Information Technology Act, 2000
The Act may be relevant where contributions involve unauthorised access to computer systems, misuse of credentials, or other conduct covered by its provisions.
E. Trade-secret and confidentiality principles
India does not have a single comprehensive trade-secret statute equivalent to some foreign regimes. Confidential information may be protected through contracts and applicable legal principles.
Employees must not assume that information becomes public merely because it is useful for an open-source project or because a similar technology exists publicly.
3. Important case laws
Direct reported cases specifically about employees contributing to open-source projects are relatively limited. The following Indian and international decisions establish relevant principles concerning employee-created software, copyright ownership, confidential information, and open-source licensing.
Case 1: Community for Creative Non-Violence v. Reid (1989)
Court: Supreme Court of the United States.
Citation: 490 U.S. 730 (1989).
Facts: The dispute concerned ownership of copyright in a sculpture commissioned by an organisation from an independent artist.
Legal principle: The Court examined whether the artist was an employee or an independent contractor and established factors for determining employee status under the applicable US copyright law.
Relevance to open-source contributions: The case helps explain why the legal relationship between a contributor and an organisation matters when determining copyright ownership. The applicable rules differ by jurisdiction, and US work-made-for-hire law is not identical to India's Copyright Act.
Practical lesson: Employers should clearly document employment status, software ownership, and any separate arrangements permitting employees to contribute code to external projects.
Case 2: Avtec Systems, Inc. v. Peiffer (1994)
Court: United States Court of Appeals for the Fourth Circuit.
Citation: 21 F.3d 568 (4th Cir. 1994).
Facts: The dispute involved software developed by an individual who had worked with a company and questions about the ownership and use of computer programs.
Legal principle: The case considered copyright ownership in software created in an employment-related context and the importance of the relationship between the work and the employer's business.
Relevance to open-source contributions: Employees who develop code as part of their assigned duties may not be free to publish that code independently without the employer's permission.
Practical lesson: Before releasing employee-developed code under an open-source licence, organisations should determine whether they own the copyright and whether the employee has authority to license it.
Case 3: Jacobsen v. Katzer (2008)
Court: United States Court of Appeals for the Federal Circuit.
Citation: 535 F.3d 1373 (Fed. Cir. 2008).
Facts: Robert Jacobsen made software available under the Artistic License. He alleged that another party incorporated the software into a competing product without complying with licence requirements, including attribution and disclosure of modifications.
Legal principle: The Court held that conditions in an open-source copyright licence may be enforceable copyright conditions rather than merely contractual promises. The case was remanded for further proceedings.
Relevance to employees: Employees who contribute to open-source projects must understand that making code freely available does not mean that all licence requirements can be ignored.
Practical lesson: Employees and employers should review attribution requirements, notices, modification disclosures, and redistribution conditions before incorporating open-source code into products.
Case 4: MDY Industries, LLC v. Blizzard Entertainment, Inc. (2010)
Court: United States Court of Appeals for the Ninth Circuit.
Citation: 629 F.3d 928 (9th Cir. 2010).
Facts: The case concerned software used with the online game World of Warcraft and the relationship between contractual restrictions and copyright infringement.
Legal principle: The Court distinguished licence conditions whose breach may constitute copyright infringement from contractual covenants whose breach does not, by itself, establish copyright infringement.
Relevance to open-source contributions: A violation of a project licence or contribution agreement does not automatically amount to copyright infringement in every jurisdiction or circumstance. The wording of the licence and the nature of the obligation matter.
Practical lesson: Organisations should distinguish copyright conditions, contractual obligations, and internal employee policies instead of treating every policy violation as the same type of legal breach.
Case 5: R.G. Anand v. Deluxe Films (1978)
Court: Supreme Court of India.
Citation: (1978) 4 SCC 118.
Facts: The case concerned an allegation that a film had copied a dramatic work.
Legal principle: Copyright generally protects original expression rather than abstract ideas, themes, or concepts alone. Infringement depends on the relevant similarities and the applicable legal test.
Relevance to employees: An employee may independently contribute code based on a general programming technique or publicly known concept. However, copying protected source code, documentation, or other copyrightable expression may raise infringement issues.
Practical lesson: Employers should assess whether a contribution reproduces protected material rather than assuming that all technically similar code is necessarily infringing.
Case 6: John Richard Brady v. Chemical Process Equipments Pvt. Ltd. (1987)
Court: Delhi High Court.
Facts: The dispute concerned technical information, drawings, and confidential knowledge associated with industrial equipment.
Legal principle: Courts may protect confidential technical information where the relevant legal requirements are established.
Relevance to employees: An employee cannot assume that proprietary algorithms, technical specifications, internal documents, or confidential source code may be published in an open-source repository merely because doing so would benefit the developer community.
Practical lesson: Employees should obtain authorisation before releasing code that may contain trade secrets or confidential information belonging to their employer or a client.
Case 7: Burlington Home Shopping Pvt. Ltd. v. Rajnish Chibber (1995)
Court: Delhi High Court.
Facts: The dispute involved a commercially valuable database and allegations relating to its use.
Legal principle: The case is relevant to the protection of commercially valuable compilations and confidential business information, depending on the applicable legal requirements.
Relevance to employees: Open-source contributions must not expose customer databases, private datasets, internal business information, or proprietary collections of information without proper authorisation.
Practical lesson: Before releasing code or sample data, employees should check for embedded credentials, customer records, confidential datasets, and other sensitive material.
Case 8: Microsoft Corporation v. Ms. K. Mayuri and Others (2007)
Court: Delhi High Court.
Facts: The proceedings concerned Microsoft's copyright claims involving computer programs and unauthorised software use.
Legal principle: Computer programs receive copyright protection under the applicable copyright framework, and unauthorised use may attract legal consequences where infringement is established.
Relevance to employees: Software employees should verify that the code they contribute or redistribute is theirs to license, or that they have the necessary permissions. Employer ownership and third-party copyright must both be considered.
Practical lesson: An employee should not upload proprietary company software to a public repository merely because they wrote or maintained it.
4. Common legal risks
Copyright ownership
Code developed during employment may belong to the employer under applicable law or contract. Personal contributions should be clearly separated from assigned work.
Confidentiality and trade secrets
Internal algorithms, credentials, business logic, customer information, and unpublished technical material must be screened before publication.
Licence compliance
Licences may impose obligations relating to attribution, source-code distribution, notices, modifications, or downstream redistribution.
Third-party code
Copying code from another project without checking its licence can create copyright, licence-compliance, and product-distribution risks.
Conflicts of interest
Contributions to competing projects may conflict with employment duties, confidentiality obligations, or properly drafted company policies.
5. Employer policies and best practices
Employers should establish a written open-source contribution policy that addresses the following matters:
Pre-approval: Identify when employees need permission before contributing to external repositories.
Ownership: Clarify the ownership of code created within assigned duties and any exceptions for personal projects.
Personal projects: Establish rules for contributions made outside working hours using personal equipment.
Confidentiality: Prohibit the unauthorised publication of trade secrets, client information, and proprietary code.
Licence review: Check licence compatibility before incorporating open-source components into commercial products.
Contribution records: Maintain records of approvals, contributors, code provenance, and relevant licences.
Security review: Scan for credentials, vulnerable dependencies, malicious code, and sensitive information.
Patent review: Determine whether contributions involve patent rights or licensing obligations.
Exit procedures: Address continuing confidentiality duties and the handling of company-owned repositories when an employee leaves.
Training: Educate employees about copyright, licensing, code ownership, and the company's contribution procedures.
6. Practical example
Suppose an employee of a software company improves an open-source Python library during weekends.
If the work is genuinely independent, does not use confidential company information, and falls outside any applicable employment ownership terms, the employee may be able to contribute it personally.
If the improvement is part of the employee's assigned duties or is covered by a valid intellectual property agreement, the employer may own the relevant rights or have contractual approval rights.
If the code contains confidential company algorithms or client information, publishing it may breach confidentiality obligations.
If the contribution includes code under a third-party licence, the employee must check whether the proposed reuse and distribution comply with that licence.
The result depends on the facts, the applicable law, and the employment and licence agreements. Merely working outside office hours does not automatically settle ownership.
7. Conclusion
Open-source contribution by employees supports collaboration, technical learning, innovation, and software quality. Nevertheless, it requires a clear understanding of intellectual property ownership, confidentiality, employment duties, and licence compliance.
The cases discussed establish useful principles concerning employee-created works, protected expression, confidential technical information, and the enforceability of open-source licence conditions. Their legal rules must be applied according to the jurisdiction and circumstances rather than treated as interchangeable.
The best approach is to adopt a transparent contribution policy, document ownership and permissions, review third-party licences, protect confidential information, and encourage lawful employee participation in open-source communities.
Legal note: The international decisions are persuasive illustrations of relevant principles, not binding Indian precedents. The precise legal position depends on Indian law, the employment agreement, the relevant open-source licence, and the facts of the contribution.

comments