A recent kerfuffle around an open source software creator asking for their package not to be included in a larger project has turned into a kind of rabbit-duck illusion for the open source community. What does it mean when the creator of a software package uses their social power - but not their legal power - to try and influence user behavior? Are they violating the spirit of open source? Or simply making requests that acknowledge open source realities?

What Happened

The actual back-and-forth is in the pull request discussion. The citadel of internet debate that is Hacker News will give you a sense of the larger community response. Briefly, what happened was:

• The creator of an open source software package asked that the package not be incorporated into a larger project. The creator acknowledged that it was technically legal to incorporate the package, but asked that it not be included anyway.

  As the author of the package that is being re-packaged here. I’m against it being repacked into here. While licensing wise I cannot stop you, I do hope you can honor my request. Thank you for considering respecting the author’s wishes.

• When pushed by the project’s maintainers, the package creator explained that they were worried that including the package in the larger project would result in many support requests from the community.

  If users experiencing issues with [the package], they will knock on my door. And I’m not willing to support that or accept that burden.

• Downstream maintainers pushed for more information or explanation. The creator continued to express disinterest in having the package included and in a conversation about the decision
• Eventually the creator threatened to relicense the package in a way that would make it legally incompatible with the project

Online opinion is split on this situation. However, some substantial part of the community has responded with a version of:

Seems like an author that doesn’t understand the spirit of FOSS.

What can be learned from this? Is this kind of request really against the spirit of FOSS?

Distinctions Between What the Law Allows and What Social Norms Allow are Real and Relevant (I)

It is notable that the creator did not kick off this discussion with the threat of legal action. Instead, the creator simply requested that the package not be included. They then explicitly acknowledged that they did not have the legal power to prevent it.

This was a request that no one had a legal obligation to respect. And yet, the creator made it because (presumably) they believed that the package maintainers lived in a world that was governed by more than black letter legal rules.

This strikes me as a totally healthy response on behalf of the creator. They clearly understood the consequences of releasing software under an open source license and the potential consequences of being included in a popular software package. The creator expressed these concerns by way of a social request instead of a legal threat because part of living in society is being able to resolve disputes without going to court.

We will never know, but it strikes me as entirely plausible that the creator may have been willing to leave it at that - as a request that may or may not be complied with - until the maintainers decided to follow up.

To be clear, the maintainers’ initial response also strikes me as a reasonable one. They probably wanted to understand the concerns that would motivate someone to make the request. They may have also hoped to be able to address those concerns and/or talk the creator out of the objection.

Unfortunately, this very human response by the maintainers also happened to push the creator to do exactly what the creator was hoping to avoid by raising the concern - spend time talking to people that they do not know about their package. Eventually, after the discussion continued, the creator decided to threaten to relicense the package in a way that would legally prevent inclusion.

It is important to recognize that this discussion ran on parallel tracks. One track was based on legal requests (or the lack of legal requests). The other was based on social/cultural requests.

That social/cultural track has the potential to be just as powerful as the legal one (in fact, it is the basis for this idea). Its existence illustrates that the reasonable resolution of the dispute did not have to rely on a strict interpretation of legal rights. Society is more than the law! The maintainers could have ignored the request and faced meaningful social/cultural consequences without any sort of legal enforcement. Social norms are real and create real change in the world. Even in open source.

Distinctions Between What the Law Allows and What Social Norms Allow are Real and Relevant (II)

On the flip side, the package in question is licensed under an MIT license. That license includes a pretty clear “anything that breaks is not my problem” disclaimer (in all caps):

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

If the legal rules were all that mattered here, the text of the license makes this entire dispute a non-issue. The creator offers the software as-is and disclaims any responsibility for it. Why would anyone come back to them if the software had a bug?

Of course, the text of the license does not match social expectations. Licensing terms aside, the creator recognizes that there is a social expectation in the open source software community that creators maintain packages - or, at a minimum, that it is acceptable for users to reach out to creators to ask for support and/or flag bugs.

While the creator seems to have understood that they have no legal obligation to deal with these requests, they also understood that they might have a social/cultural obligation to deal with them. Or, at a minimum, that the tools available to open source software creators make it hard to ignore a flood of requests. No amount of pedantic textual analysis of the license terms changes that.

Another Example of the Dark Side of the Power of Open Source?

This fits in with a long list of stories about how small pieces of code are used by millions without any sort of support for maintainers of the code. In some ways, this is a success story - a random person can create something that is used by millions! In other ways, it is a tragedy - a random person can create something that will make millions of people angry if it breaks!

Regardless of how you see this dynamic, it is pretty clear that it can create disincentives for individuals (and small groups) to strive for success in open source software. While companies like Tidelift are working to help solve this problem, being aware of the problem - and wary of how the problem might impact you - is far from failing to understand the spirit of open source software. In fact, it may be an incredibly clear-eyed understanding of how the spirit of open source software interacts with the reality of open source software. Furthermore, framing concerns about that dynamic as a social objection instead of a legal objection seems deeply within the spirit of open source software.

As a related community, this type of creator burden is something that the open source hardware community should be aware of and work to address. At the same time, I am not convinced that it is exactly the same type of problem in hardware as it is in software. To the extent that open source hardware includes open source software the problems are essentially identical. However, it is different when applied to the hardware itself.

That difference rests in the fact that design and distribution of software is collapsed into a single step - just post it to the repo. In hardware those steps are quite distinct. Designing open source hardware is quite separate from distributing actual pieces of hardware. That may make it harder for a single person to be responsible for maintaining a piece that is incorporated into millions of projects without any sort of support. But that’s another blog post for another day. Even if the dynamic is not identical, it is certainly similar enough to think about and try to avoid in open hardware.

This post originally appeared on the OSHWA blog

Today we are excited to announce that the open hardware journal HardwareX is integrating OSHWA certifications into their paper submission process.

HardwareX is an open access journal that focuses on free and open source designing, building, and customizing of scientific hardware. It has long used the Open Source Hardware Definition as a requirement for submissions. Now HardwareX is also integrating the OSHWA hardware certification program into the paper submission process.

First, HardwareX has updated its guide for authors to encourage (although not require) authors to certify their hardware for open source compliance before, during, or after submitting to HardwareX. This is a win for authors and for HardwareX. Authors can use the certification process to make sure that their hardware meets the Open Source Hardware Definition. Certification is often an iterative process where OSHWA helps creators meet all of the Definition’s requirements. HardwareX can rely on the OSHWA certification to confirm that hardware complies with the Definition, freeing up resources to review the papers themselves.

Second, OSHWA and HardwareX are standardizing ways to connect HardwareX articles to the Certification Directory. HardwareX will include OSHWA certification UIDs in their specification tables for articles that include certified hardware. Creators can update their certification directory listing with the “#HX” tag in the project description, and add a link to the HardwareX manuscript.

As the open hardware community grows, so too do our institutions. We look forward to finding new ways to collaborate with all of the parts of the community in the future. If you would like to connect with the certification program, please reach out at info@oshwa.org, check out our certification program API, or just certify your own hardware directly!

As the open source world has grown, so have concerns about the context in which openly licensed items are used. While these concerns have existed since the beginning of the open source movement, today’s larger and more diverse movement has brought new urgency to them. In light of this revived interest within the community, the time may be ripe to begin encouraging experimentation with open source licensing again.

How We Got Here

While the history of open source software is long and varied (and predates the term open source software), for the purposes of this blog post its early evolution was driven by a fairly small group of individuals motivated by a fairly homogeneous set of goals. As the approach became more popular, the community developed a wide range of licenses designed to address a wide range of concerns. This ‘First Cambrian Explosion’ of open source models and software licenses was a time of experimentation within the community. Licenses varied widely in structure, uptake, and legal enforceability.

Eventually, the sprawling nature of this experimentation began to cause problems. The Free Software Foundation’s Free Software Definition and the Open Source Initiative’s Open Source Definition were both attempts to bring some order to the open source software world.

In the specific context of licensing, the Open Source Initiative began approving licenses that met its criteria. Soon thereafter, it released a License Proliferation Report detailing the challenges created by this proliferation of licenses and proposing ways to combat them.

These activities helped to bring order and standardization to the world of open source licensing. While OSI continues to approve licenses, for well over a decade the conventional wisdom in the world of open source has been to avoid creating a new license if at all possible. As a result, for most of this century open source software license experimentation has been decidedly out of style.

Largely for the reasons described in the License Proliferation Report, this conventional wisdom has been beneficial to the community. License proliferation does create a number of problems. Standardization does help address them. However, in doing so standardization also greatly reduced the amount of license experimentation within the community.

Reduced experimentation means that concerns incorporated into approved licenses (access to modifications of openly licensed code) have been canonized, while concerns that had not been integrated into an approved license (restrictions on unethical uses of software) at the moment of formalization were largely excluded from consideration within the open source community.

What Changed

What has changed since the move towards codification of licenses? The open source software world has gotten a lot bigger. In fact, it has gotten so much bigger that it isn’t just the open source software world anymore. Creative Commons - today a towering figure in the world of openness - did not even exist when the Open Source Initiative started approving licenses. Now the open world is open source hardware, and Creative Commons-licensed photos, and open GLAM collections, and open data, and all sorts of other things (this is a whole other blog post). The open source world has moved beyond early debates that questioned the fundamental legitimacy of open source as a concept. Open source has won the argument.

An expansion of applications of open source has leady to an expansion of people within open source. Those people are more diverse than the early open source software proponents and are motivated by a wider range of interests. They also bring with them a wider range of concerns, and a wider range of relationships to those concerns, than early open source adopters.

What is Happening Now

This broader community does not necessarily share the consensus about how to approach licensing that was developed in an earlier period of open source. They bring a range of viewpoints that did not exist in the earlier days of open source software into the open source community itself. They are also applying open source concepts and licenses to a range of applications that were not front of mind - or in mind at all - during the drafting of today’s canonical licenses.

Unsatisfied with the consensus rules that have delivered us the existing suite of (incredibly successful) licenses, parts of the community have begun experimenting again. Veteren open source lawyers are rewriting licenses with public understandability in mind. Community members are transforming their interpretation of open source development into licences that invite collaboration without intending to adhere to the open source definition. Some of these licenses are designed to address concerns traditionally excluded from the scope of open source licenses. I am directly involved in the ml5.js attempt to do just that.

The creators of these experiments are responding to a standardized approach to licensing that does not fully accommodate their needs and concerns. In some cases the standardized approach does not accommodate these concerns because the community litigated including them in the past and decided it could or should not be done. However, even in those cases, that debate happened within a very different community in at least somewhat different contexts. The conclusions arrived at then are not necessarily valid for the broader world that open source finds itself inhabiting.

In light of that, it may be time to begin encouraging experimentation in open source licensing again. Encourage people to test out new approaches by applying them to real world problems. In some cases, the decisions made in the past will prove to be robust and sustainable. In others, a new debate will reveal the decisions’ shortcomings. In both cases, the open source community will be stronger by being tested from within.

Coda: Is This Post Just a Lawyer Advocating for Lawyers to Have More Fun?

Throw out the old ways of doing things! Try something new! Experiment! Is this just a call for lawyers to have fun by screwing around with exotic licensing concepts at the expense of everyone else’s stability (and sanity)?

It could be. But I don’t really think so. The thing about lawyers (as a group - there are always exceptions) is that novelty and instability makes us nervous. Things that are tried and true will probably work. That means we do not have to worry about them. New things - who knows what will happen to them? That uncertainty makes lawyers nervous.

That is part of the reason why lawyers like today’s conventional wisdom. The canonical set of open source licenses have more or less worked for decades. It is unlikely that they will explode, and it is even less likely that they will explode in the face of the lawyer who uses them on any given project. In contrast, any lawyer who writes their own license is setting themselves up for a period of anxiety, waiting to discover what they missed or how things will go wrong.

Of course, some lawyers do think it is fun to cook up new open licenses. And maybe this post is a call for them to do more of it. But, on balance and as a whole, introducing new licenses into the world of open source will probably cause open source lawyers more anxiety than joy.

I think that anxiety is probably worth it. But that will be far from a universally held position.

Feature image: Isogelus gigas Dekay (you know, trilobites. as a vivid illustration of the cambrian explosion. NOT as a suggestion that people who insist on only using the classic OSI approved licenses are stuck in the past. I use those licenses too! They are great!) from the Smithsonian Open Access collection

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.