3 ms·

Copyright applies to the literary work as a whole, and protects derivative works based on it[1]. In this case it's true the derivative work (the recipe) wouldn

by cosmie 6y ago

Copyright applies to the literary work as a whole, and protects derivative works based on it[1]. In this case it's true the derivative work (the recipe) wouldn't be copyrightable, but that doesn't absolve it from being considered a copyright violation of the original work. If you can show you independently created that recipe, then you're protected from the above assertion that it was a derivative of that copyrighted work. But if you're compiling a database of normalized recipes via scraping recipe content online, it'd be pretty easy for a copyright holder to establish this argument doesn't hold water. [1] https://copyright.uslegal.com/enumerated-categories-of-copyrightable-works/copyright-for-literary-work/ https://copyright.uslegal.com/enumerated-categories-of-copyr...

derefr 6y ago
Aren't prose recipes a kind of program source-code; and aren't the underlying ideas of their steps, algorithms? The law says you can copyright source code, but not a program's underlying algorithmic semantics[1]. What I'm talking about here, is effectively "extracting the semantics of someone else's source code/recipe, in a way where humans are "firewalled off" from the particulars of the original prose of the code/recipe; and then using the described semantics to write your own code/recipe that has those same semantics." This is explicitly something that's been decided as not copyright-infringing; which is why IP lawyers have to go after cases where there was literal plagiarism of source code, however small. The big example of this is Google v. Oracle, where API header files used in Android were literally plagiarized from OpenJDK. Google argued that this was fair use, as there was essentially no other form these files could take while retaining Java compatibility. But this argument was shut down/never resolved in their favor. All Google had to do, in the end, to avoid infringement, was to do a ground-up rewrite of those Android API header files (which ended up almost exactly the same as they were before the rewrite.) Note that they still rewrote them using an understanding of the bare facts that those header files contain, that could only have been gained by reading the original header files themselves. And yet the new derivative work, being "not literally plagiarism", was no longer considered an infringing derivative work. [1] You can patent algorithms (sort of, as business processes), but that's a different thing. Nobody's ever going to sue a recipe website for patent infringement, even if they described Nestle's patented chocolate-enrobing technique, because a description of a patented process is not a use of that patent. Patents are inherently public information, and people can share and reprint the information in them around all they like. Instead, a patent owner would only sue other companies who used the patented technique for commercial gain, for not first acquiring a license for the patented technique. (Google never sued bloggers for describing the PageRank algorithm; but up until last year, Google did sue other search-engine companies for implementing PageRank without a license.)
- cosmie 6y ago
  True. But in this case, you'd have to ensure you went through the process of truly re-implementing the algorithm of the recipe, and stripping out all non-algorithmic components of the instructions. For example, a step in an icing recipe[1] may say something like: Gradually beat in just enough milk to make frosting smooth and spreadable. If frosting is too thick, beat in more milk, a few drops at a time. If frosting becomes too thin, beat in a small amount of powdered sugar. Frosts 13x9-inch cake generously, or fills and frosts an 8- or 9-inch two-layer cake. The only "algorithmic" component to that step is that you add milk. The fact that you do so gradually, use a beater during the process, how you identify when you've added enough, how to correct for deviations in viscosity of the mixture, etc are all part of the "source code" rather than the algorithm and wouldn't be something you could republish without being considered a derivative work. The recipe without those contextual components may still be useful for those sufficiently familiar with baking, but for many people following a recipe, they'd likely need such contextual components to follow the recipe successfully. [1] https://www.bettycrocker.com/recipes/vanilla-buttercream-frosting/39107a19-be94-4571-9031-f1fc5bd1d606 https://www.bettycrocker.com/recipes/vanilla-buttercream-fro...
  - derefr 6y ago
    > The only "algorithmic" component to that step is that you add milk. The fact that you do so gradually, use a beater during the process, how you identify when you've added enough, how to correct for deviations in viscosity of the mixture, etc are all part of the "source code" rather than the algorithm and wouldn't be something you could republish without being considered a derivative work. I would disagree. Here's what I learned from your quoted paragraph, expressed in pseudo-Prolog: - beatInto(FrostingMixInBowl, Milk, $BeaterSpeed) => increaseQty(FrostingMixInBowl, Milk). - beatInto(FrostingMixInBowl, IcingSugar, $BeaterSpeed) => increaseQty(FrostingMixInBowl, IcingSugar). - invProportional(viscosity(FrostingMixInBowl), absorbancyPerUnitTime(FrostingMixInBowl)). - nonNewtownianViscosity(FrostingMixInBowl). :. invProportional(absorbancy(FrostingMixInBowl), $BeaterSpeed). // implication from standard library :. require(maxThreshold($BeaterSpeed)). // implication from standard library - invProportional(viscosity(FrostingMixInBowl), AmbientHumidity). - invProportional(viscosity(FrostingMixInBowl), AmbientTemperature). - proportional(viscosity(FrostingMixInBowl), currentQty(FrostingMixInBowl, Milk)). - invProportional(viscosity(FrostingMixInBowl), currentQty(FrostingMixInBowl, IcingSugar)). - target(viscosity(FrostingMixInBowl), centiPoise(10000)). //see https://www.globalpumps.com.au/list-of-typical-viscosities https://www.globalpumps.com.au/list-of-typical-viscosities ...and then some stuff about how much frosting we're making here, but without the context required to translate those figures into absolute extruded surface area. Anyway, do you see what I'm getting at with this? We're describing a system of dynamic constraints. What you generate from this "knowledge base" is an action plan that routes you through the system of dynamic constraints to achieve the target (in this case, icing of a specified absolute viscosity.) The constraints are generative, where constraints asserted together produce further constraints, and those constraints can be translated into structured-text warnings like: • "the icing is too thick to absorb milk at faster than N mL per second; if you introduce it faster than that, the milk will bounce off the surface of the icing rather than absorbing, and probably splatter you in the face." • "beating the icing too fast shears/aerates it, increasing its viscosity, making it unable to absorb anything, meaning that anything introduced to the icing will bounce off the surface of the icing and splatter you in the face." Such a system also allows the resolution of ambiguities, where instead of saying "if the icing is too thick", it can know the variables that affect viscosity, and so just ask you to set those variables (i.e. the ambient temperature and rH value for your kitchen) either in your user preferences or at the recipe header; and take that into account to compute initial quantities for ingredients that should produce a viscosity in no need of further adjustment. (But it could also generate the structured text explaining what actions it knows about for this step that increase and/or decrease viscosity — you know, just in case you messed up and didn't follow its perfect robot plan.) Note that this isn't super out-there tech. People build models that do these computations all the time. Which people? The operational engineers in charge of the day-to-day operations of baked-good and candy factories. I'm just suggesting, in essence, a generalized domain-specific abstract machine for modelling all such problems in an easy way (rather than rebuilding it half from scratch in spreadsheets each time), such that you could just as easily describe the dynamic-constraint system underlying a steak as one underlying a Mars bar. ...and then using all that just to emit recipe prose. :P (But you could also use it as the "mental model" a multi-purpose robotic kitchen could use to generate action plans, of course.)

by cosmie 6y ago

derefr 6y ago

Aren't prose recipes a kind of program source-code; and aren't the underlying ideas of their steps, algorithms? The law says you can copyright source code, but not a program's underlying algorithmic semantics[1]. What I'm talking about here, is effectively "extracting the semantics of someone else's source code/recipe, in a way where humans are "firewalled off" from the particulars of the original prose of the code/recipe; and then using the described semantics to write your own code/recipe that has those same semantics." This is explicitly something that's been decided as not copyright-infringing; which is why IP lawyers have to go after cases where there was literal plagiarism of source code, however small. The big example of this is Google v. Oracle, where API header files used in Android were literally plagiarized from OpenJDK. Google argued that this was fair use, as there was essentially no other form these files could take while retaining Java compatibility. But this argument was shut down/never resolved in their favor. All Google had to do, in the end, to avoid infringement, was to do a ground-up rewrite of those Android API header files (which ended up almost exactly the same as they were before the rewrite.) Note that they still rewrote them using an understanding of the bare facts that those header files contain, that could only have been gained by reading the original header files themselves. And yet the new derivative work, being "not literally plagiarism", was no longer considered an infringing derivative work. [1] You can patent algorithms (sort of, as business processes), but that's a different thing. Nobody's ever going to sue a recipe website for patent infringement, even if they described Nestle's patented chocolate-enrobing technique, because a description of a patented process is not a use of that patent. Patents are inherently public information, and people can share and reprint the information in them around all they like. Instead, a patent owner would only sue other companies who used the patented technique for commercial gain, for not first acquiring a license for the patented technique. (Google never sued bloggers for describing the PageRank algorithm; but up until last year, Google did sue other search-engine companies for implementing PageRank without a license.)

cosmie 6y ago
True. But in this case, you'd have to ensure you went through the process of truly re-implementing the algorithm of the recipe, and stripping out all non-algorithmic components of the instructions. For example, a step in an icing recipe[1] may say something like: Gradually beat in just enough milk to make frosting smooth and spreadable. If frosting is too thick, beat in more milk, a few drops at a time. If frosting becomes too thin, beat in a small amount of powdered sugar. Frosts 13x9-inch cake generously, or fills and frosts an 8- or 9-inch two-layer cake. The only "algorithmic" component to that step is that you add milk. The fact that you do so gradually, use a beater during the process, how you identify when you've added enough, how to correct for deviations in viscosity of the mixture, etc are all part of the "source code" rather than the algorithm and wouldn't be something you could republish without being considered a derivative work. The recipe without those contextual components may still be useful for those sufficiently familiar with baking, but for many people following a recipe, they'd likely need such contextual components to follow the recipe successfully. [1] https://www.bettycrocker.com/recipes/vanilla-buttercream-frosting/39107a19-be94-4571-9031-f1fc5bd1d606 https://www.bettycrocker.com/recipes/vanilla-buttercream-fro...
- derefr 6y ago
  > The only "algorithmic" component to that step is that you add milk. The fact that you do so gradually, use a beater during the process, how you identify when you've added enough, how to correct for deviations in viscosity of the mixture, etc are all part of the "source code" rather than the algorithm and wouldn't be something you could republish without being considered a derivative work. I would disagree. Here's what I learned from your quoted paragraph, expressed in pseudo-Prolog: - beatInto(FrostingMixInBowl, Milk, $BeaterSpeed) => increaseQty(FrostingMixInBowl, Milk). - beatInto(FrostingMixInBowl, IcingSugar, $BeaterSpeed) => increaseQty(FrostingMixInBowl, IcingSugar). - invProportional(viscosity(FrostingMixInBowl), absorbancyPerUnitTime(FrostingMixInBowl)). - nonNewtownianViscosity(FrostingMixInBowl). :. invProportional(absorbancy(FrostingMixInBowl), $BeaterSpeed). // implication from standard library :. require(maxThreshold($BeaterSpeed)). // implication from standard library - invProportional(viscosity(FrostingMixInBowl), AmbientHumidity). - invProportional(viscosity(FrostingMixInBowl), AmbientTemperature). - proportional(viscosity(FrostingMixInBowl), currentQty(FrostingMixInBowl, Milk)). - invProportional(viscosity(FrostingMixInBowl), currentQty(FrostingMixInBowl, IcingSugar)). - target(viscosity(FrostingMixInBowl), centiPoise(10000)). //see https://www.globalpumps.com.au/list-of-typical-viscosities https://www.globalpumps.com.au/list-of-typical-viscosities ...and then some stuff about how much frosting we're making here, but without the context required to translate those figures into absolute extruded surface area. Anyway, do you see what I'm getting at with this? We're describing a system of dynamic constraints. What you generate from this "knowledge base" is an action plan that routes you through the system of dynamic constraints to achieve the target (in this case, icing of a specified absolute viscosity.) The constraints are generative, where constraints asserted together produce further constraints, and those constraints can be translated into structured-text warnings like: • "the icing is too thick to absorb milk at faster than N mL per second; if you introduce it faster than that, the milk will bounce off the surface of the icing rather than absorbing, and probably splatter you in the face." • "beating the icing too fast shears/aerates it, increasing its viscosity, making it unable to absorb anything, meaning that anything introduced to the icing will bounce off the surface of the icing and splatter you in the face." Such a system also allows the resolution of ambiguities, where instead of saying "if the icing is too thick", it can know the variables that affect viscosity, and so just ask you to set those variables (i.e. the ambient temperature and rH value for your kitchen) either in your user preferences or at the recipe header; and take that into account to compute initial quantities for ingredients that should produce a viscosity in no need of further adjustment. (But it could also generate the structured text explaining what actions it knows about for this step that increase and/or decrease viscosity — you know, just in case you messed up and didn't follow its perfect robot plan.) Note that this isn't super out-there tech. People build models that do these computations all the time. Which people? The operational engineers in charge of the day-to-day operations of baked-good and candy factories. I'm just suggesting, in essence, a generalized domain-specific abstract machine for modelling all such problems in an easy way (rather than rebuilding it half from scratch in spreadsheets each time), such that you could just as easily describe the dynamic-constraint system underlying a steak as one underlying a Mars bar. ...and then using all that just to emit recipe prose. :P (But you could also use it as the "mental model" a multi-purpose robotic kitchen could use to generate action plans, of course.)