AALS: Law and Computers

AALS Section on Law and Computers, Free and Open Source: Next Generation Issues

Great panel!

Intro: We’ve learned a lot studying FOSS in the past decade, including the importance of intertwined copyright and contract law to sustaining it. FOSS licenses were written by programmers, not lawyers, so we came in as non-natives.

Heather Meeker of Greenberg Taurig (adviser to ALI on principles of software contracts): Open source has completely changed the function it plays in the tech industry. Ten years ago, it was the purview of hobbyists and enthusiasts, participating because of a normative idea. Now a flip-flop of demographics. Rumored figures: 1999, 20% of participants were corporate, whereas today is more like 80%. Success changed it!

Even five years ago, you still heard a lot about an ideological war (is open source more moral, more robust, more/less secure?) between open and closed, but that’s largely a thing of the past. Now people agree that the development model works well for some things and not others. Open source works really well for fundamental pieces of software, like OS—the basic stack. That allows a lot of innovation on top. Doesn’t work quite as well for high value-added software like applications.

Two goals to revising GPL: (1) clarify in light of subsequent technological developments; (2) add additional provisions like patent-related ones addressing new issues. Those who believed in open source politically tried to impose their desires on the rest of the community, especially the corporate owners, and there was an enormous amount of resistance—almost unresolvable. GPL 3 hasn’t exactly taken the world by storm. The thought pioneers of 10 years ago had a lot of clout, but today there are many constituencies and any one has trouble leading.

From an engineer’s perspective, open source doesn’t require involving the business process/requisition process. Thus, organizations overwhelmingly don’t know what open source they’re using. It’s very hard just to keep track. Legal departments would say they had a policy against using open source, and then it would turn out that the entire product was riddled with open source. There is a trainwreck coming; there are little trainwrecks all the time in due diligence. We’re at the dawning of the age of enforcement of open source by lawsuit—open source authors are willing to enforce, and companies don’t know what they’re doing so can’t comply—so this is an information management problem for the entire industry. Big burden in the form of paying lawyers, getting engineers to backtrack, etc.

Trend: take a proprietary product that’s mature and release as open source. Company isn’t making a lot of money on the product but has competitors, and releases as open source to disrupt the marketplace and get the benefits of open source development. In the past, open source was usually done from scratch. We’ll see in the future proprietary products being converted.

Also enormous trend for corporations to set up non-stock entities (foundations) to involve many companies at once in open source development, allowing collaboration in a formalized way. Helps them manage their IP rights.

Open source is countercyclical and the downturn will only increase its adoption.

Mike Madison, Pitt: Jacobsen v. Katzer, picking up on the trainwreck metaphor. The underlying software has to do with model railroads. Katzer has a small for-profit software company that produces model railroad software. Jacobsen is part of a group that produces an open source model railroad Java engine released under the Artistic License. Katzer had a patent on some software; made noises about suing Jacobsen’s group for patent infringement; Jacobsen sued for nonvalidity and for violation of the Artistic License, since Katzer had downloaded the open source software, modified it, and sold it in breach of the terms of the license. District judge denied the PI on the ground that the Artistic License did not create a copyright entitlement, only a contract right.

Appealed to Federal Circuit (because of the patent claim), and the Federal Circuit reversed, ruling that the Artistic License created a copyright entitlement, so that breach created the possibility of an injunction. The license said “provided that,” and the court of appeals treated that as a condition. The court also said that injunctive relief in the context of an open source license is necessary to accomplish the objectives of the open source collaborative, so that the copyright owner can benefit from the users of the downstream code. And then it suggested that a contract claim might also be available along with the copyright claim, but that was a one-sentence mention of “consideration,” so it’s not clear what that meant.

On remand: Katzer moved to dismiss the contract claims, and Jacobsen renewed motion for PI on both contract and copyright. On Monday, the court ruled; it seems confused about what open source and IP law are (referring a lot to TM). First, granted the motion to dismiss the contract claims on the ground that Jacobsen hasn’t specified any damages. Anyway, the contract claims are preempted by copyright.

Second, denied the PI, bearing in mind eBay on the ground that Jacobsen hasn’t demonstrated irreparable injury. The court is skeptical that there’s any injury of any kind at all. The judge refers to the idea that downstream users of the open source code wouldn’t contribute back to the project as speculative—it’s not a standard copyright claim where the owner can identify quite clearly the nature of the work and the nature of the injury. The plaintiff’s brief says that it wants the court to enforce the license, but it’s not clear how that would be done: what do we tell the defendant to do? Even though its failure to comply with the license terms is essentially conceded.

The district court rejected the application of the Federal Circuit’s idea of the purpose of open source as a workaround for the standard requirements of harm. The Federal Circuit’s ruling was warmly received in the open source community as a way to prevent forking code. The district court brings us back to reality: the high purposes of open source run into copyright litigation imperatives. Better lawyering/judicial education may be the answer, but there is still conceptual tension in the law as to what open source licenses are about.

McCoy Smith, chair of Intel’s open source legal practice group: Knowing the law isn’t enough; extralegal laws are key in open source. First, Linus’s Law (given enough eyeballs, all bugs are shallow). Second, absolute freeom to tinker: derivative works are allowed; no discrimination against persons/groups; no discrimination against fields of endeavor. Third, Schneier’s Law: if people who write open source software are liable for it, it will disappear.

The proprietary model sometimes involves warranties or indemnities for risks to customers, and possibly secures upstream protected in the same way from suppliers, but this practice isn’t universal or even commonplace. Many large companies’ end-user licenses disclaim many warranties and indemnities. Fees and/or license restrictions can be used to mitigate/insure against risks of legal assurances, though they’re most commonly used to defray development and support costs.

Open source: for-profit companies offset costs through indirect fees, such as support contracts and ancillary product sales. Each party is responsible for its own legal risks; the absence of warranty/indemnity is baked in to virtually every open source license. No party really has the ability to take on the risks of others—individual developers, nonprofits, etc. are incapable of doing so, especially since they give unlimited licenses allowing distribution of millions of copies. Nobody can demand fees for incremental risks and/or development costs.

Coming issues: consumer protection. ALI principles of software contracts draft: proposes that all software licenses come with upstream warranties (no material defects) and indemnity (IP infringement) that are nondisclaimable. In the commercial model, you’re trying to protect the downstream consumer from the monolithic developer. Doesn’t make so much sense for open source, which is disaggregated; one contributor shouldn’t necessarily take on that risk for all. Some limitations in the current draft might protect the hobbyist/academic, but there are people who make money, but not much, and are still individual developers.

Another feature of draft: in case of injunction, transferor must take steps to make end user whole. Must purchase right to continued use (buy a license to infringed IP); replace or modify software so it works the same without infringement; or cancel the agreement, refund fees, and reimburse for replacement. NB: virtually all open source licenses are non-terminable. Likely none of these alternatives are practicable for small/individual developers. These requirements would violate Schneier’s law—would kill open source, or would at least mean that only people working for big corporations can do open source.

Potential clash: public protection. The FCC has regulations saying devices emitting electromagnetic radiation can’t be sold if they allow user modifications to take the devices out of FCC parameters. Thus, you can’t use open source software to regulate that component of the device. Smith believes FDA will do the same for medical devices and maybe other regulatory agencies will act similarly in the future in the name of public interest. Private actors might do the same for non-public reasons. Will the government stifle open source for those devices? The Bureau of Export Administration had this issue with encryption years ago, but they resolved the issue in favor of open source.

Three new laws for the future: (1) Don’t assume 20^th century business models (e.g., don’t assume that the small consumer must be protected from the big developer when the consumer may be the developer). (2) Gov’t and courts should protect the egghead individual equally, or even more, than the eggshell skull consumer. (3) Avoid solutions in search of a problem: open source licenses and extralegal enforcement has been working pretty well; no need to fix the problem of warranty/indemnity.

David McGowan, San Diego: The form license debate is endlessly repetitive and focuses on something everybody knows is immaterial, which is assent. The modal user would click on a license no matter what warnings you showed her/him. Open source did the great benefit of pointing this out; it was the form agreement about freedom. It became clear that to get the sweet of open source you needed the bitter of the form. We should stop worrying about assent.

The notion of consumer v. producer oversimplifies: if you get enough producers who are also recipients, you stabilize the anti/commons and it can’t be taken private. We should learn from this that warranty disclaimers and the like are employed essentially behind the veil of ignorance, by people who don’t know what role they’ll play, and thus they are justified.

In the open source corporate model, you use open source to make money some other way. Making money by ancillary services is making money by applying IP fixed in someone’s head (expertise). That is not necessarily better than concretizing the IP into a tangible medium of expression that can be sold, reverse engineered, etc. The hardware model uses software to get margin out of hardware, which is protected by patents and trade secrets. So open source shifts commoditization—is that a net gain for freedom? The unanticipated effects are not all positive. We must net them to know.

Jacobsen: Property rules v. liability rules. This is a question of how we best net offsetting effects; do we get better pricing one way or another? The type of analysis in Jacobsen in the Federal Circuit pleased McGowan. The court made the point that there’s a difference between economic and monetary costs—lost revenues aren’t the only costs. Microstar v. Formgen is an early open source case: the gamers shouldn’t be free labor for someone else’s revenue model (comment: only the game company’s own revenue model).

Most people don’t like being zero-cost labor for others. The real import of contract law is not what happens in litigation, but to set up an architecture in which interactions among people with converging and diverging goals can be managed. The folks working on the model railroad interface are probably not happy that someone is making money off their work, even if it makes the product better. The Federal Circuit talked about downstream improvements, but the upstream ecology/willingness to participate matters. Smaller, hobby projects may well need property rules more than big corporate ones, and a property rule works really well to enforce the sociology of those systems.

(Comment, related to my comment above: there is a lot of work going on now about monetization of user-generated content. People will happily be zero-cost labor for others in appropriate circumstances, when for example YouTube gives them access to audiences/communities in return for providing free content; Linux contributors have lived with Red Hat making money indirectly on them. Viviana Zelizer’s work should come to mind.)

Q: What about patents as a threat?

Smith: it’s 17 years after the first big claim that patents were a threat—we haven’t seen the litigation. It’s out there, but it’s not as dangerous as people have thought. He understands the philosophical point about software patents, but practically it’s less important.

McGowan: He expected more of that until he read IBM’s answer in SCO. There are enough competing interests with patent portfolios of their own that it may not be worth it: you don’t want to go up against IBM with a patent case and let them find a patent that reads on you.

Meeker: Open source is particularly not vulnerable to patents. The FUD expressed in open source community about patents is like the FUD expressed in the legal community about open source 10 years ago, when lawyers assumed open source would be riddled with copyright infringement. Open source projects are bad targets, especially for patent trolls just in it for the money. Open sources tend to be effective for commoditized aspects of tech, and there’s not much upside in suing those. Open source creates an automatic store of prior art. Open source code results in any claims materializing early.

Madison on McGowan: Agrees with a lot about netting out costs and benefits. The projects can be valuable sociologically more than financially. The Java Model Railroad Initiative: Jacobsen is a physicist at Lawrence Berkeley, part of an exceptionally well organized group. The issue is how to apply eBay and the equities across diverse open source projects. When we talk about injunctive relief and property rules, remember that practicing lawyers treat software licenses in general and open source licenses in particular as contracts, not copyright matter. Only when it gets to enforcement do practitioners want to start talking copyright.

McGowan: It’s not obvious why we don’t more readily let parties contract for specific performance.

Greg Vetter, Houston: In terms of the sociology: there are two modes of licensing, BSD versus strong copylefting. As we move to more commercial involvement, will BSD licensing be more accepted?

Meeker: Corporate interests have become much more comfortable with open source of any flavor. Most won’t use GPL 3, but that’s mostly because it doesn’t have a track record. GPL is so ubiquitous that businesses have to become comfortable with it.

Eric Goldman, Santa Clara: Remains confused about interplay between Jacobsen and browsewraps. What if a browsewrap used “provided that” as its language?

Madison: he’s confused too, especially given what the district court did. Given the conclusions as to harm, it’s a heads I win, tails you lose situation for the defendant and the language doesn’t seem to matter as much.

Mark Lemley: We don’t have a clear answer to the question of whether these things are contracts or not. McGowan likes them as contracts, but then wants a property rule for enforcement. What do I get out of calling them contracts instead of “a statement of whether/when I’m going to sue you”?

McGowan: Wants to abandon the form debate. Let’s not parse magic words on condition/covenant. Default: if you’re running someone else’s code, you can’t do that without permission. If you are in violation of the terms of the license, you don’t have permission. With browsewrap, he’s willing to imply permission (unless there’s an express reservation) and discuss the scope of the implied license. We know that if the browsewrap were a dialogue box, the user’s comprehension would be the same, which is to say zero. Our discomfort with the procedure doesn’t depend on that distinction. On the other hand, the defendants in Jacobsen probably had a much better sense of the rules they were violating.