I put things here so they are on the internet

MichaelWeinberg.org

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.

This post originally appeared in TechCrunch

Mashups are one of the great art forms of our time. Easy and accessible digital tools have allowed anyone to remix videos, music and photographs into their own original works: Mashup culture has produced fantastic music, critical video, and delightful cultural artifacts of all kinds.

patent-chart3However, mashups are ultimately limited by the nature of their source material. The types of things that mashups draw from – videos, music, photos – are also the types of things that are protected by copyright, which means mashup creators need to take copyright into account when creating their works. Sometimes, because of rules such as fair use, the creator does not need permission from the person who owns rights to the source material. Other times, mostly because the work falls outside of the scope of fair use, the creator does need permission. The requirement for permission inevitably prevents some mashups from being seen by a wide audience and makes it harder for creators to make money.

Enter 3D Printing

There are plenty of reasons to be excited about 3D printing, but one of them is that it moves beyond the world of things protected by copyright. When you step away from your computer screen and look around, you realize that the physical world – the real world – is full of real, physical things that are not protected by copyright. In fact, the world is full of things that are not protected by any sort of intellectual property right at all. That means that you can take them and do whatever you want with them. And that includes mashing them up.

One of the best examples of this so far is the Free Universal Construction Kit. The kit remixes 10 different construction toys into adaptors that make them interoperable. These toys are functional objects so they are outside of the scope of copyright. While some of them were patented when they first came to market, patents only last 20 years. That means that most of the toys are no longer protected. As long as you stick with the toys that are no longer protected by patent, you can remix them to your heart’s content.

The Free Universal Construction Kit is just the beginning when it comes to remixing things. Easy-to-use tools like meshmixer allow people to remix things just as easily as they remix songs or videos. And unlike those songs or videos, many of the things will not be protected by copyright.

One of the keys to this next generation of mashups will be a strong understanding of how copyright interacts with physical objects. While copyright will not protect functional objects, it will protect decorative ones. Understanding functional vs. decorative will mean the difference between a mashup encumbered by copyright and a mashup that is in the clear.

Public Knowledge’s latest whitepaper, What’s the Deal with 3D Printing and Copyright? should help everyone begin to understand what is protected by copyright and to start thinking about what is not protected by copyright. That second category includes a lot of things just waiting to be remixed and mashed up.

This post originally appeared in TechCrunch

FCC Chairman Julius Genachowski wrote last week on TechCrunch about the importance of speed. Specifically, he highlighted the importance of speed in the next wave of Internet innovation. While he is right about the importance of speed, he missed one key point: broadband speed isn’t worth much if it is crippled by data caps.

All of the advances Chairman Genachowski pointed to – in-cloud computing, education, health care, energy, and public safety – will rely on fast broadband connections. 100 megabit-per-second networks could transform the way our society and economy function. But speed is not an end in and of itself.

The fastest car in the world won’t get you very far if you only have 20 feet of road, and a blazing-fast 4G LTE network is not worth much if you are limited to 2 GB of data per month. By and large, next-generation Internet technologies need high-speed networks because they need to move a lot of data quickly. Big Data is called Big Data for a reason – there is lots of it.

Unfortunately, while the FCC has taken steps to encourage the deployment of broadband networks, it has done little to ensure that people can make use of those networks without running into road blocks in the form of data caps.

Data caps impose real costs on consumers and society as a whole. At their most basic, they create a disincentive to use broadband. Instead of freely exploring new technologies, services, and ideas, data caps force users to decide if site, or app, or video is really worth using some of their valuable data.

Caps also have a tendency to freeze innovation. When they set their caps, most ISPs insist that “normal” users will not run into problems. Even if this were true, those caps have proven extremely slow to change. “Normal” usage patterns today barely include streaming video, let alone the types of next-generation innovation that we all look forward to. Under a data cap, that next-generation immersive and creative software to help children learn is reserved for “data hogs” willing to pay tens, or hundreds, of dollars a month in overage fees. That is not a recipe for widespread adoption of innovation.

We are also starting to see ISPs use data caps to pick winners and losers online. Whether it is Comcast exempting its own online video service from its data cap or AT&T offering to let developers buy their way out of its data cap by paying a fee, data caps become an excuse for ISPs to charge more people more money while shutting out disruptive innovators. Of course, it is also no surprise that cable companies are setting data caps well below what it would take to replace their TV offering with an over-the-top competitor.

Data caps are also beginning to create a second-class Internet for traditionally disenfranchised communities. Low-income communities, rural communities, and communities of color are increasingly relying on wireless internet connections as their only internet connection. Single digit data caps make it unreasonable to expect these connections to be used to access the “real,” data rich, Internet.

It is hard to find a positive benefit of data caps to balance out all of these costs. You do not have to be a network engineer to know that a monthly data cap is an inefficient way to address network congestion – something that happens at a specific time and place on a network. Monthly data caps cannot tell the difference between streaming a high-definition movie on a weekday evening and backing up data overnight during the weekend. There is no evidence that monthly caps shift usage away from congested periods – only that they reduce internet usage generally.

And while there may be some benefit in charging heavier users more, data caps are a bad way to do that. Most customers have no idea how much data a given activity requires. Even AT&T and Verizon disagree on how much data an hour of streaming video will consume. This uncertainty guarantees that consumers end up over-paying and under-using when it comes to broadband. If ISPs are going to charge heavy users more, they should at least use a metric that everyone – especially Chairman Genachowski – understands: speed. You may not know a megabit per second from a gigabyte per month, but when web pages start to load slowly you know that it is time for a faster connection.

However much we might wish things were different, limited competition between ISPs means that we cannot rely on market forces alone to ensure the internet remains an open platform that continues to enable innovation without permission. After all but ignoring the issue in the past, the FCC has just started the process of looking into data caps. For over a year, we have been urging them to ask ISPs basic questions about data caps: What is their purpose? How are they set? Once they are set, how are they evaluated against their purpose? What would cause them to change?

Without answers to those questions, we may end up with a blazing-fast network with everyone stuck in the slow lane.

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.

image
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.