I put things here so they are on the internet


I put things here so they are on the internet

Last month I attended the third Open Hardware Summit in New York City.  With the growth of the community and the emergence of products that target people beyond core open source hardware enthusiasts, there was a great deal of discussion about what it really means to be open source hardware and also how to be both open source and competitive in the hardware world.  This post expands upon something that I only had time to briefly touch upon during my presentation.

At the end of my talk at last month’s Open Hardware Summit, I urged the community to consider that open source hardware may be more of a political and cultural movement than a legal movement.  This was an admittedly fleeting reference to a discussion that will necessarily be a large one, so I want to use this blog post to begin to expand upon what I meant.  The goal of this explanation is not to provide answers – largely because the answers are not mine to provide, and even if they were I do not have them – but rather to attempt to bring a useful framework to the discussion.

Legal Underpinnings of Open Source Software

Let me first lay out some of the critical elements of the open source software (OSS) movement, which is often pointed to as a model for the open source hardware (OSHW) movement.  While OSS is undeniably a cultural and political movement, it is also a movement firmly grounded in the law.  Specifically, OSS takes a legal regime that can restrict sharing (copyright) and use it to promote sharing.  It accomplishes this through a legally binding license on the code.

Critically, this slight of hand works because code is protected by copyright.  More importantly, code is automatically protected by copyright.  The coder does not need to apply or register in order to obtain copyright protection on the code (although there are good reasons to register a copyright) – the mere act of writing the code means that it is protected by copyright. That copyright gives people something to license and a legal way to enforce that license.

As one of last month’s speakers (I believe Andrew Katz, but if someone remembers differently I’ll update this) helpfully explained, a license allows you do to something that you could not do anyway.  Code is protected by copyright.  Absent anything else, copying that code is a violation of copyright.  A license gives you permission, subject to certain conditions, to make a copy of that code.  Because the code is protected by copyright and licensed under conditions, copying the code in a way that violates those conditions is copyright infringement.  If someone infringes on your copyright, you can take them to court. 

This legal enforceability allows the OSS community to impose its own internal rules on people outside of the community.  Social shaming and recognition of achievement is probably enough to make sure everyone in the OSS community plays by the rules, but they are less effective for people who want to use the code but do not care about the community’s opinion.  Since OSS is useful and usable for people outside of the OSS community, this legal enforceability is critical to protecting the ethos of OSS as it comes into contact with the wider world.  

(Of course, it is possible to engage in profitable, creative industries without this sort of legal protection.  The fashion industry is a great example.  For an exploration of these industries check out Kal Raustiala and Christopher Sprigman’s new book The Knockoff Economy.)

Legal Underpinnings of Open Source Hardware

Hardware is different from software in many ways, but one of those ways is how it is, and isn’t, protected by intellectual property.  As a general matter, copyright does not protect functional objects – objects that do things.  Copyright may protect decorative elements, or specific patterns on a circuit board, but by and large most OSHW projects and products (especially as you move away from embedded electronics) are things that do something, and thus not eligible for copyright protection.  As a result, it is all but inevitable that critical elements of an OSHW product are not protected by copyright.

That does not mean that there is no protection for OSHW.  Trademarks can be protected.  However, trademarks cannot protect the functional elements of the product either.

This leaves patents.  For the purposes of this discussion, patents differ from copyright in a few critical ways.  First, you must affirmatively apply for a patent – they do not exist simply by creating an object.  Second, there is a burden to show utility, novelty, and nonobviousness.  Third, and this may be the most important, actually getting a patent is an expensive and time-intensive process.

This combination – copyright that does not protect function, trademark that needs to be applied for and does not protect function, and patents that need to be applied for and can protect functions – means that most hardware projects are “open” by default because their core functionality is not protected by any sort of intellectual property right.  Of course, in this case “open” means that their key functionality can be copied without legal repercussion, not that the schematics have been posted online or that it is easy to discover how they work (critical elements of open source hardware).

Licensing Open Source Hardware

This difference has a critical impact on licensing open source hardware.  There is nothing preventing an inventor from applying an open source hardware license to her creation.  However, for that license to be legally meaningful, she must have a right that she is actually licensing to users.  In the absence of a patent on the project, it is unlikely that she will actually be licensing anything critical to someone who wants to reproduce or build upon the creation.

This only matters if someone violates the license.  As described above, if someone copies OSS and refuses to comply with the terms of the license, that person is a copyright infringer and can expect to be brought to court.  In contrast, if someone copies OSHW and refuses to comply with the terms of the license, that person will probably be in the clear.  Since (again, in most cases) there was no intellectual property protecting the functionality of the product, there is no intellectual property right being infringed in the violation of the license.

One response to this – to try to patent every OSHW project – is simply impractical.  Even if we assume, simply for the sake of argument, that every OSHW project could meet the utility, novelty, and nonobviousness requirements of patent (something that is highly unlikely), it is unreasonable to expect every OSHW project to pay the thousands of dollars it costs to shepherd an application through the process simply to be able to turn it over to the community.

Another – to make it easier to patent OSHW projects – strikes me as ill conceived.  No matter how good the intentions, creating additional intellectual property rights or making it easier to obtain intellectual property protections rarely advance to cause of openness.  It is almost inevitable that any such process would quickly be used and abused by people outside of the OSHW community in ways that the OSHW community would live to regret.  

Where does this leave us?

First, to be clear, none of this means that OSHW is doomed or a worthless endeavor or unable to scale.  It simply means that its expansion will require critical, creative thinking.  Moreover, open source hardware is more than a license.  It is a commitment to building products that people can access, repair, and improve, and to building documentation that facilitates these goals.  Nothing about the legal status of an open source hardware license changes that.  Additionally, nothing about the legal status of an open source hardware license prevents an organization (say, theOpen Source Hardware Association) from creating a certification logo, protected by trademark, that companies that comply with open source hardware principles can affix to their products.

I believe that companies coming out of the OSHW community truly do have a desire to be open.  I also believe that they are honestly trying to find ways to compete in a broad marketplace made up of people who do not care about openness and competitors uninterested in playing by “the rules.”

The result is that they are trying to thread the needle, maintaining as much openness as possible while not making it easy for competitors to simply clone them.  Right now that path is far from clear.  Inevitably, there will be missteps along the way.  It is also possible that some “open” companies abandon their commitment and simply betray the community.

The challenge is to learn to distinguish a misstep from a betrayal while recognizing that most choices do not have straightforward right or wrong answers.  OSHW is not OSS.  The “right” license can have tremendous value as a signaling device, as a public commitment, and as a way to raise the profile of openness.  However, in many cases, the “right” license will be meaningless from a legal standpoint.  To me, the challenge of the next year of OSHW is to find a way to scale beyond the core OSHW community, maintain a meaningful commitment to openness (whatever that ultimately means), while all the while recognizing that the license itself is largely symbolic.

I am not going to pretend that is easy, or that I even have an idea of how to accomplish it.  At this point, all I really hope is that everyone is coming to this discussion with a realistic understanding of its terms.

Want to learn more about open source hardware?  In addition to the Open Source Hardware Association and the Open Hardware Summit, earlier this year Public Knowledge held OH/DC: Open Source Hardware Comes to DC - check out audio and video here.

Image: Catarina Mota.

Most people who know of Makerbot know them as a one of the leaders in the home 3D printingmarket.  Fewer people realize that they are also one of the highest profile examples of another movement: open source hardware.  Like open source software, the open source hardware community makes its plans freely available – and usable – to the general public.  This strategy was recently put to the test when another company tried to use Makerbot’s plans to make a Makerbot replica – and sell it for 2/3 of the price.

Open Source Hardware

Although the open source hardware community looks to open source software for guidance, there are obvious differences that arise when principles that were developed for virtual goods migrate to the physical world.  Unlike many open source software projects, open source hardware products are not given away for free.  If you want a Makerbot 3D printer from the Makerbot company, they will charge you for it.  However, you can download the plans and schematics for a Makerbot 3D printer and just build your own without having to give Makerbot a dime.

PK staff attorneys building a Makerbot

The one caveat is that Makerbot, and almost every other open source hardware project, retains control of their trademark.  That means that you can make your own Makerbot, but attaching the Makerbot logo to it would be trademark infringement.

This openness has lead to massive innovation.  The current Makerbot model – the Replicator – simply could not exist without the work done by a worldwide community of 3D printing enthusiasts working together to improve 3D printing.  In fact, without another open 3D printing project (the RepRap project), Makerbot probably would not exist at all.

While the open source hardware community has traditionally freely licensed its plans, a good deal of behavior was dictated by community norms, not licenses.  One of the most important norms was that simply “cloning” - that is, making an exact copy of someone else’s product and bringing it to market – wasn’t cool.  If you were going to copy someone else’s idea and bring it to market, you had an obligation, at a minimum, to improve it in some way.  Copying alone was frowned upon, but copying and improving was celebrated (for a larger examination of the unwritten rules of open source hardware, check out this post by Philip Torrone).

Enter TangiBot

Of course, community norms are not legally enforceable.  So it should have come as no surprise when an engineer named Matt Strong decided to set up a Kickstarter campaign to help market his own cloned Makerbot he called the TangiBot.  How would Makerbot and the open source hardware community react?

Makerbot mostly reacted by doing nothing.  In some ways, that is because there was not a lot they could do.  Strong was copying their technical designs, but that was his right.  The only difference, at least in theory, was that Strong was not calling his 3D printer a “Makerbot Replicator.”  He did make reference to Makerbot and the Replicator in his Kickstarter page, but it was mostly as a nominative use to explain the source of his design.  When Strong talked about the Makerbot Replicator, he was not suggesting that he was selling a Makerbot made Makerbot Replicator.  Instead, he was referring to the fact that he was copying a Makerbot Replicator.  Generally speaking, this is a permitted use of someone else’s trademark.  After all, there are not a lot of ways that Strong could have told people that he was copying a Makerbot Replicator without using the words “Makerbot Replicator.”  He also made it fairly clear that the 3D printer he was selling was not coming from Makerbot.

Did it Work?

So, was this the end for Makerbot?  It did not appear to be.  On Saturday, Strong’s Kickstarter campaign ended, falling about 90% short of his $500,000 goal.  And the reaction from the community was telling.  While at least one high profile community member criticized Strong’s use of the Makerbot name in the Kickstarter campaign (a criticism tied more to the frequency of use than the use in general), there were two other strong reactions.

The first was a “bad form” type of reaction.  Strong was seen by some (but certainly not all) as violating the spirit of open source hardware by simply cloning an existing product.  While some people joined the Kickstarter campaign just to comment against it, by and large both the open source hardware and 3D printing community expressed a reluctance to do business with someone who violated the community norms.  

This is an important reaction, but may not be enough to protect the open source hardware community as it grows.  While some people may know the complicated backstory of the relationship between Makerbot and TangiBot, many others will only see a 3D printer that is 33% cheaper than its (apparently identical) competitor.  As the world of open source hardware expands, this type of reputational check against cloning will likely become less effective. 

The second was a concern that Strong simply could not pull it off.  Makerbot’s popularity is not only tied to the specific design of the machines.  It also flows from a reputation for strong customer service and for well-built actual machines.  Put another way, Makerbot does not just design good machines, it ships good machines.

This highlights a critical difference between hardware and software.  Firefox is a great open source browser.  You can download it from Mozilla’s web site, or from any number of other sites.  To some degree, where you get Firefox from does not matter – every copy of Firefox is exactly the same program.

The same cannot be said for hardware.  Even if they are using the exact same designs, each physical item can be very different.  When people buy from Makerbot, they are buying a Makerbot designed and built product.  A 33% discount on a product that does not work may not be a deal.

What Now?

TangiBot failed to make its goal, but it is unlikely to be the last company that tries to market a clone of a Makerbot at a cheaper price (this happens all the time with another hugely successful open source hardware product, the Arduino).  Ultimately, there are at least two interesting lessons to be drawn from this episode.

The first is that the idea of open source hardware is not as fragile as it might appear.  Even though there are not legal barriers to cloning, there are cultural and economic reasons that make it hard.  Keep in mind that it took almost 8 months after the release of Makerbot’s Replicator for this question to even come up, and the cloner failed.  Hardware, as they say, is hard.  

The second, and this is discussed in the comments of an article on Hack a Day, is that consumers benefit from this type of competition.  Assuming he had the ability to follow through, Strong’s Kickstarter campaign suggests that it is possible to manufacture Makerbot Replicators for less than they are manufactured for today.  It is hard to say where those savings come from – it could be streamlining processes and better sourcing of materials, or it could be from shoddy materials and outsourcing production to less reliable facilities (for what it’s worth, Makerbots are built in Brooklyn while it appeared that TangiBots would be built in China).

As open source hardware grows in popularity, it is all but inevitable that we will see more incidents like this.  Since they raise a rich mix of legal, ethical, and normative questions, those incidents are worth paying attention to.  In a developing area like open source hardware, “right” answers are not always obvious.

In the meantime, here are a few more resources about this incident and open source hardware:

Joseph Flaherty wrote a fantastic article examining the moral questions surrounding Tangibot, with quotes from a number of experts, for Wired.com.

The TangiBot Kickstarter comment page became a center for debate, including some backers who backed simply to be able to participate in the comment thread.

All of this happened just in time for the third annual Open Hardware Summit, which will be held in New York City on September 27th.

This spring, Public Knowledge brought members of the open source hardware community to DC in order to begin to explain to policymakers what this whole open source hardware thing is about.  Audio and video from the event can be found here.

This whitepaper is a thorough analysis of role that data caps and usage based billing can play in internet access service.  It ends with a series of recommendations for regulators.

A PDF version of this paper can be found here.

4G internet connections are fast, but data caps prevent them from living up to their potential.  This whitepaper examines how quickly a fast 4G internet connection can burn through a month’s worth of data.

A PDF of this paper can be downloaded here.

This whitepaper includes recommendations to Maria Pallante, the new Registrar of Copyrights, for modernizing and updating the operations of the Copyright Office.

A PDF of this paper can be found here.