What ODbL means for commercial nutrition apps

This is an engineering overview, not legal advice. Database rights and contract questions depend on jurisdiction and architecture. Read the licence and obtain qualified advice for a consequential launch.

The Open Database License permits commercial use. It also attaches conditions to public use, attribution and certain distributions of databases derived from the licensed database. Paying a hosted provider does not automatically remove those upstream obligations.

Separate the database from its contents

ODbL governs rights in the database: its systematic collection, arrangement and substantial extraction or reuse. Individual contents can have separate rights. Open Food Facts states that its database is under ODbL, individual database contents use the Database Contents License, and product images use Creative Commons Attribution-ShareAlike, with possible additional rights in packaging.

This distinction matters. Permission to query a nutrition record does not necessarily grant unrestricted rights to every product photograph or logo returned with it.

Commercial use is allowed

Section 3 of ODbL grants worldwide rights that explicitly include commercial use. “Open” does not mean “non-commercial.” The practical questions are what you publicly display, whether you distribute a database, and whether your transformed collection is a derivative database.

Attribution is the minimum visible duty

If your app publicly displays results derived from Open Food Facts, place a clear attribution where users encounter the data, and link to the source and licence. Do not hide it in a repository that mobile users never see.

Example: “Food data from Open Food Facts, available under the ODbL.”

Keep source metadata in your own objects so attribution can survive caching, exports and UI redesigns.

Produced work, collective database or derivative database?

The licence distinguishes between outputs made from querying a database and a database based on or substantially transformed from the original. A chart, product page or calculated meal summary may be a produced work. A separate database alongside OFF may be collective. A normalized copy containing a substantial part of OFF may be derivative.

Those categories affect notice and share-alike responsibilities. They are also fact-specific. Renaming columns does not necessarily make the underlying database independent, and repeatedly extracting small portions can still become substantial.

Network access is not identical to distributing a copy

ODbL defines “convey” around enabling another person to receive a copy of the database or derivative database, and notes that mere interaction through a network is not itself conveying. That does not eliminate public-use attribution or every possible share-alike question; it simply means an API and a downloadable database are not automatically the same act.

Build compliance into the data model

• Store source and source record identifiers.

• Keep a licence registry rather than one global licence string.

• Render attribution near public data.

• Track whether images have separate terms.

• Document imports, transformations and exports.

• Review bulk-download and customer-export features separately.

• Do not promise customers that a commercial API subscription transfers ownership of upstream data.

Questions to answer before launch

• Are we displaying individual results or distributing a substantial database?

• Do customers receive exports or only interact with an API?

• Did we combine OFF with proprietary records, and can provenance be separated?

• Are we redistributing product images?

• Where will users see attribution?

• Who owns modifications and who must receive corresponding database access?

Start with the actual ODbL 1.0 text and Open Food Facts reuse guidance. Contact Open Food Facts about its data when guidance is unclear, and seek legal advice for your particular distribution model.

Dietly position: DietlyAPI is built primarily on Open Food Facts. Paid plans provide access to Dietly's hosted normalization, indexing, ranking and support; they do not cancel ODbL duties that apply upstream.

A commercial subscription and a data licence solve different problems

A hosted provider can charge for infrastructure, normalization, support, service limits and contractual permission to use its API commercially. That commercial agreement can coexist with an open licence on upstream data. The invoice does not prove that the provider owns every underlying fact, and the open licence does not require the provider to operate servers for free.

Review both layers: the provider's service terms and each upstream licence relevant to the returned data. They can impose different duties. Service terms may limit credentials, caching or throughput; ODbL addresses database rights, attribution and share-alike. Product images, brand assets and user-contributed text may introduce still other terms.

Attribution should survive every surface

List all places where data appears: web pages, native apps, PDFs, exports, widgets, email reports and public API responses. Decide where the attribution notice belongs on each surface and how a user can reach the licence. A single footer on the marketing website may not inform someone viewing an embedded result inside a customer application.

Automate attribution where possible. If the API returns source metadata, map it to a maintained notice rather than hard-coding a sentence in several clients. Include source and licence information in exports so downstream users do not accidentally strip provenance. Test attribution as part of release QA, just like privacy links and billing disclosures.

Think carefully before offering bulk exports

An interactive application that shows individual query results differs operationally and legally from a feature that lets customers download millions of normalized records. Bulk export can cross from using produced works into conveying a database or derivative database. It also changes the security, privacy and infrastructure profile of the product.

Before adding export, document which records are included, which sources they came from, what transformations were applied and which notices accompany the file. Decide how recipients can obtain any corresponding database that must be offered under applicable share-alike terms. This is the point where qualified advice is especially valuable.

Do not confuse facts with protected content

A calorie number may be a factual value, while a product photograph, label artwork or long description can carry copyright or trademark concerns independent of database rights. Preserve separate image metadata and avoid assuming the database licence covers the image. Open Food Facts explicitly calls out its image licence separately.

Logos and brand names may be necessary to identify products, but their presence does not imply sponsorship. Use them accurately, avoid misleading endorsement and review marketplace policies where an app store or advertising platform imposes additional rules.

Keep a small compliance record

Maintain a short architecture note naming sources, licences, import paths, transformations, public surfaces, attribution text and owners. Update it when adding another dataset or export feature. This record helps engineers avoid accidental regressions and gives counsel a concrete system to review instead of an abstract question about “using food data.”

Compliance is easier when provenance is designed in from the first table. Reconstructing it after records have been merged, cached and redistributed is expensive and sometimes impossible.

---

Originally published at getdietly.com. Data from the Dietly Nutrition API — 4.7M+ indexed foods, free tier available.