Software, Data, and Open Source Toolkit: Code, Licenses, and the Supply Chain

By Casey Scott McKay · 2026-01-23

Every software product is assembled from code somebody else wrote under terms nobody read, sits on data whose ownership is unclear, and depends on a supply chain that carries obligations into the finished product. This toolkit maps the whole stack: what copyright actually protects in code and what filtration removes, how copyleft obligations propagate and when they force source disclosure, why trade secret protection is the real backbone of software IP, what a scraping program can and cannot lawfully do, and how the ownership of data differs from the ownership of the code that processes it. It covers the compliance program - inventory, policy, review gate, remediation - that turns an unmanaged dependency tree into a defensible one, plus the diligence questions that reprice software transactions. It closes with a cost map, an authorities table, and the forms that paper each step.

IP and Technology > Information Technology | Toolkit | Published 23 January 2026 - Updated 13 August 2026 | Casey Scott McKay - marksy.us

Summary. Every software product is assembled from code somebody else wrote under terms nobody read, sits on data whose ownership is unclear, and depends on a supply chain that carries obligations into the finished product. This toolkit maps the whole stack: what copyright actually protects in code and what filtration removes, how copyleft obligations propagate and when they force source disclosure, why trade secret protection is the real backbone of software IP, what a scraping program can and cannot lawfully do, and how the ownership of data differs from the ownership of the code that processes it. It covers the compliance program — inventory, policy, review gate, remediation — that turns an unmanaged dependency tree into a defensible one, plus the diligence questions that reprice software transactions. It closes with a cost map, an authorities table, and the forms that paper each step.

Keywords: open source compliance · copyleft · gpl · permissive licenses · software bill of materials · supply chain · software copyright · structure sequence organization · abstraction filtration comparison · trade secrets · dtsa · data scraping · cfaa · database rights · api · contributor license agreement · dual licensing · license compatibility · remediation · source disclosure obligation

Start Here

Amadika Tervell is general counsel of a company that sells logistics software. A prospective acquirer's diligence produces four findings in one week, and each one is a different problem.

The dependency tree has eleven hundred packages, of which the engineering team can account for about forty. Three carry strong copyleft licenses and appear to be linked into the distributed product.

A core routing algorithm was written by a contractor in 2019 under a statement of work that says nothing about intellectual property.

The product's principal data asset — a database of facility characteristics assembled over six years — was built substantially by scraping public sources, some of which had terms prohibiting exactly that.

And two engineers who left last year now work for a competitor whose product shipped a suspiciously similar feature four months after they arrived.

Four findings. Four bodies of law: license compliance, copyright ownership, data and access law, and trade secrets. Each is survivable; together they reprice the deal.

This toolkit answers three questions.

What do you actually own? Code ownership, data ownership, and the difference between them.
What obligations came in with the code? And which of them reach the product you ship.
What program prevents this? Inventory, policy, a review gate, and remediation — none of it exotic, all of it usually absent.

If you read only one thing, read Copyleft and Consequences. Open source obligations are the finding that most often stops a transaction, and they are entirely preventable with a process that costs almost nothing.

Part One: What Copyright Protects in Code

Source and object code are literary works. 17 U.S.C. § 102(a)(1) protects them, and 17 U.S.C. § 101 defines a computer program as a set of statements or instructions used directly or indirectly in a computer to bring about a certain result.

But protection is thinner than clients assume. 17 U.S.C. § 102(b) excludes ideas, procedures, processes, systems, and methods of operation. In software, that exclusion does enormous work.

The analytical method. Courts apply an abstraction-filtration-comparison approach: break the program into levels of abstraction, filter out at each level the elements dictated by efficiency, dictated by external factors, or taken from the public domain, and compare what remains.

What survives filtration is often much less than the plaintiff hoped — and this is the single most important thing to tell a client contemplating a software copyright claim.

Structure, sequence, and organization can be protectable, but the analysis is fact-intensive, and where interface elements are at issue the fair use question looms large. A declaring interface reimplemented to permit developers to use their existing skills has been held a fair use in a major case, which reshaped expectations about API protection.

Practical consequences. Register the code — 17 U.S.C. § 411 requires it to sue and 17 U.S.C. § 412 conditions statutory damages and fees on timely registration. Use the deposit rules that permit redaction so registration does not publish trade secrets. And understand that the strongest software IP claim is usually a trade secret claim rather than a copyright one. See Copyright in Code; Proving or Defending a Software Copyright Claim; Software Copyright Checklist.

Part Two: Open Source and the Supply Chain

The basic mechanics. Open source code is licensed, not free. The license is a grant with conditions, and using the code outside the conditions is infringement.

Two families, roughly.

Permissive licenses require attribution, notice preservation, and sometimes a disclaimer, and otherwise permit combination with proprietary code and distribution without source. Compliance is mostly a matter of shipping the right notices — which sounds trivial and is nonetheless the most commonly missed obligation in the entire field.

Copyleft licenses require that derivative or combined works be distributed under the same license, with source available. Strong copyleft reaches the combined work; weaker copyleft reaches only the modified library. Network copyleft extends the trigger to providing the software as a network service, which is the provision that surprises software-as-a-service businesses that believed they never distributed anything.

The trigger question. Most copyleft obligations attach on distribution, not on internal use. A company using copyleft code purely internally generally has no source disclosure obligation. A company shipping software, embedding it in a device, or providing it under a network-copyleft license may.

The linking question. Whether combining code creates a derivative work subject to copyleft is contested and depends on the license text, the technical nature of the combination, and the jurisdiction. Static linking, dynamic linking, and inter-process communication sit at different points on the spectrum, and the honest answer for many combinations is that it is unsettled. Engineering decisions made in ignorance of this question routinely create obligations the business never intended.

Compliance obligations, concretely. Preserve copyright and license notices. Provide the license text. Provide attribution where required. Provide source or a written offer for source where copyleft applies. Preserve modification notices. Comply with any patent and trademark terms.

Remediation, when something is found. Remove and replace the component; obtain a commercial license where dual licensing is available; re-architect to break the combination; or comply, which means releasing source. Each is expensive in a different currency, and the cost rises steeply the later it is discovered.

See Running an Open Source Compliance Program.

Part Two-and-a-half: Reading a License Before You Rely On It

Open source licenses are short documents that engineers skim and lawyers over-abstract. Six questions extract everything that matters from any of them in about ten minutes.

One: what triggers the obligations? Use, modification, distribution, or provision as a network service. This single question separates the licenses that will never affect an internal tool from the ones that reach a hosted product.

Two: what is the scope of the reciprocal obligation, if any? The modified file, the modified library, the linked work, or the whole combined program. Licenses differ enormously here and the difference is the entire copyleft question.

Three: what must be delivered? Notices, license text, attribution, modification statements, source code, build scripts, installation information. "We ship the license file" is compliance with some licenses and not with others.

Four: what happens on breach? Some licenses terminate automatically on non-compliance, with or without a cure period. A terminated license means the use is infringement from that point forward, and a cure provision is worth knowing about before a compliance notice arrives.

Five: what does it say about patents? Express patent grants, defensive termination on filing a patent claim, and retaliation clauses. A company with a patent program should know which of its dependencies would terminate if it asserted a patent against a contributor.

Six: what does it say about trademarks? Most licenses expressly withhold trademark rights, which means using the project's name to market your product is a separate question from using its code.

And a seventh, for the unusual licenses: does it impose field-of-use restrictions, ethical-use conditions, or commercial-use limitations? A growing number of licenses do, and some are not open source in the conventional sense at all. Those belong on the review list regardless of how permissive they look.

The reason to do this per license, once, and record it. The policy classification in the compliance program is only as good as the analysis behind it, and a short internal note for each license family — trigger, scope, deliverables, termination, patent, trademark — is a durable asset that makes every subsequent review a lookup rather than a project.

Part Three: The Compliance Program

Four components. None is complicated; the difficulty is entirely in doing them consistently.

One: inventory. A software bill of materials listing every component, its version, its license, and where it is used. Automated scanning generates the list; a human reconciles it, because scanners produce both false positives and confident misidentifications.

Two: policy. A written policy classifying licenses into approved, approved-with-conditions, requires-review, and prohibited, mapped to how the component will be used — internal tool, distributed product, network service, embedded device. The same license can be fine in one context and fatal in another, which is why the policy must be use-aware rather than license-only.

Three: a review gate. New dependencies pass through review before they enter the build. This is the component that actually prevents problems, and it is the one engineering resists most. Make it fast: a pre-approved list covering the common permissive licenses that requires no review at all, and human review only for what falls outside it.

Four: notice generation and remediation. Automated assembly of the attribution file that ships with the product, and a documented process for handling a finding.

Plus contributor paperwork. A contributor license agreement or developer certificate of origin for inbound contributions, so the project's own provenance is clean. And where your company releases open source, a deliberate decision about which license, made with the business model in mind.

The diligence payoff. A company with a current bill of materials, a written policy, and evidence of a review gate passes software diligence in days. A company without them spends weeks in remediation while the transaction waits, and sometimes reprices.

Part Four: Trade Secrets, the Real Backbone

For most software businesses, trade secret protection carries more weight than copyright.

What it protects. Information deriving independent economic value from not being generally known, subject to reasonable measures to maintain secrecy. 18 U.S.C. § 1839(3). Algorithms, architecture, model weights, training data, customer data, pricing logic, and the accumulated engineering knowledge that filtration would strip out of a copyright claim.

The federal cause of action. The Defend Trade Secrets Act at 18 U.S.C. § 1836 provides a civil action for misappropriation of a trade secret related to a product or service used in interstate commerce, with injunctive relief, damages, exemplary damages for willful and malicious misappropriation, fees, and — in extraordinary circumstances — civil seizure.

"Reasonable measures" is the whole case. Access controls, confidentiality agreements, labeling, network segmentation, onboarding and exit procedures, vendor agreements, and physical controls. A company that has not taken them does not have trade secrets, whatever its documents say.

The departure problem is where most software trade secret cases begin. Exit interviews, certified return of materials, forensic imaging of devices where warranted, and access revocation on the day of departure. See Trade Secrets and the DTSA; Building a Trade Secret Program That Survives Litigation; Trade Secret Protection and Departure Checklist.

The employee mobility overlay. Restrictive covenants are increasingly constrained and vary sharply by jurisdiction, which raises the importance of the trade secret claim relative to the covenant claim. See Where an Employee Can Go.

The disclosure tension. Filing suit requires identifying the trade secret with particularity, which means disclosing it under protective order. That tension is real and should be discussed with the client before filing.

Part Five: Data

Data ownership is the area where client intuitions are most consistently wrong.

Facts are not copyrightable. A compilation may be protected as to its selection, coordination, and arrangement if those reflect originality — and that protection is thin, extending only to the original elements and not to the underlying facts.

So what protects a database? Contract, principally. Terms of use, subscription agreements, and API terms create obligations that copyright does not. Plus trade secrecy where the data is genuinely secret, plus technical access controls, plus — in some jurisdictions outside the United States — a sui generis database right with no U.S. analogue.

Scraping. The legal exposure is a stack rather than a single question: computer access law, breach of contract where terms were accepted, copyright where protectable expression is copied, trespass to chattels in narrow circumstances, and privacy obligations where the data is personal.

Computer access law has narrowed. The Computer Fraud and Abuse Act at 18 U.S.C. § 1030 has been read to focus on circumventing access barriers rather than on violating terms of use, which means scraping publicly available data without bypassing authentication is generally outside its core prohibition. That does not make scraping lawful — contract, copyright, and privacy claims remain — and it does not resolve the state-law analogues.

Practical rules for a scraping program. Document the sources and their terms. Do not bypass authentication or technical barriers. Respect rate limits. Take facts rather than expression. Assess personal data separately, because privacy obligations do not turn on ownership. And keep a record of the decisions, because the program will eventually be questioned. See Who Owns the Data; Running or Defending a Data Scraping Program; Data Collection and Scraping Risk Checklist.

The privacy layer sits on top of all of it. Ownership and lawfulness are different questions, and a company that owns data may still be prohibited from using it. See The Data Behind the Marketing; Privacy and Marketing Data Toolkit.

Part Five-and-a-half: Where Software IP Fits Together

Clients ask which protection they should rely on, and the honest answer is all of them, for different parts, at different times.

Copyright protects the literal code and, more thinly, its structure. It is cheap to obtain, it supports takedowns, and its remedies are meaningful where registration was timely. It is weak against a competitor who understands the product and reimplements it, because filtration strips out the ideas, the interfaces, the efficient solutions, and everything dictated by external constraints.

Trade secret protects what is not disclosed — the architecture nobody sees, the tuning nobody publishes, the data nobody has. It is free to obtain and expensive to maintain, and it evaporates on disclosure. It is the strongest protection for exactly the material copyright filters out, which is why the two are complements rather than alternatives.

Patents protect the claimed invention against independent development, which nothing else does. Subject-matter eligibility under 35 U.S.C. § 101 has narrowed what is available in software considerably, and the cost is real, but for a genuinely novel technical solution a patent is the only right that stops a competitor who invented the same thing independently.

Contract protects everything else, and in practice does most of the work: license terms, confidentiality obligations, access agreements, and API terms create obligations that no property right supplies.

Trademark protects the name, which is frequently the most durable asset of the four. Codebases get rewritten; the brand persists.

The allocation for a typical software business. Register the code and the releases. Run a real trade secret program, because that is where the value actually sits. Patent selectively and only where the claim would be worth enforcing. Paper everything contractually. And protect the name properly, because in ten years it may be the only one of the five that still matters.

Part Six: Ownership Paperwork

The 2019 contractor in the opening scenario is the most common single defect in software portfolios.

Employees. Work made for hire vests in the employer where the work is prepared within the scope of employment. 17 U.S.C. § 201(b). Confirm the scope, and use an assignment agreement anyway.

Contractors. Software is not among the categories eligible for commissioned work-made-for-hire treatment under 17 U.S.C. § 101, so a "work for hire" recital in a contractor agreement does not, by itself, transfer the copyright. A present-tense written assignment is required, signed by the contractor.

Transfers must be in writing. 17 U.S.C. § 204(a) requires a signed writing for any transfer of copyright ownership.

Termination rights. Grants by individual authors are subject to statutory termination windows decades later under 17 U.S.C. § 203, which matters for long-lived codebases with individual-author contributions.

Open source contributions in, and out. Inbound contributor agreements clarify what the project receives; outbound license selection determines what others may do with what you release.

See Who Owns the Work; Transfers, Licenses, and Termination Rights; Copyright Ownership and Chain of Title Checklist.

Part Seven: The AI Layer

Generative tooling now sits inside most development workflows, and it raises three questions the compliance program must answer.

Authorship of generated code. Material without sufficient human authorship is outside copyright, which affects what a company can register and enforce in its own codebase. Where generated code is a component of a larger human-authored work, the analysis is about the human contribution.

Provenance of training data and outputs. Whether generated output reproduces licensed code is a real question for a compliance program, and it is why some organizations restrict generative tooling in code paths destined for distribution.

Contractual allocation. Vendor terms differ substantially on ownership of outputs, indemnification, and whether inputs are used for training. Read them, and align the engineering policy to what the terms actually permit.

See Who Owns What the Machine Made; Deploying Generative AI Without Losing Your IP; Generative AI IP Compliance Checklist; AI, Content, and IP Toolkit.

Part Eight: Diligence

The questions that matter in a software transaction.

Is there a current software bill of materials, and does it reconcile to the build?
What copyleft components are present, and does the product's distribution model trigger their obligations?
Are attribution notices actually shipping?
Is there a written assignment from every contributor who was not an employee?
Are trade secret measures documented and current?
What data does the product depend on, where did it come from, and under what terms?
Are there outstanding third-party license obligations, audit rights, or compliance notices?
What generative tooling is in the development pipeline, and under what terms?

The findings that reprice deals, in rough order of frequency: unmanaged copyleft, missing contractor assignments, undocumented data provenance, and absent trade secret measures.

The remediation calendar. Every one of these takes weeks to fix and days to prevent. See IP Due Diligence Toolkit.

Cost Map

| Item | Relative cost | When | |---|---|---| | Automated dependency scanning | Low, recurring | Continuous | | Human reconciliation of the scan | Moderate, recurring | Quarterly | | Written policy and review gate | Low, one-time plus upkeep | Now | | Contributor and contractor assignments | Very low | At engagement | | Copyright registration of releases | Low, in batches | Per major release | | Trade secret program | Moderate | Ongoing | | Remediation of a copyleft finding | High to very high | Under deal pressure | | Trade secret litigation | Very high | Rarely, deliberately |

The ratio. The whole preventive program costs less than a single week of deal-driven remediation, and it is the difference between a diligence process that takes days and one that takes months.

What Happened at Amadika's Company

The dependency tree was scanned, reconciled by hand, and reduced to a defensible bill of materials in about five weeks. Of the three strong-copyleft components, one was not actually linked into the distributed product and was removed from the concern; one had a commercial dual license, which was purchased; and one was replaced with a permissively licensed equivalent at a cost of about three engineering weeks. The attribution file — which had never shipped — was generated and included.

The 2019 contractor signed a confirmatory assignment for a modest payment. He was cooperative, which is the common case and also the reason to do this early: the leverage runs the other way once a transaction is announced.

The scraped database was the hardest finding. Counsel sorted the sources into three groups: public data with no restrictive terms, which was fine; public data with terms prohibiting automated collection, which was a contract exposure requiring a decision; and one source where authentication had been used, which was the only genuinely serious item and which was excised along with everything derived from it. Going forward, the company adopted a documented source-approval process.

The departed engineers produced no litigation. A forensic review found no evidence of exfiltration, the company's own trade secret measures turned out to be adequate on the technical side and thin on the paperwork side, and the remediation was a proper exit process rather than a lawsuit. That is the ordinary outcome, and companies that assume otherwise spend a great deal on cases that do not exist.

The deal closed at the original price, about eleven weeks later than planned. The eleven weeks were the entire cost of not having had a compliance program, and the program that was built during them costs roughly nothing to maintain.

Part Nine: Releasing Your Own Open Source

Companies increasingly publish code, and the decision is strategic rather than merely legal. Five questions decide it.

What is the business reason? Recruiting, ecosystem adoption, standardization, commoditizing a competitor's differentiator, or reducing your own maintenance burden. Each points to a different license and a different governance model, and a release with no articulated reason accumulates obligations without benefit.

Which license? A permissive license maximizes adoption and gives up the ability to require reciprocity. A copyleft license preserves reciprocity and deters commercial adoption by companies whose compliance programs prohibit it. A dual-licensing model — copyleft for the community, commercial for those who cannot accept it — is a revenue model rather than a license choice, and it requires that the company hold all the rights, which means contributor agreements from everyone.

Who owns the contributions? Inbound contributor license agreements or developer certificates of origin. Without them, a project accumulates code the company does not own, which forecloses relicensing, dual licensing, and any transaction that depends on clean title.

What is not being released? Draw the line explicitly and enforce it in the build. The most common failure is a release process that pulls in internal modules nobody meant to publish, and the second most common is a repository whose history contains credentials or proprietary code that was later removed from the tip but remains in the commit log.

What happens to the trademark? The project name is a trademark, and the license grants no rights in it. Decide whether to allow forks to use the name, whether to require a distinguishing name for modified versions, and whether to publish a trademark policy. Projects that skip this find their name attached to distributions they do not control. See Naked Licensing; Brand Licensing Program Toolkit.

And a governance question that is not legal but determines everything. Who accepts contributions, who decides direction, and what happens if the company loses interest. A published governance model is what separates a project from a code dump, and it is what determines whether the ecosystem benefit the release was meant to produce actually materializes.

Part Ten: Responding to a Compliance Notice

Notices arrive — from a community enforcement organization, a copyright holder, a customer's diligence team, or a competitor. The response pattern matters.

Do not ignore it, and do not concede immediately. Many notices are correct in substance and imprecise in scope, and the useful first response acknowledges receipt, asks for the specific component and version at issue, and commits to a timeline for investigation.

Investigate against the build, not the repository. The question is what shipped, in which versions, to whom. A component present in the source tree but excluded from the distributed artifact is a different problem from one that shipped.

Determine whether the license terminated. Some licenses terminate automatically on non-compliance and some provide a cure window. If the license terminated and no cure provision applies, continued distribution is infringement and the exposure is different in kind from a compliance gap.

Decide the remediation. Comply, replace, re-architect, or obtain a commercial license. Cost and time differ by an order of magnitude across those four, and the choice should be made with engineering in the room.

Fix the process, not just the finding. A notice that produces a component swap and no change to the review gate produces another notice.

And document the response. The record of a diligent, prompt, good-faith remediation is worth a great deal — with the notifying party, with a court if it comes to that, and with the next acquirer's diligence team, who will ask what happened.

A Suggested Reading Path

If you have a specific problem right now, branch:

An open source finding. Copyleft and Consequences → Running an Open Source Compliance Program.
Someone copied your code. Copyright in Code → Proving or Defending a Software Copyright Claim → Software Copyright Checklist.
An engineer left for a competitor. Trade Secrets and the DTSA → Trade Secret Protection and Departure Checklist.
You are scraping, or being scraped. Who Owns the Data → Running or Defending a Data Scraping Program → Data Collection and Scraping Risk Checklist.
Ownership is unclear. Who Owns the Work → Copyright Ownership and Chain of Title Checklist.

If you are building the program from nothing, read in this order:

Copyleft and Consequences — the obligations that come in with the code.
Running an Open Source Compliance Program — inventory, policy, gate, remediation.
Trade Secrets and the DTSA — the real backbone.
Building a Trade Secret Program That Survives Litigation — reasonable measures in practice.
Copyright in Code — what registration is worth and what filtration removes.
Who Owns the Data — the data layer.

Primary Authorities

| Authority | Rule, in one line | |---|---| | 17 U.S.C. § 101 | Definitions, including computer program and the work-made-for-hire categories. | | 17 U.S.C. § 102(a) | Copyrightable subject matter, including literary works. | | 17 U.S.C. § 102(b) | Exclusion of ideas, procedures, processes, systems, and methods of operation. | | 17 U.S.C. § 106 | Exclusive rights, including reproduction and derivative works. | | 17 U.S.C. § 107 | Fair use, applied to reimplementation and interoperability. | | 17 U.S.C. § 117 | Limitations for owners of copies of computer programs. | | 17 U.S.C. § 201(b) | Works made for hire; employer as author within scope of employment. | | 17 U.S.C. § 203 | Termination of transfers by individual authors. | | 17 U.S.C. § 204(a) | Transfers of copyright ownership require a signed writing. | | 17 U.S.C. § 411 | Registration as a precondition to suit. | | 17 U.S.C. § 412 | Timely registration as a precondition to statutory damages and fees. | | 17 U.S.C. § 1201 | Circumvention of technological protection measures. | | 18 U.S.C. § 1030 | Computer Fraud and Abuse Act; access without or exceeding authorization. | | 18 U.S.C. § 1836 | DTSA civil action, remedies, and civil seizure. | | 18 U.S.C. § 1839 | Trade secret definition; reasonable measures and independent economic value. | | 35 U.S.C. § 101 | Patentable subject matter, and the eligibility limits that constrain software patents. |

Forms and Templates

Assignments are the priority. Every contractor, every consultant, every open source contributor to a project you control. Software is not eligible for commissioned work-made-for-hire treatment, so a present-tense assignment signed by the individual is the only reliable instrument. 17 U.S.C. § 204(a). Confirmatory assignments obtained years later work and cost more, in money and in leverage.

License Agreement Template adapts into a software license with three additions: a scope clause distinguishing internal use, distribution, and network provision, because those distinctions determine which obligations attach; an open source disclosure schedule listing components and their licenses; and audit and compliance provisions that are realistic about what an audit can examine. Read it with Draft License Agreement.

The open source policy itself is the operative document, and it should be short enough that engineers read it: a pre-approved license list requiring no review, a prohibited list, a review path for everything else, and a named owner. A policy that requires review for every dependency will be circumvented within a month.

Related Toolkits and Checklists

Trade Secret Protection Toolkit is the deep treatment of the backbone protection for software businesses, including departure forensics and DTSA litigation. Employee, Founder, and Mobility IP Toolkit covers the mobility layer.

AI, Content, and IP Toolkit covers generated code and training data. Privacy and Marketing Data Toolkit covers the obligations that attach to personal data regardless of who owns it.

IP Due Diligence Toolkit is where all of this is examined by someone else. Copyright Enforcement Toolkit covers the enforcement machinery for the copyright layer. Fair Use and Permissions Toolkit covers the analysis that governs reimplementation and interoperability.