Can you license data from open-source projects your company maintains?

What is already licensed, and what is not#

Open-source code is already licensed: anyone may use it under the project's license, permissive or copyleft, so a data buyer does not need your permission to read the public repository. What it cannot get from the public repository is the material your company holds privately and the structure that ties public activity to internal decisions.

That changes the question. Instead of asking whether you can license the project, ask which records around the project the company actually owns, and whether they add something the public record lacks, such as the reasoning behind a rejected design or the triage notes behind a security fix.

Why outside contributors change the answer#

Outside contributors change the answer because, under US copyright law, the person who writes text owns it unless it is a work made for hire or the rights were transferred. The Copyright Office explains that a work prepared by an employee as part of regular duties is a work made for hire, and the employer is considered the author and owner. A volunteer's issue report or review comment has no such employment link to your company.

Contributor license agreements and sign-off processes help less than many teams expect. They are usually written for contributions submitted to the repository, meaning code and documentation, and may say nothing about issue comments, discussion threads or reviews. Read the definitions in any agreement your project has used before treating discussion as covered.

Platform terms add another layer. The hosting platform sets its own terms for content posted there, so the terms of the platform where the discussion lives belong in the rights review.

Which records are worth the effort?#

The records worth the effort are the ones that connect public activity to private reasoning. A public issue shows the bug report; the internal thread shows how maintainers reproduced it, why they chose one fix over another, and what they told an enterprise customer while it was open.

Linking is where most of the value is created. A dataset that joins each public pull request to the internal ticket, the employee review thread and the release it shipped in shows a full engineering loop: problem, discussion, change, review and outcome. Teams building coding assistants and evaluation sets look for that sequence, and only the maintaining company can assemble it from private systems.

Support tickets from a commercial edition bring their own rights questions, because customer contracts may limit reuse of support content. They belong in the rights review rather than in a default package.

• 1Internal Jira or Linear tickets that mirror public issues, with maintainer notes.
• 2Slack threads where employees debated design choices, deprecations and release timing.
• 3Code review discussions among employees, including approaches that were rejected.
• 4Release checklists, incident records and postmortems for the hosted or enterprise edition.
• 5Support tickets from paying customers of a commercial edition, subject to customer contracts.

How to check rights before any package is built#

A rights check for an open-source program runs in three passes: authorship, then contracts, then privacy. The order matters because each pass removes records before the next one has to look at them, which keeps the privacy work focused on material that can actually be licensed.

Use organization membership history and employment dates rather than current status. Many developers contribute both personally and on company time, and someone who left the company may still have written years of company-owned discussion.

• 1Separate employee accounts from outside accounts using identity provider and organization membership records.
• 2Collect every contributor agreement, sign-off policy and code of conduct the project has used, with dates.
• 3List the project licenses and platform terms that apply to each repository and discussion space.
• 4Flag embargoed security material, customer-specific forks and anything covered by a customer NDA.
• 5Plan removal of usernames, emails, tokens and other secrets from commit metadata, logs and threads.
• 6Record the final inclusion and exclusion rules so a buyer can see exactly what was licensed.

Illustrative: a company behind an open-source workflow engine#

Illustrative: a fictional software company maintains an open-source workflow engine and sells an enterprise edition with hosting and support. Its public repository has an active community of outside contributors, while its private systems hold Jira tickets, Slack channels and enterprise support tickets.

Counsel concludes that public code and outside contributors' issues will not be licensed. The company scopes a package of employee-written internal tickets, maintainer design threads and code review discussions among employees, linked to public pull request identifiers but not reproducing contributor text. Enterprise support tickets are held back pending a review of customer contracts.

The result is a smaller package with clean rights: every included record was written by an employee or generated by company systems, and the exclusion rules are documented for the buyer.

How SourceX approaches open-source programs#

SourceX approaches an open-source program as two record sets: what anyone can already read, and what the company privately holds. The Rights step of the SourceX five-step transaction focuses on the second set, sorting employee authorship from contributor authorship and checking contributor agreements and customer contracts.

The SourceX Enterprise Data Value Framework explains why the private side matters. Uniqueness, domain expertise and human-generated signal increase value, while reproducibility reduces it, and public code that anyone can download is highly reproducible.

The initial assessment uses metadata only, such as systems, years of history and the mix of employee and outside contributors. If a package proceeds, the SourceX Evidence Packet documents provenance and the exclusion rules, so the buyer can see which records were left out and why.