Drafting and using open licenses for data and hardware presents both familiar old challenges (like license proliferation) and new challenges (like less developed legal frameworks and different production models). About thirty people working in these areas recently gathered (under the umbrella of the FSF-E's "European Legal Network") to discuss the latest work in these areas under the Chatham House Rules. This article will summarize what the group learned, and, I hope, stimulate discussion to improve the state of licensing in those areas.

Similar conditions

The legal issues around open data and open hardware have a lot in common with the legal issues around open software. This shouldn't be surprising, because some of the technological and economic foundations are the same. These include:

Increased usefulness of information

In our dim, dark past, having information often was not very helpful for individuals or small organizations—they often lacked key skills or tools to create valuable things out of that information. In open software, this changed years ago with compilers. More recently, in hardware, 3D printing and easier access to contract manufacturers have changed the game; and in data, increased number crunching capabilities, open tools like R (programming language), and increased access to big open data sets like Wikidata and Open Street Map have opened new doors for a very wide variety of data geeks.

Collaboration happens outside

In the same dim past, collaboration was something that happened primarily within the walls of large organizations. As readers of Opensource.com know quite well, improved communication tools make it possible to collaborate publicly and across organizations. This increased ease of collaboration on any topic—software, hardware design, and data included—drives creativity, production, and (unfortunately) legal concerns. It has also broadened who participates—smaller and smaller organizations, as well as skilled individuals, with a variety of different motivations, have become involved in all of these areas. This is as true for data and hardware as it is for open software.

Different conditions

Despite the key similarities, there are a variety of differences between software, data, and hardware. These practical differences, in turn, drive legal differences:

Ease of turning "source" information into a useful thing

While it has gotten much easier in many areas to turn "source" information (data, a hardware design, source code) into something useful, this change has not happened uniformly. For very basic physical things, 3D printing has dropped the costs of customization down dramatically, and may do so even more—one participant mentioned that in Japan, 3D printing stores are now a real thing! At the same time, certain basic electronics aren't exactly easy to create and customize, but it is much easier to find manufacturers and experiment with components than it ever has been before (as my friend Richard Hughes has done). But for CPUs of any reasonable complexity/power, billion-dollar fabs for manufacturing are still a prerequisite. (Eli Greenbaum in particular made the point about ease of compilation during our event, and has written about related issues in 3D printing.)

Fragmented roles

In open software, most organizations that design software also compile that software, but that's not always the case. Two open hardware organizations in attendance create extremely detailed hardware specifications, but outsource the actual fabrication of the hardware. This is different from both software and from a lot of traditional hardware development. On the flip side, many open data providers deliberately publish data that by itself is not very useful, with the hope that some outside innovator will find it useful and integrate it into something else. This is again somewhat different from software, where software tends to be published only when it is useful in the form it is published in (albeit sometimes to a small number of people).

Diversity of technology

In data, standards tend to be pretty well developed, but in "hardware" the technology is all over the place. There are few standards for design data interchange, and people are doing "open hardware" in such a broad variety of technical domains that it is hard to say that there is one such thing as "open hardware." It may be often more accurate to speak of open mechanical engineering, open chip design, open connection standards, etc. Lumping all these different things together under the "open hardware" moniker, when they have different technologies, different economics, different motives for participation, etc., may distort our legal thinking.

Maturity of the legal systems

Despite its flaws, copyright law is relatively well-developed and relatively consistent, having been developed through international treaties for 100 years. In contrast, other legal rights that apply to data and hardware are often not consistently protected, and often are relatively "new" legally speaking—so they are difficult to interpret. For example, one speaker pointed out that in the U.K., there are four different design rights that might apply to open hardware designs. Database rights are newer, EU-only, and elaborated in only a handful of cases; and mask rights also apply to hardware and are not consistent. In each of these cases, the fact that the laws were not designed with "open" in mind leads to different, often conflicting problems for open lawyers.

Old problems

Not surprisingly, given that so many issues (and many of the lawyers!) are the same, some old concerns came up repeatedly throughout the day. A few in particular were:

Proliferation

People are trying to address new problems, so they are writing new licenses and new agreements. This is natural and healthy, as it was early on for open software. The question is whether or not we end up with a healthy diversity of licenses addressing real problems; or whether we get an explosion of vanity licenses, or licenses that exist only to address problems "discovered" by non-experts that experts agree are not actually an issue. There were suggestions during the day that hardware is probably still in the "healthy innovation" phase, given the complexity of issues facing the hardware space, but that data may already be into proliferation.

Compatibility

Given that one of the key purposes of open licensing is reuse and recombination of materials, compatibility between licenses is important. One theme from the hardware portion of the event is that hardware is so diverse (in terms of both design and manufacture) that compatibility may be less important, and that community norms (i.e., everyone who works in technology X agrees on using license Y) may be able to practically replace formal legal theorizing about compatibility. On the flip side, in data, it may be even more important than in software, and that problems may already be coming up in practice.

Third-party rights

The core open software legal tools are typically only effective at organizing rights held by participants; rights held by third parties have always been tricky. In open software, these third-party rights are typically patents. In data and hardware, there will also be design rights, privacy rights, and others; all will potentially require solutions that live partially outside of the tools used by participants, like licenses and certificates of origin.

Freedom and openness

It was notable during the event that "free" hardware and data were hardly mentioned at all. This is partially because the event tended to attract lawyers on the pragmatic end of the spectrum, but I think also in part because the case for liberty in those areas has not been forcefully and consistently made in the way that FSF and RMS have consistently advanced those issues in software. Nevertheless, the compromises between principle and pragmatism were often lurking right below the surface, and it is inevitable that this will cause tension down the road, particularly in projects where government and educational interests become major participants (as they may in data).

Different problems

Open source software licensing is now a relatively robust and mature area of the law; it was clear from the event that this is not yet the case for open data and hardware licensing. Some of that is merely because time has passed and expertise has been developed, but after the event I think there are a few key new problems that lawyers in this area will need to wrestle with:

Heterogeneity

At the end of the day, despite the many differences, the largest software companies and the loneliest hackers are fundamentally both doing the same thing—software. The big company may use or ship the lone hacker's code, and the lone hacker may rely on libraries or APIs provided by the big company. In part because of this homogeneity, the instincts of open source license lawyers is to use "one size fits all" legal tools. In hardware, one of my key takeaways from the event is that there are so many different things going on—different technologies, different motivations for creation—on that these instincts to simplify and unify may lead us astray. We don't want to try to fit round mechanical pegs into square chip design holes, for example. In data, I suspect extremely generalized, broad licenses are still the right instinct, but we do have to be careful to test that assumption and not take it for granted.

Different legal regimes

Experienced open source lawyers have a legal toolkit that in large part depends on well-understood features of copyright law. Our temptation will be to use those same tools in data and hardware, but it was clear after the event that this instinct will sometimes lead us into mistakes. In some cases, we may be able to borrow from other areas of law—for example, one presenter spoke of using a patent/standards approach for certain classes of hardware; but in other areas (particularly databases), the body of law may be so weakly developed that this is difficult to do, or may have many conflicting requirements and obligations that dealing with them will require more nuance and complexity than is typically possible in standardized, easy-to-understand licenses. These problems also increase the temptation to use contract instead of license law—which is often problematic both legally and ethically.

Copyleft

Copyleft/share-alike is a frequent request from open communities, and again, lawyers have a specific set of tools that we're comfortable using in this area. But these tools will have to be rethought in data and hardware. This is partially for the reasons listed above—the legal regimes of database rights and design rights give us fewer useful tools and terminology to implement a copyleft in those spaces, for example. But there are also different mechanisms and paths for collaboration in these spaces, which may make legally-enforced copyleft a poor mechanism for encouraging sharing in those places.

Next steps

Open lawyering, like open source development, thrives best when it communicates. In keeping with this tradition, the group agreed that the most important next steps are about improving communication: making sure that we talk with each other about new challenges, new models, and new licenses. Possible forums for this communication include the European Legal Network and (for open data) the Open Definition's discussion list. If you're interested in joining a list (or hopefully attending the next face-to-face meeting), drop me a line! I expect to see a lot of other activity in this space in the near future—open lawyers are lucky to live in interesting, if challenging, times.