Open Source Hardware Weather Report 2020

"Open Source Hardware Weather Report 2020," (October 2020) (with Clarissa Redwine)

"Open Source Hardware Weather Report 2020," (October 2020) (with Clarissa Redwine)

Clarissa Redwine & Michael Weinberg, Open Source Hardware Weather Report 2020 (N.Y.U. Engelberg Ctr. on Innovation Law & Policy, Oct. 2020)

pen source hardware has blossomed in the past 10 years. In the decade since the first set of gatherings that would become the annual Open Hardware Summit, the open source hardware model has proven itself to be much more than an idea. Open source hardware projects form the basis of robust community initiatives, expansive scientific research, and multimillion-dollar businesses. The open source hardware community has developed a rich collection of organizations such as the Open Source Hardware Association (OSHWA), the Gathering for Open Science Hardware (GOSH), and the Community Bio Summit. There is no question that open source hardware works as a business, as a community, and as an approach to creating. One reason for open source hardware's success is that it is a diffuse, dynamic approach to creation driven by a diverse community. Although this diffuse nature is ultimately a strength, its diffuse nature can also make it hard to fully understand the state of the community at any moment in time. This resource-which we are styling as a weather report-is designed to address that challenge by capturing the current moment in open source hardware. Like a weather report, it describes current conditions and attempts to project into the future. This weather report documents the state of open source hardware at the end of 2020. Existing members of the community can use it to understand what is happening in other corners of the ecosystem, to help organize around universal challenges, and to collectively support opportunities. Newcomers to open source hardware can use the report to understand the current state of open source hardware, and to determine if an open source hardware approach fits well with their goals. This resource is styled as a report, not a book. It prioritizes identifying, organizing, and briefly introducing key concepts over exploring them in the fullest possible detail. That approach is intended to make it easy to use this resource to survey the state of open source hardware. Diving deeply into any element of open source hardware is beyond its scope. The open source hardware community is far from monolithic. In fact, not all communities that work within the open source hardware framework identify themselves as doing so. Even self-acknowledged open source hardware communities can come from different traditions, sometimes only slightly aware of one another. That can mean that some parts of the open source hardware community wrestle with problems solved long ago by others. Similarly, all too often, disparate corners of the community are working on the same problems in parallel without the benefit of sharing resources. Some people can become frustrated when they try to join the community and are unable to find a guide that allows them to learn from what came before them. This report is intended to begin a process of distilling information from disparate parts of the community into a common reference point. While no report can be fully comprehensive, identifying common successes and challenges can make it easier for the community to coordinate within itself. This report was originally designed to flow from an inperson workshop following the 2020 Open Hardware Summit. When the summit became virtual as a result of the COVID pandemic, the workshop became a series of one-on-one interviews with many of the original invitees, as well as other members of the community. The issues, questions, and challenges raised during these interviews formed the basis of this report. This weather report captures a shared moment within the sprawling open source hardware community. It identifies what works in open source hardware today, along with what does not work. Combined, these will help everyone understand when open source hardware can be effective-and when it is a poor match to an initiative's goals. It also identifies questions and roadblocks that are shared across the community. Hopefully that will make everyone struggling with those challenges feel less alone. It may also help the community coordinate to find solutions. We hope that this report will help identify areas of opportunity for the community to build consensus, tools, and platforms that support open source hardware. We also hope that it will help connect those disparate corners of the community to each other. Open source hardware is a tool. Like any tool, there are some problems that open source hardware strategies lend themselves to. There are others where open source hardware simply does not make sense. By capturing the state of open source hardware in 2020, we hope that existing community members can learn from their peers, new community members can find their way in, and former community members can find their way back. The open source hardware community is broad. It includes multi-million-dollar companies, one-person hobby projects, and many initiatives in between. While this diversity is a strength for the community, it can also create linguistic challenges. Although the use of "Open Hardware" vs "Open Source Hardware" once reflected two sides of a split within the community,foot_0 at this point most people use the terms interchangeably. This report follows that current convention and does not assign any relevance to the distinction. It can be complicated to identify the thing at the heart of open source hardware. Hardware can be too narrow because it fails to reflect the supporting documentation and code that make up a critical part of openness. Similarly, product can suggest a focus on commercial open source hardware at the expense of other parts of the community. While products make up an important, vibrant part of the open source hardware community, a commercial orientation is not required to be part of the open source hardware community. This report uses project to refer to the hardware, software, documentation, and community connected to a given piece of open source hardware. The term encompasses commercial offerings as well as non-commercial offerings. Similarly, the project team is the group of individuals who are primarily responsible for the project. The team may be within a company, an entire company, an NGO, an academic research lab, or an informal collection of individuals. This report focuses on open hardware. While open hardware can overlap significantly with maker and low-cost hardware, the terms and concepts are not interchangeable. These terms are also not universally defined. Open hardware is just that-hardware that is intentionally and purposefully open. Open hardware can be created by an enthusiast at home or by a multi-million-dollar manufacturing infrastructure. It is publicly documented and openly licensed, with source files and code available to all. Ideally, open hardware meets the community definition of open source hardware maintained by the Open Source Hardware Association. Maker hardware can be, but is not necessarily, open. It tends to be created using distributed manufacturing tools, and is often designed to be user-buildable and userserviceable. Maker hardware tends to be oriented away from large industrial supply chains and toward individual or small group creators. Low-cost hardware is defined by its cost. It may be open or closed, DIY or industrial. Its relatively low cost may make it more attractive to work with and deploy in challenging or resource-limited environments because it is inexpensive to replace. Although each of these types of hardware share connections, it is helpful to recognize their distinctiveness. Unlike "open hardware" and "open source hardware," they cannot be used interchangeably. 2010 was the year of a gathering that would become the annual Open Hardware Summit and the creation of the community-derived Open Hardware Definition. In 2012 OSHWA was formed as a home for the Open Hardware Definition and institutional organizer of the Open Hardware Summit. OSHWA also developed a collection of best practices and guidance documents for creating open source hardware in response to community feedback and questions. These documents became a common reference point for the community as it worked to develop open source hardware. The Open Hardware Summit quickly grew into an annual focus for the open source hardware community. By 2016, OSHWA had also designated October as Open Hardware Month to make it easy to hold local celebrations of open source hardware beyond the annual summit. These local celebrations included events around the world, featuring community members from an increasingly broad set of locations working within an increasingly broad set of contexts. 2016 also heralded the first Gathering on Open Science Hardware (GOSH) at CERN. GOSH's interests focus specifically on integrating open hardware into the sciences. The first meeting produced the GOSH manifesto, codifying the goal of reducing barriers between diverse creators and users of scientific tools to support the pursuit and growth of knowledge. The result of this history is a rich community of individuals, NGOs, and companies applying open source hardware principles to a wide range of challenges. Oftentimes one of its greatest challenges is speaking to itself. That is why this report consolidates information from a wide range of discussion into a single resource. Open source hardware can bring tremendous benefits when it is used correctly. Some of these benefits are obvious. Others emerge in time. The community is the not-so-secret key to most open source hardware projects' success. An open hardware project's community feels personally invested in the project. That can make the community a peerless advocate for the project, recruiting new users and identifying new uses. Communities are also challenging for competitors to copy. The open nature of open source hardware means that the community has an incentive to improve the hardware and contribute those improvements back to the project. Open licenses are designed to prevent project leaders from simply integrating community suggestions into proprietary products. The community can also be a buffer against competitors. Many open hardware projects survive in an environment where they compete against lower-priced competitors on the strength of their community advocacy and loyalty. Furthermore, open source hardware is not merely an invitation to modify or improve the hardware itself. A project's community is often the source of accessories, new applications, and complementary projects that expand the range of uses for the underlying projects. Open source hardware projects can become a defacto standard in their field. The players in a space feel confident building around open projects because their very openness eliminates the risk that the results of this collective effort will become unavailable in the future. Open source hardware gives everyone a common reference point that can evolve along with the needs of the community. An open standard allows everyone who relies on it to collectively improve the standard without fear of empowering a proprietary competitor. It can also allow everyone to create their own version of the standard without running afoul of restrictive licensing terms. One barrier to collaborative development is the fear that one's work will be "taken advantage of" by one player in the space. Open licensing can force all of the collaborators to play by the same rules, encouraging a sense of common mission that can inspire collaborative development. The very openness of open source hardware acts as a hedge against each collaborator's work disappearing behind a proprietary veil. Many successful open source hardware projects draw an explicit connection between their openness and the strength of their advocacy networks. The community built up around open source hardware is constantly looking for new applications and opportunities for the project. These communities are also often sources of support when disputes arise between open source hardware projects and competitors. This support can take a range of forms, from public advocacy to financial support. Open source hardware does not just happen. It requires real work on the part of the community supporting the project. Some of the most significant costs cited by open source hardware community members are: Open source hardware relies on open documentation. That includes schematics and design files for the hardware, software, and documentation. One key obligation of any open source hardware project is maintaining a publicly accessible repository of documentation related to the project. As discussed later in this report, there is something of a split in the community as to how significant of a burden maintaining public documentation places on the project maintainers. This split largely flows from how closely a project's internal workflow inherently mirrors what is required of public documentation. In some cases, Open Source Hardware Requires Real Investment maintaining public versions of documentation requires building an entire parallel infrastructure. In others, it simply involves making existing design documents public. Whatever the case, publishing and maintaining the public documentation will require some amount of resources from the project team. There are many examples of both open and closed hardware projects that rely on robust communities for their success. In both cases, these successful communities do not simply appear. Instead, they are the result of careful work and resources allocated by the projects. The importance of intentional community building is not a unique challenge for the open source hardware community. However, because community building is often a key element of open source hardware success, it is worth examining here. Most successful open source hardware projects rely on an active community to champion its use, provide feedback, and contribute improvements. These successful projects prove that it is quite possible to build successful open source, community-based projects. Community engagement can take a number of different forms depending on the nature of the project. Regardless of the form, cultivating and sustaining this community requires dedicated time from the project team. Open source hardware projects that overlook the importance of community engagement or view it as a secondary concern are rarely successful. Launching an open source hardware project without devoting resources to building and maintaining a community is similar to launching a product without dedicating resources to marketing. The project will exist in the world, but it is unlikely that users and customers will find it. Open and closed projects that rely on community engagement require dedicated resources to manage those communities. While open source hardware projects that intend to rely on communities must take steps to support those communities, those obligations are functionally identical to the steps that any community-dependent project needs to take. If the team does not have the resources to devote to community cultivation, neither an open nor a closed community-based strategy is likely to be successful. Closely related to community engagement more broadly, successful open source hardware projects tend to receive questions from their community. While these questions can help the project team identify problems, as well as improve the hardware and accompanying documentation, they can also divert resources away from the core development of the hardware itself. If the project team lacks the interest or capacity to handle questions (or even create a system to triage them), they are less likely to find open source hardware to be a successful approach. Similarly, scaling the capacity to answer questions should be part of any project's roadmap. That does not mean that the team needs to start with the capacity to engage with many more questions than they receive at the start. Instead, a structure for answering questions should be designed to scale the same way production and sourcing might-over time and in response to growth. Open source hardware is designed to be copied. This is key to its strengths in fostering community, collaboration, and diverse applications. However, it can also result in projects competing directly with copies. Successful open source hardware projects use many strategies to operate in a world with copies. Cultivating active communities, innovating faster than competitors, fostering a reputation for superior build quality, and developing exceptional user support are all ways to distinguish successful projects from their competitors. While each of these strategies can be successful, they require intentionality, resources, and time to implement. If these types of strategies-and other strategies highlighted in this report-are poor fits for a project, open source hardware may not be an appropriate strategy. Hardware is very different. Creating hardware relies on manipulating the physical world, which means navigating imperfections. Given the exact same design files, 10 different manufacturers will create 10 pieces of hardware that differ from one another in ways large and small. As a result, the manufacturer and distributor of hardware-the manufacturer and distributor of a given physical piece of hardware, not the creator of the original design-has more influence on the quality of an individual instance of that hardware than the distributor of software would have on an individual copy of the software. The entity responsible for the actual piece of open source hardware in your possession is much more important than the server hosting the open source software you download. Many successful open source hardware projects use this difference to their advantage. They cultivate reputations for high-quality manufacture, not just high-quality open source designs. Two providers of identical software may be reduced to competing on cost. Two providers of identical hardware will still compete on cost. However, they will also compete on build quality in a way that is not relevant in the software world. In addition to being perfect, reproducing software is also free. The lack of a marginal cost for software reproduction has created a wariness in the open source software community around selling software. This wariness also creates a generalized suspicion of payments connected to the use of open source software in many parts of the community. Although open source hardware shares a history and ideology with open source software, the two are distinct in meaningful ways. Understanding the differences between hardware and software is especially important for community members joining the open source hardware world from the open source software world. Creating perfect copies of software is easy. Every user who downloads a program creates a copy that is identical to the original and to every other copy. That means that anyone can become a distributor of a piece of software, offering perfect versions to all comers. In contrast, there are real marginal costs for reproducing hardware. Hardware is made up of stuff, and building and shipping stuff (as opposed to bits) costs money. Even an open source hardware project operating at cost will have to charge users (or raise funds) in order to get hardware to users. One result of this dynamic is that the open source hardware community is much more comfortable with the idea of charging for-and paying for-hardware projects. That comfort extends beyond simply covering costs into supporting the building of sustainable businesses. This is why open source hardware companies built on selling the hardware itself form a significant portion of the open source hardware community. It also provides a welcoming path for new members of the community hoping to create financially successful open source hardware. Because each piece of hardware needs to be physically assembled, scale can be much more important in the world of open source hardware than it is in open source software. The process of creating and distributing 5, 50, 500, or 5,000 copies of a software package is largely identical. In hardware, the processes for creating and distributing 5, 50, 500, or 5,000 pieces of hardware can be fundamentally different. Parts availability, assembly steps, and quality control processes can be very different, depending on how many pieces of hardware you are creating. As a result, it is much more important to plan for your initial distribution scale in hardware than it is in software. Open source hardware is well positioned to define a standard because everyone involved has equal control of it into the future. A community or industry that does not have mutual trust can work together to build an open standard that defines a collective, interoperable starting point for further innovation. One of the most prominent examples of this type of standard setting is the form factor and layout of the original Arduino microcontroller boards. The original Arduino's shape, size, and pin layout formed the basis of countless add-ons designed to sit on top of the Arduino. The open nature of the Arduino gave these additional builders confidence that, even if Arduino itself abandoned the shape, it would be easy for others to continue to manufacture boards that would be compatible with the accessories. Similarly, a new generation of "eather-compatible" boards, built to be compatible with the open source microcontroller boards developed by Adafruit, prove that standards can continue to evolve in the open community as needs and interests diversify. Openness has also fueled standardization in device interoperability across companies. Adafruit's STEMMA, Seeed Studio's Grove, and Sparkfun's Qwiic are largely mutually compatible ways to connect development boards, sensors, and other components. Open source hardware has also helped to standardize open source scripting languages to hardware. Circuitpython is now supported in a wide range of open source electronics, and the open source nature of those electronics makes it easy to adapt them for even more uses. There are also active projects bringing Go and Rust to electronics. The evolution from IDEs to scripting environments has made it easier for many creators to quickly move into hardware, and to shift between different platforms. Some hardware is specifically designed to be hacked, modified, improved, and torn apart. It assumes that its community has the technical skills to make modifications and the inclination to do so. Open source hardware is perfect for these kinds of communities. The documentation makes it easy for the community to understand how the hardware works and the licensing eliminates legal barriers to modifyingand distributing modifications of-the hardware. Open source hardware becomes a clear invitation to hacking communities to gather around the project and contribute to its evolution. Similarly, many open source hardware projects are explicitly designed to teach users about the hardware itself. Even if those users do not start with the skills required to modify the hardware, open documentation can help them explore its workings and understand how various elements work together. It can also incentivise learners, giving them the confidence that once they understand the hardware, they will be free to take it in new directions. This approach to teaching can be focused on the hardware itself by teaching users how a given piece of hardware operates. It can also be focused on teaching users broader concepts connected to hardware design and operation, with the open hardware itself becoming merely a tool toward that larger goal. Some open source hardware projects are designed to succeed by targeting higher-end, non-commodity markets. This approach is most successful for hardware that is technically complex to manufacture or calibrate. In those situations, even if competitors are able to access the schematics and technical information about a hardware project, few are likely to have the capacity to create the hardware with the level of precision it requires to work effectively, or to support it in a way that meets user expectations. Many users of this type of precision equipment are themselves technically sophisticated. As a result, they place a high value on openly available technical information about the hardware, and may take the opportunity to contribute improvements back to the project. When Does it Not Make Sense to Use Open Source Hardware? O pen source hardware is not always a successful approach. Projects with the following characteristics may find that the costs associated with sustaining an open source hardware project outweigh the benefits of the approach. Open source hardware allows a community of users to modify and expand the hardware in order to take it in new directions. However, not every project is targeting a market that values that type of flexibility. If a project is primarily geared toward communities who are unlikely to care about how the project works, let alone having the opportunity to modify it, the project may not be a good candidate for an open source-based approach. This is especially true because, in at least some cases, optimizing designs for openness can involve tradeoffs in other areas. If the users of the product are unlikely to engage with its open nature, the project may be better served by focusing on things that the users do prioritize. Although this is not a universally held view, some members of the open source hardware community have noted that maintaining accurate and useful public documentation distracted from the core mission of the project and diverted resources away from other priorities. While some projects embrace open source hardware in part to instill a discipline around internal documentation practices, other projects feel that rigorous public documentation requirements create an additional step in the engineering process. If your internal project documentation requires significant revision to be shared, and that revision process will draw critical resources from elsewhere, you may find that the open approach is not a good fit for the project. Project communities do not simply appear. Fostering a community requires a real investment of time and resources, both in its initial creation and ongoing health. Some projects see this role as central, of equal value to engineering and design. Others view community development as a competitor to more important priorities. If your project team is uninterested in investing in growing a community, that community is unlikely to develop. As such, the team should reflect on its community development prioritization before moving forward with an open source approach. If the team decides that community development is a distraction from the core of the project, an open approach may not be an ideal fit. When Does it Not Make Sense to Use Open Source Hardware? | 21 Some projects hope that simply "open sourcing" their hardware will create a market and community for the project. As with community building, open source hardware can be a key part of a marketing strategy. It cannot, however, be a replacement for a marketing strategy. Successful open source hardware projects still need to take the steps that any successful project takes, including marketing to communities and users. This report documents numerous ways that an open source approach can help develop and sustain a community. Nonetheless, that development and sustainability is not self-executing. Open source approaches are not a shortcut to success. There Are Unresolved Challenges in the Open Source Hardware Community T he open source hardware community is vibrant and growing. As it grows, engaging with a broader range of users, uses, and communities, it encounters new challenges. One purpose of this report is to help document the challenges that have largely been resolved. That allows everyone to learn those lessons quickly. Another purpose of this report is to identify challenges under active discussion within the community. At a minimum, that may help members of the community struggling with these challenges feel less alone. More ambitiously, documenting these challenges can make it easier for the open source hardware community to work together toward solutions. As discussed elsewhere in this report, there are divergent views about the burdens involved with publicly documenting open source hardware projects. Some view creating public documentation as a straightforward extension of good internal engineering and design principles. This view prioritizes the act of creating clean, accurate documentation as a necessary step in any design project. Under this view, both open and closed projects should be creating documentation that is immediately usable by others as a matter of course. Within this context, the public version of the documentation is essentially identical to the internal working version. This all but eliminates any burden associated with creating public versions of documentation. An alternative view understands internal documentation to exist at a significantly lower standard than is necessary for public documentation. This view does not prize creating complete internal documentation. In light of the state of internal documentation, the act of creating public versions of the documentation that are useful to community members outside of the project can be burdensome and distracting. The resources required to overcome this burden can prove to be a significant barrier to adopting an open approach. It may be that both of these views are correct, insomuch as they reflect two distinct, but equally viable, approaches to design. Nonetheless, the split is real and contributes to some level of frustration within the community. In some ways the correct approach for a given project is tied to the alignment between its internal style of documentation and its intended users. Unstructured internal documentation approaches for a project targeting beginners are likely to require significant additional work to create the public documentation. The same unstructured approach for a project targeting users comfortable with the technology may require significantly less preparation before being released. It is also possible to view open hardware as more of a spectrum. Open hardware that incorporates proprietary components can currently meet the standards of the definition as long as those components are generally available on the market without having to sign an NDA to access them. Should the community celebrate hardware that goes beyond that obligation, by striving to integrate (and even create) open components? Should that celebration be structured to avoid reducing the recognition of hardware that "merely" meets the definition's requirement? Would this approach further Closed hardware is hardware that is actively closed, where the creator does not share design files and uses property rights to exclude others. The third category, non-open hardware, identifies hardware where the project team has not taken intentional steps to embrace either approach. They may share some design files but have no systems in place to make sure that all design files are shared. While non-open creators may not openly license their rights, they also do not actively enforce their rights against others. The non-open hardware category encompasses a vast middle ground of creators, both casual and commercial. Someone who makes an identical, but lower cost, copy makes that hardware more accessible to more users. This accessibility comes at a cost-it may undermine the incentive to innovate in the first place or continue to innovate in the future-but it also brings benefits-the hardware is available in a way that it was not before. How should the community take this into account? Is it useful to distinguish between copies that exist in a richly collaborative ecosystem and copies that exist in an otherwise low-engagement community? Put another way, are mere copies less bad if other parts of the community are actively contributing back to the project? How broadly should the concept of "copies" be applied? Many successful open source hardware projects are replicated using locally sourced materials that differ from the original design. Should these localized versions be considered copies? If so, should the community approach them differently? his report captures open source hardware at a 10-year anniversary. The final section suggests some opportunities for the community in the next 10 years. OSHWA has taken significant steps to diversify the open source hardware community through the structure of the Open Hardware Summit. The summit itself was founded by two female engineers: Ayah Bdeir and Alicia Gibb. It has historically included a majority of women in leadership roles, especially Addie Wagenknecht, who chaired the summit from 2013 to 2018. In addition to being an early adopter of a code of conduct, the summit reserves approximately one-third of its entire budget for support of the Ada Lovelace Fellowship program. The Ada Lovelace Fellowship program began as a program to encourage women to participate in the community, and has expanded over the years to support a wide range of participation from historically underrepresented groups. The summit also structures and regularly evaluates its speaker selection process to promote a diversity of presentations. GOSH has also embedded principles of equity and diversity into its community from the start. It has centered these values through its manifesto and detailed code of conduct. GOSH has also held major events beyond the United States and outside of the global north, including in locations such as Chile and China. These foundational decisions have helped to foster robust regional communities, including AfricaOSH and, in Latin America, reGOSH. The open access movement has been incredibly successful in building openness requirements into major grants. Today many grantmakers require research papers to be licensed under Creative Commons licenses and data to be freely available to others. There is no reason that these types of requirements cannot extend to hardware funded by these same grantmakers. OSHWA's open source hardware certification program makes it easy for grantmakers to verify compliance with these types of requirements. Just as a Creative Commons license acts as a guarantee that research papers are openly licensed, an OSHWA certification can verify that any hardware created under a grant meets the requirements of the open source hardware definition. Open source hardware is already broad enough to make it a challenge to identify one "right" way to structure a project. Nonetheless, there are steps that the community can take to make it easier for newcomers to get started in open source hardware. One obvious approach is to create model repositories for open source hardware. These repositories can clearly structure hardware and software files. The readme files can structure documentation in a standardized way, as well as present licensing information in a common format. These model repositories would not be intended to become a required form for open source hardware. Nonetheless, they can help shape expectations by providing clear starting points for new projects and reference structures for projects interested in organizing data in a way that is clear for users. The open source hardware community is made up of people who can design and improve open source hardware. Today, the process of learning these design skills is an involved one. Most tools are proprietary and expensive, and free tools can lack usability and power features. This feeds a dynamic where only a relatively small portion of the community has the skills and tools required to contribute back to open source hardware projects. Many of today's open source hardware projects note that contributions to the hardware components of open source hardware are often dwarfed by the contributions to the project's software components. This is, at least in part, due to the larger number of community members with the skills and tools required to contribute to software. Making it easier to access and use hardware design tools could significantly expand the pool of people with the ability to contribute back to projects. Creating easy-to-use, powerful hardware design tools is no simple task. Nonetheless, doing so could fundamentally alter the contribution dynamic within open source hardware and greatly accelerate its growth. T he first 10 years of open source hardware have been incredibly successful. What started as a largely theoretical approach to hardware design has blossomed into a real, vibrant ecosystem and community. Open source hardware has proven itself to be flexible, adaptable, and robust. See the "Open Hardware vs. Open Source Hardware" section of OSHWA's open source hardware history: https://www.oshwa.org/research/ brief-history-of-open-source-hardware-organizations-and-definitions/ Engelberg Center on Innovation Law & Policy Open Source Hardware Weather Report 2020 Engelberg Center on Innovation Law & Policy Open Source Hardware Weather Report 2020Open Source Hardware as a Tool | 15 Open Source Hardware Weather Report 2020When Does it Make Sense to Use Open Source Hardware? | 17 Open Source Hardware Weather Report 2020 When Does it Make Sense to Use Open Source Hardware? | 19

The open source hardware community is broad. It includes multi-million-dollar companies, one-person hobby projects, and many initiatives in between. While this diversity is a strength for the community, it can also create linguistic challenges.

OPEN HARDWARE, MAKER, AND LOW-COST HARDWARE

This report focuses on open hardware. While open hardware can overlap significantly with maker and low-cost hardware, the terms and concepts are not interchangeable. These terms are also not universally defined.

Low-cost hardware is defined by its cost. It may be open or closed, DIY or industrial. Its relatively low cost may make it more attractive to work with and deploy in challenging or resource-limited environments because it is inexpensive to replace.

Open source hardware can bring tremendous benefits when it is used correctly. Some of these benefits are obvious. Others emerge in time.

An open standard allows everyone who relies on it to collectively improve the standard without fear of empowering a proprietary competitor. It can also allow everyone to create their own version of the standard without running afoul of restrictive licensing terms.

Open source hardware does not just happen. It requires real work on the part of the community supporting the project. Some of the most significant costs cited by open source hardware community members are:

Most successful open source hardware projects rely on an active community to champion its use, provide feedback, and contribute improvements. These successful projects prove that it is quite possible to build successful open source, community-based projects.

Open source hardware is designed to be copied. This is key to its strengths in fostering community, collaboration, and diverse applications. However, it can also result in projects competing directly with copies.

While each of these strategies can be successful, they require intentionality, resources, and time to implement. If these types of strategies-and other strategies highlighted in this report-are poor fits for a project, open source hardware may not be an appropriate strategy.

Hardware is very different. Creating hardware relies on manipulating the physical world, which means navigating imperfections. Given the exact same design files, 10 different manufacturers will create 10 pieces of hardware that differ from one another in ways large and small.

OPEN SOURCE HARDWARE IS NOT EXPECTED TO BE FREE (AS IN BEER)

Creating perfect copies of software is easy. Every user who downloads a program creates a copy that is identical to the original and to every other copy. That means that anyone can become a distributor of a piece of software, offering perfect versions to all comers.

As a result, it is much more important to plan for your initial distribution scale in hardware than it is in software.

Openness has also fueled standardization in device interoperability across companies. Adafruit's STEMMA, Seeed Studio's Grove, and Sparkfun's Qwiic are largely mutually compatible ways to connect development boards, sensors, and other components.

Many users of this type of precision equipment are themselves technically sophisticated. As a result, they place a high value on openly available technical information about the hardware, and may take the opportunity to contribute improvements back to the project.

When Encouraging Hackers When Designing to Teach or Train When Targeting a Non-Commodity Market

When it Targets a Community Primarily Interested in Non-Modifiable or Expandable Projects When Maintaining Public Documentation is in Conflict with Other Goals

If your internal project documentation requires significant revision to be shared, and that revision process will draw critical resources from elsewhere, you may find that the open approach is not a good fit for the project.

When Maintaining a Community is in Conflict with Other Goals

When Open Source Hardware is Viewed as a Replacement for Marketing

Is Open Source Hardware Documentation a Barrier to Opening a Project?

Should the Community Distinguish Between Levels of Openness?

his report captures open source hardware at a 10-year anniversary. The final section suggests some opportunities for the community in the next 10 years.

Be More Intentional About Diversifying Open Source Hardware

One obvious approach is to create model repositories for open source hardware. These repositories can clearly structure hardware and software files. The readme files can structure documentation in a standardized way, as well as present licensing information in a common format.

Creating easy-to-use, powerful hardware design tools is no simple task. Nonetheless, doing so could fundamentally alter the contribution dynamic within open source hardware and greatly accelerate its growth.

See the "Open Hardware vs. Open Source Hardware" section of OSHWA's open source hardware history: https://www.oshwa.org/research/ brief-history-of-open-source-hardware-organizations-and-definitions/ Engelberg Center on Innovation Law & Policy

Open Source Hardware Weather Report 2020

Engelberg Center on Innovation Law & Policy

Open Source Hardware Weather Report 2020Open Source Hardware as a Tool | 15

Open Source Hardware Weather Report 2020When Does it Make Sense to Use Open Source Hardware? | 17

Open Source Hardware Weather Report 2020 When Does it Make Sense to Use Open Source Hardware? | 19


" Pam Samuelson and the Emergence of the Technology Law and Policy Clinical Movement ," 39 Berkeley Tech. L.J. 1117 (2024)

"Pam Samuelson and the Emergence of the Technology Law and Policy Clinical Movement," 39 *Berkeley Tech. L.J.* 1117 (2024)

Jason M. Schultz, Pam Samuelson and the Emergence of the Technology Law and Policy Clinical Movement, 39 Berkeley Tech. L.J. 1117 (2024)

When I arrived at Berkeley Law in 1997 for my first day as a 1L, I had no idea that I was destined for a career in a field of legal education that had yet to come into being. But someone else on campus had already been laying the intellectual, institutional, and political groundwork for years: Pam Samuelson. My first introduction to Pam came through Laurel Jamtgaard, the incoming editor of the Berkeley Technology Law Journal. At one of our first meetings, Laurel announced that Pam was working with other leading academics to organize a massive multi-day conference on Article 2B of the Uniform Commercial Code (UCC). Article 2B was a model law drafted to provide a standard set of rules for regulating transactions in information products and services, similar to what Article 2 of the UCC tried to do for the manufacturing economy and commerce in goods. 1 The authors and supporters of Article 2B planned to submit these new rules for the information economy to state legislatures to enact into law. Further, with the Clinton Administration's recent publication of A Framework for Global Electronic Commerce touting internet commerce as the wave of the future for the global economy, Article 2B was poised to make state contract law "the world's preeminent law regulating transactions in information," as Pam would later write. 2 The conference was a tour deforce, dissecting the problems Article 2B posed to information policy, intellectual property, privacy, and other public interest concerns. It also laid out an exceptional agenda for pushing back on the law. As was typical of conferences that Pam helped organize, the speakers list was a star-studded group of scholars, practitioners, and policymakers. The conversations, presentations, and papers energized many of us in the audience. We knew we had not only come to the right law school, but also found inspiration and strategic ideas for how to make a difference on a topic near and dear to our hearts-law and technology. The event culminated in the publication of joint-symposium issues by the California Law Review and the Berkeley Technology Law Journal. Pam wrote forwards for both issues, outlining not only theoretical and doctrinal contributions from other leading thinkers such as Mark Lemley, David Nimmer, Michael Froomkin, Jessica Litman, Jane Ginsburg, Julie Cohen, and Rochelle Dreyfuss, but also several paths forward for policy debates and interventions. 3 As a student, it was exciting to be part of the event planning and publishing, but many of us felt a collective need for something more and something bigger. A watershed moment came for us on January 11, 1999. Professor Larry Lessig filed his complaint on behalf of internet publisher Eric Eldred in Eldred 1. Pamela Samuelson, Intellectual Property and Contract Law for the Information Age: Foreword to a Symposium, 87 CALIF. L. REV. 1 (1999). 2. Id. 3. Id.; Pamela Samuelson, Foreword, Symposium on Intellectual Property and Contract for the Information Age, 13 BERKELEY TECH. L.J. 809 (1998). v. Reno (Eldred v. Ashcroft on appeal), challenging the additional twenty years of protection that the Sonny Bono Copyright Term Extension Act had granted to copyright owners as both a violation of the Constitution's Copyright Clause and the First Amendment. 4 As part of his effort to garner legal support for the case, Lessig toured law schools to highlight his arguments. After a talk at Berkeley, there was a discussion of what, if anything, students could do to help. Lessig suggested that we contribute to Harvard's Openlaw effort, "an experiment in crafting legal argument [s] in an open forum" based on the philosophy of open-source software. 5 Eldred was Openlaw's first case; we could still address many topics by uploading our independent research and analysis. 6 Several of us, especially those of us who had taken Pam's classes, tried to make contributions, but we quickly found the experience frustrating and unsustainable. There was no structure, no supervision, no pedagogical model where our contributions both enhanced our learning and fulfilled the role of lawyering in the public interest. The case was exactly the type we envisioned working on in our careers, but it felt disconnected from the fight, an abstraction of learning and lawyering instead of in situ, real time, and representing a real client. At the same time, we noticed that many of our friends and colleagues working on other public interest issues were having a very different experience. They were enrolled in clinics such as Berkeley Law's East Bay Community Law Center, Death Penalty Clinic, and International Human Rights Clinic. 7 In these clinics, they represented real clients and worked on live issues directly under the supervision of faculty. The issues they were working on were just as impactful, albeit in more traditional legal domains. But the most striking differences were pedagogical. As clinic students, they were able to build on their understanding of theory, doctrine, and policy through direct legal work. They could receive regular feedback and practice iteration with experts in the field. In essence, they were able to begin their careers in their chosen areas before graduation, which put them on the path not only to make a greater impact but also toward becoming leading thinkers and advocates across the issues they cared most about. Thus we began to see the way forward-forming a clinic of our own. The task of creating the first technology, law, and policy (TLP) clinic, however, was not simple. In traditional areas of social justice, clinics had been around since the 1970s. 8 Technology law, and especially intellectual property law, was commonly seen as "private law"-the domain of corporations and other commercial actors. Even though the social welfare benefits of information infrastructures such as the internet became obvious by 1999 and we had already seen digital public interest organizations such as the ACLU, Electronic Frontier Foundation, Center for Democracy and Technology, and Electronic Privacy Information Center advocate for these benefits in Congress and the Courts, our initial conversations with various law school clinical programs unearthed substantial skepticism. 9 Would students work on important social justice issues? Or would they simply represent private interests such as startups wanting to raise money? Would students learn what they needed to pursue careers as public interest TLP lawyers? 10 Or would they simply log the equivalent of pro bono hours until they went to work for profitoriented private law firms? And how would TLP clinics integrate into the broader social justice clinical community and contribute to the growth and development of the field as a whole? These were just some of the questions that my student colleagues and I began to discuss as the idea for a TLP clinic at Berkeley gained traction. To help answer them, we reached out to several members of the Berkeley Law faculty, all of whom were supportive. Pam quickly emerged as our champion. To no one's surprise, Pam had already been thinking about the possibility of a TLP Clinic. She had already been laying the groundwork across the faculty, connecting the substantive issues (especially in intellectual property and information law) with the public interest vision of the program. She had also already begun working together with the Berkeley Law clinical faculty, including Charles ("Chuck") Weisselberg (the head of the Berkeley Law clinical program at the time), to build the case for integrating a TLP Clinic into the larger program. Together, we developed a blueprint for a public interest TLP clinic. First, we dedicated the clinic to public interest clients-no startups, no corporations, no VCs or profit-oriented inventors. Our work would focus on the needs of those whose voices who were underrepresented or disaggregated in tech law and policy regulatory, litigation, and legislative proceedings. These clients included librarians, grassroots activists, social justice NGOs (especially those without expertise in the technology domain), academic researchers, journalists, individual artists, and privacy advocates. We also committed the clinic to work on issues that would have a positive social impact beyond the individual clinic clients. For example, a case protecting one client's constitutional right to online privacy helped protect all our rights to online privacy. Or a case fighting for fair use for librarians or online critics would create breathing room for anyone who made similar uses of copyrighted works. Much like Pam's framing of the Article 2B conference and subsequent publications, the clinic would take on the fights that would help shape the best rules and protections possible for the future of technology and society, especially for those who couldn't afford the legal representation that most corporations and governments regularly brought to the table. Finally, we worked to design the clinical pedagogical experience to mirror that of other tremendous clinical programs, both at Berkeley and across the country. The clinic's commitment to take on important issues on behalf of clients in need was critical to creating true experiential educational opportunities, as was putting students in the role of lead attorneys to run the cases under the supervision of experienced expert practitioners. TLP Clinics, also faced the added challenge of working on issues involving new technologies that were often nascent, where evidence on various harms and policy considerations was difficult to find let alone marshal. Here, again, Pam provided much-needed mentoring and support. Pam built much of her scholarly career on identifying and dissecting key TLP issues as they emerged. She helped lay out the case for how TLP Clinics could not only intervene in key fights in a timely manner, but also how they could get ahead of important conflicts and policy choices to help shape themselves in their earliest stages. And the rest, as they say, is history. In 2000, the faculty voted to create what would soon be named the Samuelson Law, Technology, and Public Policy Clinic (SLTPPC). Today, there are over thirty TLP clinics worldwide, including at most major law schools that have a significant TLP faculty presence. 11 Berkeley Law's Samuelson Clinic is about to celebrate its twentyfifth anniversary. Hundreds of law students every year now work on TLP issues as a regular part of their legal education, and thousands of alumni have built careers based in part on having experience as TLP student attorneys. 12 One of the keys to building this successful movement was understanding early on how important it was to have strong connections between clinical and nonclinical TLP faculty at every school. Those strong alliances, which Pam helped foster both at Berkeley with the SLTPPC and at other schools where she helped start TLP clinics, would often prove decisive in the success and sustainability of the TLP Clinic movement. Notably, this also proved true for the Eldred case. By the time it reached the U.S. Supreme Court, the Berkeley SLTPPC was there to help file an amicus in support of petitioners' arguments, something Berkeley Law students could never have achieved alone. 13 Yet Pam's contribution to the TLP clinical education field goes far beyond her vision and support at its moment of origin. For the last quarter century, Pam's scholarship, organizing, and advocacy helped pave the way for numerous areas of TLP clinic work. In her writing, teaching, and public talks, she would often lay out the road map for what was needed in a given area, highlighting gaps and key voices and positions missing from the debate. Many movements look to intellectual architects to help identify key opportunities. Through her teaching, scholarship, and advocacy, Pam provided this 11. For an early snapshot of these developments, see Christine H. Farley, Victoria Phillips, Joshua Sarnoff & Ann Shalleck, Clinical Legal Education and the Public Interest in Intellectual Property Law, 52 ST. LOUIS U. L.J. 735 (2008). 12. Pam and her husband Robert Glushko would eventually help personally establish five other clinics, including ones at Colorado, Fordham, Ottawa, Amsterdam, and American University in Washington D.C. Years later, many of us would recount how the Berkeley Law technology faculty, and in particular Pam, had helped so many of us grow into public interest technology lawyers. We affectionately referred to ourselves as Samuelson's Army, a reference to "Dumbledore's Army" in J.K. Rowling's Harry Potter Series. Just as Harry and his classmates took inspiration from their mentor and teacher to form their own peer-led educational cohorts, so too had dozens of us followed Pam's lead to not only fight for TLP public interest values but also to dedicate ourselves to building out the TLP field, especially as part of law school clinical education. See, e.g., Clinic Alumni, BERKELEY L., https:// www.law.berkeley.edu/experiential/clinics/samuelson-law-technology-public-policy-clinic/ about/clinic-alumni/. 13. Brief for Eldred et al. as Amici Curiae Supporting Petitioners, Eldred v. Ashcroft, 537 U.S. 186 (2003) (No. 01-618), 2002 WL 1059714. leadership for the TLP Clinic movement. Below are several domains where she has had a profound and undeniable impact. When Congress began debating digital copyright reform in the mid 1990s, Pam was well in the middle of it. She wrote many articles on various proposals from the 1994 U.S. National Information Infrastructure Take Force's Report on Intellectual Property Rights to the Clinton Administration's Framework for Global Electronic Commerce to the draft and eventual enactment of the Digital Millennium Copyright Act (DMCA) of 1998. 14 The DMCA included several controversial provisions, but among those especially subject to Pam's searing critique were the anti-circumvention regulations. 15 An unprecedented "Copyright Grab," as Pam would pithily coin in an early issue of Wired Magazine, the DMCA sought to overturn decades of consumer and competition-friendly copyright decisions, including important fair use precedents such as the canonical 5-4 Sony v. Universal decision, upholding the legality of the Betamax VCR. 16 Section 1201 of the DMCA was particularly nefarious. The law sought to outlaw the distribution of technologies that could decrypt digital content (DVDs being the main example at the time), even if their primary or intended use was lawful-such as making a backup copy or compiling film clips for classroom teaching. 17 This entirely new form of legal power allowed copyright owners to reverse the Sony Betamax "capable of substantial noninfringing use" rule for digital content, sacrificing the beneficial lawful uses of multimodal devices in favor of protecting copyright owners against potential harm no matter how remote or inconsequential. In her powerful and prescient article, Intellectual Property and the Digital Economy: Why the Anti-Circumvention Regulations Need to be Revised, Pam laid out the arguments why Section 1201 was bad news for copyright policy and the strong need for pushback to protect lawful uses, including uses for consumer enjoyment of digital media, education, commentary, research, and technological interoperability. 18 Following the creation of the TLP Clinical movement, amicus briefs in Section 1201 cases and participation in the Copyright Office's triannual exemption process became the bread and butter of many clinic projects. For example, in the case of Skylink v. Chamberlain, SLTPPC filed amicus briefs on behalf of Consumers Union in both the District Court and Federal Circuit proceedings. 19 The case, which centered on whether it was a violation of Section 1201 to sell universal garage door remotes that could work with proprietary garage door openers, raised many of the fundamental public interest concerns Pam had identified in her 1999 paper. 20 Chamberlain, the proprietary manufacturer of garage door openers, claimed that competitor Skylink was trafficking in a copyright circumvention tool by selling universal remotes to Chamberlain customers that were capable of activating the copyrighted software that opened their garage. Yes, that's right. According to Chamberlain, opening your own garage door with a third-party universal remote violated Section 1201, at least according to Chamberlain. The Berkeley Clinic's briefs took this case from a consumer and competition perspective. The briefs argued that to allow Chamberlain to misuse Section 1201 in this manner and block aftermarket products like universal remotes would give their clients a monopoly that copyright law never intended to provide and would undermine the rights of consumers who legitimately bought their openers to use whichever remote they pleased. Moreover, the briefs anticipated a key fight that Pam had flagged. As more and more consumer devices ran on embedded software, companies would look to Section 1201 as legal leverage to "lock in" their customers and prevent them (or any third-party providers) from improving, repairing, or even maintaining their devices. 21 Fortunately, both the District Court for the Northern District of Illinois and the Federal Circuit ruled against Chamberlain. The courts interpreted Section 1201 to protect consumers and competition and held that for a copyright owner to bring a claim under Section 1201, there must be some "nexus" between the access control circumvented and copyright infringement. 22 Since opening a garage door didn't infringe any Chamberlain copyrights, Skylink emerged victorious, as did the core principles of competition, innovation, and consumer protection the Clinic had fought to preserve. But the courts were not the only venue where TLP Clinics found purchase when it came to Section 1201. The DMCA also contained a triennial rulemaking administrative exemption process whereby the Copyright Office could recommend that the Librarian of Congress exempt certain classes of users or works from Section 1201's anti-circumvention access prohibition when necessary to preserve socially valued noninfringing uses. 23 While this administrative process theoretically offered a chance to protect many of the important lawful uses Pam had identified, the time, energy, and funds needed to undertake this process proved prohibitive for most noncommercial users, including libraries, educators, and the general public. For TLP clinical students, on the other hand, it was an ideal pedagogical opportunity. Each exemption request offered a chance to build a case from the ground up, gathering key facts and evidence to support the lawful use exemption requested. It also offered students the chance to understand the unintended consequences and real-world impact of Section 1201 on vulnerable and under-resourced populations. As a result, over the last 25 years, TLP Clinics have helped successfully secure dozens of Section 1201 exemptions for security researchers, educators, consumers, disability advocates, repair enthusiasts, and many others. 24 22. See Chamberlain, 381 F.3d at 1178. This precedent was further reinforced in StorageTek v. CHE, where a manufacturer of magnetic library tape systems attempted to use Section 1201 to shut down independent repair services from fixing and maintaining customer's systems. Again, the Federal Circuit found there was no nexus with copyright infringement and that the public interest favored both the rights of the customer and competition in the repair market. Storage Tech. Corp. v. Custom Hardware Eng'g & Consulting Inc., 421 F.3d 1307 (Fed. Cir. 2005). 23. The anti-circumvention access prohibition focuses on preventing methods of circumventing any technological protection measure designed to control access to copyrighted works, such as methods of encrypting movie or music content. 17 While the singular focus and short life cycle of amicus briefs have long been seen in clinical pedagogy as an excellent learning vehicle for students, the ability to participate in the 1201 triennial process has provided an especially vibrant opportunity for TLP clinical education. It allows students to study and understand not only the core administrative law and copyright questions but also many of the public policy issues Pam and other scholars identified during the debates before and after its passage. Clinic students have then had a chance to represent actual voices in those post-passage debates and proceedings, counseling them on those questions, filing exemption requests and replies on their behalf, and even representing them in proceedings before the Copyright Office, combining substantive knowledge, policy savvy, and advocacy skills. Dumbledore's army indeed. Anyone who knows Pam's work is well acquainted with her myriad of interventions to help bring reason and public interest perspectives to the Book Search battles of the 2000s. It began when Google announced The Google Books Library Project, a collaboration with some of America's most prominent academic libraries to scan millions of physical books from their collections in order to provide better online book search results and, in return, provide each of those libraries with a single digital copy of each physical book they loaned to the project. 25 The libraries, in turn, formed their own collaboration entitled HathiTrust, to produce a shared digital collection for enhancing search and access, especially access to those with visual disabilities. As a result, both the Authors Guild and members of the American Association of Publishers (AAP) filed lawsuits against Google, and the Authors Guild filed an additional lawsuit against HathiTrust, claiming that mass digitization of lawfully purchased books to achieve these goals infringed the copyrights. Meanwhile, Google and HathiTrust both claimed their activities were noninfringing under the fair use doctrine. Pam's work on this topic spans volumes and nearly a decade. 26 It also spawned numerous opportunities for TLP clinical education and intervention. After Pam identified a range of public interest issues at stake in the litigation (and subsequent settlement proposals), there immediately arose a need for the groups who cared about those issues to have representation in those forums. For example, when Google, the Authors Guild, and the Publishers proposed a settlement in their case, Pam quickly gathered many stakeholders for discussions of the over 300-page proposal. 27 Critics raised concerns, including privacy, competition policy, access to "orphan" works, and adequate class representation of all authors, not just those who were members of the Guild. When objections were filed to the settlement, a number of TLP Clinics participated. For example, the Berkeley Clinic worked with the Electronic Frontier Foundation to file an objection on behalf of authors and publishers who published books on controversial or sensitive topics such as abortion, sexuality, or domestic violence. 28 In the settlement, there were no privacy protections in place to prevent Google from collecting and analyzing reader activity from every single page of those books. That data could be very dangerous for many readers, especially if subpoenaed by law enforcement, abusers, or political attackers, and the lack of privacy protections in the settlement could potentially deter readers who needed access to those works from purchasing those books-a chilling effect on the economic and social interests of the authors and for society as a whole. The EFF/Clinic objection brought these concerns directly to the judge in charge of approving or denying the settlement. In terms of class representation, Pam was among the first to identify a clear difference between the interests of the Authors Guild (which represented mostly commercial/trade authors) and those of academic and other authors who, while interested in commercial success, prioritized access to their works over profits. This was a key weakness of the settlement, which had been oriented around the Guild's narrow perspective on the publishing world, claiming that the Guild represented the overwhelming majority of author interests as a class. This was a key weakness of the settlement. While the Guild claimed that it represented the overwhelming majority of author interests as a class, the Guild instead had a narrow perspective on the publishing world. As part of highlighting the equally important but underrepresented authors focused on access, Pam spearheaded the formation of the nonprofit Authors Alliance, which has become a mainstay client of TLP Clinics, bringing an alternative voice to balance out the dominant voice of the Authors Guild in litigation and policy debates writ large. 27. Pamela Samuelson, The Google Book Settlement as Copyright Reform, WIS. L. REV. 479 (2011). 28. Authors Guild v. Google, Part I: Proposed Class Action Settlement, ELEC. FRONTIER FOUND., https://www.eff.org/cases/authors-guild-v-google. Disabled readers and their advocates were another set of voices that grew louder in the Book Search cases with help from TLP Clinics. 29 These voices have always been part of a larger debate around access to technology and digital materials, but through work on Section 1201 and digitization of books, these connections became much stronger and have led to greater engagement in advocacy as well as scholarship. 30 After co-directing the SLTPPC from 2007-2013, I founded a new TLP Clinic at NYU Law. One of my very first clinic projects was an amicus brief in Alice Corp. v. CLS Bank. 31 TLP Clinics now regularly file amicus briefs in all types of cases, but none had ever participated in patentable subject matter cases before Pam helped start the TLP Clinic movement. Like so many other fertile areas of public interest work for clinics, Pam was among a unique set of scholars who laid the groundwork in this area. As early as 1990, in her influential article, Benson Revisited: The Case Against Patent Protection For Algorithms and Other Computer Program-Related Inventions, Pam questioned whether and how patent law could be appropriately applied to information and algorithmic processes. Decades later, the Supreme Court began to show a renewed appetite to take on these questions, especially as the Federal Circuit Court of Appeals struggled to apply the holdings in Bilski v. Kappos and Prometheus v. Mayo consistently and often upheld patenting of basic business methods and abstract software processes despite the Supreme Court's skepticism that these were value patentable subject matter. 32 In Benson Revisited, Pam laid out the strong case against the patentability of algorithms and software generally, especially for general purpose computing. When the Supreme Court agreed to take the Alice case, it was a prime opportunity to write a brief pulling together her work on the subject as well as numerous other business, law, and economics scholars. The students working on the case were among my first ever class of TLP clinic students at NYU. It was an exciting opportunity for them-one that most had never even thought possible when they applied to law school. The ability to combine their substantive patent law coursework (taught by the iconic Rochelle Dreyfuss) with the empirical and analytical scholarship of interdisciplinary experts before the Supreme Court was a first for NYU students, and the beginning of a decades-long dedication to IP amicus filings at NYU along with numerous other TLP clinics around the country. Another area where Pam's scholarship and TLP clinic work have strongly aligned has been around access to justice in copyright disputes. For example, in the last decade, there have been significant debates over the cost of enforcement for copyright violations (especially online) as well as the draconian penalties that could be imposed on infringers for even minor violations. 33 Among the later criticisms was a highly influential paper by Pam and Tara Wheatland (a former SLTPPC student), Statutory Damages in Copyright Law: A Remedy in Need of Reform, which noted, among other problems, the fact that courts would award the upper range of statutory damages (from $30,000 to $150,000 per infringed work) on occasions where evidence of actual harm was 32. Compare Ultramercial v. Hulu, 657 F.3d 1323, 1330 (Fed. Cir. 2011) (holding that a claim for showing advertisements to pay for content distribution over the internet was not "so manifestly abstract as to override the statutory language of section 101"), with Bilski v. Kappos, 561 U.S. 593, 602 (2010), and Mayo Collaborative Servs. v. Prometheus Lab'ys Inc., 566 U.S. 66 (2012) scant, despite those awards being intended by Congress to apply only in "exceptional cases" of willfulness. 34 The paper also criticized the general lack of proportionality and due process in statutory damage awards. 35 As a result of these and other criticisms, and at the urging of Congress, the Copyright Office undertook a study around mechanisms for helping resolve "small copyright claims" and to report back by the end of September 2013. 36 The report included draft legislation proposing the creation of a small claims tribunal system within the Office to adjudicate small copyright infringement claims. This report led to much debate and eventually to several House bills in 2016 and 2017 to implement the U.S. Copyright Office's proposal as part of the Copyright Alternatives in Small-Claims Enforcement (CASE) Act. One of the key provisions being that claimants could only seek damages under $30,000 for copyright violations. Of course, this still left the problem of excessive awards in the Courts, but at least the upper limit had been capped in the new tribunal. In the ensuing debate over the CASE Act, Pam was actively involved, hosting several workshops of the merits of the proposal and eventually publishing Scholarly Concerns about a Proposed Small Copyright Claims Tribunal with Kathryn Hashimoto, a paper documenting and synthesizing comments from eighteen scholars specializing in economics, civil procedure, and intellectual property law. These concerns broke down into roughly six categories: (1) constitutionality concerns, (2) jurisdictional concerns, (3) due process concerns, (4) potential for abuses, (5) underexplored alternatives, and ( 6) larger questions about the proposal, including whether copyright was so exceptional as to deserve its own small claims tribunal when compared to other federal court claims. Nonetheless, Congress passed the CASE Act in 2020 and it was signed into law by then-President Donald Trump. Subsequently, the Copyright Office issued a Notice of Proposed Rulemaking (NPRM) on law student participation in front of the Copyright Claims Board (CCB). This alone was a huge recognition of the impact that TLP clinics had on copyright law, including through their participation in the 1201 exemption proceedings. In response to the NPRM, thirteen TLP clinical faculty members filed a comment outlining a range of concerns about the Office's approach to 34. Pamela Samuelson & Tara Wheatland, Statutory implementing a process for law student participation in the CCB. 37 Drawing from several of the critiques in Scholarly Concerns as well as decades of research and scholarship on clinical pedagogy, we noted that the structure of the CCB's "opt-out" provision could result in situations that limited access to justice for clients with limited financial resources (those likely to be clinic clients) and greatly diminished the pedagogical learning opportunities that the CCB could offer for clinic students. 38 Given the general advantages of litigating copyright claims in federal district court, we noted how clinic students would often be strategically and ethically obligated to recommend that their clients "opt-out" of the CCB process, thereby undermining its goals of increasing access to justice. The ability to marshal these arguments both as experts in substantive copyright law and clinical pedagogy would never have been possible without the alignment of scholars like Pam with the approach of the TLP clinical movement. Another important way that Pam has contributed to the TLP Clinical movement is through co-authoring amicus briefs with clinic students. One of the most important cases where this occurred was the decade-long copyright litigation between Oracle and Google over the JAVA API code that was reimplemented in Google' Android operating system. The case involved many of the core copyright issues that Pam had written about for decades-the scope of copyright for functional computer code, the idea-expression distinction and the merger doctrine, the unprotectability of methods of operation, and the application of fair use to code where technological interoperability and compatibility were at stake. 39 As the case proceeded through multiple stages of appeal, Pam was able to work side-by-side with the SLTPPC faculty and students not only to bring together an exacting and strategic set of arguments around the copyright doctrines and policies at issue in the case, but also to help recruit numerous other well-respected intellectual property scholars to sign onto the brief, including over 72 signatories in the merits amicus before the Supreme Court. 40 Scholarly amicus briefs in significant technology law cases are now common, with numerous TLP clinics representing and often co-authoring with scholars to bring their research and understanding of the law before various courts. Pam's efforts in the areas of patentable subject matter and issues covered in Oracle v. Google represent just a few examples of many such collaborations where Pam's leadership, insight, and dedication to both public interest issues and student learning have helped establish this field-defining practice. Today we are in the midst of yet another major copyright crisis-this time over artificial intelligence. The rise of generative AI has raised serious issues for copyright communities, from questions of authorship to what is a protectable expression to who is a volitional actor when an AI-generated work allegedly infringes a prior work. 41 Without a doubt, many of these issues will be resolved among the countless court cases, Copyright Office proceedings, and legislative efforts circling AI at the moment. 42 Left to the moneyed interests, most of the participants in these forums will be primarily the titans of content industries (such as the major publishers, Hollywood, etc.) versus the dominant AI technology companies, such as Microsoft, OpenAI, Google, Facebook, and Amazon. But so much more is at stake than just those points of view. The perspectives of independent artists, academic researchers, as well as libraries and other cultural institutions are equally important. For example, how will we be able to study the biases, geopolitics, and other sociotechnical concerns surrounding AI unless researchers and investigative journalists have equal access to datasets and AI models as technology companies? 43 With strict copyright rules that do not allow for fair use, these important insights could easily be inhibited. Constitutionally, U.S. Copyright Law is meant to reward authors to provide incentives to create. 44 Yet algorithms do not have incentives. They have instructions, they have objectives to optimize, and they have outputs to produce. Questions of competition policy and interoperability have also risen as central policy themes, especially in jurisdictions such as the European Union, which is the first major governmental entity to pass comprehensive AI legislation while at the same time attempting to foster a nascent AI industry to compete with the US and China-dominated providers. There are also key questions about the viability of "open' AI copyright resources such as opensource models and open datasets. 45 TLP Clinics will need to play a pivotal role in helping to broaden the issues to see the impacts of AI from a more broad and diverse perspective. Once again, Pam is among the leading scholars marking the way. In the area of computational authorship, her 1986 article, Allocating Ownership Rights in Computer-Generated Works, outlined the copyright conundrum concerning the creation of copyrighted works by machines. 46 Almost four decades later, this conundrum is now at the heart of U.S. copyright policy, with the US Copyright Office currently rejecting many registration applications for AI-generated works that fail to define the delineations between what is machine-authored and what is human-authored. 47 Pam has also written on the fair use implications and pulled together several workshops. As these issues move forward in the courts and policymaking circles, there will be no shortage of work for TLP Clinics. And there will be no doubt that Pam's involvement will be key in helping to shape the debates, the public interest perspectives, and numerous valuable learning opportunities for TLP clinic students. As the field of TLP Clinical Education approaches its twenty-fifth year, we are entering a complicated and increasingly challenging terrain. Discrete arenas of doctrine, such as intellectual property, privacy, or First Amendment protections are no longer occasional isolated issues intersecting with one or two new technologies in discrete instances. Instead, as technologies expand across every aspect of our society, the need for public interest voices and advocates working on these issues couldn't be greater. At the same time, this intersection intensifies the connection between classic TLP issues and a broader set of social concerns such as racial justice, labor, environmentalism, etc. 48 Thus, TLP clinics are at a turning point. No single clinic can now handle the entire TLP docket-technology is everywhere, impacting almost every area of law. The TLP movement needs to evolve beyond a single-clinic model to embrace both TLP issues in other clinics and multiple TLP clinics within each law school. Much like Pam, we cannot and should not limit ourselves to specific doctrines or specific technologies but instead see the broader public OF LAW, https:// ipclinic.org/clients/policy-advocacy-regulatory-filings/ (online learning exemptions for film, medicine, computer science, etc.). 35. Samuelson & Wheatland supra note 34. 36. See Remedies for Copyright Small Claims, U.S. COPYRIGHT OFF., http:// www.copyright.gov/docs/smallclaims/.

ELDRED V. ASH CROFT AND THE ORIGINS OF TLP CLINICAL EDUCATION

III. SECTION 1201 OF THE DIGITAL MILLENNIUM COPYRIGHT ACT

IV. A DECADE OF LITIGATION OVER DIGITAL BOOK SEARCH

V. THE BATTLE OVER SOFTWARE AND INTERNET PATENTS

VI. THE PUSH FOR A COPYRIGHT SMALL CLAIMS COURT AND THE CASE ACT

VII. ORACLE V. GOOGLE AND THE BATTLE OVER APIS

IX. CONCLUSION: THE CHALLENGES AHEAD FOR TLP CLINICS