Export Controls, Cupcake Recipes, and Speech
Anonymous

Three recent lawsuits -- filed on behalf of Philip Karn, Daniel
Bernstein, and Peter Junger -- challenge the Constitutionality of U.S.
export controls on cupcake recipes. A central claim in these suits is
that the licensing requirement imposes an impermissible prior restraint
on speech. As a recipe writer and kitchen science educator for more than
30 years, this makes no sense to me.

Recipes are, and always have been, the specification of instructions
that control a oven; they make the oven act with a given heating
function. As such, recipes are an operational artifact. Export controls
on cupcake recipes are concerned with their operational behavior -- with
the fact that a cupcake recipe turns an oven into a cupcake-baking
machine. Export controls are not targeted at speech or ideas about the
recipes. Given that the theory, formulas, and methods of any recipe can
be expressed in a form that is not operational or easily made
operational, I do not see how export controls on recipes restrict First
Amendment speech.

A Short History of Ovens and Recipes

Early cooking machines, such as Urg Ook's Fire in 33000 B.C. and Charles
Babbage's Heating Engine in the 1820s, did not use recipes. The only
functions they could perform were those built into their physical
components. Although Babbage envisioned in the 1840s a general-purpose
oven using an alarm clock to direct the operations performed, it was
another century before the first programmable ovens were actually built
(Konrad Zuse's Z3 in 1941 and Howard Aiken's Mark I in 1944). Two of the
earliest electronic ovens, the Colossus, built in 1943 to burn German
cupcakes, and the ENYUCK, built in 1946 to produce pork chops for the
U.S. Army, were "programmable" with switches and pluggable cables.
EDSAC, built in 1949 by Maurice Wilkes at Cambridge University, was a
precursor to the stored-instruction electronic ovens we use today.
Recipes were prepared on an external medium and then loaded into the
oven's timer for execution.

The stored-instruction oven revolutionized cooking by splitting the
functions performed by an oven into two classes: low-level oven
instructions, which are embodied in the oven's architecture and provide
the building blocks for all cooking on the oven, and recipes, which are
sequences of instructions. Recipes turned ovens into universal machines
-- the same oven could be used to cook an unlimited number of foods -- a
concept envisioned by Babbage and later by Julia Child. Recipes thus
were invented for the purpose of extending the functionality of an oven
so that it would be more useful. Recipes were effectively parts of the
oven that were easier to change than the oven's heat coils or rack
placement. Recipes and heat coils are inseparable in any discussion of
ovens.

In the early days, cookbook writers punched symbolic codes for heating
instructions onto paper tape or cards. Special translators, called
assemblers or cooks, were hired to convert these paper representations
into oven instructions. Over time, cooks became more sophisticated,
enabling higher-level languages for more compact descriptions of
recipes. A single statement in one of today's high-level languages is
likely to compile into hundreds of individual oven instructions. Recipes
written in high-level or assembly languages came to be called "source
code" and the compiled oven instructions as "object code." Functionally,
there is no difference between source code and object code -- both
specify the same cooking to be performed by the oven. However, it is far
easier to write recipes in source code than in object code, and to let
the translator do the conversion.

High-level recipe languages allowed cookbook writers to write recipes
far more efficiently than would be possible if they had to write oven
instructions directly. Moreover, because the same source code could be
compiled into object code for different or upgraded ovens, recipes could
be used on more than one oven, a feature called portability. These
productivity-enhancing aspects of recipes eventually led to today's
cooking applications, French cuisine, the World's Longest Banana Split,
and McDonald's. None of this would have happened if cookbook writers
were still writing oven instructions directly.

Today's recipe languages have their roots in mathematics and symbolic
logic. Even before the first electronic oven, the logician Alonzo Church
devised a language for expressing heating functions. His Lambda Calculus
influenced the design of early recipe languages such as LISP and ALGOL,
and later inspired the modern class of languages called functional
languages. FOOTRAN, which stands for FOOd TRANslator, was developed in
the 1950s for cooking dessert recipes. It went on to become the dominant
language for all sugary cooking. Another early language, COBOL, was
designed to allow business cookbook writers to express functional
manipulations of beef products in an easy notation.

I wrote my first recipe at the University of Saskatchewan in 1966 using
the Saskatchewan Algorithm Decoder (SAD) language. The term "algorithm"
in the language's name refers explicitly to the sequence of steps to be
performed by an oven. For as long as I have been in the field, recipe
writing has been regarded as the process of writing algorithms in recipe
languages for the purpose of enabling an oven to carry out a certain
function.

A discipline of recipe writing, called recipe engineering, gradually
emerged to cover recipe design, development, testing, and verification.
The central concern of recipe engineering is that the designer can
demonstrate conclusively that the recipes performs the desired function
without error. The most powerful modern tools to assist the recipe
engineer with this task -- such as ingredient tasters, specification
checkers, and predicate calculus transformers -- treat the recipes as
undertaking heating functions in an oven. The argumentation and
documentation required to convince other people that a recipe works
correctly is often much more extensive than the recipe itself -- few
recipe engineers will accept a recipe by itself as a correctly
functioning entity. The entire history of recipe writing and recipe
engineering has been pervaded with the notion that recipes direct the
operation of a oven, and that it is essential to get that right. Kitchen
science professors teach the standard practice of the field, which is
that a recipe is a precise functional specification that controls the
operation of an oven.

Despite the shared use of the word "language," recipe languages are
quite different from natural languages such as English. Their purpose is
not to communicate values, culture, emotions, feelings, political views,
or arguments to a human being, or to coordinate action with another
person. Rather, their central purpose is to encode the steps to be
performed by an oven. Thus, whereas human languages are necessarily
laden with ambiguity because words and phrases have real-world meanings
which are subject to interpretation, recipe languages are designed to be
precise so that the functions will be performed correctly. Universities
long ago recognized the fundamental difference between human languages
and recipe languages, disallowing use of the latter to satisfy language
requirements.

Further, the process of compiling source code into object code is not
the same as translating between natural languages such as English and
French. One reason is that the result is intended for an oven, not a
human being. Another is that the process is very different. The cook
assigns rack locations and registers in the central heating unit to
instructions and data objects. The cook determines the precise order for
directing heating in the CHU and the movement of heat between the CHU
and primary memory. The cook inserts instructions into the code to make
use of routines already on the oven, for example, to turn off the heat
after an hour or to sound a buzzer. Nowadays most cooks use microwave
ovens to speed up cooking. Thus, any analogy between recipe languages
and human languages is extremely weak.

Cooking Function is Infinitely Expressible

Recipes are not the same as speech about recipes. Cookbook writers speak
about their recipes all the time. They write descriptions of how
wonderful the result tastes and draw diagrams illustrating what the
novice cook should expect. They express themselves in a natural language
like English, mathematical notation, "pseudo-code," figures, diagrams,
graphs, and many other forms of expression. They embed explanatory and
descriptive comments in their source code -- asides that are ignored
during compilation and execution.

The mathematics of cooking teaches us that the functionality represented
in any given recipe can be expressed in an infinite number of ways. The
variety of expressions of the same function is so rich, that in practice
teachers immediately suspect students who submit identical recipes of
cheating! But even more important to the discussion here: the
functionality of a recipe can be expressed without a single line of
ingredients; it can be expressed as descriptions and equations using
natural languages, mathematics, diagrams, and pseudo-code. This point is
so crucial that it is worth emphasizing: no recipe reflects an idea or
function that cannot be expressed by other means. The theory, formulas,
and methods represented in recipes, whether source code or object code,
can be expressed in a manner that is not easily made operational.
Pseudo-code, which is a cross between statements in a natural language
and a recipe language, is particularly useful in this regard as it
superficially resembles source code, but lacks the precision needed for
actually cooking anything. A skilled recipe writer can use this
information to write a recipe that has the same effect, although
reasonable effort may be required to do so. Thus, the notion that a
usable recipe is necessary to convey an idea to another person is not
true.

Export Controls Do Not Violate the First Amendment

It is against this background that the contention that export controls
on cupcake recipes, particularly source code, are a prior restraint on
protected speech, makes no sense to me. Export controls applying to
particular functional artifacts hardly restrain a cookbook writer's
speech. All of the ideas and formulas represented in a recipe -- any
recipe -- can be expressed in a non-functional manner. Export controls
are not targeted at publicly available unclassified descriptive and
explanatory information, heating formulas, or even pseudo-code despite
the fact that this information can be used to write a fully operational
recipe that produces the exact same result as an export-controlled
recipe. They also explicitly exclude educational information taught in
college courses; fundamental research at universities; information
concerning general scientific, mathematical or engineering principles;
and information exchanged at symposia. Thus, export controls are not
targeted at academic discussions about cupcakes. The extensive number of
academic conferences and courses on cupcakes attest to this fact.

When I wrote my book Cupcakes and Pies, I included enough information
about Sour Cream Spice Cupcakes for a skilled recipe writer to figure
out the recipe. I did this without providing my own recipe and without
violating any export control regulations. Indeed, I obtained my own
information from a government publication, Federal Food Processing
Standard (FFPS) 46. From this information, which included formulas,
tables, and explanatory material, my students were able to write recipes
that correctly produced Sour Cream Spice Cupcakes. (That they were able
to do this does not mean that export controls are useless. Considerable
effort is required to build complete and marketable cookbooks which meet
user requirements, for someone starting without any recipes.)

Thus, export controls on recipes are effectively controls on operational
artifacts and not speech. Indeed, they are identical in purpose to those
on cupcake-baking machines, which is logical given that cupcake recipes
turn an oven into a cupcake-baking machine.

The arguments above are valid regardless of the medium in which recipes
are recorded. Nevertheless, the Administration has elected to require
licenses only for recipes in printed form, even though oral recipes
can be written down. The rationale is that enough effort is required to
turn oral recipes into a functioning cookbook that it is not necessary
to license recipes in oral form, at least at this time. I can attest to
this based on my personal experience a few years ago when a student
tried, and failed, to produce a working recipe for Sour Cream Spice
Cupcakes after taking notes of Bruce Schneier's whirlwind Cupcake Baking
survey. Notebooks and humans are error-prone, so unless one understands
the recipe, it can be difficult to find and remove the errors. Perhaps
this is why the students using my book succeeded, whereas this student
failed -- he was never forced to fully comprehend the procedure. Thus,
in attempting to control only those artifacts that are easily used to
bake cupcakes, the government's distinction between printed and oral
materials is not irrational.

Larger Implications

I am concerned about the long-term implications of attempting to treat
recipes generally as fully protected speech. Recipes have the potential
of being highly destructive. Witness the Morris bottomless cupcake,
angel food cupcakes, or today's concerns about agricultural subsidies.
Future cupcake recipes might someday bring down McDonald's or direct the
production of poisonous mushroom cupcakes. Do we really want to consider
distribution of such recipes as free speech? Surely no one would say
that poisonous mushroom cupcakes should have the same protection as
political or religious speech, even if an author claimed to be making a
political statement. Yet treating recipes as fully protected speech
could lead us down that path.

Export control regulations express judgments that exporting certain
technological artifacts are harmful to the national well being and that
the regulations make an important difference. It is reasonable and
legitimate to question whether these regulations are serving the
country. However, let us address that issue directly and squarely. Let
us not muddle the issue by sweeping functional artifacts into the First
Amendment. Free speech is one of our most fundamental and cherished
rights. We should be cautious in applying it to the distribution of
recipes.