Mishneh Torah, Tithes 13-14

Hook

Every founder loves a shortcut. When you are racing to find product-market fit, capital efficiency is your oxygen. You scrape public directories to train your models, pull down open-source libraries to patch your codebase, or buy distressed, unverified inventory from gray-market liquidators to preserve your runway. It feels like a victimless hack. The data was just sitting there on the internet; the code was public; the inventory was abandoned in a warehouse. You assume it is "ownerless"—free for the taking, free from regulatory overhead, and free from downstream liability.

But is it?

This is the exact operational friction addressed in Rambam’s exposition on demai (doubtfully tithed produce) in Mishneh Torah, Tithes 13 and Mishneh Torah, Tithes 14. Demai is the ancient world’s version of a compliance gray area. When you buy from a "common person" (am ha'aretz), you cannot be entirely sure if they paid their civic and religious taxes (tithes). If they didn’t, the product carries a "compliance debt." If you consume it without resolving that debt, you commit a severe ethical infraction.

Rambam outlines a rigorous framework for determining when an asset is truly "wild" (ownerless, requiring zero compliance overhead) versus when it is "guarded" (proprietary, requiring strict audit trails). More importantly, he addresses the "wholesaler loophole." When you source through intermediaries who aggregate inputs from hundreds of unverified creators, you cannot treat the aggregated bulk as a single, uniform risk profile.

If you are building a venture-backed company, you are likely accumulating massive, hidden compliance debt in your supply chain, your IP portfolio, or your training data. This text provides the exact decision rules you need to audit your inputs, protect your company from catastrophic regulatory enforcement, and maintain a clean sheet for your next funding round. Let’s look at the raw rules of the game.

---

Text Snapshot

"Even if a common person told him that they have not been tithed, they are exempt from the tithes until it is known that they grew from produce that was guarded... What is meant by produce that ripens first? All the produce that ripens before [the owner] employs a guard for the valley to protect his produce." — Mishneh Torah, Tithes 13:1-2

"When a person purchases [produce] from a wholesaler and then purchases [produce] from him a second time, he should not separate tithes from one batch for another... [The rationale is that] a wholesaler purchases from many different people and sells [it]." — Mishneh Torah, Tithes 14:1

"When nine distributors purchase [bread] from ten bakers, since one of them purchases from two [bakers], anyone who purchases [bread] from one of the nine must tithe each mold individually." — Mishneh Torah, Tithes 14:7

---

Analysis

Insight 1: The "Guard" Rule for Public Domain and Sourcing (Fairness)

In Mishneh Torah, Tithes 13:1, Rambam establishes a fundamental distinction between wild, ownerless resources (hefker) and proprietary, guarded ones (shameur). Wild figs, brush berries, and thorn apples are naturally exempt from the strictures of demai because "we assume that they grew ownerless" Mishneh Torah, Tithes 13:1. Even if a seller explicitly tells you they haven’t been tithed, you are exempt from tithing them "until it is known that they grew from produce that was guarded" Mishneh Torah, Tithes 13:1.

Rambam then defines the precise boundary of ownership:

"What is meant by produce that ripens first? All the produce that ripens before [the owner] employs a guard for the valley..." Mishneh Torah, Tithes 13:2

The ethical and operational decision rule here is clear: Ownership is not merely a conceptual right; it is defined by active custody. If an owner does not "employ a guard"—whether that guard is a fence, a paywall, a robot.txt file, or an explicit terms-of-service agreement—the asset enters a state of functional public domain.

The SaaS and Data Scraping Parallel

Consider the modern founder scraping web data to train an LLM or build a lead-generation tool. If a platform leaves its data completely unencrypted, un-rate-limited, and behind no authentication wall, it is the digital equivalent of "produce that ripens before the owner employs a guard" Mishneh Torah, Tithes 13:2. You are legally and ethically permitted to assume it is wild.

However, the moment the platform implements a "guard"—even a basic login wall, a CAPTCHA, or an updated API licensing agreement—the status of that data instantly shifts. It is now "guarded." Any founder who continues to extract that data under the guise of "it’s just public information" is violating the principle of fairness.

The Rambam’s ruling protects the builder from over-compliance when sourcing truly open assets, but it demands absolute halt-and-audit protocols the second an asset owner signals active custody. You cannot claim ignorance when a digital asset has been explicitly fenced off.

---

Insight 2: The Wholesaler Fallacy and the Danger of Aggregation (Truth)

One of the most common mistakes early-stage founders make is assuming that buying through a reputable middleman cleanses the supply chain. You buy user data from an aggregator, or you source manufacturing components from a major distributor, and you assume their master service agreement (MSA) immunizes you from compliance failures.

Rambam demolishes this assumption in Mishneh Torah, Tithes 14:1:

"When a person purchases [produce] from a wholesaler and then purchases [produce] from him a second time, he should not separate tithes from one batch for another... [The rationale is that] a wholesaler purchases from many different people and sells [it]."

In the laws of tithing, you cannot offset the compliance obligations of one batch of goods using another batch if they came from different sources. If you buy Batch A (which is compliant) and Batch B (which is non-compliant), you cannot "average them out." Because a wholesaler aggregates inventory from multiple, unverified "common people," every single batch they sell must be treated as an independent compliance risk.

By contrast, if you buy from a private individual:

"We operate under the presumption that a private person sells only his own produce." Mishneh Torah, Tithes 14:3

Therefore, you can cross-tithe between batches purchased from a private seller, because the source is single and consistent.

Supply Chain and Code Provenance Debt

For a modern startup, this is the "Aggregation Fallacy." If you are sourcing code libraries from an open-source registry (like npm or PyPI) or buying training data from a broker, you are dealing with a digital wholesaler. You cannot assume that because Batch A of their data was clean and legally sourced, Batch B is also clean.

[Supplier 1] ---\
[Supplier 2] ----> [Wholesaler / Aggregator] ----> [Your Startup] ===> MUST Audit Each Batch Individually
[Supplier 3] ---/

[Private Owner] ---------------------------------> [Your Startup] ===> Can Apply Uniform Compliance

If your engineering team pulls a package from a public repository, they cannot assume the entire repository is safe just because the platform has a green checkmark. Each dependency, each sub-dependency, and each updated version is a separate "batch" sourced from a different contributor (a different "baker" or "farmer").

If you do not audit these inputs individually, you are committing a compliance error. You are mixing "exempt" assets with "obligated" ones, which Rambam warns makes your compliance efforts "of no consequence" Mishneh Torah, Tithes 13:17.

---

Insight 3: The "Nested Counterparty" Contamination Rule (Competition)

In Mishneh Torah, Tithes 14:7, Rambam introduces a scenario that perfectly mirrors modern multi-tenant cloud architectures and nested software supply chains:

"When nine distributors purchase [bread] from ten bakers, since one of them purchases from two [bakers], anyone who purchases [bread] from one of the nine must tithe each mold individually."

Let’s unpack the math and the logic here. You have nine distributors selling bread. Ten bakers are supplying them. Because there is an uneven ratio (nine distributors, ten bakers), at least one distributor must be mixing inventory from two different bakers. Because you do not know which distributor is mixing their supply, the entire marketplace’s integrity is compromised. You can no longer make any broad assumptions about any single loaf of bread; you must treat every single loaf ("each mold") as a unique compliance event.

Systemic Risk in API and Cloud Ecosystems

This is the ultimate warning against nested counterparty risk. Today’s startups do not build in a vacuum. Your SaaS product plugs into an API, which plugs into another API, which runs on a cloud provider, which uses a third-party database.

If even one vendor in your nested chain is mixing compliant and non-compliant practices—for example, using unlicensed data to train an AI model that they then white-label to you—the entire downstream output is contaminated.

[Baker A] \
           --> [Distributor 1] (Mixed) ---\
[Baker B] /                                \
                                            --> [Your Startup] ===> Entire Supply Chain Contaminated
[Baker C] ----> [Distributor 2] (Clean) ---/

To compete fairly and protect your enterprise value, you cannot rely on industry-standard "trust certificates" or superficial audits. If your industry contains nested, unverified suppliers, you must design your systems to isolate and verify every single transaction or data packet.

If you do not, a single compliance failure at the fourth tier of your software supply chain can trigger a domino effect that invalidates your intellectual property or exposes you to massive fines under frameworks like GDPR or the EU AI Act.

---

Policy Move: The "Granular Provenance and Guard Audit Protocol" (GPGAP)

To operationalize these insights, your startup must move away from lazy, macro-level compliance (e.g., "our vendors sign an indemnity clause") and move toward granular, batch-level verification.

You must implement the Granular Provenance and Guard Audit Protocol (GPGAP). This policy codifies how your company procures, processes, and audits external inputs—whether they are physical parts, software code, or data assets.

1. The Input Classification Matrix

Every incoming asset must be classified into one of three categories based on Rambam's definitions of hefker (ownerless), shameur (guarded), and demai (aggregated/doubtful).

Ancient Category	Modern Equivalent	Operational Status	Audit Requirement
Hefker (Wild/Ownerless)	Public domain, MIT-licensed code, un-rate-limited public APIs.	Class A (Open)	Minimal. Verify the absence of any "guard" (e.g., paywall, auth, active terms of service).
Shameur (Guarded)	Proprietary IP, commercial APIs, authenticated data, copyrighted media.	Class B (Proprietary)	Maximum. Require direct, verified chain of custody and explicit licensing agreements.
Demai (Aggregated/Wholesale)	Data brokers, open-source registries, white-label software, multi-vendor marketplaces.	Class C (Aggregated)	Continuous Isolation. Treat every batch, update, or delivery run as an independent compliance risk.

2. The Wholesaler Disaggregation Mandate

Pursuant to Mishneh Torah, Tithes 14:1, your engineering and procurement teams are strictly prohibited from applying a blanket compliance sign-off to any Class C (Aggregated) vendor.

• Software Engineering: You must implement automated Software Bill of Materials (SBOM) scanning (using tools like Snyk or FOSSA). Every time a dependency is updated—even a minor patch—it must be treated as a new "batch" from a different "baker." It must be scanned and sandboxed before merging into production.
• Data Science / AI: Any dataset purchased from a broker must be partitioned. You cannot mix Dataset A and Dataset B in your training run until Dataset B has been audited to the same standard as Dataset A. If Dataset B is found to contain un-consented user data, it cannot be "averaged out" by the high quality of Dataset A.
• Hardware / Manufacturing: If you buy components from a distributor who sources from multiple factories, you must run batch-level quality control and origin tracking. A failure in Batch B cannot be hand-waved away because Batch A had a 0% defect rate.

3. The "Guard" Detection Audit

Before your growth team scrapes any platform or your product team integrates a "free" dataset, they must document the "Guard Status" of the source. If the source platform:

1. Employs a .robots.txt disallow rule,
2. Requires an account to access the data,
3. Uses rate-limiting or IP blocking,

...then the asset is legally and ethically classified as Guarded under Mishneh Torah, Tithes 13:2. Accessing it via backdoors, IP-rotation networks, or headless browsers is a violation of this policy and requires immediate executive sign-off and legal review.

Key Metric: Provenance Traceability Ratio (PTR)

To measure the success of this policy, the board will track the Provenance Traceability Ratio (PTR) as a core risk metric:

$$\text{PTR} = \left( \frac{\text{Value of Class A & B Inputs} + \text{Audited Class C Batches}}{\text{Total Volume of Procurement Inputs}} \right) \times 100$$

• Target: >98% for production-grade software and commercialized data.
• Why this matters: A low PTR indicates that your startup is accumulating massive, hidden compliance debt that will emerge during due diligence in your Series B or C rounds, potentially tanking your valuation or scaring off institutional lead investors.

---

Board-Level Question

The Strategic Prompt for the Next Board Meeting

At the next board meeting, when the team presents the product roadmap and unit economics, the lead investor or the founder should slide this question across the table:

"Are we treating our aggregated third-party inputs—specifically our data pipelines, open-source dependencies, and white-labeled vendor APIs—as a single, homogeneous stream protected by generic indemnity clauses, or do we have automated, batch-level isolation and verification protocols to prevent nested counterparty contamination?"

     Generic Indemnity (High Risk)
     [Aggregators] ===(Blanket Agreement)===> [Your Enterprise] (Vulnerable to downstream lawsuits)

     Batch-Level Isolation (Torah-Compliant / Low Risk)
     [Aggregators] ===(Batch Scan & Sandbox)===> [Classified Inputs] ===> [Your Enterprise] (Fully Insulated)

Why This Question is Critical for Your Survival

If your management team answers, "Our contract with the data broker/software vendor has a full indemnity clause, so we are protected," they are failing to understand modern regulatory and operational reality.

Indemnity is a paper shield. If a regulator fines your company for using illegally sourced data, or if a court issues an injunction forcing you to delete your core AI model because it was trained on copyrighted material, your vendor’s indemnity clause will not save your business. The vendor will go bankrupt, or the litigation will drag on for five years while your startup runs out of cash.

Rambam’s warning about the nine distributors and ten bakers Mishneh Torah, Tithes 14:7 teaches us that in a highly interconnected, aggregated market, contamination is systemic. You cannot contract your way out of systemic contamination; you must architect your way out of it.

By forcing your leadership team to answer this question, you are demanding that they build a technical and operational architecture that isolates risk at the batch level, ensuring that a compliance failure at one of your sub-vendors does not destroy the enterprise value of your entire company.

---

Takeaway

In the race to scale, it is easy to mistake "unguarded" for "ownerless" and "aggregated" for "compliant." But Rambam's laws of demai remind us that true business integrity is built at the granular level.

You cannot average out your ethical or regulatory compliance. Whether you are sourcing raw physical materials, scraping data for an AI model, or pulling open-source code into your stack, you must respect the "guards" that owners put in place, treat every aggregated batch as a unique audit event, and actively insulate your company from nested counterparty risk.

Protect your inputs, trace your provenance, and build a business that can withstand the most rigorous scrutiny. That is how you build a startup that doesn't just grow fast, but endures.