De-identified is not the same as yours to sell: Spirit's vendor objections
Three separate software vendors told the bankruptcy court that records in Spirit's data sale were generated by their own platforms. De-identification answers a privacy question, not an ownership one.
A third objection class: property, not privacy
The dispute over Spirit Airlines' deidentified data sale has been reported mainly as a privacy story. Employee groups and more than 120 lawmakers argue about what happens to the working records of roughly 17,000 former staff. The court-appointed consumer privacy ombudsman answered that question from the court's side in her October 5, 2026 supplemental report. A third class of objections is about something different: property. Several software vendors told the bankruptcy court that records inside the proposed sale were generated by their platforms and were never Spirit's to sell.
At least three separate vendor groups filed limited objections in the case, and each also moved to enforce its own confidentiality agreements: Springshot, Inc. (docket 1508, filed August 21, 2026); International Aero Engines LLC and IAE International Aero Engines AG (docket 1538, filed August 27, 2026); and Navitaire LLC together with Amadeus IT Group, S.A. (docket 1602, filed September 14, 2026). Navitaire, which states it was a vendor to Spirit for 19 years, joins the earlier vendor objections and, in its words, "any and all other objections on file or to be filed."
All three describe themselves as narrow. None asks the court to stop the sale of assets Spirit actually owned. Springshot told the court it "does not seek to scuttle any sale of valuable estate property actually owned by the Debtors"; Navitaire wrote that, "Like other objectors, Navitaire does not care to scuttle the Sale." Each asks for the same shape of relief: identify the material it claims, exclude it, and prevent its onward transfer.
Status as of October 17, 2026: no approval order has been entered, the hearing is listed for November 6, 2026 after successive adjournments, and the public docket does not show the vendor objections as resolved. These are historical filings from outside the last 30 days and are labelled as such.
- Separate the questions in any records sale: whose personal information is in it, and whose property the records are.
- A vendor objection is not necessarily an attempt to kill the deal. All three here asked for exclusions and process, not rejection.
- The objection deadline in this case passed on August 17, 2026, yet a further vendor objection was filed on September 14, 2026 by joining the earlier ones.
The clause that creates the problem is a data-generation clause
Springshot's objection quotes the ownership provision of the Master Software as a Service Agreement it signed with Spirit on April 1, 2022. Under that clause Springshot "own[s] all right, title and interest, including all intellectual property rights, in and to the Software, Service, any data or information generated by the Service or Software, and any suggestions, ideas, enhancement requests, feedback, or recommendations provided by Customer or any other party relating to the Service or Software."
The filing then describes what that clause covers in practice. The platform, it says, transformed multiple sources of operational data into "structured, granular flight-specific data records" - a "digital execution history" of the turn operation for each aircraft, held in a proprietary format that supported both human and automated decisions. Springshot calls the result a "proprietary operational data corpus" and argues it is "among the most AI-relevant assets to be purchased."
For an owner, the useful part is where this language lives. A clause like this is generally not in a privacy notice, a data-processing addendum or an MSA security schedule. It sits in the intellectual-property or ownership section of a platform, SaaS, integration or professional-services agreement - the part business teams rarely read when they think about their own data.
The same pattern appears from the other side in IAE's filing, which describes proprietary commercial, technical and financial information it supplied to Spirit and says the Data Agreement's confidentiality terms prohibit transfer "to any third party without the prior written consent of IAE."
- List the systems whose output describes how work was actually performed, not just what was stored.
- For each one, read the ownership or intellectual-property clause and identify who is stated to own data generated by the service or software.
- Distinguish information you supplied from information a vendor's platform produced from your activity. The second category is where these disputes live.
- Check whether the agreement needs the vendor's written consent before any transfer, and whether that consent has been asked for.
De-identification settles the person question, not the ownership question
Both objections make the same argument about the remedy that dominates the public debate. Springshot states that "the deidentification of personal data does not preserve the value of Springshot's ownership of its data, or protect Springshot from the misappropriation of that value," and explains why: the value "resides in the aggregated operational sequencing for modeling purposes, and the proprietary organization and analysis of that data that is output by Springshot's platform."
IAE makes the removal point directly. Because the seller "may have made copies, modifications, and derivatives" of its information, "particularly within internal communications, deidentification is insufficient to ensure that the IAE Proprietary Information has been removed." It asks the court to require the seller to demonstrate the absence of its material rather than assume de-identification achieved it.
That is a different axis from everything in the privacy dispute, and it follows from how the sale itself is drafted. Springshot notes that the sale agreement requires deidentification to "preserve referential integrity across the data set". Referential integrity is what makes an operating archive useful for training - and it is also what preserves the structure a vendor claims to own.
A certificate that names and identifiers were removed answers a question about people. It does not answer whether the pattern of work inside the records is the seller's to sell.
- Do not treat a de-identification report as a title document. It evidences a privacy step, not ownership.
- Ask whether the de-identification method preserves referential integrity, and if so, what the preserved structure contains.
- Check whether any permitted use of the records is limited by an agreement with the system that produced them.
The buyer's completeness covenant points the other way
Springshot's filing quotes the sale agreement's covenant at Section 3(e), under which the seller must ensure that "no portion of the Assets has been deleted, modified or removed" other than through the deidentification of personal data, ordinary-course changes, and "de minimis" removals to preserve the seller's privileged materials. Section 1(c) provides that the buyer may transfer the assets onward, with personal data remaining protected in later transfers.
Springshot draws the conclusion it cares about: the agreement's protections are limited to consumer personal data and the seller's own privileged material, and "there are no similar protections for third parties' intellectual property rights swept into the broad definition of Assets."
The commercial tension is concrete. A buyer purchasing a training corpus has an interest in receiving it intact, and here has a covenant saying so. A vendor whose contract assigns it the data its platform generated has an interest in having that material removed. A seller can be asked to satisfy both at once, and only one of them is usually visible in the draft the seller reviews.
The assets as defined in the sale agreement's exhibit are broad: productivity and collaboration data, core business systems and business application data including employee behaviour and productivity data, and workflow and process data including HR and legacy operations data. Nothing in that definition sorts records by who generated them.
- Ask whether your draft sale or licence agreement contains a completeness or no-deletion covenant, and who it binds.
- Ask what mechanism lets you remove an item after signing if a third party establishes a claim.
- Check whether the buyer's onward-transfer right is subject to the same exclusions you negotiated.
- Test the asset definition against your vendor list, not against your own filing cabinet.
What the vendors asked the court for, in their own words
Springshot asked the court to decline approval "unless and until the order approving the sale expressly and unequivocally provides that, notwithstanding the language in the proposed Sale Agreement, Springshot's intellectual property (i) is not property of the Debtors' estate, (ii) is excluded from the Assets to be sold to Google under the Sale Agreement, and (iii) will not otherwise be transferred or used in a manner inconsistent with the SaaS Agreement." It also asked for a forensic process to "first identify, and then segregate" its property, and argued that de-identification alone would not achieve that.
IAE asked that the court "not approve the Data Sale until the Debtors demonstrate that the Data Sale excludes IAE Proprietary Information (including any copies, modifications, or derivatives thereof)," and that Spirit implement a removal protocol "agreeable to IAE", with an injunction as the alternative.
Navitaire asked that the sale not be approved "unless the Confidential Navitaire Data is excluded from the Sale and there are sufficient protocols in place to ensure that the Confidential Navitaire Data is removed from any data transferred to Google (or other purchaser)."
Three vendors, three filings and one repeated structure: an express statement that the excluded material is not estate property, a named exclusion in the order, and a verified removal process before transfer. That is a workable shape for a seller's own scope document, written before a buyer's draft asks for completeness.
- Put the exclusion in the operative document, not in a side letter or a verbal assurance.
- Name who performs the identification step, and what they hand over: a schedule, a forensic report, or a certification.
- Make the exclusion survive onward transfer to the buyer's later recipients.
- Ask what happens to the deal if the identification step finds more excluded material than expected.
What these filings do not establish
These are objections and allegations in a contested bankruptcy case. Whether any particular record in the proposed sale falls within a vendor's ownership claim remains disputed, and the court had not ruled on the vendor objections as of the dates on the filings. An objection is an assertion, not a finding.
The objectors also have commercial interests of their own. Springshot's objection notes that Google announced a five-year data and AI partnership with Ryanair one week before the Spirit auction closed, describing it as the same operational-decision function Springshot served at Spirit. A competitor's objection is still a contractual claim worth reading, but it is not a neutral assessment.
Nor does any of this price a dataset. The $10 million figure is a successful bid in a bankruptcy auction, not a completed payment, and the commonly reported volumes come from filings as quoted in reporting rather than an audit. We have not established that any vendor in this case received compensation, or that any vendor objection was sustained.
What transfers is the question rather than the answer. Before describing records as "our operating data" in a licensing or sale document, check which agreements say who owns what your systems produced - and treat the answer as a scope issue to resolve before diligence, not a disclosure to make during it.
- Treat the docket as the status source and the filings as claims, not outcomes.
- Weigh an objector's commercial interest alongside its contractual argument.
- Keep bid, recommendation, order, transfer and payment as separate stages.
- A vendor list is a rights map. Build it before you describe a dataset's scope.
Public program descriptions are not seller-specific contracts or legal advice. See our evidence methodology.