Inhaltsverzeichnis von Intellectual Property and Open Source : A Practical Guide to Protecting Code

Inhaltsvorschau

When programmers get together to talk, the conversation is likely at some point to turn from .NET frameworks or memory usage patterns to copyrights, patents, or trade secrets. People in the computer field realize that a cluster of legal concerns known as intellectual property (IP) plays a big role in its development. Consider just a few of the headline-making legal issues in technology over the past decade, most of which will be remembered by readers of this book:

One of the most explosively popular applications in modern times, Napster, was shut down by a copyright infringement lawsuit in 2000. The founders of Napster thought they were safe from copyright infringement charges because the service itself never copied music files. But because its users shared copyrighted music without authorization from the copyright holders, the Supreme Court took down Napster a theory of “contributory copyright infringement.”
Around the same time, a promising new file-sharing service called Aimster was temporarily shut down on a different IP basis: America Online claimed infringement on its AIM trademark.
The shutdown of Napster (and Aimster) fostered a sudden interest by the public in new or previously obscure peer-to-peer file-sharing protocols. The changing technical and legal landscape has forced the music recording industry to shift its enforcement efforts to individuals, leading occasionally to lawsuits against six-year-olds and grandmothers, and sparking debates over whether colleges should collaborate in making students obey music industry restrictions on network use.
The SCO Group, a tiny computer company formerly prominent in the field of Unix, sued the most famous computer company in the world, IBM, in 2005. SCO put forward a cluster of complaints (soon taken up in lawsuits and countersuits involving other companies) covering just about every area of IP: abuse of its UNIX trademark, copyright infringement, and theft of trade secrets. (The trademark is officially on the uppercase name UNIX, but most of the computer field uses the casual spelling “Unix”.)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Imagine you are a software developer embarking on a new project with a large existing codebase and an active group of developers. On first impression, the code is messy and contradictory. It is plagued by corner cases and inexplicable design decisions. Your first thought might be to discard all of it and start over fresh. Indeed, some of the long-time contributors agree.

With time, however, you begin to understand some of the design decisions that went into the code. Many of the pure abstractions failed, and the previous contributors patched the code in order to achieve workable results in particular circumstances. In most cases, the original design was roughly followed, but parts of the code were extended or trimmed to accommodate for bugs or adjust to new circumstances. There are some new users of the code, as well—other groups have started using the code to do things that the original developers had never foreseen. Those new users have to be accommodated. The code may be messy, but at least it is understood, and it works where it needs to.

This scenario, which any programmer would dread, is like the current state of intellectual property law. The law is a code, just like computer code. It is even described that way; the books that hold the laws are described as the United States Code (USC). There are definitions, reserved words, and code sections. There are the rough equivalents of subroutines, symbol tables, and linkers. Lawyers and judges act as interpreters. (Lawsuits concerning single passages of the code often take years, making other interpreted languages look like a lap of the Indianapolis 500 in comparison.)

It gets worse: every line of the legal code was written by committee, and almost every line of it has been patched by a later piece of legislation or modified by a court. Indeed, IP law is rooted in a more than 200-year-old codebase. Is it any wonder that it is a mess?

Nevertheless, there is usually logic behind the apparent messiness (or even madness) in the law. Just as with the long-time developers above, the original design of the intellectual property code has been stretched in some places and squeezed in others to make it fit new circumstances and changed priorities. Also, like the developers above, new laws have come to depend on the specific structures defined as intellectual property. We even have courts to carry out a form of test-driven development for new laws. Like the code described above, it may be messy, but at least it is understood, and it usually works where it needs to.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There are four main branches of intellectual property, each designed to protect a different type of intellectual product. Later chapters will focus on individual types of intellectual property. For now it is enough to introduce the four primary systems that constitute IP.

Patents are time-limited statutory monopolies designed to protect inventions and technological developments. In return for full disclosure of your idea, you are granted the ability to prevent anyone else from making, using, selling, offering for sale, or importing the invention. Patents last for a maximum of about 20 years, after which the invention becomes part of the public domain.

During its life, the patent protects all implementations of a particular idea. You have the right to prevent other people from practicing (either making or using) your invention, even if they independently invent or re-implement the advancement described in your patent (in other words, even if they didn’t copy your idea).

Because patents offer such strong protection, they are designed to be hard to get. A patent must disclose an invention that is “useful,” “novel,” and “non-obvious.” Unfortunately, this doesn’t mean that all granted patents are useful, novel, and non-obvious! Further, the patent must completely describe the best way to implement the invention using highly technical language. Well-drafted patents usually cost from $10,000 to $50,000 to obtain and generally require the assistance of a registered patent lawyer.

Copyrights are limitations on the expression of an idea. They are designed to protect paintings, sculptures, writings, boat hulls, dramatic works, architectural drawings, and anything else that shows individual creative expression. According to the copyright statute, copyright protection automatically attaches to anything you create as soon as it is “fixed in a tangible medium of expression”—basically, as soon as it is written down or recorded somewhere. Copyrights can last from 90 to about 150 years, depending on the circumstances.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Intellectual property starts with economics. Intellectual property law is, at its most basic, an attempt to remedy a failure in the market for knowledge. We want more knowledge in society, but the nature of knowledge tends to discourage (or technically, underencourage) efforts to create and share new ideas.

Normally, economists analyze society in terms of preferences, markets, and incentives. We all have preferences—things that we want and things that we don’t want. A market is the place where we exchange goods and services with others, making decisions about how to best satisfy our preferences. There are costs (incentives) associated with getting what we want; the “price” of something is the result of balancing how much we want some good (our demand) with how much other people are willing to provide that good (the supply).

The interesting thing about markets is that they involve tradeoffs. Because we have limited resources, we have to make choices between different goods. If something costs very little, we tend to substitute the low-cost goods for high-cost goods.

Normally, the balancing of costs and preferences results in an optimal aggregate distribution of goods. Every once in a while, however, we encounter a market failure, a situation where balancing costs and preferences results in overproduction or underproduction of a certain good.

In this particular case, the good that we want is knowledge. As we will see, creating new knowledge is costly, and normal markets tend to discourage the creation of new knowledge. Intellectual property is the tool that we use to remedy this market failure. That is, intellectual property is the tool we use to change incentives to increase the amount of knowledge in society.

More specifically, intellectual property law is designed to fix the problems that arise because: 1) knowledge costs more to create than it costs to copy (or consume); and 2) secret knowledge is more valuable to individuals, but shared knowledge is more valuable to society.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

So, does intellectual property work? Yes...and no. In one sense, our intellectual property system has been phenomenally successful in encouraging people to create intellectual property. For the past 50 years—and especially the past 30—there has been a tide of stronger intellectual property protections across industries. This growth in IP has encouraged people to invest heavily in the development of new intellectual property, and has moved IP to the core of many business strategies. For most businesses in the United States, in fact, the intellectual property part of the business is the most valuable aspect of the business.

Nevertheless, people’s attitudes about intellectual property are changing. We are starting to see a swing away from stronger intellectual property protections, and toward more openness and collaboration. As things change, it is important to understand not only the current intellectual property laws, but also the structure and purpose of the underlying system. Part of this swing toward openness is reflected in the growing acceptance and importance of open source software.

Whether or not people agree about the desirability of intellectual property, it still has to be acknowledged as an independent discipline and a major force in the computing industry. For example, there are intellectual property divisions in law schools, intellectual property departments in corporations, and intellectual property lawyers in the telephone book.

Furthermore, different concepts under the intellectual property umbrella work together and it takes a lawyer to help you understand how they are coordinated and apply to your specific situation. For instance, should a particular inventor rely on a trade secret or a patent for protection? Is copyright enough to protect a cartoon character, or should it be registered as a trademark as well? These concepts become entwined through use.

The next chapters take a deeper dive into the specifics of each branch of intellectual property. Except where necessary, I will not return again to the broader foundations of intellectual property law. As you read, however, it would be valuable to consider the philosophical foundations as they relate to each branch of the law. In some cases, the original intent has been frustrated by later developments in the law. In other cases, the utilitarian bargain is more or less working as expected.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Imagine you are a programmer learning a new computer language. When you are given a program in the new language, the syntax is usually obscure even if the overall constructs are familiar. Repeated exposure and study may alert you to reserved words and give you an idea of their meaning, but fully understanding the program requires you to know the syntax and semantics of the language as well as the problem domain addressed by the code.

Patents are the type of intellectual property that most closely resemble code in this context. A well-written patent document is highly structured, with required sections, definitions, reserved words, and “program flow” constructs.

As a result, patent documents tend to be very boring, somewhat ungrammatical, and only semi-intelligible to an ordinary competent English speaker. Even when you understand the problem domain addressed by a particular patent (i.e., the area of technology described within the patent) you do not fully understand the patent until you also have a handle on the specificities of the patent language.

In fact, patents are specifically like pattern-matching code such as regular expressions. Instead of matching text, however, patents match technology. As anyone who has used regular expressions can tell you, though, very complex regular expressions don’t always match what you think they should when you first run them. Patents are similar; in truth, nobody (not even patent lawyers) knows exactly what a patent will match until the patent is tested by running it through a court.

Patent law differs from other forms of intellectual property in its substantial focus on the patent document itself. The limits and bounds of the patent grant are almost entirely defined by the words and phrases used in the patent instrument.

This chapter is one of two in this book that look at patents, one of the most controversial topics at the crossroads of computers and intellectual property. Because patent law is so intimately concerned with the language and structure of the patent document, it is valuable to begin by looking at the patent document itself. Only after we understand the patent document can we begin to look at getting and using the patent.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Pattern-matching code usually has a compact form used to represent the range of possible inputs matched by a particular expression. Examples include regular expressions, tag tables, document type definitions (DTDs), and schema. State machines or automata can also be used to represent patterns.

As noted earlier, patents are very similar to code, pattern-matching code in particular. It should not be surprising, then, that a patent document has a detailed file format, not unlike the file formats used by your computer.

For example, the standard file format for Linux is called the Executable and Linking Format, or ELF for short. Every ELF file begins with a structure called the ELF header. This structure contains information that describes the contents of the file. It includes the file’s magic-number signature, with flags indicating whether the contents are 32-bit or 64-bit, little-endian or big-endian, etc.

After the ELF header comes the program header table, which points to the various parts of your program. This is followed by one or more code segments and (usually) a section header table used for linking your program.

The format of a patent is surprisingly similar to the format of an ELF file. The first page of the patent is called the face of the patent and acts like a header for the patent file. It contains information about the patent. For example, it includes the patent number, the list of inventors, the patent’s magic dates, a list of cited references, and an abstract describing the contents of the file.

After the face of the patent come the figures and short descriptions, designed to illustrate the various parts of your invention. This is followed by the detailed description, a series of paragraphs describing the implementation and functioning of your invention as illustrated by the figures. The final part of the patent consists of the claims, a series of sentences describing the bounds of legal protection granted by the patent.

The similarities are illustrated in .

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The face of the patent contains metainformation about the patent—required dates, numbers, outside references, etc. We will examine certain portions of the face in detail.

The largest feature on the face of the patent (aside from the designation of the document as a United States Patent) is the assigned patent number. Patent numbers are assigned in order as patent applications are approved. Therefore, the assigned patent numbers not only provide unique identifiers for each invention, but also serve as a running tally of all patents approved by the United States Patent and Trademark Office (USPTO or PTO) since the organization of the office on July 4, 1836. (Patents were approved prior to this date by the secretary of state; there were about 10,000 patents between the first patent act in 1790 and 1836.)

There is not any necessary correspondence between a patent’s number and its application date, its issue date, or any other date associated with the patent. Because numbers are issued in order of approval, however, you can get a rough idea of the age of a patent by looking at its number. At the time of writing, the most recently issued patent is number 7,278,169, for “Controlling the downloading and recording of digital data.” The oldest enforceable patent is number 4,739,880 for a “Laundry Hamper.” Patents with numbers lower than that have fallen into the public domain. By the time you read this, however, the Laundry Hamper will be old news, and many other patents will also have entered the public domain.

Some patents have letter codes at the start of the number, for example, D552,191 for a “Dragon” design or RE39,316 for a “Sliding visor.” These codes refer to specific categories of patents as opposed to standard utility patents. shows the various specialized patent types.

Table : Specialized patent categories and their numbers
Example patent numbers	Specialized category

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Conceiving an invention is more than just “thinking it up.” For example, most of us have “thought up” teleportation. What we haven’t thought up are the specifics of a working idea. Even if we assume that someone already came up with a machine that would be theoretically capable of teleportation, but they just didn’t realize that the machine could be used for teleportation, that person would still not have conceived teleportation in the legal sense. To be an inventor, you must come up with and recognize that you have a working idea.

The conception of an invention is complete if an inventor can provide a description that would enable a person having ordinary skill in the art to actually make the invention without extensive research or experimentation. This is sometimes called an enabling disclosure.

Reducing an invention to practice involves the process of filling in the technical details necessary to make the invention work. Sometimes the process of stating an idea makes the reduction to practice obvious; many times it does not.

A good example showing the distinction between conception and reduction to practice is the story of Thomas Edison and the lightbulb. Very early on, Edison had a working idea—that passing electricity through a resistant material could cause it to glow, providing light. Turning that conception into a workable lightbulb, however, was difficult. Edison tried over 6,000 different materials before trying the carbonized cotton thread filament that resulted in patent number 223,898.

A reduction to practice can be either actual (you actually build the invention) or constructive. I stated earlier that the conception is complete when the inventor can make an enabling disclosure. Constructive reduction to practice is complete when the inventor actually makes that disclosure.

In many circumstances, there is no question about inventorship. Either one person or a small number of people conceives, designs, and builds the invention. When there is more than one person, all of them are listed as co-inventors. Nevertheless, there are two recurring issues that complicate real-world inventorship discussions: political and business pressures, and determining contributions.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The body of the patent is commonly called the specification. It makes up the bulk of the patent document, and is the part of the document most people refer to when they talk about the patent. On first glance, this seems reasonable; after all, the specification contains all of the pictures, equations, method descriptions, and assorted details necessary to make the invention work.

It doesn’t matter; much of what is written in the specification has relatively little effect on what is covered by the patent. Most experienced patent lawyers will skip right to the claims when interpreting a patent. This is changing, however; there are some recent cases that held patents invalid based on screwy comments or poor drafting in the specifications. Further, any ambiguous claim terms are interpreted by referring to the specification and patent history. Nevertheless, the fact remains that the specification is one of the least legally significant parts of the patent.

So why include a specification at all? One answer goes back to the utilitarian bargain inherent in the patent law. The specification preserves and communicates to society the knowledge held by the inventor. The technical know-how contained within the specification gives the patent long-run value by enabling others to make and use the invention after the patent expires. The short-run value (the boundaries of the right to exclude) are largely defined by the dates on the face of the patent and the claims at the back.

With that said, the specification, while not great reading by any means, is the most interesting part of the patent. It generally includes the drawing sheets, the background and summary of the invention, descriptions of the drawings, and a detailed description of various aspects of the invention.

The drawing sheets are placed right below the face of the patent. As described earlier in the section titled ,” a patent usually has at least one figure. Most patents have many figures, varying in type according to what they are intended to show.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The claims are the legal heart of the patent. Just as the patent dates define the temporal boundaries of patent protection, the language of the claims defines the intellectual boundaries of the patent. As described by 35 U.S.C. § 112:

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.

Translated, this means that the claims are the invention. Each separate claim is a separate invention and represents a separate grant of rights from the government.

Patent claims appear at the end of the patent as a series of numbered sentences. Each patent claim is one sentence. Because it is difficult to shoehorn the complete subject matter of the patent into a single sentence, patent claims are among the most awkward and ungrammatical sentences you will ever read. Nevertheless, after you learn the ropes and work your way through a few patents, you will get a feel for the rhythm and conventions of claim language and will be better able to understand new claims.

A claim, like the patent as a whole, is highly structured. It has a preamble, transitional phrase, one or more limitations, and optional effects clauses. shows claim 1 for Amazon’s ’411 patent.

Figure : Claim 1 of Amazon’s 1-click patent

The preamble

The preamble has only one requirement: it must specify the type of invention being described by the claim. For example, the preamble may recite a system, an apparatus, a method, a composition of matter, or any other type of patentable advance.

In addition to defining the type of invention described by the claim, the preamble may also state a goal or introduce terminology. For example, Amazon’s 1-click patent states, “A method for placing an order for an item” (see ). Other patents may specify a “A wireless networking system for connecting mobile computers to the Internet.”

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There are a number of resources available on the Internet for looking up patent documents. The best overall search interface is provided free by the USPTO at http://www.uspto.gov/patft/index.html. There are a number of searches, such as the quick search and the patent number search, but the real jewel is the advanced patent searching capability. The PTO has divided up and indexed all U.S. patents granted since 1976. A nestable Boolean search is available, including operators for each field of the patent and range operators for the dates. Results are provided as HTML rather than in the standard patent document format, but the database is always up-to-date.

Google also has an excellent patent search interface available at http://www.google.com/patents. Google’s search doesn’t have the same per-field granularity provided by the PTO and its information can sometimes be spotty due to the necessity of using OCR to recognize many old patents. Nevertheless, Google’s full-text searching can’t be beat and it offers easy PDF downloads of each patent.

Finally, patents in PDF format can be downloaded either through Google’s patent search, http://www.pat2pdf.org or Free Patents Online (at http://freepatentsonline.com). For the latter two services, however, you will need to know the number of the patent you are looking for first; neither of these services really provides a way to search or browse the patents.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One of the first assignments frequently given to new programming students is the Fibonacci function: given a number n, return the nth number in the Fibonacci sequence. A typical response to this assignment might be coded as follows:

def fib(n):

    if n == 0: return 0

    elif n == 1: return 1

    else: fib(n−1) + fib(n−2)

Unfortunately, this code has a trick: trying to compute fib(n) any numbers larger than 40 or so results in incredibly long running times. In algorithmic terms, this code has complexity O(2ⁿ). In other words, the running time increases exponentially as the number requested goes up. Before n gets very large, the running time is too long to be feasible.

The reason why the fib function is so expensive is because it redoes the work each time. If you ask for fib(5), the function also works out fib(4) and fib(3). The calculation of fib(4) in turn works out fib(3) and fib(2). The calculation of fib(3) works out fib(2) and fib(1), etc. There is a lot of duplicated effort, and that duplicated effort takes work and time.

One technique for speeding up this function is memoization. Memoization works by caching the results of each call in a lookup table. The first time a function is called with certain arguments, the memoized function computes the result and associates the function arguments with the result value. When the function is called later with the same arguments, the memoized function returns the cached value rather than spending time and processing power computing the results again.

For example, a memoized Fibonacci function might look like the following:

memo = {0:0, 1:1}



def memo_fib(n):

    if n in memo: return memo[n]

    else:

        result = memo_fib(n−1) + memo_fib(n−2)

        memo[n] = result

        return result

Unlike the original fib function, this function can be called with very large numbers and will return almost instantly.

It is important to note that a memoized function is always slower than a normal function the first time it is run. The functions associated with memoization—the value lookup, cache miss, and association of the result with the argument list—all take time and processing power. Nevertheless, memoization is a critical optimization tool. If the cost of creating the result is much greater than the cost of the caching machinery, returning a cached result is much cheaper than re-creating the result for each function call.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The patent system as a whole can be compared to applying memoization to the process of invention. Creating a new invention is like calling an expensive function. Just as it is inefficient to recompute the Fibonacci numbers for each function invocation, it is inefficient to force everyone facing a technical problem to independently invent the solution to that problem. The patent system acts like a problem cache, storing the solutions to specific problems for later recall. The next time someone has the same problem, the saved solution (as captured in the patent document) can be used.

Just as with memoization, there is a cost associated with the patent process, specifically, the approximately 20-year term of exclusive rights associated with the patent. Nevertheless, the essence of the utilitarian bargain is that granting temporary exclusive rights to inventions is ultimately less expensive than forcing people to independently recreate the same invention.

Thus, patents are an expression of the utilitarian model for intellectual property described in . They can be viewed as a contract between society (represented by the government) and an inventor. In return for the development of new technology and its eventual dedication to the public domain, the government agrees to grant a roughly 20-year exclusive right to make, use, sell, or import the invention. After the patent expires, the patent is dedicated to the public domain for anybody to make, use, or sell.

Further, the patent system can also be viewed as an optimization of our collective inventive capacity. The invention process is expensive. Even though many inventions seem obvious in retrospect, it is very difficult to come up with the original breakthrough idea. The patent system catalogs these inventions—solutions to problems—as patents, making them available for others to use.

Returning to the comparison we made in between regular expressions and patents, it is interesting to note that regular expression evaluation is one of the most frequently memoized operations in languages that support regular expressions. Just as described above, the regular expression is evaluated and the result cached; subsequent use of the regular expression reuses the cached version.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Patentable subject matter is set out by four sections of the U.S. Code: sections 101 (subject matter and utility), 102 (novelty), 103 (obviousness), and 112 (enablement). Each of these sections has thousands of pages of interpretation in books and court cases; we will whittle these four horsemen of the patent act into a general framework that we will use to explain the structure and mechanics of the patent law.

Because this section is so short and so important, it is reproduced here in its entirety:

§101. Inventions patentable
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefore [sic], subject to the conditions and requirements of this title.

The first important point to note is that the law is written such that it assumes that a patent should be granted unless certain conditions apply. Although the conditions for getting a patent are frequently stated in the negative (“You can’t get a patent unless...”), the default position in the law is that anything “new and useful” is patentable.

Statutory subject matter

Section 101 defines what is considered statutory subject matter: processes, machines, items of manufacture, and compositions of matter. Processes are defined as any “process, act or method” and are directed to technical and industrial processes (who says legislators don’t understand recursion?). Machines don’t have to be wholly tangible and can include systems and devices. “Items of manufacture” describes items that are made somehow via human effort. “Compositions of matter” are chemical compounds and mixtures.

These statutory categories can interlock. For example, the inventor of a new kind of peanut butter sandwich could receive three different patents: a process patent on the method of making the sandwich, a machine patent (or device patent, as they are frequently called) on the sandwich-making contraption, and an article of manufacture patent on the sandwich itself.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

So, you have come up with a new invention: you have invented a mousetrap that can read email (Zawinski’s Law states that every program attempts to expand until it can read mail—programs that cannot so expand are replaced by ones that can). The process of protecting your email-reading mousetrap will usually vary depending on whether you are in a typical corporate environment or in a startup/solo inventor environment.

Corporate patent processes vary from company to company. Some procedures may be essentially ad hoc, while others may be completely formalized. Generally, the more established the company, the more formal the patent process. In most cases, corporate patent processes go through four stages: disclosure, evaluation, application, and prosecution.

Disclosure

The first stage in the corporate patent process is disclosure—letting your company know that you have come up with a new and possibly patentable idea. Informally, disclosure may be as easy as sticking your head into your boss’s office to tell him about your idea. In most cases, though, your disclosure will require a written record, known as an invention disclosure form.

The disclosure form serves a couple of purposes. First, it serves as a record of the invention. Second, it allows your company to evaluate the invention for patentability, and third, it serves as an initial disclosure for the patent attorney.

Most disclosure forms have two parts, bookkeeping data and a description of the invention. The bookkeeping data is generally basic, consisting of a title, conception date, and list of inventors. Your company may also ask about the relationship of your invention to current development, both at your company and at competitors’ companies. They will also probably ask about whether you have told anybody else about your invention.

The description of the invention forms the bulk of the disclosure. Typical forms ask for background on the invention and a detailed description of how the invention works. You may be asked to provide code, examples, engineering specifications, design diagrams, and flowcharts, basically anything necessary to describe the invention to another engineer.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Patents are the most expensive and powerful weapons in an IP arsenal. For some companies, particularly pharmaceutical companies, patents are the lifeblood of invention and the key to profitability. For other companies, particularly software companies, patents are the rough equivalent of madly proliferating nuclear weapon arsenals.

For example, an unscientific survey was performed on the popular patent blog “Patently-O” in late 2007. Readers were asked whether the patent system, taken as a whole, had been positive (made money) or negative (lost money) for their companies. shows the results from 131 corporate employees, all of who were highly involved in their companies’ patents and patenting processes.

Figure : Corporate perception of patents across industry groups (used by permission of Dennis Crouch)

These results merge responses from small corporations with those from large corporations. It also excludes individuals at law firms, government entities, and educational institutions. Individuals responded to the question, “Overall, has your company made money from the patent system?” There were three potential responses: “Clearly positive (made money),” “Unsure whether positive or negative,” and “Clearly negative (lost money).” For the graph shown in , these responses were converted to a simple numerical scale: 1, 0, and −1, respectively. The y-axis ranges from −1 to 1.

The most interesting aspect of this graph is that software companies consider participating in the patent system to be a money-losing proposition—but they still do it. Even companies that are highly successful in getting software patents can have an uneasy relationship with the patent system. During Patent Office hearingsconcerning software patents and industry, Adobe’s principal scientist, Douglas Brotz, stated:

Good morning, Mr. Secretary and members of the Panel. My name is Douglas Brotz. I’m Principal Scientist at Adobe Systems, Incorporated, and I am representing the views of Adobe Systems as well as my own....

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The movie Antitrust came out at the height of the dot-com boom. Antitrust was Hollywood’s take on the geek chic of the late 1990s: the story of a few heroic open source hackers taking on an evil, grasping corporation situated in the Pacific Northwest.

Predictably, it was awful.

Buried among all the things that this movie got wrong, though, was one thing it got right: early in the movie, the protagonist is seen wearing a t-shirt that labels him a “code poet.” In one phrase, they captured why software is subject to copyright law—because it is a form of personal expression, not just a means of accomplishing some function.

Understanding the subtle distinctions inherent in that statement is essential to understanding the storms of controversy that inevitably arise around copyright issues.

Copyright is probably the most difficult of the four major branches of intellectual property law. Although patent documents (and some aspects of patent practice) are more complex and intricate than the copyright equivalents, the underlying mechanics of the patent system are relatively simple.

Patents can be seen as a straightforward exchange: describe your invention to society and in return receive exclusive control over the use of the invention. After a while, the period of exclusive control ends and everybody receives the benefit of your inventive effort.

Copyright is superficially similar but fundamentally different. Like patent law, copyright is part of the grand bargain discussed in . In return for the creation of knowledge, we also grant to authors a time-limited property right over the fruits of their intellectual efforts.

However, copyright has a far more human dimension than the mechanical results of inventive effort; it is much more about who we are than about what we do. As a result, copyright is much more subtle than patent law. In particular, there are two fundamental differences between patents and copyrights:

Patent law covers function; copyright law covers expression.
You have to work to get your invention

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Copyright is probably the most difficult of the four major branches of intellectual property law. Although patent documents (and some aspects of patent practice) are more complex and intricate than the copyright equivalents, the underlying mechanics of the patent system are relatively simple.

Patents can be seen as a straightforward exchange: describe your invention to society and in return receive exclusive control over the use of the invention. After a while, the period of exclusive control ends and everybody receives the benefit of your inventive effort.

Copyright is superficially similar but fundamentally different. Like patent law, copyright is part of the grand bargain discussed in . In return for the creation of knowledge, we also grant to authors a time-limited property right over the fruits of their intellectual efforts.

However, copyright has a far more human dimension than the mechanical results of inventive effort; it is much more about who we are than about what we do. As a result, copyright is much more subtle than patent law. In particular, there are two fundamental differences between patents and copyrights:

Patent law covers function; copyright law covers expression.
You have to work to get your invention into the protected space of patents. You have to work to get your expression out of the protected space of copyright.

The social and legal difficulties of copyright law can mostly be traced to one or both of these fundamental principles.

The first fundamental principle is that copyright protects personal expression in all its varieties. This is both the great strength and compelling weakness of copyright.

To understand why, think again about the economic difficulty of knowledge creation. In , we discussed how knowledge has network effects; the more people who possess a piece of information, the more valuable the information becomes. Nevertheless, people sometimes don't want to share their knowledge because they lose the personal advantages that come from keeping the information a secret. The result is a market failure, because the incentives that promote secrecy tend to reduce knowledge-sharing below the optimal level.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

So with the context of history, it is time to start looking at the terms in the law to see how they are applied today. The basic rules for copyright are set forth in Title 17 of the U. S. Code, which is largely still based on the Copyright Act of 1976.

The Copyright Act gives protection to “original works of authorship fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device.”

Works of authorship include:

Literary works
Musical works, including any accompanying words
Dramatic works, including any accompanying music
Pantomimes and choreographic works
Pictorial, graphic, and sculptural works
Motion pictures and other audiovisual works
Sound recordings
Architectural works

These categories are flexible. As noted above, software is considered a literary work. Unless you are sure that some type of expression is outside the bounds of copyright, then you should assume that copyright applies.

The first core principle of copyright is that it applies only to an expression. So, what is an expression?

In math, an expression is a combination of symbols (numbers, operators, and variables) that can be evaluated.
In a computer context, an expression can also refer to some representation of a value or something that can be evaluated to return a value.
In language, an expression is a communication in speech or writing.

The common thread between these (and other) definitions is that they all make reference to something concrete, usually a specific sequence of words or symbols. Different symbols are used to illustrate a particular thought or convey a particular idea.

Broadening this definition, an expression is any artifact used to convey an idea. The artifact may be ink on a paper, code in a file, paint on a canvas, or words on a page; the important aspect is that concrete physical representation communicates an idea from one person to another.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As with patents, the patchwork of laws affecting copyright has made it somewhat complicated to figure out the copyright status of some works. For this issue, there are three different laws to consider: the Copyright Act of 1909, the Copyright Act of 1976 (which went into force on January 1, 1978), and the Sonny Bono Copyright Term Extension Act of 1998. The duration of a copyright depends on when the copyrighted work was first created, when it was first published, and where the work was created. For our purposes, we will assume that all works were created in the United States.

Starting from the oldest works, anything that was registered or published before 1923 is in the public domain. These works can be used by anyone for any purpose; their use cannot be controlled, despite the fact that some publishers put copyright symbols on reproductions of public domain works.

If a work was published between 1923 and 1963, a two-term system was applied, with a renewal required 28 years after the initial registration to maintain the copyright. If the copyright owner did not apply for copyright renewal, the copyright expired and these works are now in the public domain. If the copyright owner did renew the copyright registration, these works had their terms automatically extended to 95 years. These works will enter into the public domain no sooner that 2018 (95 years from 1923).

If a work was published between 1964 and 1977, there is no renewal requirement. These works will automatically have a 95-year term and will enter the public domain no sooner than 2059.

The Copyright Act of 1976 established new, much longer copyright terms for all new works. For all works fixed on or after January 1, 1978, the copyright term extends for the author’s life plus an additional 70 years after the author’s death. If it is a joint work (a work made by more than one author), the term extends to 70 years after the last surviving author’s death. For works for hire (works created in the course of employment) or anonymous/pseudonymous works, the copyright extends for 95 years from publication or 120 years from creation, whichever is shorter.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

By default, authors own their copyrights. This may seem natural now, but it was actually a substantial change made in the 1976 law; under all previous iterations of the Copyright Act the copyright was owned by the publisher (remember, this was a publishing right). In most situations under the current law, you own the rights to your personal creative expression.

One important distinction is that owning a reproduction of someone’s expression (the result of the verb “copy”) doesn’t give any rights to the underlying creative expression (the noun “copy”). For example, if you own a CD of the Muppets’ Greatest Hits, your ownership is limited to the particular piece of plastic that you bought in the store. It so happens that the piece of plastic you own can be read in a certain way to reproduce the Muppets’ music, but your rights over the music are limited to reading the disc.

When the 1976 Copyright Act flipped the default from “works are not copyrighted unless they have been registered” to “works are copyrighted unless an exception applies,” it created a broad new category of copyrighted works: unpublished copyrighted works. Under previous Copyright acts, there was no concept of copyright for an unpublished work, because copyright applied only to published works.

Unpublished copyrighted works are by far the most common category. If you doodle in school, you create an unpublished copyrighted work. If you take notes in a meeting, you create an unpublished copyrighted work. If you sing “Happy Birthday” for the video camera at a party, you create an unpublished copyrighted work. Just as the Turing machine proceeds through its computations leaving symbols on its tape, so too, do we move through life leaving behind us a trail of miniscule copyrighted artifacts.

Although we have talked about personal expression so far, more than one person can be considered the author of a work. When several people work together to create a single work, the result may be a

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Copyright, like other forms of intellectual property, reserves to its owners certain exclusive rights. In the case of copyright, Section 106 of the Copyright Act grants the owners of copyrights the exclusive right to do (or allow someone else to do) the following:

Reproduce the copyrighted work
Prepare derivative works based upon the work
Distribute copies of the work to the public
Perform the copyrighted work publicly
Display the copyrighted work publicly

The first and (now) most fundamental reserved right is the right to reproduce a copyrighted work. Some people believe that any private copying within a home is acceptable under copyright law. Under the strict terms of the statute, there is no provision for copying of any kind, private or not. This is why, for example, the RIAA (the Recording Industry Association of America) argues that putting MP3s on your iPod is a copyright violation. In their view, any copying must be explicitly authorized.

This argument does not hold up in many circumstances because of fair use (which we will discuss further below), but there is support for their position that any copying infringes their copyrights.

You may occasionally see the terms “ and “sound recording” applied to copyrighted works. A “ is the physical object that embodies a work of authorship, like a CD, DVD, or hard drive. According to the Copyright Act, a “sound recording” is any work that results “from the fixation of a series of musical, spoken, or other sounds, but not including the sounds accompanying a motion picture or other audiovisual work.” Phonorecords usually (but do not necessarily) contain sound recordings.

One of the more important reserved rights under copyright law is making derivative works. According to the Copyright Act, a derivative work is:

...a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In June of 2001, Slashdot led with the headline, “More Trouble With AOL And GAIM” (http://yro.slashdot.org/article.pl?sid=01/06/25/2115200). Mark Spencer, the author of GAIM (later renamed “Gaim”) explained it in his own words:

Well, AOL is at it again. In 1998, I wrote a program called GAIM which provided Linux users with a way to participate in AOL’s Instant Messenger (tm) service. GAIM is one of the best examples of Open Source software in action....
In July of 1999, I received a letter from AOL’s Legal Representation requesting that we remove their AOL trademark and logo from our web site and product name, which we promptly did. Now, in 2001, the same firm has sent us notice requiring that we change the name of the product...because they believe GAIM’s name to be confusingly similar to the AIM trademark....

The legal challenges from AOL continued for almost six years. A settlement was finally reached, but one of the conditions was that the project be renamed. Gaim was renamed Pidgin in April, 2007. The code continued, but the name had to go. And the reason was trademark law.

The traditional definition of a trademark is a word, name, or symbol used to identify particular products or services offered by a particular manufacturer or coming from a particular source. Trademarks have their roots in manufacturing—in the trades (hence the name). As soon as people began to specialize in the manufacture of certain goods, they wanted a method of distinguishing their wares from others offering similar goods. Thus, they began to “mark” their products with some sort of identifying symbol or name.

Over time, the concept of the trademark was expanded to include other types of commercial enterprises—services, trade associations, certifications, and so forth. These alternate marks are all considered under the category of trademark law, but they have their own individual names. Trademarks (as opposed to the general category of trademark law) have been maintained for use in connection with goods.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The traditional definition of a trademark is a word, name, or symbol used to identify particular products or services offered by a particular manufacturer or coming from a particular source. Trademarks have their roots in manufacturing—in the trades (hence the name). As soon as people began to specialize in the manufacture of certain goods, they wanted a method of distinguishing their wares from others offering similar goods. Thus, they began to “mark” their products with some sort of identifying symbol or name.

Over time, the concept of the trademark was expanded to include other types of commercial enterprises—services, trade associations, certifications, and so forth. These alternate marks are all considered under the category of trademark law, but they have their own individual names. Trademarks (as opposed to the general category of trademark law) have been maintained for use in connection with goods. Service marks are used in connection with services. Collective marks are used by associations, cooperatives, or other groups to indicate membership. Certification marks are used to indicate the approval or endorsement of a third-party product or service. Because these all cover different types of products, services, and situations, lawyers discussing trademark law talk generally about “marks” when they are referring to any of the different types. gives common examples of each kind of mark.

Table : Types of marks
Type of Mark	Examples
Trademark	Linux, Exxon, Coca-Cola, Chevrolet, KitchenAid, Special K
Service marks	Flickr, Netflix, FedEx, Sharper Image, TruGreen Chemlawn
Collective marks	Girl Scouts, Better Business Bureau, SEIU, PGA, American Heart Association
Certification marks	Good Housekeeping Seal of Approval, TRUSTe, Hacker Safe, Open Source

The problem with this definition of trademarks is that it conveys a lot of information without conveying a lot of understanding. So perhaps a better way to appreciate trademarks is to think about the shortcut icons on the desktop of your computer. shows a typical shortcut icon.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Trademarks are not rooted in a utilitarian public goods bargain like patents and copyrights. One reason is that trademarks are just too old; some forms of trademark-like marking go back almost 4,000 years. (The foundations of the utilitarian bargain underlying patent and copyright law only go back four or five hundred years at the most.) However, the difference between trademarks and patents and copyrights is much more fundamental than just age.

The trademark laws are actually quite specific regarding the source of the authority used to pass federal trademark-related laws. The first national trademark law, passed in 1870, cited the patent and copyright clause of the United States Constitution as the basic authority for trademark law. This law was overturned by the Supreme Court as beyond the power of Congress; the patent and copyright clause contained no explicit or implicit provision enabling Congress to establish trademark protection. Undeterred, Congress tried again in 1881, this time basing the statute in the Commerce clause of the Constitution. The Commerce clause rationale stuck, and is the explicit basis for Federal Trademark law today.

Specifically, patents and copyrights were developed to combat a public goods problem. There are disincentives to developing or sharing patentable or copyrightable knowledge because the knowledge is non-excludable. Those same economic fundamentals, however, aren’t driving trademark law. Putting aside any question of trademarks as an art form, there just is no public goods justification for encouraging the development of new words for the English lexicon (like Exxon or Flickr), tiny repetitive melodies (like the Windows startup sound) or small, stylized drawings (like the Firefox icon).

Nevertheless, trademark-like markings developed spontaneously in many civilizations across the world. The independent development of trademarks in so many places suggests that there are underlying causes that tend to encourage their creation. Two theories are used to explain the development and function of trademarks in economic terms.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Keeping in mind the analogy of trademarks to computer shortcut icons, the contours of trademark law are easier to understand. Trademark law is designed to allow users to exclusively identify the commercial source or origin of their products or services. Trademark rights arise through actual use of the mark in a commercial context; that is, trademark rights first start to accrue when consumers first have the opportunity to make the necessary mental associations. Those who hold trademarks are allowed, and in fact required, to protect the mental association between the mark and the associated service, product, or company. Failure to protect the customer associations connected with the mark removes the distinctiveness of the mark as an identifier, resulting in the termination of the trademark rights.

So far, our discussion of trademarks has focused on word marks (like the word “Firefox”) and visual symbols (like the Fox-and-Earth icon used for Firefox). shows a number of these well-known business marks.

Figure : Well-known business logos

While these types of marks are by far the most common, any distinctive symbol, word, shape, sound, scent, color, or texture may be used as a mark if it performs the necessary source-identifying function. For example, Owens Corning has a trademark on the color pink as applied to home insulation; NBC has a trademark on the three note musical phrase often heard on that network; and the grocery retailer Food4Less has a trademark on pyramid-shaped roof ornaments.

Although trademark law doesn’t arise out of the same theoretical foundation as patents and copyrights, it is similar to them in that it grants a bundle of exclusive rights—specifically, property rights—in products of the mind.

A trademark is born

Like copyrights, trademark property rights arise naturally, with no need for formalities. When you create an expressive work, the copyright immediately applies; when you start to use a distinctive mark, trademark rights automatically apply.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Trade secrets are the oldest form of intellectual property. According to some experts, trade secret law dates back at least to the Roman Empire, where the Roman courts recognized lawsuits for an actio servi corrupti, literally, an action for corrupting a slave. The actio servi corrupti was used to protect slaveholding tradesmen or landholders from the harm caused by rivals “corrupting” a slave, usually through bribery or intimidation, and causing that slave to turn over confidential information. Anyone found guilty of corrupting a slave was liable to the slave owner for twice the amount of damages.

Partially because of its ancient heritage, trade secret law doesn’t include modern 17th-, 18th-, and 19th-century notions such as utility and the public domain. Therefore, trade secrets don’t work under the same framework as other types of intellectual property. Instead, trade secrets are just valuable information that you keep secret. We as a society have decided that, in some cases, we will honor and protect your right to keep your business to yourself. As a result, basic trade secret law is relatively uncomplicated.

Basic trade secret law is important because almost all of the information created or handled by employees is initially a trade secret. This includes source code, product plans, marketing documents, customer lists, procedure manuals, and internal telephone directories—if it is written down or only known by employees, then it is probably considered a trade secret by the company. (That also means that its use is probably restricted—see the discussion in about proprietary information agreements.) It doesn’t matter that those secrets may also be protected by copyrights or patents; trade secret law is the first line of defense.

There is no single definition for “trade secrets” within the U.S. because each state has its own trade secret law. However, trade secrets are typically understood to include any information (formulas, processes, designs, compilations, programs, instructions—in short, anything) that is

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There is no single definition for “trade secrets” within the U.S. because each state has its own trade secret law. However, trade secrets are typically understood to include any information (formulas, processes, designs, compilations, programs, instructions—in short, anything) that is secret, valuable, and derives part of its value from being secret. Trade secrets are fragile; they must be protected and will terminate if they are made available to the public.

Despite this fragility, trade secrets include some of the most valuable intellectual property in the world. For example, the formula for Coca-Cola is famously a trade secret. So are the eleven secret herbs and spices in KFC’s original recipe for fried chicken. Particularly of interest to software developers is the fact that most source code produced in the computer industry is also considered a trade secret. My favorite example of a trade secret, however, is the Flaming Moe.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The “Flaming Moe” comes from a 1991 episode of The Simpsons. When Moe’s Tavern runs out of beer one night, Homer tells Moe about a drink that he accidentally invented, called the “Flaming Homer.” The drink is made up of many different types of liquor mixed together with a secret ingredient—Krusty’s Non-Narkotik Kough Syrup—and set on fire before serving. The combination of the cough syrup and the fire makes the drink irresistible.

Moe steals Homer’s recipe and begins serving it as the Flaming Moe. The drink is so popular that various restaurant chains attempt to obtain the secret recipe by stealing or reverse engineering the drink. When that doesn’t work, the restaurants offer to purchase the secret recipe for one million dollars. Before Moe can sell the recipe, however, Homer tells everybody the secret of the drink. Within days, all the restaurants in Springfield are offering their own versions of the Flaming Moe, and Moe’s Tavern has sunk back into obscurity.

The story of the Flaming Moe has just about every essential element of trade secret law. We will walk through the story to illustrate the connection, pointing out differences or similarities with software development.

A trade secret is created when valuable business information is developed and then kept secret. Trade secrets do not require any registration or official recognition. As long as you realize a business advantage in the information and keep the information secret, you are covered by trade secret law.

It is debatable whether Homer ever had the Flaming Homer as a trade secret. On one hand, business plans and prospective business information are protected as trade secrets. If nothing else, Homer could have acted independently to sell the secret recipe, giving him an advantage. On the other hand, Homer wasn’t in the drink business like Moe. Possession of the recipe wasn’t valuable business information in Homer’s work at the nuclear plant. (Although you can come up with scenarios in which Homer could have used the drink to increase his prospects in the nuclear power business, those scenarios all require more intelligence and imagination than Homer has.)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Trade secrets were the first form of intellectual property protection applied to software. Trade secrets fit early computing technology. Both the computers (and the programs) were kept within centralized glass rooms in data processing centers, and only a small number of qualified people were allowed to interact with the computer in any substantial way. The source code was very specialized and generally non-portable. There was little source or object code shared anywhere, inside or outside the company, and the few distributions of code were handled under individually negotiated agreements.

This was a perfect situation for the trade secret protection of software to develop. Secret information—the actual code—brought value to the businesses that used it. Keeping this information protected was relatively easy; very few people had access to the code or the computers that ran it, and the functioning of the programs was not usually immediately apparent to outside observers.

This trend continued through the heyday of the mainframe and minicomputers. Even when those computers were networked, users did not have “computers” on their desks. Instead, they had some sort of terminal device that showed only the green screen interface and did not reveal the underlying workings of the program. The centralization of the mainframe/minicomputer systems facilitated maintenance of trade secret protection.

The biggest blow to trade secret protection was the industry shift from centralized to distributed computing, also known as the rise of the personal computer. For the first time, the market required companies to have their programs installed on uncontrolled computers. The increasing standardization of computer languages and hardware has increased the feasibility and viability of reverse engineering by decompilation, making trade secret protection in software more fragile.

Today, most software companies still attempt to maintain trade secret protection in their object code, mostly by including restrictions on reverse engineering and similar trade secret-defeating measures in contracts, EULAs (End User License Agreements), and

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Trade secrets are some of the basic building blocks of any intellectual property strategy for businesses. No matter how large, how small, or how open, each company has its own “secret sauce” that it uses to address new problems. Especially with the rise of software-as-a-service vendors, many companies are finding trade secret protection a valuable part of their intellectual property.

Most individuals, however, don’t realize that trade secret protection can be used on a smaller scale as well. A programmer’s code toolbox can be a trade secret, and so can personal development procedures and techniques. With the increasing use of developers as independent consultants, it is useful to keep trade secret law in mind as one tool that can enhance personal profitability.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

It may seem strange to have a chapter on contracts and licenses in an intellectual property book. Contracts and licenses are not themselves intellectual property and are generally considered to be a distinct discipline, not part of the same area of law as intellectual property.

Nevertheless, contracts are essential to our system of intellectual property. They are the means by which you share intellectual property. Everything that we have talked about up to this point has been about how to keep intellectual property inside your organization.

The problem is that simply keeping knowledge to yourself is neither very profitable nor very socially constructive. Our economy runs on trading things, and in the intellectual property market that means sharing. Contracts and licenses are the means by which people let their intellectual property out in a controlled way.

Security professionals usually recommend that firewalls be designed around the so-called German model: anything not expressly permitted is forbidden. An administrator usually starts by screening out all traffic in both directions. She then creates access rules that selectively allow in DNS traffic, web traffic, remote logins, and other allowed network uses. By using an appropriate set of rules, the administrator can have very fine-grained control over all traffic that goes across the network.

Intellectual property is similar. By default, users have (almost) no rights, so (almost) anything they do infringes on the rights granted to the intellectual property owner. Contracts and licenses provide access rules that allow other people to go through the legal firewall and use the intellectual property. By using the proper licenses, IP holders can have very fine-grained control over all uses of their work.

It has to be acknowledged up front that “control” over intellectual property is a slippery concept. For example, movie producers relying on intellectual property laws invariably wish they had more control over the movies being shared via peer-to-peer networks. Network administrators can just drop “bad” packets at the router; intellectual property administrators have to write letters or sue people for not following their access rules.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Security professionals usually recommend that firewalls be designed around the so-called German model: anything not expressly permitted is forbidden. An administrator usually starts by screening out all traffic in both directions. She then creates access rules that selectively allow in DNS traffic, web traffic, remote logins, and other allowed network uses. By using an appropriate set of rules, the administrator can have very fine-grained control over all traffic that goes across the network.

Intellectual property is similar. By default, users have (almost) no rights, so (almost) anything they do infringes on the rights granted to the intellectual property owner. Contracts and licenses provide access rules that allow other people to go through the legal firewall and use the intellectual property. By using the proper licenses, IP holders can have very fine-grained control over all uses of their work.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

It has to be acknowledged up front that “control” over intellectual property is a slippery concept. For example, movie producers relying on intellectual property laws invariably wish they had more control over the movies being shared via peer-to-peer networks. Network administrators can just drop “bad” packets at the router; intellectual property administrators have to write letters or sue people for not following their access rules.

While the proper extent of intellectual property control is hotly debated, however, the mechanism of control is widely accepted. The combination of the intellectual property firewall and contract access rules is enough to support the many thousands of businesses whose products are essentially intellectual property.

This is not surprising when you consider the essential role of contracts in our society generally. We live in a world of laws; everything from speeding tickets to subway signs are affected by or reflective of the laws governing our society. Despite our awareness of these laws, however, we don’t interact with them very much. We (hopefully!) don’t get speeding tickets very often. We aren’t personally sued for product liability. Most people only go into court as a party once or twice in their entire lives. A lot of these laws are in a sense invisible to people following them.

That is not the case with contracts. Normal people interact with contracts on a daily basis. There are contracts for cell phone service, contracts for parking your car, and contracts for starting a job. Each time you pay with a credit card, you are entering a contract.

Contracts are also everywhere in the business world. Contracts are used to buy office supplies, arrange loans, sell assets, and enter partnerships. In one way of thinking, the only way for a corporation to interact with the world is through the language of contracts.

That is because contracts are just agreements. People sometimes think of “contracts” as something official, whereas “agreements” are something less. This is not the case. Any binding arrangement is a contract under law and will be subject to the legal system.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Because the obligations of a contract only apply to the contracting parties, the people who sign or assent to the contract, the courts are very permissive regarding the allowable scope of contracts. Nevertheless, there are a few basic requirements for a contract to be considered valid.

Contract law in its broadest sense is set up to ask (and answer) four basic questions about the entities associated with the contract (called parties to the contract):

Did the parties make an agreement?
How should the contract be interpreted? What did each party promise?
Did one or both parties fail to keep a promise (called a breach)?
If so, what compensation (remedies) should be given the non-breaching party?

In general, the role of contract law is not to punish wrongdoing. There aren’t really “wrongs” in contract law, and contracts can be invalidated if the specific terms appear punitive. Rather than wrongdoing, there is only breach—failing to keep your promise. Enforcing a contract means that you are entitled to the benefit of your bargain, via specific performance (court-ordered follow-through on the contract), via damages (money), or both.

Some types of contracts, called contracts against public policy, cannot be enforced by the courts. These are contracts containing promises that, if fulfilled, would harm society in general. For example, contracts containing promises to do something illegal are against public policy, as are contracts designed to restrain competition in an industry, and marriage brokerage contracts.

It is noteworthy that contracts to pay gambling debts are against public policy in most places in the United States, and cannot be enforced in court. Therefore, people who loan money for use in gambling sometimes resort to other means to encourage payment.

The right to enter into a contract is one of the most basic economic rights; it is one of the essential aspects of becoming an adult in our society. As such, it is much easier to describe who

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The essence of intellectual property law, like all property laws, is exclusion. Property can be arbitrarily used or sold because property holders can prevent others from using or intruding upon their property. Intellectual property holders generally use contracts to extract economic rent (profit) from the use of the property.

IP holders can make money from their intellectual property in two ways: they can sell all the rights to the property (an assignment) or grant limited rights to the property (a license).

Of these, intellectual property assignment is the most straightforward. As with physical property, an assignment hands complete ownership and control to the buyer (here called an assignee). Although there is specific legal language required to effectively assign a particular piece of intellectual property, assignment can be understood by analogy to the sale of a physical object like a car. While you own the car, you can do anything you want with it; but when you sell the car, you hand over both the car and all ability to use (i.e., drive, kick, wash, show off) the car.

Intellectual property assignment works the same way. Intellectual property has two aspects: the physical embodiment of the property and the associated rights. When you sell the IP, you hand over the physical embodiments of the property (such as the patent documents, copyright registration forms, software source code, etc.), as well as all rights to assign or license the intellectual property in the future.

Intellectual property licenses are trickier. Implicit in the ability to exclude totally is the ability to only exclude partially. An IP holder can use contract law to grant partial rights to many people at the same time.

To understand intellectual property licensing, think of a hotel. There is only a single building, but the owners have carved it up into many different pieces—the different rooms—that can be “sold” individually. Different rooms are reserved to different people each night, and each person may have paid a different price to rent the room. Different people may stay for different lengths of time. Regardless of how many people are staying in the hotel, however, the owners still maintain control over and ultimate ownership of the property.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

When you create or invent something, you create new intellectual property. You can share that property by applying a license.

Because licenses are contracts, the number and variety of licenses is potentially infinite. However, intellectual property licensing law, like regular contract law, favors written contracts. And like regular contract law, certain types of contracts for intellectual property—notably assignments—must be explicit and in writing or they will not be enforceable.

If you are applying a license to some sort of software for commercial reasons, you should see an expert that can help you draft the exact license language you need to meet your business goals. Just as computer languages have a number of reserved words, so contract law has a number of reserved terms of art—particular phrases or sentences that have long-established legal meanings. Using the right keywords in a contract is just as important as using the right keywords in a computer program.

One important option to consider is a license that open sources your software. Open source licenses are easier in the sense that they are not negotiated or drafted anew each time they are used, but are generally chosen from a list of standard open source licenses.

Applying an open source license to your code is relatively simple. The common method is to choose a license from the list at http://opensource.org/ and include a copy of the license text in a file called LICENSE.txt in your repository. The license is applied to each file in the repository by including a short copyright notice in each file. For example, to apply the Apache Version 2.0 License to your code, you would include:

Copyright [year] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at:
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

“Open source” is one of the most misunderstood concepts in the computing industry today. Most people in the industry, and even a number of people outside the industry, have heard of open source software. They may be able to name some of the most prominent open source projects, like Linux, Apache, and Firefox.

But what most people don’t understand about open source software is why it works. Software released as open source costs money and time to make—it has value. To some people, especially those who are more business-minded, this sounds like a throwback to late-90s dot-com-era business plans: give your product away for free and make it up on volume. They see very few business models in that sort of thinking.

To others, open source sounds anti-commercial. This point of view was best illustrated by Steve Ballmer, CEO of Microsoft. “Linux is a cancer that attaches itself in an intellectual property sense to everything it touches,” stated Ballmer in 2001. “The way the license is written, if you use any open source software, you have to make the rest of your software open source...open source is not available to commercial companies.”

It is worth noting that Microsoft’s own actions have since proved Ballmer wrong. Since Ballmer gave that quote, Microsoft has successfully released a number of open source products and certified two licenses as open source, all without making the rest of its software open source.

Nevertheless, the point remains that most people don’t understand the basis of open source, even if they work with open source products. So that is where we begin: by addressing the general why and what of open source, before looking at the specifics of how open source licenses work.

This chapter has one fairly narrow goal: to provide an economic and legal structure to help explain why open source works. Open source, like intellectual property in general, is really a legal and economic system rather than a simple collection of rules and licenses. In my opinion, understanding the big picture is just as important as understanding the language of a particular license. I hope that readers with many different backgrounds will be able to get a better grasp on the phenomenon of open source.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

First, a note about labels and semantics. One of the consistent debates in the free software community has been about labels. “Free software,” “open source software,” “free as in speech, not as in beer,” and “libre software” have all been used to try to describe and put a label on the legal construct that I will discuss here as open source. By using the “open source” label, I am not trying to take a side in these debates.

For those involved in free software, I am aware of the important philosophical differences implied in the use of the term “free software” as opposed to “open source.” Where applicable, I will use the correct term to describe how they are both socially and legally different. Nevertheless, because open source software is a strict superset of free software, I will generally use the more inclusive term when discussing legal elements common to both.

I also make a distinction between open source licenses as recognized by the Open Source Initiative (OSI) and other source-available open source licenses like the Microsoft Shared Source licenses. I will generally use the term “source-available” when discussing these licenses to distinguishing them from OSI- or FSF-approved licenses.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Most people can’t give a definition of open source, even those who work with open source projects on a day-to-day basis. Most people will say that it is about giving things away for free. Programmers will usually be more specific and talk about giving source code away for free. The savviest commenters will talk about freedom and the rights to modify the source code to a product.

It is true that open source software is frequently free (as in price), that source code is usually what is being provided for free, and that there are additional rights (or freedoms) given to those who receive the open source product. However, all of these are peripheral to the true nature of open source.

At its core, open source is a legal construct for cooperation and trade in intellectual property. People occasionally say that open source and intellectual property are opposites. This is not true. Open source software could not exist as we know it without intellectual property. So before I begin, I want to start outside the realm of software, and even outside the realm of intellectual property, to create a framework for understanding open source and how it applies in the market today.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

To those not in the financial industry, banks and credit unions look about the same. They both accept deposits, give mortgages, and provide checking accounts. For a basic consumer of financial services, there isn’t much difference in the day-to-day experience. However, the day-to-day experience is misleading; there are, in fact, substantial and important differences between these two outwardly similar institutions. These internal differences create very different incentives and lead to different results.

When looking at the software world, a similar division applies. Both traditional software and open source projects produce software, but like banks and credit unions, there are substantial differences between the two. While the analogy isn’t exact, there are important similarities between what I will call corporate model organizations (like banks and traditional software companies) on one hand, and cooperative model organizations (like credit unions and open source projects) on the other.

Where necessary to help illustrate the difference, I will highlight examples from two roughly comparable software projects: the Apache HTTP Server and Microsoft Internet Information Services (IIS). These two software products address the same market, have roughly comparable functionality, and are, respectively, number one and number two in market share across the world. However, IIS is built in a corporate organization, and Apache is built in a cooperative organization.

The first and most fundamental feature distinguishing corporate and cooperative organizations is ownership. Corporate organizations are owned by their shareholders, and cooperatives are owned by their members. This difference in ownership is fundamental because it changes the relationship between the directors of the organization and its customers. Each institution is set up primarily to serve the interests of its owners.

In a bank, the directors and executives have one mandate: to return profits to the owners (the shareholders) by making the bank profitable and successful overall. It works out that in the capitalist system, the standard way to make a profit for shareholders is to provide services desired by customers. If the interests of customers and shareholders ever diverge, however, it is the responsibility of the directors of the bank to make the choice that favors the shareholder/owners.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Open source software projects are driven by the commonly-owned, cooperative nature of development. The difficulty, however, is that the cooperative systems are unstable because there is a tendency for individuals to free ride on the work of others.

As discussed in , the free rider problem usually arises around public goods, which are costly and non-excludable. The situation with cooperative development is technically different; instead of being intrinsically non-excludable, open source developers make their code non-excludable by choice. Nevertheless, the result is the same. Once somebody has paid the cost of development, the incentive for all others is to use the free code without giving anything back. The role of open source licenses is to align the interests of the cooperating developers by providing the legal foundation for cooperation and trade in intellectual property.

To better understand the role of the law and open source licenses, it is useful to look for a moment at the field of game theory—the study of interactions leading to different cost and reward outcomes.

Zero-sum games

One of the fundamentals in game theory is the concept of the zero-sum game. A zero-sum game (ZSG) is any set of interactions conducted around a finite resource. Even an infinite resource has only 100% of market share, to be divided among competitors. A competition for market share is also a ZSG.

There are many different examples of ZSGs (markets, for example). If you track any fixed commodity (or fixed basket of commodities) over a period of time, some people will buy and some people will sell, but the collective gain by the winners in the transactions will be exactly equal to the collective loss by the losers.

Another ZSG is the share of advertising dollars spent on different advertising outlets. Over the past several years, the percentage of money spent on online advertising has gone up, by definition driving down the percentage of money spent on radio, television, newspaper, and other advertising. The competition for the pool of total advertising dollars is a ZSG.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Keeping in mind the cooperation-inducing function of open source licenses, it is interesting to look at the annotated open source definition on opensource.org (http://www.opensource.org/docs/definition.php):

Open source doesn’t just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
Rationale: By constraining the license to require free redistribution, we eliminate the temptation to throw away many long-term gains in order to make a few short-term sales dollars. If we didn’t do this, there would be lots of pressure for cooperators to defect.

The open source definition is explicit about the purpose for requiring licenses to allow free redistribution: to encourage cooperation and discourage defection. This is the underlying motivation and economic rationale for open source licenses.

At first glance, this first principle of the open source definition is not too different from the FSF’s freedom 2, “The freedom to redistribute copies so you can help your neighbor.” Nevertheless, they are not equivalent.

The distinction between this part of the open source definition and the FSF’s freedom 2 is that the open source definition is normative whereas freedom 2 is rights-oriented. Saying, “everyone should have the following rights,” is not sufficient to create the necessary framework for cooperation. What is needed is the enforceable expectation of cooperative behavior, as provided by the second principle of the open source definition:

2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As described above, open source licenses have more commonalities than differences. Before leaving the abstract discussion of open source, however, there is one high-level difference in open source licenses that should be mentioned, and that is the difference between academic and reciprocal licenses.

Academic licenses receive their name from their historical context: most of them were originally developed and applied to code written in universities. These licenses allow unfettered use of the open source code, including the crucial aspect of embedding the open source code into proprietary applications.

Reciprocal licenses receive their name from the fact that they require each licensee of the code to reciprocally apply the same open source license to any code derived from the originally licensed code. Reciprocal licenses are sometimes called GPL-style licenses, after the most important reciprocal license, the GNU General Public License.

There are fervent advocates of both styles of licenses. Academic (BSD-style) license advocates argue that their licenses grant more “freedom” to the users of the code. GPL-style license advocates argue that the reciprocal nature of the license makes sure that the code stays free.

At the core, both sides are right. The essential difference between these two styles of licenses is the extent to which programmers are allowed to defect and act in an uncooperative manner. Academic licenses allow defection, while reciprocal licenses do not. Academic licenses thus allow programmers a wider array of licensing options while reciprocal licenses constrain the software to cooperative development only.

The primary concern with academic licenses is that they do not use the power of copyright to modify the Programmer’s Dilemma payoff matrix in the same way that reciprocal licenses do. As a result, there is the temptation for individuals or businesses participating in development to defect.

There have been a number high-profile defections using academic-licensed code. For example, one of the most staunchly proprietary companies, Microsoft, ships code with its operating system that was originally licensed as open source under an academic license. Many other companies embed highly successful open source libraries for compression, database access, or XML handling into their proprietary products.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Waking up one day, you have a flash of insight. You know your idea will take off—you have come up with the next Facebook or YouTube.

In the meantime, you help out with an open source project that allows people to automate their home stereos. You were recently made a core developer on the project, and it is just starting to get to the point where you know it will be successful.

Wait...you have a job?

You may already be in trouble.

I know it sounds a little far-fetched that simply thinking of an idea or participating in an open source project while employed can get you into trouble. It almost sounds like the setup for a bad legal thriller. If merely thinking of an idea or sending in a patch could get you into trouble, people would be engaged in lawsuits all the time.

The more nuanced answer, which we will discuss further, is that it really depends on the specifics of what you do and the agreements you have already made with your employer. However, that doesn’t mean that lawsuits over basic ideas don’t happen.

In 1994, Evan Brown approached his employer, DSC Communications, with a big idea: he had figured out an efficient way to decompile legacy binary code into high-level source code. DSC was initially interested, but negotiations between Brown and DSC soon broke down. Afraid that Brown would sell the idea to a competitor, DSC sued.

At the center of the case was DSC’s proprietary information agreement (PIA). The PIA required employees to tell DSC about any new inventions developed or conceived while employed by DSC. It allowed employees to exclude any preexisting ideas or inventions, but any non-excluded inventions, including future inventions, were assigned to DSC as a condition of employment.

Brown insists that he came up with the initial concept in 1976, although he didn’t declare the decompilation process on the PIA he signed when he joined DSC in 1987. From Brown’s perspective, he hadn’t completely figured out the decompilation process, so there was no “idea” to disclose. Further, the decompilation process was not related to Brown’s job in DSC and Brown worked on the idea only at home.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

I know it sounds a little far-fetched that simply thinking of an idea or participating in an open source project while employed can get you into trouble. It almost sounds like the setup for a bad legal thriller. If merely thinking of an idea or sending in a patch could get you into trouble, people would be engaged in lawsuits all the time.

The more nuanced answer, which we will discuss further, is that it really depends on the specifics of what you do and the agreements you have already made with your employer. However, that doesn’t mean that lawsuits over basic ideas don’t happen.

In 1994, Evan Brown approached his employer, DSC Communications, with a big idea: he had figured out an efficient way to decompile legacy binary code into high-level source code. DSC was initially interested, but negotiations between Brown and DSC soon broke down. Afraid that Brown would sell the idea to a competitor, DSC sued.

At the center of the case was DSC’s proprietary information agreement (PIA). The PIA required employees to tell DSC about any new inventions developed or conceived while employed by DSC. It allowed employees to exclude any preexisting ideas or inventions, but any non-excluded inventions, including future inventions, were assigned to DSC as a condition of employment.

Brown insists that he came up with the initial concept in 1976, although he didn’t declare the decompilation process on the PIA he signed when he joined DSC in 1987. From Brown’s perspective, he hadn’t completely figured out the decompilation process, so there was no “idea” to disclose. Further, the decompilation process was not related to Brown’s job in DSC and Brown worked on the idea only at home.

From DSC’s perspective, the PIA signed by Brown assigned all of the intellectual property developed by Brown during his employment to DSC. Their ownership could be justified by claiming that Brown’s development of the process was suggested by the work and training he received on the job.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

These cases are arguably overreaching, but the basic principle remains: if you are an employee, your employer may own the intellectual property created by your efforts. Thus, there may be legal difficulties with creating new code, either to use for your own business interests or to advance an open source project.

There are no bright-line rules here; instead, there are a number of interrelated legal issues. We will look at some of the legal doctrines that apply and then at a number of principles that can help keep you out of trouble.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The first and most important principle is that if you have any expectation of participating in an independent project, look at what you signed. It is even better to do this before you do anything on your own, perhaps even before you sign the agreement! Employment is a contractual relationship between the employee and the employer. Accordingly, most aspects of what you can and can’t do as an employee will be governed by the terms of your employment contract. Only in a few circumstances will other, overriding rights take precedence over the private agreement between you and the company.

If you have come up with an idea, the single most important document that you probably signed is a proprietary information agreement. In both the Brown and Barstow cases above, the PIA was the cornerstone of the company’s case against the inventor. The employees had signed the agreement that granted their employers rights over their inventions.

Not all companies have PIAs, but most technically oriented companies will make you sign a PIA as a condition of employment. Companies usually include PIAs in the packet of papers to be signed by each new employee.

The law governing employment agreements varies from state to state, so there are no specific rules that will prove true in all circumstances. Also, even some of the general principles discussed here will have slightly different interpretations depending on where you are and where your employer is located.

contains the full text of an example PIA. I will use text from this example agreement to illustrate some of the issues with PIAs generally, but be aware that individual aspects of this agreement may not apply in your state.

If you have a question about a particular employment contract or a particular PIA, it is worth the expense to have your own lawyer look at the individual circumstances and individual agreements that apply to you. This should be done before you sign a PIA or begin employment if you want the best chance of successfully modifying the terms.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The second important principle is that employers may have rights to employee works even if there isn’t a contract. Even when there isn’t an explicit PIA governing what will and will not belong to the company, the company may still have some implicit rights to the intellectual property created by its employees.

The first category of employer rights has to do with works for hire. A work for hire can be created when an employee creates the work in the scope of his or her employment. This is because the copyright act defines works for hire relative to the employer-employee relationship. Title 17, Section 101 of the United States Copyright Code defines works made for hire as “a work prepared by an employee within the scope of his or her employment.”

To determine if this provision applies, the terms “employee” and “the scope of employment” must be analyzed.

Becoming an employee

An employer-employee relationship doesn’t simply mean that you work for somebody (as with the common definition). Instead, employee status is determined under an area of law called the common law of agency. The common law of agency is used to describe a situation when one person is acting on behalf of another, or in other words, when a person is acting as an agent. Under the common law of agency, determination of employee status is generally made according to three factors:

The employer has control over the work. If the company can control how the work is done, has all the work done at the company office, or provides the equipment and tools needed to create the work, the company may have control over the work.
The employer has control over the employee. If the company sets the employee’s schedule, controls the assignments given to the employee, and determines who will report to the employee, and to whom the employee will report, the company may have control over the employee.
The employer’s dealings with the employee are consistent with employment

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The third principle to keep in mind is to always communicate with your employer—in writing. Both the “communicate” and the “in writing” parts are important.

For developers, the easy and wrong approach is to ignore this principle. While at first it may seem easier to ask forgiveness than permission, such a strategy is risky. Assume for a moment that you have a great idea, but you decide not to tell your employer. What happens?

If your idea turns out not to be successful, maybe nothing will happen. Your efforts will attract no attention, no funding, and no lawsuits. This is the best-case scenario.

If your idea is a success it will likely attract attention. In many cases, your employer will then start wondering about the success of your project and why you are not making their products successful instead. Perhaps you will be fired. If your project is a substantial financial success, your employer may in fact be obligated to sue you. From the employer’s perspective, you may have profited from intellectual property that was, in fact, owned by the company. Your employer’s duties to the company and to the shareholders may require him to recover the profits and code that (in his opinion) should have belonged to the company. This lawsuit won’t necessarily be successful, but it won’t be fun to go through, even if you win.

Communication with the company is important enough that most PIAs include a paragraph requiring that employees must keep their companies informed of any new ideas, inventions, or advances. The following paragraph is typical:

During the period of my employment, I will promptly disclose to the Company fully and in writing and will hold in trust for the sole right and benefit of the Company any and all Inventions. In addition, I will disclose all patent applications filed by me during the three (3) years after termination of my employment with the Company.

The company includes this provision so that it will have the chance to enforce the other contract rights included in the PIA, in particular, the obligation to assign any new intellectual property to the employer.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The chapter so far can be summarized pretty easily: if you have a job, your company may own your code and you may get into trouble if you try to start a business or contribute to an open source project. In particular, watch what you sign, because your employment agreements will control what you can and can’t do.

So, what can you do? Nothing is a silver bullet, but there are a number of principles that will help keep you out of trouble.

There are a number of documents that you sign, and they affect what you can do with the things you create. If you have questions about your particular PIA or employment agreements, refuse the temptation to guess about what they mean; see a lawyer. The laws vary so much from state to state that seemingly clear paragraphs may not mean what you think they mean.

The most important thing you can do is to be open with your employer about what you want to do. When cases come to court, the most troublesome evidence comes when the inventors tried to keep secrets from their companies. The secrecy itself opens the door to the lawsuit and provides evidence of wrongdoing.

The reason why some developers try to keep secrets is because they are afraid that they won’t be able to pursue their ideas. That is why inventors and developers should talk to their employers before they start to do anything. Preemptive permission is the most effective.

The key is to approach your employer before you have created any intellectual property at all. For example, imagine that your company makes voice recognition software. If you approach your company and get permission to start playing with web applications on the side, they will likely say yes, because that is not directly related to any company products, and it will increase your skills as a developer. If you later approach them saying that you would like to create an application for serving homemade videos over the web, they will again likely say yes. After all, they have already given permission to create web applications in general. If your site then turns out to be the next YouTube, you will have a much better chance at keeping control over your IP because you were open about it.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The following is a typical exchange from an Internet discussion about software licensing issues:

Person #1: I posted my code under the [license] license.
Person #2: You should have used the [LICENSE] license. It is the only license that is free.
Person #1: I chose the [license] because only [license] really is free!
Person #2: You chose wrong.
Person #1: You only think I chose wrong! You fool! You fell victim to one of the classic blunders! The most famous of which is never choose emacs over vi, but only slightly less well-known is this: never ever license your code under [LICENSE]! Ha ha ha ha ha ha ha! Ha ha ha ha ha ha ha! Ha ha ha....

There have been many hours and pages dedicated to analyzing the difference between different software licenses. Software licensing can be a headache—one of the unfortunate costs that the intellectual property system imposes on society. Nevertheless, we spend the time because it is vital to get these issues handled correctly.

Intellectual property (and copyright in particular, which covers source code) is oriented toward preventing use of copyrighted material. Speaking generally, if you don’t license your code, it can’t be used (legally) by other people.

More specifically, software licensing is about setting boundaries on what other people can do with your code. The complexity of licensing comes from defining and explaining those boundaries in legal, enforceable terms.

The most important thing to keep in mind is that software licenses are social contracts just as much as they are legal documents. When you choose a license, what you are really doing is charting a course for the future, and often you are establishing a relationship to a larger community. A few questions to consider might be:

Are you interested in commercial, proprietary companies being part of your community?
Are you morally opposed to proprietary software?
Why are you distributing the code?
Are you joining an existing community?
Are you trying to start a business, and if so, what is your business model?

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Intellectual property (and copyright in particular, which covers source code) is oriented toward preventing use of copyrighted material. Speaking generally, if you don’t license your code, it can’t be used (legally) by other people.

More specifically, software licensing is about setting boundaries on what other people can do with your code. The complexity of licensing comes from defining and explaining those boundaries in legal, enforceable terms.

The most important thing to keep in mind is that software licenses are social contracts just as much as they are legal documents. When you choose a license, what you are really doing is charting a course for the future, and often you are establishing a relationship to a larger community. A few questions to consider might be:

Are you interested in commercial, proprietary companies being part of your community?
Are you morally opposed to proprietary software?
Why are you distributing the code?
Are you joining an existing community?
Are you trying to start a business, and if so, what is your business model?
What are your expectations for the code and the people using the code?

These questions, while not usually talked about, are at the core of software licensing. If licensing were purely about mechanical and legal choices, licensing discussions would not be so interesting and would not invite such strong feelings. Especially because licenses (and business models and community expectations) can be difficult to change later, it is worthwhile spending the time to understand these questions up front.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Under our current copyright law, copyrighted intellectual property comes into existence as soon as someone creates a tangible work. In the absence of any licensing declarations, the default provisions of copyright law are applied, which do not allow any uses other than fair use. Therefore, some sort of declaration is necessary to allow greater sharing (or greater control).

One option, however, is to declare that no license is required to use the work. This is sometimes referred to as putting works in the public domain, but it can also technically be considered a license of its own under property law principles. As described in , one meaning of the word “license” is a unilateral permission to use someone else’s property. An author may give others license (permission) to use copyrighted materials however they might like.

Some people are surprised that this would be considered, but for others this may be the most attractive “licensing” option of all. Writers write, musicians play, and developers code, even in the absence of financial rewards. The essence of this philosophy was captured by Woody Guthrie in the late 1930s when he was distributed a songbook to listeners of his L.A. radio show Woody and Lefty Lou who wanted the words to his recordings:

This song is Copyrighted in U.S., under Seal of Copyright #154085, for a period of 28 years, and anybody caught singin’ it without our permission, will be mighty good friends of ourn, cause we don’t give a dern. Publish it. Write it. Sing it. Swing to it. Yodel it. We wrote it, that’s all we wanted to do.

For some artists, the psychic rewards of seeing others enjoy their work may be more valuable than the financial rewards associated with copyright.

Even for those with more commercial purposes in mind, releasing control over code is a good way to encourage other people to use the code. For example, the embeddable database SQLite has seen wide usage in a number of systems, from Apple’s CoreData system to Mozilla’s new bookmarks database, in part because of its public domain license declaration. Further, SQLite’s author has achieved

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

A second licensing option is to exercise tight control over all downstream use of your work. The best example of tight control is traditional proprietary software licensing. The number of different possible tight-control licenses is almost infinite, because the rights granted under copyright can be partitioned arbitrarily.

In the simplest case, the person receiving the software is usually granted only the rights to install a single copy and run the software on a single computer. In these licenses, there are so few rights granted to downstream users that it is relatively easy for the license to specify the few allowed uses. Most shrink-wrapped software, like games, is licensed along this model.

More complex are time-based, seat-based, or other “flexible” proprietary licensing schemes. These licenses try to partition the market, charging different users different licensing fees according to their specific needs and ability to pay. The licensing programs for Microsoft Server and Oracle are examples of this model.

There are also some proprietary licenses that allow redistribution of some closed source components. For example, many applications are written in Visual Basic, a proprietary language owned and controlled by Microsoft. These applications require the Visual Basic interpreter to run, so Microsoft has licensed portions of the Visual Basic runtime so that application developers can include it free of charge with their applications, but there are restrictions on what is available as a “redistributable” and which other applications can be linked with the final application.

Any particular application can be licensed in a number of ways, and licensed to many different users under different license agreements. If this is how you would like to license your work, it is worth consulting with a lawyer to create a license that will match your business needs.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The third important option is licensing code under an open source license. This forms a middle ground between public domain and proprietary licensing, and can most accurately be thought of as a spectrum of licensing options. The various open source licenses should be considered in terms of the control that you would like to exercise later over your software.

The simplest licenses make very few demands on downstream users, reserving only the rights of attribution (essentially, keeping names and copyright notices intact). These licenses are typically short because it is relatively easy to specify the few restrictions imposed on use. These are sometimes called academic licenses because they were originally written for and popularized by universities. The MIT and BSD 2-clause licenses are examples of this type.

Moving slightly up the scale in control and complexity are licenses that grant substantial rights to downstream users, but include patent, trademark, or public recognition provisions. Works created under these licenses are available for almost all downstream uses, including use in proprietary closed source products.

Although most downstream uses of the code are allowed, there are some restrictions on ancillary or peripheral rights granted to users downstream. Most of these restrictions center on things that downstream users might do to legally challenge the authors of a program.

License clauses discussing patent and trademark provisions are common (and important) in this context. Quoting from the Apache License version 2.0:

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Do not write your own license. You would think this principle would be obvious, but it apparently isn't. Many hundreds of people have attempted to write their own open source licenses over the years, and many thousands more have tried to write their own proprietary licenses. includes a table of the open source licenses applied to packages in a typical Linux distribution—there are over two hundred.

Some people think they can do it better, clearer, shorter, or with a different arrangement of rights; they can’t. Others think it might be thrilling to have their names associated with a new license; it isn’t. It is essentially never a good idea to write your own license. Don’t do it. These sections explain why.

The first reason why you should not write your own license goes back to the idea of picking a community by picking a license. Widely used licenses allow projects to tap into broader development communities. They bring in developers and arouse interest just as a function of the license. Of course, applying a widely accepted license to your code is not enough to guarantee success. Many other things are also important, such as code quality and the usefulness of a project. Nevertheless, license issues can present a substantial initial barrier to participation. Many developers will not even look at a project unless the license is widely known and widely accepted.

On the other hand, creating and using your own license also puts you in a different community—a community of one. Just as using a widely accepted license creates the opportunity for code sharing and development from a broader group of developers, using your own license confines the possible collaborators for your project to the people willing to work with your license.

A number of years ago, “open source” and “free software” were concepts only. People were free to come up with their own licenses focusing on the principles of source availability and modification rights. These licenses were “free software” (and later “open source”) because of their ideological perspective only.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Choosing a license can be both easy and difficult. A number of factors enter into the choice, the most important of which are the hard decisions about the business and community expectations you have for your software. After that initial decision, however, the remaining decisions can be broken down into a relatively easy series of steps.

The first decision is whether your code is intended for use with an existing open source project. If your work will be shared with an existing community, particularly a large existing community, you should consider using the predominant license.

For example, contributors to the Linux kernel should use the GPL version 2 (GPL2). Contributors to the Eclipse IDE should use the Eclipse Public License. Contributors to OpenSolaris should use the Sun Common Development and Distribution License (CDDL), and so on.

The exception to this rule is when the community is using a license that is either proven legally deficient (such as the Artistic License) or is obscure enough that it is not recognized as either free software by the FSF or open source by the OSI. In that case, you can participate in the community by licensing your code under an academic or permissive license: the BSD License, the Academic Free License (AFL) or the Apache License (AL). Other developers will still be able to use your code, and you will be able to use theirs.

When licensing your own work, there are hundreds of licenses available to choose from: includes a list of approved open source licenses, includes a list of approved free software licenses, and includes a list of licenses used in the Fedora Linux distribution.

In fact, there are far too many licenses. A number of other books discuss and analyze open source licensing, including Andrew St. Laurent’s Understanding Open Source and Free Software Licensing (O’Reilly) and Lawrence Rosen’s Open Source Licensing: Software Freedom and Intellectual Property Law (Prentice Hall). Both of those works go into more detail about the specifics of each license.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Imagine that you are a developer with a new open source project. You got permission from your employer (), you chose a license (), and you released version 0.01 on the Web. The next day, you received a bug report and a patch.

Great, but who owns the bug report? Who owns the patch? Can you use them?

Most people would answer that of course they can use the patch—after all, that is why the contributor sent it in. Unfortunately, that is not the whole story. Open source is a great mechanism for sharing code and sharing ideas, but it relies upon copyright to function smoothly. Therefore, proper copyright licensing has to be respected.

Copyright is sometimes called the “metaphysics of the law” because it can get so theoretical about the interplay of ideas, expressions, and works. It should not be surprising, then, that the first item to be determined is whether a patch is a “work” that is eligible for copyright protection.

Unfortunately, courts have not established a clear, easily applicable standard regarding whether or not something is a copyrightable work, especially in the software realm. Nevertheless, there are a number of good rules of thumb that can help you make this determination.

Patch length

The first thing to look at is the length of the patch. While there is no set length for determining whether something is a copyrightable work or not, many courts have found that very short contributions are not considered works for purposes of the copyright law. This could be because very short contributions can fall under the words and phrases doctrine. If a particular expression is so short that there are only a few ways to express it, then the expression is not copyrightable and is not a “work” that has to be analyzed under the copyright law.

Of course, “very short” isn’t a very exact definition, but the courts have not given a specific number of characters or lines that qualify as “very short.” The GNU projects consider anything under 15–20 lines to be very short and do not require any additional paperwork; other projects go up to 25 or 50 lines.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Copyright is sometimes called the “metaphysics of the law” because it can get so theoretical about the interplay of ideas, expressions, and works. It should not be surprising, then, that the first item to be determined is whether a patch is a “work” that is eligible for copyright protection.

Unfortunately, courts have not established a clear, easily applicable standard regarding whether or not something is a copyrightable work, especially in the software realm. Nevertheless, there are a number of good rules of thumb that can help you make this determination.

Patch length

The first thing to look at is the length of the patch. While there is no set length for determining whether something is a copyrightable work or not, many courts have found that very short contributions are not considered works for purposes of the copyright law. This could be because very short contributions can fall under the words and phrases doctrine. If a particular expression is so short that there are only a few ways to express it, then the expression is not copyrightable and is not a “work” that has to be analyzed under the copyright law.

Of course, “very short” isn’t a very exact definition, but the courts have not given a specific number of characters or lines that qualify as “very short.” The GNU projects consider anything under 15–20 lines to be very short and do not require any additional paperwork; other projects go up to 25 or 50 lines.

Patch context

Another aspect to look at is the context of the patch. A patch that implements a particularly tricky function or has an elegant expression of an algorithm is more likely to be considered a “work” than a patch that deals with more mundane aspects of the code.

In a similar vein, it can be helpful to look at anything that might be considered expressive. Comments and non-requisite functions are much more likely to contain copyrightable expression. On the other hand, even large patches that are just mechanical (like patches that fix code indentation or globally rename a particular function) are unlikely to contain any copyrightable expression at all.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

It is probably becoming obvious that creating open source projects with unregulated contributions can quickly become unworkable. In fact, one of the fastest ways to doom a promising project is to create an active project with no copyright licensing and assignment policies. Just at the time such a project acquires enough momentum and enough contributors to succeed, there may be too much copyright inertia (or uncertainty) to allow many other potential developers—including businesses—to participate.

Developers contributing code to open source projects, therefore, should make sure that there are explicit policies governing the receipt and licensing of outside patches and contributions. Without such an agreement, it is possible, or even likely, that any contributed code will end up in an unproductive legal limbo.

From a project maintainer’s perspective, though, the set of choices is a little more complex. There are three different ways of dealing with the licensing of open source projects, and it may make sense to transition from one choice to another over the lifetime of the project.

The first method of dealing with open source copyright issues is to require that all new contributions be licensed under a preferred existing open source license. Requiring an open source license for all contributions helps confirm that all users—the project maintainer as well as all downstream users—have sufficient rights to run and distribute the code.

One particularly easy way to handle this issue is to cover the entire project under a license that has a contributions clause, such as the one included in the Apache License, version 2.0:

Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

License agreements come with a number of administrative issues that can make the difference between a project that is viable for the long term and one that is not. These administrative tasks are a cost imposed by the system. Choosing good practices for handling these issues, though, can substantially reduce such costs (and any associated risks).

One of the easiest and most important things that code maintainers can do is to make sure that there is a record of all contributors. This information can be integrated with the project’s source code control system. Just about every source code repository allows administrators to keep track of who made which check-ins. Some repository systems also allow comments to be included at check-in time. If a developer has been granted repository commit privileges, then her username will be associated with her contributions. If someone is doing a commit on behalf of another user, the comment field can be used to record the original author of the contribution. Without these records, reconstructing the correct commit history of a project can be very difficult.

One best practice that all open source projects should adopt is to require a signed contributor agreement or copyright assignment before giving commit privileges to a new developer. The completed license agreements or copyright assignments should be recorded in the source code repository. By keeping the agreements close to the code, you make it easier to correlate particular contributions with particular agreements.

When people are just trying to get in their first patch, it is too easy to let licensing documentation slide. Nevertheless, if you make contributor agreements part of the initial setup procedure—just like exchanging SSH keys and setting up user accounts—you are less likely to overlook them.

Federal law requires that a number of important documents—including any intellectual property assignments—be completed in writing and signed. When a developer needs to sign a CLA or an assignment agreement, it is necessary to have someone ready to receive the agreement via mail, fax, or email.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

A lot of the most difficult questions in free and open source software revolve around the GPL. The GPL has a lot of things going for it: it is the single most common open source software license, it has brought together a large and vibrant community of developers, and it is a brilliant hack, socially and legally.

At the same time, there is no single license that is more mistrusted or reviled than the GPL. Many open source developers refuse to accept or release code under the GPL because it imposes restrictions at the same time that it grants freedoms. I know from personal experience that the GPL gives most lawyers fits.

In short, very few people have a balanced or nuanced view of the GPL—they either love it or hate it. Speaking in broad generalizations, though, I think that these strong emotional reactions arise from two core issues.

The first issue is the philosophy of free software. More than any other single document, the GPL has come to embody the free software movement, so people’s reactions to the GPL mirror their opinions of free software as a moral imperative. Supporters see the Free Software Foundation (FSF) and the GPL as an ethical vanguard, paving the way for a better society. Detractors feel imposed upon because they see the FSF mixing its morality with its code. Many companies don’t like the GPL because they have a hard time seeing the business models that accompany free software. They only see that their business models are threatened.

These social issues are interesting, but beyond the scope of this book.

The second issue, though, is quite appropriate to our discussion: legal ambiguity. There is basically no argument that the GPL is a valid and enforceable license. There is, however, a lot of confusion about when and where the GPL applies. In some ways, the GPL is treated like HIV/AIDS in the early 1980s; a lot of people weren’t sure how you get infected, so there was a lot of hyperbole and misinformation.

By way of comparison, there is a current controversy in the Python language community about setuptools, a packaging system that puts Python code into packages known as “eggs.” Like the GPL, some people love setuptools, and some people hate it. After a long discussion with a number of detractors, the setuptools author wrote a post titled, “Wow, I Think I Actually *Get* It Now!” (

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before continuing, it is important to point out that there is wide agreement on a number of the issues that have traditionally surrounded the GPL. In day-to-day use, people don’t usually encounter the difficult situations that we will discuss throughout this chapter. Accordingly, a lot of frequently asked GPL-related questions have easy answers.

There are four common situations involving the GPL: distributing GPL-licensed code, avoiding GPL-licensed code, running GPL-licensed code, and creating a larger distribution of independent programs, some of which are licensed under the GPL.

Distributing GPL-licensed code

When someone distributes GPL-licensed code, the terms of the GPL apply. Full GPL-licensed source code (or at least an offer of full source code) must accompany the distribution of any binary applications. It doesn’t matter if the GPL-licensed program has been modified or not; if source code comes into a company licensed under the GPL, then it must leave the company licensed under the GPL. Any modifications to the program must also be licensed under the GPL.

The few times that the GPL has been an issue in court, GPL enforcers have generally won because there have been obvious violations of the license conditions—a GPL-licensed program was being distributed with “no source nor offer.” (Technically, the cases have not continued to the point where the court issued a final ruling, but the GPL enforcers settled on favorable terms).

Avoiding GPL-licensed code

If people don’t want to deal with the GPL, they usually completely avoid it. In a corporate setting, this is usually manifested by creating a corporate policy against using any GPL-licensed code.

In most cases, corporate policies against GPL-licensed code are limited to developers. Sometimes, however, corporate managers have the incorrect impression that any use of GPL-licensed applications requires the company to release all of the company source code under the GPL. This unreasonable fear of GPL infection leads people to ban

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before analyzing the debate over linking and the GPL, we need to define a couple of essential terms more explicitly: derivative works, collective works, and functional language.

As discussed in , the copyright statute defines a derivative work as “a work based upon one or more preexisting works.” On one hand, basing a work “upon one or more preexisting works” usually means that there is some sort of transformation or adaptation of the original. Otherwise the combination would simply be a compilation under copyright law. No transformation or adaptation takes place during the linking of program code (the code is transformed in the compilation step, but linking just resolves references). On the other hand, the statute also allows a derivative work to be created when the original work is accompanied by “annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship.” In other words, a work may be considered a derivative work if it layers additional creative expression on top of an underlying original work, even if there are no changes to the underlying work.

Creating a derivative work is one of the specific property rights granted under copyright law, so the owner of the original work has the right to impose restrictions on derivative works. In the case of the GPL, this means that the author of the original program has the right to require any derivative works to also be licensed under the GPL.

The copyright statute states that a collective work (or compilation) is created when a person brings together “preexisting materials or...data...in such a way that the resulting work as a whole constitutes an original work of authorship.” In a software context, you can create a collective work when you combine different pieces of software without making changes to the individual pieces, like in a Linux distribution. In GPLv2 language, a collective work is a mere aggregation of software.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There are a number of reasons for concern over the issue of linking and licensing. We already explored one reason: how the uncertainty surrounding this issue magnifies the social concerns around the GPL. Even people who would like to work with GPL-licensed code are worried that it will show up uninvited in their ecosystem. Corporate policies prohibiting the GPL are just the most benign manifestation of this concern. On a deeper level, comments comparing free software to communism or to cancer are expressions of this underlying uncertainty—as logically incoherent and factually incorrect as those comments might be.

The more fundamental problem is that the arguments over linking and licensing are really arguments over the scope of copyright...and regardless of your opinion about what should and should not be copyrighted, winning this argument is a losing proposition. This issue was brought into relief by an April 10, 2008 blog post from Bradley Kuhn (FOSS Community Liaison for the Software Freedom Law Center) titled, “The GPL is a Tool to Encourage Freedom, Not an End in Itself” (http://www.softwarefreedom.org/technology/blog/2008/apr/10/gpl-not-end-in-itself/):

I was amazed to be involved in yet another discussion recently regarding the old debate about the scope of the GPL under copyright law. The debate itself isn’t amazing—these debates have happened somewhere every six months, almost on cue, since around 1994 or so...
I’m disturbed by the notion that some believe the goal of the GPL is to expand copyrightability and the inclusiveness of derivative works. It seems that so many forget (or maybe they never even knew) that copyleft was invented to hack copyright—to turn its typical applications to software inside out. [...]
It’s unfortunate that the entrenched interests outside of software are (more or less) inadvertently strengthening software copyright, too. Thus, in the meantime, we must hold steadfast to the GPL going as far as is legally permitted under this ridiculously expansive copyright system we have.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

With these terms in mind, let’s turn our attention to the strategy and tactics surrounding the GPL. The GPLv2 makes an explicit tie between derivative works under copyright and the reach of the GPL; the GPL applies to “either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications" (emphasis added). The GPLv3 similarly ties its interpretation to copyright law.

Strategically, the FSF has stated that it is opposed to strong software copyrights in general. Copyright law must be interpreted to determine what constitutes derivative work; the GPL intends to go only as far as copyright law does.

The problem is that in a number of public statements from the FSF, the tactical decision has been to take an expansive view of copyright, applying the GPL in the broadest range of situations possible. In the words of Bradley Kuhn, there has been a decision to “hold steadfast to the GPL going as far as is legally permitted under this ridiculously expansive copyright system we have.” The result is uncertainty and a perception, fed by the FSF itself, that the GPL is more infective than the license and the law may support.

The relationship between linking, derivative works, and the scope of the GPL is one of the secret controversies of free and open source software. Despite its importance, this issue isn’t on the radar for most free and open source software developers.

To understand why, think of the old controversy between vi and emacs. People can argue for either editor, but the arguments are mostly technical and can really only be appreciated by those with the proper background. Those outside the programming tradition, particularly outside the Unix programming tradition, are largely unaware of the controversy.

The controversy over linking and licensing is similar. As you can see in this chapter, this is a complex technical and legal issue, and the arguments on each side are hard to appreciate without having the proper background. Like the vi and emacs “holy war,” this isn’t an issue that is easily resolved. There are arguments and prominent open source experts on both sides of the divide. For example, Eben Moglen (attorney for the FSF and founder of the Software Freedom Conservancy) and Lawrence Rosen (former general counsel and director of the OSI) disagree on the scope of linking and licensing.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The key issue is whether linking creates a derivative work. Because of the intricacies of both copyright law and computer software, this is a complex and difficult question. For example, the standard definition of a derivative work usually requires some transformation of the original work, but not always.

Sometimes, a dynamically linked work could just include annotations and elaborations on a base binary. Consider the Linux kernel. Are kernel modules annotations or elaborations upon the base expression of the kernel? Perhaps—so maybe they are derivative works under the law.

Another argument is that linking creates a collective work, not a derivative work. Collective works are treated differently under the law (and under the GPL). In support of this argument, there is no real difference between having two binary images on disk and having two binary images in memory. Some systems, in fact, may not have separate disks or memory, but just a single area for both storage and working memory. In that case, the distinction between a link and an aggregation is unclear.

A counter-argument is that while collective works are usually different from derivative works, it is possible for something to be a collective work and a derivative work at the same time. Courts sometimes look at the Congressional Record to figure out the meaning of a law. When discussing the Copyright Act, one representative said:

Between them the terms “compilations” and “derivative works” which are defined in section 101, comprehend every copyrightable work that employs preexisting material or data of any kind. There is necessarily some overlapping between the two, but they basically represent different concepts. (emphasis added)

If the courts recognize any overlap between the worlds of collective and derivative works, then the results of software linking might be one of the few types of works that inhabit that space. If so, the GPL might apply to linked software that is a collective-derivative work hybrid.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Unfortunately, there are no clear and definitive answers for the questions raised here. Nevertheless, the purpose of this chapter is to give guidelines, not headaches. Keeping in mind the difficulty of these issues, here are some questions and answers about GPL, linking, and copyright.

Can I link a GPL-licensed program to and from other software under different licenses?: The short answer is, “Maybe.” It depends on whether the linking is for your own private use and whether you create a derivative work of the GPL-licensed program. Also note that code may be covered by more than one type of intellectual property protection, and each type of intellectual property protection has to be considered individually. For example, the functional parts of your code may be subject to patents. The use of patented program functionality requires the agreement of the patent owner.
Does the GPL apply to merely compiling or running a GPL-licensed program?: No, the GPL does not apply to just compiling and running the program for private use. The GPLv2 excludes “activities other than copying, distribution and modification” of the program and “the act of running the Program” is specifically not restricted. The GPLv3 states that, “You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.”
Does the GPL apply to compiling a GPL-licensed program by itself and distributing it to someone else?: Yes. The compiled program may or may not be a derivative work, but distribution is the key; the GPL always applies. Under the terms of the GPL, the developer must distribute the source code for the program along with the binary copy. To ease this burden for embedded systems, the GPL frees the developer from including the source code with the device; instead, the developer can provide it online (or by mail order) and provide documentation pointing to it.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One of the themes of this book is the growing strength of intellectual property protections like fortresses on the intellectual landscape. Like medieval castles, many different types of protection can be placed around a particular piece of intellectual turf. There are patent walls, copyright towers, and trade secret battlements that can only be accessed through licensing gates.

When medieval armies attacked, they had two ways to overcome castle defenses: by siege and by assault. During a siege, attackers would try to wait out the defenders of the castle, letting time do the work of removing the castle defenses. An assault, on the other hand, would attack the castle protections head-on to defeat them.

Both of these tactics are applicable to modern intellectual property defenses. Some sorts of protection, notably patent protection, can just be waited out. For example, the entire generic drugs industry exists because the patent protections around certain drugs have expired.

Reverse engineering, on the other hand, is more like a direct assault; the intellectual property protections are carefully surmounted or avoided to capture the prize within. Like medieval assaults, reverse engineering is risky, expensive, and complicated, but when it works, it provides a way inside the intellectual property fortress.

Reverse engineering is one of the most celebrated traditions of our legal system. It isn’t often that the dry world of intellectual property produces a good story, but reverse engineering has been at the center of some of the best stories in the history of computer engineering.

Understanding important reverse engineering cases is also essential to new reverse engineering projects. Part of what makes reverse engineering risky is that there is no law that clearly lays out the requirements for acceptable reverse engineering. There is only a selection of incidents where courts have looked at specific cases of reverse engineering and either accepted the result as acceptable or not. By seeing what courts have accepted in the past, general guidelines for reverse engineering have been developed.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Reverse engineering is one of the most celebrated traditions of our legal system. It isn’t often that the dry world of intellectual property produces a good story, but reverse engineering has been at the center of some of the best stories in the history of computer engineering.

Understanding important reverse engineering cases is also essential to new reverse engineering projects. Part of what makes reverse engineering risky is that there is no law that clearly lays out the requirements for acceptable reverse engineering. There is only a selection of incidents where courts have looked at specific cases of reverse engineering and either accepted the result as acceptable or not. By seeing what courts have accepted in the past, general guidelines for reverse engineering have been developed.

One of the most famous instances of reverse engineering was the creation of a compatible PC BIOS in the early 1980s. In the early days of the personal computer revolution, IBM decided that it needed some sort of computer to compete with the increasingly successful Apple II. IBM’s Data Systems Division, however, was afraid that a too-powerful entry-level computer would cannibalize sales of the more profitable IBM DisplayWriter. Ideally, IBM wanted the PC as a low-power, low-quality product that could blunt the effect of Apple’s sales, allowing IBM to keep control of the computer industry while still retaining the ability to up-sell serious computer users on the mainframes and minicomputers that were IBM’s primary products.

So instead of using custom designed, high quality IBM components, the IBM PC used commodity hardware components from different vendors. IBM intended to keep control of the architecture by retaining copyright control over just one component, the ROM-BIOS.

Against IBM’s own expectations, however, the PC was very successful. It very quickly created a market for IBM PC-compatible computers, which a number of computer makers attempted to address.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In both the open source and commercial contexts, reverse engineering is an essential part of the software ecosystem, but it is especially important in the world of open source. Many of the most commercially important and widely used open source products are reverse engineered clones of proprietary products.

For example, the Samba project started out as an effort to reverse engineer Microsoft’s proprietary Server Message Block (SMB) disk-sharing protocol, which has now expanded into an effort to replicate the server-side file sharing, printing, and domain administration functions of Microsoft Windows servers. Samba was (and is) developed using reverse engineering processes because most of the necessary specifications do not exist or are not published outside of Microsoft.

The Wine Project is another reverse engineering project addressing compatibility with Microsoft Windows, but does so in a more ambitious fashion. The Wine project aims to provide a complete reimplementation of the Windows API. OpenOffice.org and Abiword are word processors that have implemented reverse engineered compatibility with some Microsoft Office file formats. Mono is a reimplementation of the .NET runtime.

Reverse engineering is also important to the Linux kernel. Some companies do not release drivers for Linux, so a number of hardware drivers have been reverse engineered from the available hardware.

When open source projects re-create proprietary software, proper reverse engineering procedure is necessary to protect the integrity of the projects. In the few cases where proper procedures have not been followed, there have been substantial negative repercussions, from the removal of code to the shutting down of entire projects.

A clean room procedure is a method of software development that intends to produce new code functionally similar to a competitor’s copyrighted code without infringing the competitor’s copyright. The difference from the traditional development procedure is that the specification is not created from scratch, but is instead based on the competitor’s product.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Digital Millennium Copyright Act, or DMCA, is a relatively new extension to the copyright statute that can restrict reverse engineering. Ironically, the DMCA was one of the first copyright acts to explicitly recognize the value of reverse engineered interoperability, and contains explicit protections for reverse engineering. Specifically, Section 1201(f) of the DMCA allows software developers to circumvent technological protection measures of a lawfully obtained computer program in order to identify and analyze those “elements necessary to achieve interoperability of an independently created computer program with other programs.”

In spite of the official protection for reverse engineering, however, the creation of specific reverse engineering requirements has had the effect of reducing the scope of the reverse engineering rights. For example, developers can only reverse engineer software if there are no other means available to achieve interoperability, if the reverse engineering is otherwise allowed under the fair use provisions of copyright law, and if the developer asks permission to reverse engineer the software first. The difficulties imposed by these requirements, particularly the “permission” requirement, are obvious.

The DMCA is also noted for its “trafficking” provisions. Under the DMCA, it is illegal to “traffic” “in any technology, product, service, device, component, or part thereof, that is primarily designed or produced for the purpose of circumventing protection afforded by a technological measure that effectively protects a right of a copyright owner under this title in a work or a portion thereof.” This portion of the DMCA is designed to protect digital rights management (DRM) technologies.

Digital rights management is an umbrella term given to technologies that attempt to prevent unlicensed or unauthorized uses of copyrighted material. For example, CSS (Content Scrambling System) on DVDs, FairPlay on iTunes songs, and SecuROM on many game discs are all examples of DRM.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

You have a successful project. Everybody from the U.S. Government to Google is using your code and loving it. Companies want to donate time and resources to your project. So what are you going to do now?: You’re going to incorporate as a non-profit entity.

I realize that incorporating as a non-profit entity is not nearly as exciting as going to Disneyland. But if you are in this situation, incorporating as a non-profit entity may be one of the best things that you can do for your project.

Incorporating your project is a fairly substantial step, one that imposes substantial additional burdens on the developers involved. Nevertheless, most projects that get to a certain size or achieve a certain amount of distribution choose to incorporate. Why? In a word, scalability.

Imagine a new web application. It contains a stack of individual components, such as the typical LAMP (Linux/Apache/MySQL/PHP) setup, that communicate only vertically. Although Linux, Apache, and MySQL all tolerate a certain amount of concurrency, all requests ultimately trickle down to the database layer, which handles the requests coming in from the processes.

This setup works great—up to a certain point. When faced with overwhelming traffic, the database becomes a bottleneck. It can’t keep up with the flood of requests, and the web application falls over.

That is why companies handling billions of hits each day don’t have a single database; they have a distributed system that hands off queries to a large number of different backend database machines. Concurrency between the many backend databases is handled by some sort of distributed locking system. The distributed lock imposes a layer of overhead on the entire application, but the overhead is necessary to coordinate the large numbers of machines needed for massive-scale web serving.

Open source projects work the same way. At the start, you set up an account with Sourceforge or Google Code, a simple web page with documentation, and away you go. Contributors come and fit themselves into your project.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Incorporating your project is a fairly substantial step, one that imposes substantial additional burdens on the developers involved. Nevertheless, most projects that get to a certain size or achieve a certain amount of distribution choose to incorporate. Why? In a word, scalability.

Imagine a new web application. It contains a stack of individual components, such as the typical LAMP (Linux/Apache/MySQL/PHP) setup, that communicate only vertically. Although Linux, Apache, and MySQL all tolerate a certain amount of concurrency, all requests ultimately trickle down to the database layer, which handles the requests coming in from the processes.

This setup works great—up to a certain point. When faced with overwhelming traffic, the database becomes a bottleneck. It can’t keep up with the flood of requests, and the web application falls over.

That is why companies handling billions of hits each day don’t have a single database; they have a distributed system that hands off queries to a large number of different backend database machines. Concurrency between the many backend databases is handled by some sort of distributed locking system. The distributed lock imposes a layer of overhead on the entire application, but the overhead is necessary to coordinate the large numbers of machines needed for massive-scale web serving.

Open source projects work the same way. At the start, you set up an account with Sourceforge or Google Code, a simple web page with documentation, and away you go. Contributors come and fit themselves into your project.

As projects get larger, however, coordinating the work of the many volunteers becomes more difficult. At a certain point, project administration becomes more effort than the coding itself.

This scenario should be familiar, even if you don’t participate in a project that has entered the heavy administration phase. It is a classic computer science coordination problem, applied to people. The project maintainer acts like a big lock at the center of the project, and if there are too many volunteers, the project starts to suffer from lock contention. Unfortunately, the most important work on the project—the code—can get pushed aside.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The laws for creating a non-profit entity vary from state to state, so there is no single magic formula to create a non-profit foundation for your project. The following principles are representative, however, and they give an idea of the types of strictures and structures that you may have in your state.

Speaking of states, the first thing to do is to choose a state in which to incorporate. Although some states may have advantages over others, such as lower fees or fewer required reports, the best course of action is usually to incorporate in the state where one or more members of the project will establish the principal place of business—the official address for the new non-profit and its legal home. The problem is that the principle place of business for an open source project can be somewhat nebulous, as projects can have contributors from all over the globe. In that case, other considerations, such as convenience or well-developed non-profit law might apply.

About Delaware

Despite the general rule above, there is one state that must be mentioned in particular. Many non-profits (like many corporations) choose to register in Delaware. This is for three reasons.

First, it is easy to create a Delaware corporation. As of this writing, the state requires only an $89 filing fee and no yearly franchise fee. Delaware even has expedited filing rules that allow you to create your non-profit in a day. The convenience also extends to corporate formalities; Delaware requires fewer directors and fewer meetings than many other states.

Second, Delaware has a long history of business law. Court cases are decided on precedent—on what has been decided before. Delaware has an advantage because its long history of business cases has given it the most extensive and well-defined body of corporate law in the United States. This makes it is easy for lawyers and courts to find the right answers for basic issues and makes business decisions more predictable, both of which may lower legal costs.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As I mentioned earlier, there are drawbacks to having a non-profit organization. They have reporting and fundraising requirements, and must adhere to certain formalities. These requirements must be observed, and that takes time.

However, the first and most important thing to remember about incorporated non-profit organizations is that the people associated with them must always remember to respect the existence of the organization. This almost sounds ridiculous, but it is the single biggest problem that people encounter.

To understand why this is a problem, think again about the analogy of a distributed locking system for an application. Assume for a moment that you implemented such a system, but instead of using it, you allowed certain threads or processes to directly manipulate protected shared resources.

Crazy, right? The application is already paying for the overhead of the locking system. Completely ignoring the locks means that you get none of the protection that the locking system is supposed to provide, and the application is going to blow up sooner or later when it turns out that two processes have done the wrong thing at the wrong time.

This is exactly analogous to ignoring the corporate formalities required for your non-profit entity. If you have already paid for the overhead of incorporating a non-profit organization, why ignore it? Just like in the distributed locking system, ignoring your non-profit means that the legal protections (and tax-exempt status) provided by the corporate form may not protect you, and your project may blow up when someone does the wrong thing at the wrong time.

Thankfully, the operating requirements for a non-profit are very manageable. They basically boil down to rules about doing your best, holding meetings, keeping notes, receiving money, spending money, and providing reports.

The people involved in a non-profit cannot and are not expected to be perfect. We can’t make the right decisions all the time. However, those who have been entrusted to act for a non-profit organization are required to do their best to advance the interests of the non-profit and to not let their own interests get in the way.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One growing alternative to the incorporation of individual projects is to join an umbrella organization. An umbrella organization is a single non-profit organization that is designed to provide infrastructure and support to many related or unrelated subprojects. This single umbrella organization acts as the fiscal sponsor and corporate parent for the projects, allowing them to receive the benefits of non-profit incorporation while sharing some of the burdens.

In particular, projects organized under the umbrella organization receive the benefits described above, without actually having to form and maintain their own organizations. Another benefit is that the only Board of Directors is at the level of the umbrella organization, so open source projects coming in under an umbrella organization can usually keep the same organizational structure they had as a decentralized project. This single professionalized organization can provide support to many separate associated projects.

If your project already has substantial corporate involvement, in may make sense to form your own non-profit organization. If your project needs the infrastructure provided by a non-profit, but is relatively new or growing, it may make sense to apply for membership in an umbrella organization. As these organizations are presently constituted, the option remains to form your own dedicated non-profit organization later.

The three most prominent umbrella organizations for free and open source software are the Free Software Foundation (http://www.fsf.org/), the Apache Software Foundation, (http://www.apache.org/foundation/), and the Software Freedom Conservancy (http://conservancy.softwarefreedom.org/). It would probably be best to try the Software Freedom Conservancy first, as that organization handles the broadest range of projects.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Proprietary Information and Inventions Assignment Agreement

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

[NAME OF COMPANY]

In consideration of my employment with ______________________ (the “Company”), the Company’s promise to disclose to me its confidential and proprietary information (as defined below), the compensation now and hereafter paid to me, and for other good and valuable consideration, the receipt and sufficiency of which is hereby acknowledged, I hereby agree with the Company as follows:

Recognition of Company’s Rights; Nondisclosure. At all times during the term of my employment and thereafter, I will hold in strictest confidence and will not disclose, use, lecture upon, or publish any of the Company’s Proprietary Information (defined below), except as such disclosure, use, or publication may be required in connection with my work for the Company, or unless the President or the Board of Directors of the Company expressly authorizes such in writing. I hereby assign to the Company any rights I may have or acquire in such Proprietary Information and recognize that all Proprietary Information shall be the sole property of the Company and its assigns and that the Company and its assigns shall be the sole owner of all patent rights, copyrights, trade secret rights, and all other rights throughout the world (collectively, “Proprietary Rights”) in connection therewith.
The term “Proprietary Information” shall mean trade secrets, confidential knowledge, data, or any other proprietary information of, or acquired by, the Company and each of its subsidiaries or affiliated companies. By way of illustration but not limitation, “Proprietary Information” includes:
1. this Agreement;
2. inventions, trade secrets, ideas, processes, formulas, data, lists, programs, other works of authorship, know-how, improvements, discoveries, developments, designs, and techniques relating to the business or proposed business of the Company and that were learned or discovered by me during the term of my employment with the Company, except as expressly permitted by the Board of Directors of the Company during the term of my employment, at the time of my termination, or subsequent to my termination (hereinafter, included Proprietary Information is collectively referred to as “

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Open Source Licenses

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The following licenses have been certified as Open Source by the Open Source Initiative. The license categories are from the Open Source Initiative’s License Proliferation Committee report.

For a list of current licenses, see the following sites:

http://opensource.org/licenses/category

http:// opensource.org/licenses/alphabetical

We used statistics obtained from public sources to determine which licenses are widely used. We believed that there were a few licenses that, while not the most popular, were widely used within their communities and that these also belonged in this group.

Apache License, 2.0
New and Simplified BSD licenses
GNU General Public License (GPL)(version 2)
GNU Library or “Lesser” General Public License (LGPL) (version 2)
MIT license
Mozilla Public License 1.1 (MPL)
Common Development and Distribution License
Common Public License 1.0
Eclipse Public License

Certain licensors, such as schools and the U.S. government, have specialized concerns, such as specialized rules for government copyrights. Licenses that were identified as meeting a special need were placed in this group.

Educational Community License
NASA Open Source Agreement 1.3
Open Group Test Suite License

Adaptive Public License
Artistic License 2.0
Open Software License
Qt Public License (QPL)
zlib/libpng License

Several licenses in this group are excellent licenses and have their own followings. The committee struggled with this group, but ultimately decided that if we were to attack the license proliferation problem, we had to prune licenses. Thus, licenses that were perceived as completely or partially redundant with existing licenses were placed in this group.

Academic Free License
Attribution Assurance Licenses
Eiffel Forum License version 2.0
Fair License
Historical Permission Notice and Disclaimer
Lucent Public License version 1.02
University of Illinois/NCSA Open Source License
X.Net License

Licenses in this group are specific to their authors and cannot be reused by others. Many, but not all, of these licenses fall into the category of vanity licenses.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Free Software Licenses

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

These licenses have been certified as Free Software Licenses by the Free Software Foundation. For discussion of these licenses, see “Various Licenses and Comments about Them,” at http://www.gnu.org/licenses/license-list.html.

GNU General Public License (GPL) version 3
GNU General Public License (GPL) version 2
GNU Lesser General Public License (LGPL) version 3
GNU Lesser General Public License (LGPL) version 2.1
GNU Affero General Public License (AGPL) version 3
Apache License, version 2.0
Artistic License 2.0
Clarified Artistic License
Berkeley Database License (a.k.a. the Sleepycat Software Product License)
Boost Software License
Modified BSD license
CeCILL version 2
Cryptix General License
eCos license version 2.0
Eiffel Forum License, version 2
EU DataGrid Software License
Expat License
FreeBSD license
License of the iMatix Standard Function Library
Intel Open Source License
Microsoft Public License (Ms-PL)
NCSA/University of Illinois Open Source License
License of Netscape Javascript
OpenLDAP License, Version 2.7
License of Perl 5 and below
Public Domain
License of Python 2.0.1, 2.1.1, and newer versions
License of Python 1.6a2 and earlier versions
License of Ruby
Standard ML of New Jersey Copyright License
License of Vim, version 6.1 or later
W3C Software Notice and License
X11 License
XFree86 1.1 License
License of Zlib
Zope Public License, versions 2.0 and 2.1

The following licenses are free software licenses, but are not compatible with the GNU GPL.

Affero General Public License version 1
Academic Free License, all versions through 3.0
Apache License, version 1.1
Apache License, version 1.0
Apple Public Source License (APSL), version 2
Original BSD license
Common Development and Distribution License (CDDL)
Common Public License version 1.0
Condor Public License
Eclipse Public License version 1.0
IBM Public License, version 1.0
Interbase Public License, version 1.0
Jabber Open Source License, version 1.0
LaTeX Project Public License 1.3a
LaTeX Project Public License 1.2
Lucent Public License version 1.02 (Plan 9 license)
Microsoft Reciprocal License (Ms-RL)
Mozilla Public License (MPL)
Netizen Open Source License (NOSL), version 1.0

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Licenses Approved for Use with Fedora

GPL Compatibility Matrix

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

shows the licenses that are approved for use with the Fedora project. This is for software only; documentation and other content have different licenses. For the current list, see the licensing page on the Fedora wiki: http://fedoraproject.org/wiki/Licensing.

Table : Fedora-approved licenses
Full name	Short name	FSF free?	GPLv2 compat?
3dfxGlide License	Glide	Yes	NO	NO
Academic Free License	AFL	Yes	NO
Academy of Motion Picture Arts and Sciences BSD	AMPAS BSD	Yes	NO	NO
Adobe Systems Incorporated Source Code License Agreement	Adobe	Yes	Yes	Yes
Affero General Public License 1.0	AGPLv1	Yes	NO
Affero General Public License 3.0	AGPLv3	Yes	NO	Yes—special exception
Amazon Digital Services License	ADSL	Yes	Yes	Yes
Apache Software License 1.0	ASL 1.0	Yes	NO	NO
Apache Software License 1.1	ASL 1.1	Yes	NO	NO
Apache Software License 2.0	ASL 2.0	Yes	NO	Yes
Apple Public Source License 2.0	APSL 2.0	Yes	NO
Artistic (clarified)	Artistic clarified	Yes	Yes	Yes
Artistic 2.0	Artistic 2.0	Yes	Yes	Yes
Aspell-ru License	ARL	Yes	NO	NO
BitTorrent License	BitTorrent	Yes	NO	NO
Boost Software License	Boost	Yes	Yes	Yes
BSD License (original)	BSD with advertising	Yes	NO	NO
BSD License (no advertising)	BSD	Yes	Yes	Yes
BSD License (two clause)	BSD	Yes	Yes	Yes
CeCILL License v2	CeCILL	Yes	Yes
CMU License (BSD like)	MIT	Yes	Yes	Yes
Common Development Distribution License	CDDL	Yes	NO
Common Public License	CPL	Yes	NO
Condor Public License	Condor	Yes	NO
Copyright Attribution Only	Copyright only	Yes	Yes	Yes
CPAL License 1.0	CPAL	Yes	NO	NO
Cryptix General License	Cryptix	Yes	NO
Crystal Stacker License	Crystal Stacker	Yes	Yes	Yes
Do What The F*ck You Want To Public License	WTFPL	Yes	Yes	Yes
DOC License	DOC	Yes	Yes	Yes
Eclipse Public License 1.0	EPL	Yes	NO
eCos License v2.0

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In , the labels across the top of the columns show the license under which you want to release your project, whereas the labels down the left side of the rows show the license of the code you want to copy into your project.

Table : Including source code in your project

GPLv2 only	OK	OK []	NO	OK if you convert to GPLv2 []	OK if you convert to GPLv2 [] []	NO
GPLv2 or later	OK []	OK	OK	OK if you convert to GPL []	OK if you convert to GPL []	OK if you convert to GPLv3 []
GPLv3	NO	OK if you upgrade to GPLv3 []	OK	OK if you convert to GPLv3 []	OK if you convert to GPLv3 [] []	OK if you convert to GPLv3 []
LGPLv2.1 only	OK if you convert to GPLv2 []	OK if you convert to GPL [] []	OK if you convert to GPLv3 []	OK	OK []	OK if you convert to GPLv3 [] []
LGPLv2.1 or later	OK if you convert to GPLv2 [] []	OK if you convert to GPL []	OK if you convert to GPLv3 []	OK []	OK	OK
LGPLv3	NO	OK if you upgrade and convert to GPLv3 [] []	OK if you convert to GPLv3 []	OK if you convert to GPLv3 []	OK if you upgrade to LGPLv3 []	OK

In , the labels across the top of the columns show the license under which you want to release your project, whereas the labels down the left side of the rows show the license of the code you want to copy into your project.

Table : Linking libraries with your project

GPLv2 only	OK	OK []	NO	OK if you convert to GPLv2 []	OK if you convert to GPLv2 [] []	NO
GPLv2 or later	OK []	OK	OK	OK if you convert to GPL [] []	OK if you convert to GPL []	OK if you convert to GPLv3 []
GPLv3	NO	OK if you upgrade to GPLv3 [ ]	OK	OK if you convert to GPLv3 []	OK if you convert to GPLv3 [] []	OK if you convert to GPLv3 []

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Copyright-Only Dedication (based on United States law) or Public Domain Certification

The person or persons who have associated work with this document (the “Dedicator” or “Certifier”) hereby either (a) certifies that, to the best of his knowledge, the work of authorship identified is in the public domain of the country from which the work is published, or (b) hereby dedicates whatever copyright the dedicators holds in the work of authorship identified below (the “Work”) to the public domain. A certifier, moreover, dedicates any copyright interest he may have in the associated work, and for these purposes, is described as a “dedicator” below.

A certifier has taken reasonable steps to verify the copyright status of this work. Certifier recognizes that his good faith efforts may not shield him from liability if in fact the work certified is not in the public domain.

Dedicator makes this dedication for the benefit of the public at large and to the detriment of the Dedicator’s heirs and successors. Dedicator intends this dedication to be an overt act of relinquishment in perpetuity of all present and future rights under copyright law, whether vested or contingent, in the Work. Dedicator understands that such relinquishment of all rights includes the relinquishment of all rights to enforce (by lawsuit or otherwise) those copyrights in the Work.

Dedicator recognizes that, once placed in the public domain, the Work may be freely reproduced, distributed, transmitted, used, modified, built upon, or otherwise exploited by anyone for any purpose, commercial or non-commercial, and in any way, including by methods that have not yet been invented or conceived.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The following is a BSD license template. To generate your own license, change the values of OWNER, ORGANIZATION, and YEAR from their original values as given here, and substitute your own.

There is also a third optional clause, shown in brackets below.

The BSD License

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Copyright (c) <YEAR>, <OWNER>

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
[OPTIONAL] Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Apache License,

Version 2.0,

January 2004

http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

Definitions.
“License” shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.
“Licensor” shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.
“Legal Entity” shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
“You” (or “Your”) shall mean an individual or Legal Entity exercising permissions granted by this License.
“Source” form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.
“Object” form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.
“Work” shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).
“Derivative Works” shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

1. Definitions

2. Source Code License

3. Distribution Obligations

4. Inability to Comply Due to Statute or Regulation

5. Application of this License

6. Versions of the License

7. DISCLAIMER OF WARRANTY

8. Termination

9. LIMITATION OF LIABILITY

10. U.S. Government End Users

11. MISCELLANEOUS

12. Responsibility for Claims

14. Multiple-Licensed Code

Applying the Mozilla Public License

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

1.0.1. “Commercial Use” means distribution or otherwise making the Covered Code available to a third party.

“Contributor” means each entity that creates or contributes to the creation of Modifications.

1.2. “Contributor Version” means the combination of the Original Code, prior Modifications used by a Contributor, and the Modifications made by that particular Contributor.

1.3. “Covered Code” means the Original Code or Modifications or the combination of the Original Code and Modifications, in each case including portions thereof.

1.4. “Electronic Distribution Mechanism” means a mechanism generally accepted in the software development community for the electronic transfer of data.

1.5. “Executable” means Covered Code in any form other than Source Code.

1.6. “Initial Developer” means the individual or entity identified as the Initial Developer in the Source Code notice required by Exhibit A.

1.7. “Larger Work” means a work which combines Covered Code or portions thereof with code not governed by the terms of this License.

1.8.1. “Licensable” means having the right to grant, to the maximum extent possible, whether at the time of the initial grant or subsequently acquired, any and all of the rights conveyed herein.

1.9. “Modifications” means any addition to or deletion from the substance or structure of either the Original Code or any previous Modifications. When Covered Code is released as a series of files, a Modification is:

Any addition to or deletion from the contents of a file containing Original Code or previous Modifications.
Any new file that contains any part of the Original Code or previous Modifications.

1.10. “Original Code” means Source Code of computer software code which is described in the Source Code notice required by Exhibit A as Original Code, and which, at the time of its release under this License is not already Covered Code governed by this License.

1.10.1. “Patent Claims” means any patent claim(s), now owned or hereafter acquired, including without limitation, method, process, and apparatus claims, in any patent Licensable by grantor.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Initial Developer hereby grants You a world-wide, royalty-free, non-exclusive license, subject to third party intellectual property claims:

under intellectual property rights (other than patent or trademark) Licensable by Initial Developer to use, reproduce, modify, display, perform, sublicense and distribute the Original Code (or portions thereof) with or without Modifications, and/or as part of a Larger Work; and
under Patents Claims infringed by the making, using or selling of Original Code, to make, have made, use, practice, sell, and offer for sale, and/or otherwise dispose of the Original Code (or portions thereof).
the licenses granted in this Section 2.1(a) and (b) are effective on the date Initial Developer first distributes Original Code under the terms of this License.
Notwithstanding Section 2.1(b) above, no patent license is granted:
1. for code that You delete from the Original Code;
2. separate from the Original Code; or
3. for infringements caused by:
  1. the modification of the Original Code or
  2. the combination of the Original Code with other software or devices.

Subject to third party intellectual property claims, each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license

under intellectual property rights (other than patent or trademark) Licensable by Contributor, to use, reproduce, modify, display, perform, sublicense and distribute the Modifications created by such Contributor (or portions thereof) either on an unmodified basis, with other Modifications, as Covered Code and/or as part of a Larger Work; and
under Patent Claims infringed by the making, using, or selling of Modifications made by that Contributor either alone and/or in combination with its Contributor Version (or portions of such combination), to make, use, sell, offer for sale, have made, and/or otherwise dispose of:
1. Modifications made by that Contributor (or portions thereof); and

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Modifications which You create or to which You contribute are governed by the terms of this License, including without limitation Section 2.2. The Source Code version of Covered Code may be distributed only under the terms of this License or a future version of this License released under Section 6.1, and You must include a copy of this License with every copy of the Source Code You distribute. You may not offer or impose any terms on any Source Code version that alters or restricts the applicable version of this License or the recipients’ rights hereunder. However, You may include an additional document offering the additional rights described in Section 3.5.

Any Modification which You create or to which You contribute must be made available in Source Code form under the terms of this License either on the same media as an Executable version or via an accepted Electronic Distribution Mechanism to anyone to whom you made an Executable version available; and if made available via Electronic Distribution Mechanism, must remain available for at least twelve (12) months after the date it initially became available, or at least six (6) months after a subsequent version of that particular Modification has been made available to such recipients. You are responsible for ensuring that the Source Code version remains available even if the Electronic Distribution Mechanism is maintained by a third party.

You must cause all Covered Code to which You contribute to contain a file documenting the changes You made to create that Covered Code and the date of any change. You must include a prominent statement that the Modification is derived, directly or indirectly, from Original Code provided by the Initial Developer and including the name of the Initial Developer in (a) the Source Code, and (b) in any notice in an Executable version or related documentation in which You describe the origin or ownership of the Covered Code.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

If it is impossible for You to comply with any of the terms of this License with respect to some or all of the Covered Code due to statute, judicial order, or regulation then You must: (a) comply with the terms of this License to the maximum extent possible; and (b) describe the limitations and the code they affect. Such description must be included in the LEGAL file described in Section 3.4 and must be included with all distributions of the Source Code. Except to the extent prohibited by statute or regulation, such description must be sufficiently detailed for a recipient of ordinary skill to be able to understand it.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This License applies to code to which the Initial Developer has attached the notice in Exhibit A and to related Covered Code.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Netscape Communications Corporation ("Netscape”) may publish revised and/or new versions of the License from time to time. Each version will be given a distinguishing version number.

Once Covered Code has been published under a particular version of the License, You may always continue to use it under the terms of that version. You may also choose to use such Covered Code under the terms of any subsequent version of the License published by Netscape. No one other than Netscape has the right to modify the terms applicable to Covered Code created under this License.

If You create or use a modified version of this License (which you may only do in order to apply it to code which is not already Covered Code governed by this License), You must (a) rename Your license so that the phrases “Mozilla”, “MOZILLAPL”, “MOZPL”, “Netscape”, “MPL”, “NPL” or any confusingly similar phrase do not appear in your license (except to note that your license differs from this License) and (b) otherwise make it clear that Your version of the license contains terms which differ from the Mozilla Public License and Netscape Public License. (Filling in the name of the Initial Developer, Original Code or Contributor in the notice described in Exhibit A shall not of themselves be deemed to be modifications of this License.)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

COVERED CODE IS PROVIDED UNDER THIS LICENSE ON AN “AS IS” BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE COVERED CODE IS FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE COVERED CODE IS WITH YOU. SHOULD ANY COVERED CODE PROVE DEFECTIVE IN ANY RESPECT, YOU (NOT THE INITIAL DEVELOPER OR ANY OTHER CONTRIBUTOR) ASSUME THE COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF ANY COVERED CODE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

8.1. This License and the rights granted hereunder will terminate automatically if You fail to comply with terms herein and fail to cure such breach within 30 days of becoming aware of the breach. All sublicenses to the Covered Code which are properly granted shall survive any termination of this License. Provisions which, by their nature, must remain in effect beyond the termination of this License shall survive.

8.2. If You initiate litigation by asserting a patent infringement claim (excluding declaratory judgment actions) against Initial Developer or a Contributor (the Initial Developer or Contributor against whom You file such action is referred to as “Participant”) alleging that:

such Participant’s Contributor Version directly or indirectly infringes any patent, then any and all rights granted by such Participant to You under Sections 2.1 and/or 2.2 of this License shall, upon 60 days notice from Participant terminate prospectively, unless if within 60 days after receipt of notice You either:
1. agree in writing to pay Participant a mutually agreeable reasonable royalty for Your past and future use of Modifications made by such Participant, or
2. withdraw Your litigation claim with respect to the Contributor Version against such Participant.
If within 60 days of notice, a reasonable royalty and payment arrangement are not mutually agreed upon in writing by the parties or the litigation claim is not withdrawn, the rights granted by Participant to You under Sections 2.1 and/or 2.2 automatically terminate at the expiration of the 60 day notice period specified above.
any software, hardware, or device, other than such Participant’s Contributor Version, directly or indirectly infringes any patent, then any rights granted to You by such Participant under Sections 2.1(b) and 2.2(b) are revoked effective as of the date You first made, used, sold, distributed, or had made, Modifications made by that Participant.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, WHETHER TORT (INCLUDING NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL YOU, THE INITIAL DEVELOPER, ANY OTHER CONTRIBUTOR, OR ANY DISTRIBUTOR OF COVERED CODE, OR ANY SUPPLIER OF ANY OF SUCH PARTIES, BE LIABLE TO ANY PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF GOODWILL, WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER COMMERCIAL DAMAGES OR LOSSES, EVEN IF SUCH PARTY SHALL HAVE BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGES. THIS LIMITATION OF LIABILITY SHALL NOT APPLY TO LIABILITY FOR DEATH OR PERSONAL INJURY RESULTING FROM SUCH PARTY’S NEGLIGENCE TO THE EXTENT APPLICABLE LAW PROHIBITS SUCH LIMITATION. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THIS EXCLUSION AND LIMITATION MAY NOT APPLY TO YOU.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Covered Code is a “commercial item,” as that term is defined in 48 C.F.R. 2.101 (Oct. 1995), consisting of “commercial computer software” and “commercial computer software documentation,” as such terms are used in 48 C.F.R. 12.212 (Sept. 1995). Consistent with 48 C.F.R. 12.212 and 48 C.F.R. 227.7202-1 through 227.7202-4 (June 1995), all U.S. Government End Users acquire Covered Code with only those rights set forth herein.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This License represents the complete agreement concerning subject matter hereof. If any provision of this License is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable. This License shall be governed by California law provisions (except to the extent applicable law, if any, provides otherwise), excluding its conflict-of-law provisions. With respect to disputes in which at least one party is a citizen of, or an entity chartered or registered to do business in the United States of America, any litigation relating to this License shall be subject to the jurisdiction of the Federal Courts of the Northern District of California, with venue lying in Santa Clara County, California, with the losing party responsible for costs, including without limitation, court costs and reasonable attorneys’ fees and expenses. The application of the United Nations Convention on Contracts for the International Sale of Goods is expressly excluded. Any law or regulation which provides that the language of a contract shall be construed against the drafter shall not apply to this License.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As between Initial Developer and the Contributors, each party is responsible for claims and damages arising, directly or indirectly, out of its utilization of rights under this License and You agree to work with Initial Developer and Contributors to distribute such responsibility on an equitable basis. Nothing herein is intended or shall be deemed to constitute any admission of liability.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Initial Developer may designate portions of the Covered Code as Multiple-Licensed. Multiple-Licensed means that the Initial Developer permits you to utilize portions of the Covered Code under Your choice of the MPL or the alternative licenses, if any, specified by the Initial Developer in the file described in Exhibit A.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

To apply the Mozilla Public License to your code, include the following information at the top of your file:

The contents of this file are subject to the Mozilla Public License Version 1.1 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.mozilla.org/MPL/
Software distributed under the License is distributed on an “AS IS” basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License.
The Original Code is ______________________________________.
The Initial Developer of the Original Code is ________________________.
Portions created by ______________________ are Copyright (C) ______ _______________________.
All Rights Reserved.
Contributor(s): ______________________________________.
Alternatively, the contents of this file may be used under the terms of the _____ license (the [___] License), in which case the provisions of [______] License are applicable instead of those above. If you wish to allow use of your version of this file only under the terms of the [____] License and not to allow others to use your version of this file under the MPL, indicate your decision by deleting the provisions above and replace them with the notice and other provisions required by the [___] License. If you do not delete the provisions above, a recipient may use your version of this file under either the MPL or the [___] License.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The GNU Lesser General Public License (LGPL), Version 2.1

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Version 2.1, February 1999

51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

[This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.]

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software—to make sure the software is free for all its users.

This license, the Lesser General Public License, applies to some specially designated software packages—typically libraries—of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below.

When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things.

To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it.

For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The GNU Lesser General Public License (LGPL), Version 3

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below.

As used herein, “this License” refers to version 3 of the GNU Lesser General Public License, and the “GNU GPL” refers to version 3 of the GNU General Public License.

“The Library” refers to a covered work governed by this License, other than an Application or a Combined Work as defined below.

An “Application” is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library.

A “Combined Work” is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the “Linked Version”.

The “Minimal Corresponding Source” for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.

The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.

You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL.

If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The GNU General Public License (GPL), Version 2

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software—to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation’s software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.

Also, for each author’s protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors’ reputations.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The GNU General Public License (GPL), Version 3

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program—to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.

For the developers’ and authors’ protection, the GPL clearly explains that there is no warranty for this free software. For both users’ and authors’ sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Open Software License (OSL), Version 3.0

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This Open Software License (the “License”) applies to any original work of authorship (the “Original Work”) whose owner (the “Licensor”) has placed the following licensing notice adjacent to the copyright notice for the Original Work:

Grant of Copyright License. Licensor grants You a worldwide, royalty-free, non-exclusive, sublicensable license, for the duration of the copyright, to do the following:
1. to reproduce the Original Work in copies, either alone or as part of a collective work;
2. to translate, adapt, alter, transform, modify, or arrange the Original Work, thereby creating derivative works (“Derivative Works”) based upon the Original Work;
3. to distribute or communicate copies of the Original Work and Derivative Works to the public, with the proviso that copies of Original Work or Derivative Works that You distribute or communicate shall be licensed under this Open Software License;
4. to perform the Original Work publicly; and
5. to display the Original Work publicly.
Grant of Patent License. Licensor grants You a worldwide, royalty-free, non-exclusive, sublicensable license, under patent claims owned or controlled by the Licensor that are embodied in the Original Work as furnished by the Licensor, for the duration of the patents, to make, use, sell, offer for sale, have made, and import the Original Work and Derivative Works.
Grant of Source Code License. The term “Source Code” means the preferred form of the Original Work for making modifications to it and all available documentation describing how to modify the Original Work. Licensor agrees to provide a machine-readable copy of the Source Code of the Original Work along with each copy of the Original Work that Licensor distributes. Licensor reserves the right to satisfy this obligation by placing a machine-readable copy of the Source Code in an information repository reasonably calculated to permit inexpensive and convenient access by You for as long as Licensor continues to distribute the Original Work.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.