You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, this sounds great and it can be useful for a project I have in mind. The thing is I cant find the database, where is it? The file with all the recipes info.
Thank you.
Best regards, Hugo.
Unfortunately there is no publicly available collection yet - as I still have to figure out ways of aggregating lawfull (-compliant) content.
I'm currently working at integrating already established self-hosted tools ( Tandoor, Paprika, Mealie,..) to allow users to share their recipes to the public.
As this is just a "one-man pet-project" and the topic is quite complex, the progress is quite slow, but still ongoing.
as I am in Germany - things get tricky with copyright law pretty easy. In my understanding, I am not allowed to re-publish content without explicit approval from the author / rights owner.
Only in the edge-case were a recipe hold only the instruction - it would be possible that it is not copyrighted. As soon as you have sentences like "Oh I really like strawberry with that" it already gets complicated.
I'll add a note on the repo about this!
My current plan is to write some plugins to current existing Recipe-Managers, so people are able to share their own recipes (not imported from the web) via a centralized platform and thus build the database with legal content.
Just to add one thing that hasn't come up: even if individual recipes aren't protectable (ingredient lists and functional steps generally aren't), the EU has a separate sui generis database right (Directive 96/9/EC). Systematically extracting a substantial part of someone else's recipe collection can be actionable on its own, independently of whether each recipe is copyrightable. So @Dwarfex's caution isn't unfounded.
On "take it down if someone complains", that's notice-and-takedown, which shields a host for third-party uploads. If the project publishes the scraped content itself it's the publisher, not the intermediary, so that safe harbour doesn't apply. And in Germany the cost arrives via Abmahnung before any court does.
The plugin route (Tandoor/Mealie/Paprika + explicit CC0 or CC-BY at submission time) seems like the right call for a solo maintainer.
Separately, +1 on the README note about the dataset not existing yet. This repo ranks first for "open recipe database" and it'd save people a click.
You can host it anywhere. EU regulations are pretty much irrelevant. Switzerland, USA, Singapore all block this as an issue.
The liability caution is unfounded - as they are user submitted, publisher responsibility would be like claiming Facebook stole War and Peace because "all the words are there". There is literally no way for anyone to cross reference. Doesn't even make sense.
This entire system could easily be hosted in flat files. Dstributed via IPFS or similar.
In fact there is Cooklang already for this as a markdown.
Then users can just plug into a global distributed recipie collection with zero liability or constraint - cant even be taken down and any application can tap into it however they want.
Edit - example of .cook markdown.
>> time: 1 hour
>> servings: 6
Preheat the oven to 180C.
Brown @ground beef{500%g} and chopped @onion{1} in a #large skillet{} over medium heat.
Stir in @tomato sauce{400%g} and @dried oregano{1%tsp}.
Layer the meat mixture with @lasagna noodles{12} and @ricotta cheese{250%g} in a #baking dish{}.
Bake for 30 minutes until bubbling
```.
Two quick points and then I think this is the same disagreement as @Dwarfex's original plan, just phrased differently.
Hosting location doesn't help. Jurisdiction attaches to the maintainer as a person, not to the server. A resident of Germany doesn't become unreachable by hosting in Singapore, the Abmahnung still arrives at his address.
The Facebook analogy is backwards. Intermediary safe harbour (DSA in the EU, §512 in the US) is conditional on being able to act on a takedown notice. Architecting the system so it "can't even be taken down" removes the exact capability that immunity depends on, you can't claim the host shield and advertise you're structurally incapable of the obligation that activates it.
On the .cook example itself: Cooklang is a serialization format, not a provenance filter. Your own snippet has styled prose ("brown... over medium heat", "bake until bubbling"), not just quantities. If that text was lifted from a published recipe, wrapping it in @ingredient{} syntax doesn't change what it is legally, it changes the file extension of the problem, not the problem.
That said, "user submitted" with an explicit license at submission is literally @Dwarfex's stated plan (Tandoor/Mealie/Paprika plugins). Cooklang + IPFS is a genuinely good answer for distributing that corpus once it exists. So I think the actual disagreement has narrowed to almost nothing.
@Dwarfex is there anywhere to follow the plugin work, or too early for that?
There IS NO maintainer. Its distributed.
The facebook analogy is not backwards - its a collection of recipies. Whether it can be taken down is entirely irrelevant.
No - the .cook lang is not an examnple at all. These are common phrases that in no way could possibly be copywrite protected.
The entire problem here is that you are looking at this completely wrong - as though it should remain here on Github with PHP interface and a maintainer. Again - a distributed user maintained system.
There are already massive collections that ALREADY EXIST as well - and there is no problem.
I think we're now talking about two different projects. This issue is about @Dwarfex's repo, which has a named maintainer who's told us he's exposed under German law for what he publishes. A separate, ownerless, IPFS-distributed system is a different proposal (possibly a good one) but it doesn't change his risk in the one we're actually discussing.
I'll leave it there rather than go another round. If those existing large collections you mentioned are usable, a link would genuinely help, that's what OP was after in the first place.
I thank you for your interest - If it was "just so simple" - I would have released stuff here.
There are
Copy Right issues (mentioned - "I like it with a variant of..."
Database Right Issues ("You have mirrored my entire collection of material - even if it is not all copyrighted itself)
Redistribution Issues - Are you legally able to re-use / analyze / investigate things - If some kind of collection was published.
Crawling 3rd Party Sites issues
What about the "first" node in a distributed system (possibly me) -> how to you establish a proper distributed network without a starting point. etc. pp.
Soo many open questions to answer for a pet-project with little time and a risk I am currently not willing to take for it.
But - there is hope - I also contribute (little) to OpenFoodFacts - people there do have experience with this sort of stuff -> but I need to find the time to re-establish for clarifications or support.
Activity
Dwarfex commentedon Oct 26, 2025
Hi Hugo,
sorry for the late response!
Great to hear from your interest in this project.
Unfortunately there is no publicly available collection yet - as I still have to figure out ways of aggregating lawfull (-compliant) content.
I'm currently working at integrating already established self-hosted tools ( Tandoor, Paprika, Mealie,..) to allow users to share their recipes to the public.
As this is just a "one-man pet-project" and the topic is quite complex, the progress is quite slow, but still ongoing.
Greetings,
Dwarfex
Dwarfex commentedon Jan 23, 2026
Hi @MaxPleaner,
as I am in Germany - things get tricky with copyright law pretty easy. In my understanding, I am not allowed to re-publish content without explicit approval from the author / rights owner.
Only in the edge-case were a recipe hold only the instruction - it would be possible that it is not copyrighted. As soon as you have sentences like "Oh I really like strawberry with that" it already gets complicated.
I'll add a note on the repo about this!
My current plan is to write some plugins to current existing Recipe-Managers, so people are able to share their own recipes (not imported from the web) via a centralized platform and thus build the database with legal content.
audas commentedon Aug 25, 2026
I do not understand the issue.
Just make an open source database of recipies. Strip out any text. If someone complains place it on hold , instantly scan it and remove creative text.
Hugo966 commentedon Aug 25, 2026
Just to add one thing that hasn't come up: even if individual recipes aren't protectable (ingredient lists and functional steps generally aren't), the EU has a separate sui generis database right (Directive 96/9/EC). Systematically extracting a substantial part of someone else's recipe collection can be actionable on its own, independently of whether each recipe is copyrightable. So @Dwarfex's caution isn't unfounded.
On "take it down if someone complains", that's notice-and-takedown, which shields a host for third-party uploads. If the project publishes the scraped content itself it's the publisher, not the intermediary, so that safe harbour doesn't apply. And in Germany the cost arrives via Abmahnung before any court does.
The plugin route (Tandoor/Mealie/Paprika + explicit CC0 or CC-BY at submission time) seems like the right call for a solo maintainer.
Separately, +1 on the README note about the dataset not existing yet. This repo ranks first for "open recipe database" and it'd save people a click.
audas commentedon Aug 25, 2026
You can host it anywhere. EU regulations are pretty much irrelevant. Switzerland, USA, Singapore all block this as an issue.
The liability caution is unfounded - as they are user submitted, publisher responsibility would be like claiming Facebook stole War and Peace because "all the words are there". There is literally no way for anyone to cross reference. Doesn't even make sense.
This entire system could easily be hosted in flat files. Dstributed via IPFS or similar.
In fact there is Cooklang already for this as a markdown.
Then users can just plug into a global distributed recipie collection with zero liability or constraint - cant even be taken down and any application can tap into it however they want.
Edit - example of .cook markdown.
Hugo966 commentedon Aug 25, 2026
Two quick points and then I think this is the same disagreement as @Dwarfex's original plan, just phrased differently.
Hosting location doesn't help. Jurisdiction attaches to the maintainer as a person, not to the server. A resident of Germany doesn't become unreachable by hosting in Singapore, the Abmahnung still arrives at his address.
The Facebook analogy is backwards. Intermediary safe harbour (DSA in the EU, §512 in the US) is conditional on being able to act on a takedown notice. Architecting the system so it "can't even be taken down" removes the exact capability that immunity depends on, you can't claim the host shield and advertise you're structurally incapable of the obligation that activates it.
On the .cook example itself: Cooklang is a serialization format, not a provenance filter. Your own snippet has styled prose ("brown... over medium heat", "bake until bubbling"), not just quantities. If that text was lifted from a published recipe, wrapping it in
@ingredient{}syntax doesn't change what it is legally, it changes the file extension of the problem, not the problem.That said, "user submitted" with an explicit license at submission is literally @Dwarfex's stated plan (Tandoor/Mealie/Paprika plugins). Cooklang + IPFS is a genuinely good answer for distributing that corpus once it exists. So I think the actual disagreement has narrowed to almost nothing.
@Dwarfex is there anywhere to follow the plugin work, or too early for that?
audas commentedon Aug 26, 2026
There IS NO maintainer. Its distributed.
The facebook analogy is not backwards - its a collection of recipies. Whether it can be taken down is entirely irrelevant.
No - the .cook lang is not an examnple at all. These are common phrases that in no way could possibly be copywrite protected.
The entire problem here is that you are looking at this completely wrong - as though it should remain here on Github with PHP interface and a maintainer. Again - a distributed user maintained system.
There are already massive collections that ALREADY EXIST as well - and there is no problem.
Hugo966 commentedon Sep 2, 2026
I think we're now talking about two different projects. This issue is about @Dwarfex's repo, which has a named maintainer who's told us he's exposed under German law for what he publishes. A separate, ownerless, IPFS-distributed system is a different proposal (possibly a good one) but it doesn't change his risk in the one we're actually discussing.
I'll leave it there rather than go another round. If those existing large collections you mentioned are usable, a link would genuinely help, that's what OP was after in the first place.
Dwarfex commentedon Sep 2, 2026
Guys,
I thank you for your interest - If it was "just so simple" - I would have released stuff here.
There are
What about the "first" node in a distributed system (possibly me) -> how to you establish a proper distributed network without a starting point. etc. pp.
Soo many open questions to answer for a pet-project with little time and a risk I am currently not willing to take for it.
But - there is hope - I also contribute (little) to OpenFoodFacts - people there do have experience with this sort of stuff -> but I need to find the time to re-establish for clarifications or support.
In the meantime:
A small little tool I use is https://github.com/Dwarfex/recipe-parser-server using this: https://github.com/hhursev/recipe-scrapers
and possibly this: https://archive.org/details/cooking-recipes
Edit: @Hugo966
In regards to the plugins: no work there yet, except researching the Plugin Systems of different tools.