The shift to digital goods has allowed merchants of digital goods to combine the advantages of both selling and renting, leaving purchasers with the disadvantages of both.¹ A better approach would be to maintain traditional sales and renting norms into the world of digital goods. Specifically, merchants should be forced to choose between licensing their goods under an ongoing duty to maintain them or selling the goods outright, removing their obligation to maintain them in the future.

Traditional Choices

Since Ye Olden Times, a merchant has basically had two choices with regard to getting money for their stuff.² The first choice was to sell the stuff. The second choice was to rent the stuff out. As is often the case, these choices come with pros and cons for everyone involved in the transaction.

Selling Pros

The biggest advantage to a merchant selling a good was that they were no longer responsible for it. A buyer bought it. That new person now owned it. Subject to any warranty requirements, once the seller sold the good, it was the purchaser’s problem. When someone figured out that you could use a pen to pick most Kryptonite bike locks, Kryptonite did not have to upgrade all of the locks they had sold up to that point. They had sold them. Newly discovered security problems were the buyers’ problem.

Selling had advantages for buyers too. Once a buyer buys something, they can do whatever they want with it. Paint it purple, break it up into a million pieces, give it to a friend, sell it to a stranger - the choice is theirs. A buyer does not need to check in with the original seller or get their permission. They own it.

Selling Cons

Of course, all of these benefits come at a cost. For the seller, it is a lack of control after sale. Maybe the seller doesn’t want a buyer to paint it purple, break it up into a million pieces, give it away, or sell it again. If the seller sold it, their opinion doesn’t matter. They lost control once the sale was complete.

Selling has costs for a buyer too. Once a buyer buys a good, they are on their own. They are on the hook to fix it, maintain it, or replace it if it turns out that it has a gaping security flaw.

Renting Pros

Renting (or leasing, or licensing) has its own set of tradeoffs. For owners, one of those benefits is ongoing control. If someone renting a house wants to paint it purple, the owner renting the house can tell them no. It’s still the owner’s house and that owner gets the final word.

Renting has benefits for renters as well. A renter does not own the thing they are renting. If it breaks, they can go back to the owner to get it fixed. Renters do not need to worry about regular maintenance in the same way that owners might (as Larry Summers may or may not have first said, ‘In the history of the world, nobody has ever washed a rental car.”) In some situations, the owner may even be obligated to maintain the thing being rented at a certain level. For example, landlords usually have an implied warranty of habitabilty that makes them responsible for maintaining the property so that it is livable for the tenants.

Renting Cons

The cons of renting are fairly straightforward. For owners, renting brings an ongoing obligation to maintain the thing being rented. Owners continue to be responsible for the thing during the period of the lease.

Correspondingly, renters lose control over how they use the thing being rented. Their use is still governed by the preferences of the true owner. That means that renters cannot do whatever they want - instead, they need to play by the owner’s rules.

Digital Choices

In a traditional marketplace, the choice between selling and renting feels like a true choice with various costs and benefits. Sometimes it makes sense to rent. Sometimes it makes sense to sell. Both options involve tradeoffs for everyone involved and there is no universally “correct” answer for either people putting goods on the market or people looking to acquire them.

That is not true in the world of digital goods. In the world of digital goods, it is almost always in the person marketing the goods’ interest to make them available to rent instead of selling them outright. Although digital goods are often framed as being “sold,” they are almost always licensed (read: rented) by the owner. Moreover, they are licensed on terms that allow owners to combine the pros of the sale and renting choices for themselves while forcing the cons of both on the people paying for them.

Pros for Owners

The digital lease model allows a seller to maintain ongoing control over how the digital good is used. That means restrictions on giving the good to others, reselling it, or any number of other things. At the same time, the terms of the licensing agreement can essentially eliminate any obligation to maintain the good over time. Security vulnerabilities, incompatibilities, and simple bugs are not the seller’s problem.

Cons for Consumers

Consolidating the benefits with owners means consolidating the costs with consumers. Consumers do not get to control the digital goods they pay for - owners can veto modifications, transfers, and anything else. Owners can even just turn the good off, or make it disappear altogether. At the same time, consumers also do not get any sort of protection against the failure of the good, or to rely on someone else to maintain it.

A Better Balance

It is easy to understand why someone offering a digital good would prefer this arrangement. It is less clear why this arrangement is something that we should support as a matter of public policy. Instead, we could work to restore the balance between owners and consumers by reviving the obligation to choose between selling and renting digital goods. This would recreate a meaningful choice for everyone involved in the transaction.

Keep Renting

Owners could continue to lease their digital goods, maintaining control over how they are used. However, that control would come at the cost of a duty to maintain the digital good over time.

What would that duty to maintain look like? For starters, it could include an obligation to patch known security vulnerabilities and maintain compatibility so that the good continues to be usable. These obligations are not impossible to meet. Today services such as Netflix or Spotify regularly update their software and release versions that are compatible with new (or updated) platforms as part of their service offering. It should probably not come as a surprise that these services clearly market themselves as rentals, where it is clear that cancelling a subscription means losing access to the service.

Meeting these obligations would look very different for digital goods that position themselves as something closer to being ‘sold.’ The version of AutoCAD someone paid for in 1997 is undoubtedly full of security vulnerabilities. It also would no longer run on generally available hardware. DRM-restricted music where the validation server has been taken offline is similarly of little value. If the owners want to maintain control over software, music, or other goods, they should also have a duty to maintain it for the term of the rental. That is true even if they decide that the rental extends into perpetuity.

Or Sell

Owners who want to avoid maintaining their digital goods into perpetuity have a simple alternative - just sell them. Selling the digital good should relieve the owner of any ongoing obligations to them. It would also mark the end of the seller’s ability to control what the buyer does with the good. Once the good was purchased, the new owner would be free to do whatever they want with it.

---

While I think it might be a useful way to think about what it means to own or lease digital goods, it doesn’t even qualify as the tip of the iceberg on this issue. If you are looking for a real place to start I recommend Aaron Perzanowski and Jason Schultz’s book The End of Ownership, and not just because I work with Jason at the Engelberg Center. You can buy a physical copy, or download your own open access copy.

Feature image: Riding a Giant Corncob to Market from the Smithsonian Open Access Collection

This post originally appeared on the Engelberg Center blog

The open source hardware response to COVID-19 was one of the few bright spots in the early days of the virus. Responding to shortages of equipment and supplies, informal, distributed communities came together to design, manufacture, and distribute a wide range of medical equipment where it was needed most.

Today the Engelberg Center, in partnership with the Wilson Center, is proud to announce Stitching Together a Solution: Lessons from the Open Source Hardware Response to COVID-19. Drawn from interviews and discussions with makers, organizations, and government regulators, this whitepaper explores how these efforts came together and details their challenges and successes. It then presents recommendations to help make better use of this flexible, responsive capacity during future crises.

The paper details how grassroots communities came together, often relying on existing ties and networks. It also examines how government regulators learned to interact with these communities in an attempt to support them. While the early months of the response shimmered with possibilities, the collective experiences during that period teach hard lessons and suggest ways to work better in the future.

There are many ways that governments and the open source hardware community can prepare now to support more effective emergency responses in the future. The report contains fifteen specific steps that authorities can take to guarantee that the capacity inherent to the open source hardware community is fully available when it is most needed. These recommendations focus on recognizing the capacity, expanding its capabilities, and preparing to use it more effectively in the future.

You can read the full report here.

This post originally appeared in Volume 75 of Make Magazine

It is appropriate that, ten years after the first Open Hardware Summit, open source hardware was a key part of the initial COVID response. Engineers, designers, and medical professionals collaborated from around the world to design and deploy medical equipment to meet the world’s unprecedented need.

In many ways, this is exactly what participants had in mind during the first open hardware workshop organized by Ayah Bdeir and held in the Eyebeam art space in October of 2010. They were not the first people to discuss open source hardware — open source activists like Bruce Perens had been advocating for open source hardware since the late 1990s. Nonetheless, that gathering helped lay the groundwork for the modern open source hardware movement.

The idea of open hardware does not exist in a void. It builds on decades of engineering, legal, and cultural work by the open source software community. In fact, most of the structures of the open source hardware community started as structures in the open source software community. While many of those central tenants remain the same, a decade of applying software’s ideas of openness to hardware has created a culture all its own.

By 2020, the Open Hardware Summit (virtual this time thanks to COVID) had grown into an international event, bridging together a community spread around the world.

Why 2010?

By 2010, two related trends began to converge. The first was the arrival of “good enough” hardware. Although things like processing power continue to increase rapidly, by 2010 hardware components did not need to be on the absolute cutting edge in order to do genuinely interesting and useful things. As articulated by Bunnie Huang at the 2011 Open Hardware Summit, this dynamic made it relatively easy for small businesses and groups of people to create compelling hardware without having access to multi-million dollar research pipelines.

This relative ease of creation helped spur the second trend: the emergence of a critical mass of companies and communities creating accessible, open hardware. Adafruit, Arduino, Evil Mad Scientist Laboratories, Makerbot, Reprap, Sparkfun — by 2010 these efforts were not isolated incidents. They were a budding community that validated each other.

That community quickly began to formalize itself. That initial workshop was quickly followed by a number of important milestones, including kicking off an annual Open Hardware Summit, creating an open hardware definition, agreeing on a logo, and, led by Alicia Gibb, establishing the Open Source Hardware Association (OSHWA) to house it all. A few years later, the Gathering for Open Science Hardware (GOSH) created a manifesto specifically for bringing open source hardware to the scientific community. All of this happened in collaboration and dialogue with the larger Maker movement, which was also growing.

Growth and Challenges

The needs of the open hardware community growed as more people joined. Once the community grew beyond a relatively small group of people with in-person connections, Phil Torrone realized that writing down the unspoken rules of open source hardware would make it easier for new people to join the community. Documenting the rules acted as an invitation to new community members, giving them confidence to navigate the collective expectations of open source hardware.

This period also helped to show that open source hardware theories also worked in practice. In a prelude to today’s COVID responses, the Safecast radiation sensor project organized radiation level tracking in response to the Fukushima Daiichi Nuclear Power Plant disaster. Open source hardware companies multiplied across a wide range of industries. While there were high profile stumbles — such as the flagship open source hardware company Makerbot going closed — the trend in open source hardware was towards growth and new applications.

That growth brought additional challenges. Although OSHWA maintained the community-created definition of open source hardware, no one owned the term ‘open source hardware’. The celebrated “open gear” open source hardware logo was similarly free from any one individual or organization’s control. While this openness brought a number of benefits, it also meant that nothing prevented decidedly not-open hardware from advertising itself as if it was open. This behavior — sometimes described as “open-washing” — threatened to undermine the term open source hardware and render it meaningless.

In response, OSHWA decided to create a new open source hardware certification program and certification logo. The free program gave open source hardware creators and users an easy way to identify open source hardware that met the requirements of the open source hardware definition. Regardless of how a piece of hardware was advertised, a certification logo meant that it complied with the community definition of open source hardware.

The certification program also gave OSHWA an opportunity to consolidate information about one of the other perpetual open source hardware challenges — licensing.

Licensing is one of the biggest differences between open source software and open source hardware. Software is “born closed” — automatically protected by copyright from the moment it is written. A piece of software is fully protected by copyright, meaning that anyone who wants to use it needs permission from the creator — a license. Over the decades, the open source software movement has capitalized on the born closed nature of software, using licenses to spread the requirements of openness beyond people with an inherent interest in openness.

In contrast, major parts of hardware are “born open” — not automatically protected by copyright or any other kind of right. While some parts of hardware may be protected by copyright, other parts may be free by default. This creates a much more complicated rights situation, making it much harder to understand when a license is necessary — and when a license can require other users to be open.

Although existing open source software licenses can be used to license portions of open source hardware, the community also created licenses drafted with the specifics of hardware in mind. Various licenses, such as the TAPR Open Hardware License, the Solderpad Open Hardware License, and the CERN Open Hardware Licenses emerged as options for the community. While these licenses do not necessarily clarify when a piece of hardware requires a license in the first place, they can help give the community confidence that — to the extent that they are necessary — the licenses will perform as expected. CERN’s recently released second generation licenses use “flavor of openness” designations to help make navigation even easier.

Open Source Hardware in 2020

Ten years in, the open source hardware community continues to grow. OSHWA’s certification program includes hardware from over forty countries on five continents. Open Hardware Month activities in October include a similarly international set of events. GOSH continues to help spread open source hardware in the international science community.

The global response to COVID vividly illustrates the importance of open source hardware approaches. Teams from around the world came together to rapidly create, innovate, and distribute a broad range of medical supplies to communities that needed them most. Their open approach allowed improvements and best practices to propagate quickly, and for communities to easily modify equipment as needed.

If 2010’s original open source hardware workshop was about exploring a theory of open source hardware, 2020’s open source hardware community proves that theory out every day.

The Next Ten Years

Open source hardware is all about collaborative innovation, so the next ten years will look very different from the first ten. While we cannot anticipate all of the challenges, some opportunities are clear:

Marking the path for open source hardware success. There are scores of examples of successful open source hardware companies. While they are beginning to highlight common factors for success, we are far from a playbook (or playbooks) for successfully creating open source hardware. Further distilling the lessons for open source hardware success will make it even easier for a broader open source hardware community to succeed.

Diversify Open Source Hardware. Although the open source hardware community is already an international one, it will continue to work to be a community that welcomes and celebrates members from a broad range of backgrounds and experiences. In addition to individual diversity, the open source hardware community will also work to incorporate more types of hardware and hardware applications.

Easier academic paths. Some of open source hardware’s strongest advocates are in academia. Unfortunately, it can be hard for traditional academic structures to recognize contributions to open source hardware. The academic portions of the open source hardware community continue to work to make sure that contributions to open source hardware are valued equally with contributions to less open projects.

More open components. One of open source software’s great strengths is that any given piece of open source software is built upon a number of open source libraries and other building blocks. The open source hardware community will work to build more open components, allowing open source hardware practices to extend deeper into the hardware world.

Keep growing the community. The open source hardware community has grown in the last 10 years, but there is plenty of room to keep going. As open source hardware becomes more common and accessible, the community will continue to expand, finding (and building) new ways to use open source hardware.

This post originally appeared as part of a series on open hardware and key messages for public policy hosted by the Journal of Open Hardware

One of COVID’s early victims was the medical supply chain. As the crisis spread in the spring of 2020, public health authorities began to report shortages of everything from plastic face shields to ventilators. In response, seemingly overnight and from nowhere, a distributed network of open source designers, manufacturers, and distributors — for example, Make4Covid, GetUsPPE, Makers Unite!, and Open Source Medical Supplies — emerged to fill the void.

This open hardware community was not a formal organization. Instead, it was made up of individuals with skills that made up pieces of the puzzle — a textile designer, an electrical engineer, a 3D printer in a makerspace — assembling themselves into an open production network. Using open hardware principles, they designed new equipment (sometimes from scratch), found ways to manufacture that equipment locally with digital production tools or crafting assembly lines, and distributed that equipment to the places that needed it most.

This response is a powerful validation of open hardware design concepts. By developing in the open, and in openly licensing their work, these individuals and networks were able to quickly iterate on designs. Improvements discovered in one corner of the network were quickly adopted across the network, resulting in a rapid convergence on the most effective approaches.

The response allowed society to respond nimbly to the COVID crisis. Informal, distributed networks were able to quickly design the equipment that was needed. That equipment was free to be produced locally in order to address localized shortages. Individual communities could also easily modify the open equipment designs in order to match local medical or manufacturing conditions. Sometimes these local modifications were contributed back to the collective. Other times they were only relevant to one place at one time.

The openness at the heart of open source hardware is what made this fluid response possible. Creators who contributed to collective designs could be confident that their work would not be removed from their control by an entity assering some sort of intellectual property ownership over it. Designs could be modified without negotiating licenses, or even identifying the original creators. Equipment could be manufactured by anyone without reporting to — or obtaining permission from — a central authority.

Although the open hardware response to COVID was extraordinary, there is reason to believe that it could have been even more impactful with more formal support from public health authorities.

Most of the early open hardware development was guided by a combination of the ad hoc interests of response participants and information gleaned from public reports of need by medical responders. This meant that the alignment between the demands of medical responders and the open hardware community was imperfect, leading to inefficiencies on both sides. Public health authorities could have improved the efficiency of the response by playing a matchmaking and information distribution role, clearly communicating need to the open hardware community and capacity to the medical community.

Similarly, the informal networks of open hardware designers, manufacturers, and distributors were not well matched to the existing regulatory frameworks that control some types of medical equipment. While this regulation is important and exists for good reason, public health authorities could have worked with the open hardware community and regulators to develop clear guidelines for how the open hardware community could work within frameworks. These groups also could have worked collaboratively to build new regulations that were most appropriate for the emergency conditions at the time.

As a result, the open hardware response to COVID stands as a tantalizing example of the power of open hardware in a crisis and an opportunity to prepare even more effective responses in the future. While we hope that COVID is a once-in-a-lifetime crisis, many types of crises strain our supply chains. By taking steps to recognize and engage the power of the open hardware community, governments, public health authorities, and emergency responders can enhance their capacity for flexible, effective response to crises in the future.

These steps can take many forms, but they all rely on the decision to take the power of open hardware seriously. Building connections with open hardware networks and government supply chains in advance of the next crisis, forging paths for communication between regulators and non-traditional creators, and making publicly-funded hardware available to open hardware communities will help to supercharge the open hardware response to the next crisis. Failing to take these steps will make it that much harder for the open hardware community to make a full contribution to crisis responses in the future.

update May 10, 2021: ml5.js formally announced version 1.0 of the license and code of conduct. You can read the launch post, the license, and the Code of Conduct. While a number of edits were made to the Code of Conduct during the review period, the final version of the licensing structure largely tracks what is described in this post.

Today the ml5.js team unveiled a proposal for a new license to impose ethical use requirements on their open source machine learning library. The community announcement is here. It is full of useful information about the context, purpose, and goals of the project so I encourage you to check it out. This post is intended to be a bit more focused on the license and license mechanisms themselves.

For context, ml5.js is a library that makes machine learning and artificial intelligence accessible to artists, creative coders and students. It is so easy to use that it even allows me to access things like style transfer and body tracking.

While access to powerful machine learning tools allows people to create amazing things, the ml5.js community also recognizes that it can be used for less socially productive applications. They reached out to the Engelberg Center and Tech Policy Clinic to see if there was a way to use their open source license to limit problematic uses of the library.

There is nothing new about attempting to introduce ethical obligations into open source software licenses. The conventional wisdom in open source software licensing today is that this is a bad idea. In part, this is due to the fact that it can be maddeningly hard to define ‘bad uses’ in a license in any robust, accurate way. In a way, this wisdom is codified in the fact that the Open Source Definition maintained by OSI (a prohibition against non-ethical uses would violate the “No Discrimination Against Fields of Endeavor” principle, among others).

Nonetheless, as the popularity of open source software has grown - and the community has become even more aware of the possible negative uses of software - there has been an increased interest in finding a way to mix ethical principles with an open source ethos. The Hippocratic License and Anti-Capitalist Software License are two recent examples.

Within this context, the ml5.js team decided to see if there was a way to bind its community to the ethical principles that they have worked hard to cultivate through the license on the software itself.

The ml5.js Approach

The proposed ml5.js approach relies on three main components:

1. Separate the license from the community Code of Conduct
2. Require recognition by a Code of Conduct Committee before a user is formally out of compliance with the Code of Conduct
3. License ‘decay,’ so that the enhanced obligations of the license decay into a more standard MIT license after three years.

Separate the License from the Community Code of Conduct

One major challenge with attempting to impose ethical obligations via open source software licenses is defining ‘bad.’ Terrorists can become freedom fighters, industrial tools can be used for war, and general purpose code can be used to discriminate against vulnerable communities. Even if one could define ‘bad’ at the moment of drafting, the length of copyright term means that today’s definition would need to apply in 50 or 100 years.

The ml5.js approach separates the license from an evolving Code of Conduct. The license obligates users to comply with the rules established in the Code of Conduct. The Code of Conduct can evolve over time. Equally importantly, the ml5.js community (which tends to skew towards artists and away from lawyers) tends to be more comfortable interpreting and amending Codes of Conduct than licenses.

This approach comes at the cost of legal ambiguity. An activity that is allowed today might become prohibited three, five, or even ten years from now. The excuse provisions in the license itself, as well as the Code of Conduct Committee described below, are designed to mitigate that risk somewhat. Nonetheless, they do not eliminate it. Ultimately, the ml5.js team decided that they were comfortable potentially alienating edge cases in service of making a clear commitment to ethical uses.

Code of Conduct Committee Review of Violations

ml5.js is made up of commits from individuals contributors. Each one of them licenses their code to users under the license for the ml5.js repo. Any one of them could potentially accuse a user of violating the Code of Conduct, which would mean the user was violating the ml5.js license. That could mean that one contributor’s fringe interpretation of the Code of Conduct could disrupt uses that the majority of the ml5.js community found acceptable.

In order to reduce this risk, and to smooth the interpretation of the Code of Conduct, the license requires that a Code of Conduct Committee made up of members from the ml5.js community agree that a user is violating the Code of Conduct before they fall out of compliance with the license. Although this is not a guarantee that the Code of Conduct will be enforced fairly and in a way that matches the ml5.js community’s expectations as a whole, it will hopefully reduce the heckler’s veto that the ambiguous nature of ethical concerns introduce to the process.

License Decay

The extended term of copyright protection can make trying to create a new license dangerous. A poorly thought out license can create problems for decades into the future. The license decay provision of the ml5.js approach represents an attempt to reduce two types of that danger.

The ml5.js library is made up of thousands of individual commits by individual contributors. For the first three years of an individual commits’ existence, that commitment will be licensed under the heightened ml5.js obligations. After three years, that license decays into the widely-used MIT license.

The first danger that this mechanism addresses is what would happen if ml5.js was abandoned by the community. As long as ml5.js is in active development, the ml5.js library as a whole will contain commits that are less than three years old. That means that anyone using the library will be bound to comply with the Code of Conduct. However, if active development ceases, after three years the ml5.js library will no longer contain commits that require compliance with the Code of Conduct and the license will effectively revert to the MIT license.

Additionally, the ml5.js license assumes the existence of a Code of Conduct Committee and, implicitly, of a community that is regularly updating the Code of Conduct itself. If development of ml5.js stopped, it is also likely that the Code of Conduct Committee would stop operating. Decay helps avoid fights over the interpretation of the Code of Conduct well after the Committee has dissolved.

The second danger is simply that this exercise turns out to be a horrible idea. The three year period allows the community to change course. After three years the legacy of this wrong path will be more or less erased.

Will This Work?

Will this approach work? It is hard to say. It is certainly something different. The approach is much more restrictive than traditional open source licensing. It also requires more administrative overhead to operate. As of now, the ml5.js team believes that these costs are worth paying in order to make a strong commitment to ethical uses of the library. The comment period is open now. If you disagree, we would love to hear from you in the repo, on twitter, on Discord, or via email at feedback@ml5js.org.

Oh, and one last thing. Huge thanks to the Blue Oak Council for their model license. Doing something like this is hard, and doing it in a way that the community understands is even harder. Their easy-to-understand license formed the basis of the license we are using. That being said, they do not endorse this idea and any problems that it creates are ours alone.