Licensing Data and Models for Artificial Intelligence: Training Rights, Outputs, and Indemnities

Summary. What you are buying, what the seller can actually grant, and who bears the risk.

Three assets, not one

The most common drafting error in this field is treating an artificial intelligence transaction as a single license. It is three, and they behave differently:

The data layer. The corpus used to train or fine-tune a model. Text, images, audio, video, code, tabular records, sensor readings. Its legal character depends entirely on what it contains — copyrighted works, personal information, trade secrets, contractually restricted material, or nothing protectable at all.

The model layer. The trained artifact: architecture, weights, tokenizer, configuration. Its legal character is genuinely unsettled. It is not obviously a copyrightable work; it is not a patent; it is quite plausibly a trade secret where kept confidential, and it is definitely a valuable thing that contracts can allocate.

The output layer. What the model produces. Text, images, code, predictions, classifications. Its ownership is contested and, for practical purposes, is a matter of contract rather than of intellectual property doctrine.

A license that says "Licensor grants Licensee a license to the AI Technology" has allocated nothing. Every negotiation should begin by naming the three layers and addressing each.

The data layer

What rights are actually needed

To use a corpus for training, a licensee needs, depending on content:

Copyright rights. Reproduction under 17 U.S.C. § 106 at minimum, since training involves copying. Whether it also involves preparing derivative works is contested and worth addressing expressly rather than leaving to argument. Whether any of this is excused by fair use under 17 U.S.C. § 107 is the central open question of the field — and a licensee who has a license does not need the answer, which is precisely the point of licensing.

Contractual rights. This layer is independent of copyright and frequently controls. Terms of service, database licenses, API agreements, and subscription terms routinely prohibit uses that copyright would permit. Fair use is not a defense to breach of contract. A licensee acquiring a dataset assembled by scraping should ask what the source sites' terms said, and should expect the answer to be unsatisfying.

Privacy rights. Where the corpus contains personal information, the relevant question is not ownership but lawful basis and purpose limitation. Data collected for one purpose may not be usable for training without a separate basis, and rights to deletion and correction create obligations that survive the license. Sectoral regimes add layers — financial data under 15 U.S.C. § 6801 and 15 U.S.C. § 6802, health information under its own framework, and biometric identifiers under state statutes with private rights of action.

Trade secret clearance. A corpus containing another party's confidential information creates exposure under 18 U.S.C. § 1836 and its state analogues, and the definition in 18 U.S.C. § 1839 is broad enough to reach a great deal of ordinary commercial information.

Rights of publicity. Where the corpus contains identifiable persons, state law and the growing set of digital replica statutes apply independently of copyright.

Copyright management information

17 U.S.C. § 1202 prohibits removing or altering copyright management information — the author, title, terms of use, and identifying information conveyed with a work — and providing false CMI. Claims under it are being asserted in training-data disputes independently of infringement, with remedies under 17 U.S.C. § 1203.

This matters operationally. Pipelines that strip metadata during preprocessing — which is standard practice for entirely technical reasons — may be creating exposure. The practical response is to preserve CMI where feasible, document why removal was technically necessary where it was not, and address the issue expressly in licenses.

What a data licensor can actually grant

The uncomfortable answer is often: less than the license says.

A dataset aggregator that assembled a corpus by scraping does not own the underlying works. It can grant what it has — which may be a compilation copyright in the selection and arrangement, and nothing in the individual items. A license reciting that "Licensor owns all right, title, and interest in the Data" should prompt the question how, and the answer should be documented rather than assumed.

Diligence questions for any data license:

• How was the data collected? Crawl, purchase, contribution, license, or internal generation?
• What were the source terms of service at the time of collection, and were they archived?
• Were machine-readable restrictions honored?
• Does the corpus contain personal information? Under what basis?
• Does it contain material subject to third-party confidentiality obligations?
• Was CMI preserved?
• What representations will the licensor make, and are they backed by anything?

The model layer

What a model is, legally

There is no settled answer, and the practical consequence is that model rights are allocated by contract against an uncertain background.

Copyright is a poor fit. Model weights are numerical parameters produced by an optimization process. The originality and human authorship required for copyright are difficult to locate in them, and the argument that weights are copyrightable is not one anyone should rely on as the sole basis for a licensing position.

Trade secret is the strongest fit. Weights, training methodology, data mixtures, and hyperparameters derive independent economic value from not being generally known and are subject to reasonable secrecy measures — the definition in 18 U.S.C. § 1839. This is why closed-weight providers treat model access as a confidentiality relationship rather than as a copyright license.

Patent may protect the architecture or training method, subject to eligibility analysis, but rarely protects a specific trained artifact.

Contract does the work. In practice, a model license is a bundle of permissions and restrictions enforceable as contract terms, whatever the underlying property status.

Open weights are not open source

A significant source of confusion. Many widely used models are released under licenses that permit downloading and running the weights but impose restrictions that open source definitions do not permit:

• Acceptable use policies prohibiting categories of application
• Scale thresholds requiring a separate license above a user or revenue level
• Restrictions on using outputs to train competing models
• Attribution and naming requirements
• Downstream flow-down obligations

These are enforceable contract terms. They are also not open source, and describing them as such creates real compliance problems — an engineering team that believes a model is "open source" will use it in ways the license prohibits.

Practical guidance: read the actual license. Maintain a model inventory recording, for each model in use, the license, the specific restrictions, the scale thresholds, and the flow-down obligations. Treat this exactly as a mature organization treats open source software compliance, because the failure modes are identical.

Fine-tuning and derivatives

When a licensee fine-tunes a licensed model on its own data, what does it own?

The honest answer is that the property analysis is murky and the contract is what matters. Address expressly:

• Who owns the fine-tuned weights?
• Who owns the adapter or delta if the tuning produces a separable artifact?
• May the licensee distribute the fine-tuned model, and under what terms?
• Does the base license's acceptable use policy flow down to the fine-tuned model?
• What happens to the fine-tuned model if the base license terminates?
• May the licensor use the licensee's fine-tuning data for any purpose?

That last question is the one that most often surprises licensees. Many hosted fine-tuning services reserve rights to use submitted data for service improvement unless the customer opts out. Read the data-use provisions in the service terms, not just the license.

The output layer

Ownership

Two questions are frequently conflated.

Does copyright subsist in the output? United States law requires human authorship. Purely machine-generated material without sufficient human creative contribution is not copyrightable, and the Copyright Office has taken this position consistently in registration practice. Where a human makes substantial creative choices — in selection, arrangement, modification, or in prompting sufficiently expressive to constitute authorship — protection may attach to the human contribution.

Who owns whatever rights exist? This is contract. Providers commonly assign to the customer whatever rights the provider has in outputs, which is a sensible allocation and also, potentially, an assignment of nothing.

The drafting implication: an output ownership clause should not represent that the outputs are copyrightable. It should assign whatever rights exist, disclaim any representation about copyrightability, and address the practical questions that actually matter:

• May the customer use outputs commercially, without restriction?
• Does the provider have any residual license to use customer outputs?
• Are similar outputs to other customers permitted? (They will be; say so.)
• Who bears the risk if an output infringes a third party's rights?

Output infringement risk

An output can infringe. A model may reproduce substantial portions of a training work, generate an image substantially similar to a protected one, or produce code closely tracking a licensed repository.

This risk cannot be eliminated. It can be reduced — through output filtering, similarity detection, retrieval attribution, and training-data curation — and it can be allocated, which is why indemnities have become the central commercial term in this field.

Indemnities

Indemnification is where the negotiation actually happens, because it is the only mechanism for allocating risks that no one can eliminate.

What a provider-side indemnity typically covers:

• Third-party claims that the model infringes intellectual property rights
• Third-party claims that outputs infringe, usually subject to conditions
• Sometimes claims relating to training data

The conditions that matter more than the grant:

The practical assessment: an output indemnity capped at twelve months of fees, excluding fine-tuned models and any use where filtering was disabled, is worth considerably less than it appears. Read the conditions before valuing the grant.

Customer-side indemnity typically covers the customer's input data, its fine-tuning corpus, and its use of outputs in ways the provider did not contemplate. Negotiate the scope of "customer data" carefully; a broad definition can sweep in material the customer received from third parties under their own restrictions.

Frequently asked questions

Does an indemnity from a large provider make the risk go away? No. It converts an unbounded risk into a contractual claim against a counterparty, subject to conditions and a cap. Read the conditions, price the cap against realistic exposure, and confirm the indemnity survives termination for claims arising from term-period use. An indemnity capped at twelve months of fees is a meaningful comfort for a small deployment and nearly meaningless for a large one.

Can we train on our customers' data? Only if the customer agreement permits it. Many enterprise agreements prohibit it outright, some permit it in de-identified or aggregated form, and a few permit it broadly. A vendor training on customer data without an express right has created exposure across its entire customer base at once, and it is one of the more common findings in diligence.

What is the difference between fine-tuning, retrieval, and prompting, legally? Fine-tuning modifies the model using data, which implicates training rights. Retrieval keeps the data outside the model and supplies it at inference, which usually implicates only the right to access and display the material — a materially lighter posture, and often the right architecture for licensed content. Prompting with a protected work supplies it as an input, which raises different questions and frequently voids output indemnities.

Who is liable if an output defames someone or gives harmful advice? Not a copyright question, and not answered by any of the licenses above. Allocate it expressly: the provider will disclaim; the deployer will usually bear it; and professional liability insurance may or may not respond depending on how the system is characterized. Address it in the contract and in the insurance review, not by assuming the model license covers it.

Do we need a license to train on publicly available data? "Publicly available" is not a legal category. Public accessibility is not permission. The relevant questions are whether the material is copyrighted, what the source's terms of service said, whether personal information is involved, and whether fair use would apply — which is contested. A license removes the question.

Are model weights copyrightable? Unsettled and doubtful. Trade secret protection is the stronger theory for closed models, and contract governs in practice.

Can we own the outputs? You can own whatever rights exist, by assignment. Whether copyright subsists depends on human creative contribution. Do not build a business on the assumption that unedited machine output is protectable.

Is an "open weight" model open source? Usually not. Acceptable use policies, scale thresholds, and restrictions on training competing models are common and are enforceable contract terms.

Does fine-tuning void our indemnity? Frequently, yes. Check the conditions before fine-tuning a model whose output indemnity you are relying on.

What if a licensor cannot document provenance? Price the risk or decline. Provenance cannot be reconstructed after the fact, and a licensor who cannot say how a corpus was assembled cannot meaningfully warrant it.

Does removing metadata from training data create liability? Potentially, under 17 U.S.C. § 1202. Preserve copyright management information where feasible and document technical necessity where removal is unavoidable.

What happens to a model if the data license ends? This is the hardest question in the field and it must be addressed expressly. See the discussion below.

The termination problem

Every data license ends. What happens to a model trained on that data is the question nobody wants to answer and everybody must.

The licensor's position: the license permitted training during the term. When it ends, the licensee must stop using anything derived from the data, including the model.

The licensee's position: training consumed the data; the model is a new artifact; requiring its destruction is a forfeiture disproportionate to any harm.

Why this cannot be left to litigation. Retraining a large model is expensive and slow, and a licensee that must destroy a production model on thirty days' notice faces a business interruption of a different order than an ordinary license termination. Conversely, a licensor whose data is embedded permanently in a competitor's model has given away more than it charged for.

Terms that resolve it in advance:

• Perpetual training rights with a term-limited data license. The licensee may use the data during the term; models trained during the term survive. This is the most common commercial resolution and it should be stated explicitly rather than implied.
• Survival of models but not of data. The corpus is deleted on termination; models persist. Include certification of deletion.
• Wind-down periods long enough to retrain — six to twenty-four months depending on the model's scale.
• A retraining fee or continuation license priced to reflect the model's ongoing value.
• Segregation requirements so that a licensee can demonstrate which models used which corpora. Without this, a termination dispute becomes unresolvable as a factual matter.
• Termination for cause versus convenience treated differently. Many licenses permit model survival on convenience termination and require destruction on termination for material breach.

The deletion question. Where the underlying obligation is privacy-driven — a data subject exercises a deletion right — the analysis is different and harder. Whether deleting a record requires removing its influence from a trained model is technically difficult and legally unsettled. Practical approaches include documented deletion from the corpus and from any retrieval index, exclusion from future training runs, and — where the technique is available and the risk warrants it — targeted unlearning. Commit to what you can actually do, and say so in the contract and the privacy notice.

Provenance: the operational requirement

Everything above depends on knowing what is in the corpus and how it got there. Provenance cannot be reconstructed after the fact, and organizations that did not maintain it discover the fact at the worst possible time — in diligence, in litigation, or when a customer asks.

What a provenance record contains, per source:

Archive the terms as they existed on the collection date. Site terms change, and reconstructing what a page said two years ago is a genuine evidentiary problem. A stored copy with a timestamp resolves it.

Segregate by license. A corpus that mixes freely licensed material, purchased material, and material under restrictive terms is unusable for any purpose more restrictive than its most restrictive component — and impossible to remediate if the components cannot be separated. Tag at ingestion.

Maintain a model-to-corpus mapping. Which models were trained on which corpora, at which versions, on which dates. This is what makes a termination provision enforceable and a deletion commitment credible.

The contractual layer nobody notices

Copyright analysis dominates the discussion, and contract quietly controls more outcomes.

Terms of service. Most websites prohibit automated collection. These prohibitions are enforceable as contract terms against a party that agreed to them, and fair use is not a defense to breach. Whether browsewrap terms bind a scraper who never clicked anything is a separate and contested question, but the risk is real and it is not answered by a fair use analysis.

API agreements. Explicit and negotiated. An API license that prohibits using returned data to train a model means what it says, and violations are straightforward breaches.

Subscription and database licenses. Academic databases, news archives, financial data services, and image libraries typically restrict use to internal research or to specified purposes. Training is usually not among them.

Employment and contractor agreements. Data brought in by employees from prior employers, or by contractors from other clients, creates trade secret exposure under 18 U.S.C. § 1836 that no copyright analysis addresses.

Upstream customer contracts. A vendor that trains on customer data must have the right to do so. Many enterprise agreements prohibit it, some permit it with de-identification, and a few permit it outright. Check before, not after.

Computer fraud statutes. Access that exceeds authorization can implicate 18 U.S.C. § 1030, though the scope of that statute for scraping publicly accessible material has been substantially narrowed. Technical circumvention of access controls is a different matter and carries real risk.

The practical rule: a training-data diligence review that examines only copyright status has examined the smaller half of the problem.

Negotiating positions

As a data licensor:

• Grant training rights expressly and narrowly — training, fine-tuning, and evaluation are different acts; name the ones granted.
• Distinguish internal use from distribution. A right to train an internal model is not a right to distribute one.
• Address output rights: does the licensee's use of outputs implicate your data?
• Limit retention and require deletion certification.
• Require segregation so termination is enforceable.
• Warrant only what you can document. A warranty of clear title to a scraped corpus is a warranty you cannot support.
• Cap indemnity exposure realistically.

As a data licensee:

• Require provenance documentation as a deliverable, not a representation.
• Require representations with specifics: how collected, under what terms, with what filtering.
• Negotiate perpetual rights to models trained during the term.
• Require notice of any third-party claim relating to the data.
• Negotiate an indemnity that survives termination for claims arising from term-period use.
• Address personal information explicitly, including deletion mechanics.
• Get audit or verification rights where the corpus is material to the business.

As a model licensor:

• Treat weights as confidential information and structure access accordingly.
• State acceptable use clearly and make it flow down.
• Address fine-tuning: permitted or not, and who owns the result.
• Prohibit distillation and competing-model training on outputs if that is the intent — and be aware that this is a restriction, not an intellectual property right.
• Set scale thresholds with objective triggers.
• Structure output indemnities with conditions you can actually verify.

As a model licensee:

• Read the actual license, not the marketing description.
• Maintain a model inventory with license terms, restrictions, and thresholds.
• Confirm what voids the indemnity before fine-tuning or disabling filters.
• Address version pinning: an indemnity conditioned on using the current version conflicts with a production requirement for stability.
• Negotiate survival of the license for models already deployed.
• Confirm the provider's data use rights over your inputs and fine-tuning data.

A worked transaction

Sedgewick Analytics builds forecasting software for agricultural cooperatives. It wants to add a natural-language interface and a yield-prediction model. It needs two things it does not have: a foundation model and a corpus of agronomic records.

The data deal

Thornfield Agronomics offers a licensed corpus: eleven years of field trial data, soil analyses, weather records, and yield outcomes across 40,000 plots, plus 90,000 pages of trial reports.

Sedgewick's counsel, Ayotunde Fitzsimmons, asks the diligence questions and gets uneven answers.

How was it collected? Field trials Thornfield ran under contract for growers, plus purchased weather data, plus reports written by Thornfield agronomists.

What did the grower contracts say? Thornfield produces a template. It permits Thornfield to "use trial data for research and product development." It says nothing about training models or about licensing data to third parties.

Whose weather data? A commercial provider. The subscription agreement prohibits redistribution and restricts use to Thornfield's internal operations.

Personal information? Grower names, farm locations, and contact details appear throughout the reports.

Ayotunde's assessment: Thornfield can license the trial reports it authored. It probably can license the trial data under the "product development" language, though the absence of any reference to sublicensing is a real gap. It cannot license the weather data at all. And the personal information requires either removal or a lawful basis Thornfield has not established.

How the deal is restructured:

1. Scope narrowed. The weather data is excluded entirely; Sedgewick licenses it directly from the provider on terms permitting model training, at additional cost.
2. Grower consent. Thornfield obtains consent amendments from growers representing 78% of the plots. Data from the remaining 22% is excluded and segregated.
3. Personal information removed before delivery, with a documented de-identification process and a prohibition on re-identification attempts.
4. Provenance delivered as a work product, not merely warranted: a source manifest with collection dates, governing contracts, and consent status per plot.
5. Training rights granted expressly — training, fine-tuning, and evaluation, each named — for internal use and for models embedded in Sedgewick's product.
6. Term and survival. The data license runs five years. Models trained during the term survive perpetually; the corpus must be deleted within ninety days of termination, with certification. This single provision took longer to negotiate than everything else combined.
7. Segregation obligation. Sedgewick must maintain a model-to-corpus mapping so the survival provision is enforceable.
8. Indemnity. Thornfield indemnifies for claims that the licensed data infringes or was collected without authority, capped at 2× fees, surviving termination for claims arising from term-period use. Sedgewick indemnifies for its own use of outputs.

The model deal

Sedgewick evaluates three foundation models.

Model A is hosted, closed weights, with an output indemnity. Ayotunde reads the conditions: coverage requires using the current version, prohibits disabling content filters, excludes fine-tuned models, and is capped at fees paid in the preceding twelve months. Sedgewick intends to fine-tune. The indemnity would be void.

Model B is an "open" release. Ayotunde reads the license and finds an acceptable use policy prohibiting use in "agricultural advisory services affecting food safety," a scale threshold requiring a separate license above 500,000 monthly active users, and a prohibition on using outputs to train competing models. It is not open source, and the first restriction is close enough to Sedgewick's product to require a written interpretation from the licensor.

Model C is a smaller open-weight model under a permissive license with no field restrictions. It requires more fine-tuning to reach acceptable performance.

Sedgewick chooses C, and Ayotunde documents why in a memorandum the board will read: the indemnity on A was illusory given the fine-tuning plan, and B's field restriction created an unacceptable dependency on a licensor's interpretation.

What went into the model inventory

The last row is the honest one. A permissive open-weight license with no indemnity means Sedgewick bears output risk itself. Ayotunde's memorandum says so, quantifies it, and recommends output filtering and a similarity check on generated agronomic recommendations — mitigation rather than transfer.

Practical risk mitigation

Where risk cannot be transferred, it can be reduced. The techniques below are engineering decisions with legal consequences, and counsel should know enough to ask for them.

Data-side

• Deduplication and near-duplicate removal reduce memorization, which is the mechanism by which outputs reproduce training material.
• Exclusion lists for known high-risk sources.
• Honoring machine-readable reservations is cheap and is powerful evidence of good faith.
• Segregation by license so the corpus's permitted uses are knowable.
• CMI preservation where technically feasible.
• De-identification of personal information, with re-identification prohibited contractually.

Model-side

• Memorization testing before release: probe the model with prompts designed to elicit training data and measure what comes back.
• Output filtering for verbatim or near-verbatim reproduction of known protected material.
• Similarity detection on generated images and code against reference corpora.
• Retrieval with attribution instead of parametric recall, where the use case permits — a retrieval system that quotes and cites is a materially different legal posture than one that generates from memory.
• Refusal behavior for prompts explicitly requesting protected material.

Operational

• Version pinning with a documented upgrade path, reconciling stability requirements against indemnity conditions requiring current versions.
• Logging of prompts and outputs sufficient to reconstruct an incident, balanced against privacy obligations and retention limits.
• An incident path for third-party claims about outputs: preserve, assess, notify the indemnitor within the contractual window, and decide about the specific behavior.
• Customer-facing terms that allocate output risk downstream consistently with what the organization received upstream. A vendor that accepts no indemnity from its model provider and grants a broad one to its customers has assumed the entire risk.

Diligence in a transaction

When artificial intelligence assets are material to an acquisition or a financing, the diligence looks different from ordinary software diligence, and the standard technology questionnaire misses most of what matters.

Ask for the corpus inventory, not a summary. A list of every dataset used to train any model in production, with source, collection method, governing terms, and dates. A target that cannot produce this has a valuation problem, not a documentation problem.

Ask for the archived terms. Not a description of what the terms permitted — the stored copies of the terms as they existed at collection. This is the single most revealing request in the entire exercise, and the answer is frequently that no such copies exist.

Ask for the model inventory. Every model in production or development, its base model, its license, the field and scale restrictions, the flow-down obligations, and which corpora trained it.

Ask about the customer data question. Does the target train on customer data? Under what contractual right? A vendor training on enterprise customer data without an express right has a liability spread across its entire customer base.

Ask about consent and lawful basis for any personal information, and about deletion mechanics. Commitments made in a privacy notice are enforceable regardless of technical feasibility.

Ask about open-weight compliance. Field restrictions and scale thresholds in model licenses are the artificial intelligence equivalent of copyleft obligations in software, and organizations discover them at scale, in diligence, after the product is built.

Ask about indemnities in both directions. What the target received from its providers, and what it granted to its customers. The gap between them is retained risk, and it is frequently large.

Ask about pending claims and demand letters relating to training data, and about any takedown or deletion demands received.

Assess remediation cost, not just risk. If a corpus must be excluded, what does retraining cost and how long does it take? If a model license must be replaced, what is the migration effort? These numbers, not the abstract legal risk, are what belong in the purchase agreement's price and indemnity negotiations.

Structure accordingly. Where provenance is thin, the tools are: specific indemnities carved out from the general cap, escrow tied to defined risks, purchase price adjustment, or — where the corpus cannot be documented at all — excluding it from the transaction and requiring retraining as a closing condition.

Where the law is likely to move

Predicting doctrine is a poor use of a practitioner's time, but a few structural pressures are worth naming because they change what should be negotiated today.

Fair use for training will be answered, partially. Courts are working through the question, and the emerging pattern separates training from outputs: a training process that produces statistical relationships is a different case than a system whose outputs substitute for the works it learned from. The shared-purpose analysis of Andy Warhol Foundation for the Visual Arts, Inc. v. Goldsmith, 598 U.S. 508 (2023) supplies the framework for the second question even though it said nothing about machine learning. Contracts drafted now should not assume a favorable answer.

Licensing markets are forming, and that changes factor four. As content licensing for training becomes an established market, the argument that no market is displaced weakens. A use that was defensible in 2022 may not be in 2028 for exactly the reason the fourth factor exists. Licenses signed now are partly insurance against that shift.

Provenance will become a compliance requirement, not a best practice. Transparency obligations requiring disclosure of training data sources are moving through several jurisdictions. Organizations that maintain provenance records will comply cheaply; those that do not cannot comply at any price, because the records cannot be created retroactively.

Digital replica and voice rights will expand. State statutes are proliferating, and a federal framework has been proposed repeatedly. Training corpora containing identifiable voices and likenesses carry risk that copyright analysis does not capture.

Model weights will get a clearer legal character, probably through contract rather than legislation. Courts resolving disputes about weights will characterize them, and the first well-reasoned opinions will do more to settle practice than any statute.

What to do about all of this now: document provenance obsessively, license where licenses are available and reasonably priced, negotiate model survival on termination, keep corpora segregated so components can be removed, and avoid representations you cannot support. None of that depends on how the open questions resolve, which is precisely why it is the right advice.

Related documents

• Negotiating an AI Data or Model License: A Practical Guide
• AI Licensing Diligence Checklist: A Practical Checklist
• AI Licensing Toolkit: Data Provenance Records, License Terms, and Indemnity Clauses
• Copyright Fair Use: The Four Factors, Transformative Use, and What Warhol Changed
• Copyright Infringement Claims Against Generative AI: The New York Times, Getty, and What Comes Next
• AI Governance and Compliance: Building a Program for the EU AI Act, State AI Laws, and Everything After
• Open Source Software: Licenses, Compliance, and Risk
• Data Scraping After hiQ v. LinkedIn: Copyright, Contract, and Computer Fraud Claims
• Cloud and SaaS Agreements: Service Levels, Data Rights, Security, and Exit