Third-party content inside licensed records: attachments and embedded documents

What counts as third-party content in company records?#

Third-party content is any material inside your records that someone outside the company created and still holds rights in. It arrives quietly: a supplier's datasheet attached to a purchasing thread, a consultant's report linked from a wiki page, a screenshot of another vendor's dashboard in a support ticket.

Messages your customers wrote in a ticket are also authored by outsiders, but they are usually handled through the customer contract and privacy review rather than this filter. The categories below are the ones that most often carry someone else's copyright, license terms or confidentiality.

• 1Email attachments: contracts, quotes, spec sheets and reports sent by customers, vendors and advisers.
• 2Vendor documentation: manuals, datasheets, installation guides and release notes in shared drives or wikis.
• 3Quoted publications: news articles, analyst reports and paywalled research pasted into Slack, Teams or email.
• 4Images: stock photos, screenshots of other software, product photos and marketing images.
• 5Customer uploads: files and logs customers attached to support tickets or portals.
• 6Embedded documents: Google Docs, design frames and videos embedded in Confluence or Notion pages.
• 7Purchased materials: industry standards, training courses and templates bought under a license.
• 8Open-source code: libraries and snippets inside repositories, each under its own license.

Why outside material creates risk in a data license#

Outside material creates risk on three fronts: copyright in the work itself, the contract terms under which you received it, and confidentiality owed to the sender. A vendor manual may be free to download and still carry terms limiting its use; a consultant's report may be confidential under the engagement letter.

The fourth front is your own warranty. Buyers ask suppliers to promise that the data does not infringe third-party rights, and a single folder of embedded vendor PDFs can turn that promise into exposure.

Provenance standards reflect the issue. The Data & Trust Alliance's Data Provenance Standards include, in their Use group, elements for the license to use and for copyright, patent and trademark status, which is the kind of metadata a careful buyer expects a supplier to be able to answer.

Exclusion checklist by content type#

The exclusion checklist sets a default for each content type and leaves room for counsel to bring material back case by case. Defaults are deliberately strict, because removing a file costs little while defending one can cost a great deal.

Two record families need a closer look than the table suggests. Wiki pages often mix staff writing with pasted vendor instructions in the same paragraph, and code review threads sometimes quote documentation from outside projects at length. Both pass a file-type filter, so they depend on the text-level steps below.

How to filter third-party content at scale#

Filtering at scale combines rules that catch most material automatically with sampling that catches what the rules miss. The order matters: remove whole file types first, then work inside the text.

Keep the filter log. A list of which rules ran, on which systems, and what the sample review found is the evidence behind any warranty you give.

• 1Drop attachments and binary files by type before text processing, leaving a placeholder such as attachment removed: PDF.
• 2Exclude folders and spaces that hold vendor documentation, purchased standards or archived marketing material.
• 3Strip quoted reply chains and forwarded bodies from email by detecting reply and forward headers.
• 4Flag long passages that match published text or sit next to a link to an outside site, and remove the quoted block.
• 5Remove vendored dependency directories from repositories and keep license files for the rest.
• 6Review a sample from each record family by hand, and widen the rules wherever outside text slipped through.

Scoping the non-infringement warranty#

The non-infringement warranty should describe what the supplier actually controls: the records its people wrote and the filters it applied. Broad wording that covers every byte in the delivery makes the supplier answer for material it never authored and may not know is there.

A buyer is more likely to accept narrower wording when the supplier can show the filter log and the exclusion list. The warranty then describes something the supplier demonstrably did.

Illustrative: an architecture firm strips its submittals#

Illustrative: a fictional architecture and engineering firm keeps RFIs, submittals and review comments in Procore, marked-up sheets in Bluebeam and internal discussion in Teams. Submittals arrive packed with manufacturer product data, subcontractor shop drawings and consultants' calculations.

The managing principal and counsel agree on a rule: the firm licenses the questions, review comments and responses its staff wrote, and every submittal attachment comes out. Shop drawings, product data and consultant reports are replaced with placeholders naming the document type, and long passages quoted from codes and standards in RFI responses are cut back to a reference.

The warranty in the license covers firm-authored text and the agreed filters. The archive stays useful because the reasoning of each review survives even where the document under review does not.

How SourceX handles outside material#

SourceX treats third-party content as a Rights question first and a Preparation task second within the SourceX five-step transaction, which runs Supply, Rights, Preparation, Approval and Delivery. The rights review identifies which record families carry outside material; preparation applies the filters the supplier approved.

The SourceX Evidence Packet records provenance and licensing rights for each record family, with permitted use, the privacy record and release authorization, so the scope of any warranty matches a documented process.