Michael Weinberg

Coming to Terms with § 1201

Tue, 26 May 2026 00:00:00 +0000

Last month the Engelberg Center released Unbalanced Interests: How the § 1201 Process Ate Itself (also hosted on this site). The report is a deep dive into the triennial § 1201 process, which is something of a marquee event in copyright policy circles, although not necessarily a particularly loved one. In the context of this blog, it is the thing that precipitates the unlocking 3D printers posts every three years.

I wrote the report because I have been participating in this process since the 2010 cycle and wanted to dig into just how much collective effort it required, and how to balance that effort against the benefits it produces. The short version is that the process requires a great deal of effort and produces very little benefit for anyone involved or the public in general.

The 1201 process (named after the section of copyright law that establishes it) acts as a giant copyright policy time sink. Of course, by its nature, the government maintains many time sinks. This one just happens to be mine.

Established by Congress, the process assumes that every three years a bunch of third parties have time to represent the public in a proceeding that runs for about a year. The process is managed by the Copyright Office. The Copyright Office sees itself as mediating between a number of competing interests, not as an advocate for the public’s interest.

For reasons I’ll get to at the end of this post, in many ways the enduring relevance of the process is that it provides a rare forum to have policy fights about copyright law. But first, a very quick tour of the findings.

Findings

The 1201 process requires a huge amount of effort from a huge amount of parties.

During the most recent proceeding, which kicked off with an NPRM on October 19, 2023 and ended with a Final Rule just over a year later on October 28, 2024, 96 nonprofit organizations, law school clinics, trade associations, academics, companies, and individuals submitted over 1,000 pages of petitions, comments, opposition comments, and reply comments (in addition to participating in three days of public hearings). Most of the participants involved do not track billable hours, but that corpus probably represents over 10,000 person hours of work.

The process is also in service of a law that is rarely used. The 1201 process technically consists of requests to be exempted from the law that prohibits breaking DRM. Over the three year period covered by the last exemption, only 12 rightsholder suits included an alleged violation of that prohibition as a claim. Five of those came from the same CAD software developer. All 12 included underlying copyright claims, which likely offer penalties that eclipse anything that would be available under 1201.

As a result, one could draw the conclusion that the costs associated with the 1201 process far outweigh any benefits that the provision provides to rightsholders.

Bonus Features

For better or worse, every three years the 1201 process brings together a large swath of players in copyright policy debates. Partially as a way to recognize their work, the report contains three bonus features. Those are:

Burden of Proof an interactive visualization of triennial comments submitted to the Copyright Office from 2000 to 2024. It was created with the always excellent Jer Thorp who decided to take a break from his otherwise interesting work to dig into triennial comment analytics. In addition to exploring the data with various filters, high-quality prints are available in a range of sizes. That unquestionably makes it the #1 office accessory for every serious 1201 fan.
The 1201 Commenter Leaderboard, a ranking of all the individuals who have filed comments in a triennial proceeding. Although some individual comments are filed on behalf of multiple organizations or clients, the leaderboard only counts such joint comments as a single comment for ranking purposes. I was heartened to see people in the 1201 community have strong opinions about methodology.
The 2003 Media Explorer, a way to explore media referenced by commenters during the 2003 triennial proceeding. During that round of the proceeding, a large number of individuals filed comments in support of exemptions allowing circumvention of DRM protecting media. As part of their filings, commenters identified specific DVDs and albums they had purchased and were unable to make full use of because of DRM-based restrictions. This site allows you to explore them.

Why Does This Happen?

If the costs of the process outweigh the benefits, why does it persist? My theory is that it provides one of the few administrative arenas for copyright policy debates.

The evolution of copyright law mostly happens through the courts. While Congress sets the rules (and occasionally spends a year or two considering a major rewrite), 1998’s DMCA is the most recent significant legislative update to those rules (sorry MMA nerds). Whereas issues such as net neutrality are contested at a regulatory agency like the FCC, there is no administrative agency setting copyright rules.

However, every three years, the 1201 process provides a non-ligitation forum to hash out the limits of copyright law. That makes it a best-bad option to at least debate these issues, and everyone runs in to do so. Does that justify its continued existence? Perhaps not, but it may explain it.

AI-Assisted Library Rewriting and Relicensing Brings Open Source Software into the IP World of Open Source Hardware

Mon, 30 Mar 2026 00:00:00 +0000

A dispute about a python library called chardet may be an early rumble of an earthquake in the world of open source software (OSS) and intellectual property law. The incident exposes the potential fragility of the legal model underpinning OSS in the Large Language Model era. Suddenly, open source hardware (OSHW)’s experience creating open works without comprehensive IP protections could have many lessons for OSS.

First, as usual, some context.

LLM-Assisted Library Rewrite

Ars has a good summary of the precipitating incident. Briefly, chardet is a python library released under the LGPL, which is a restrictive open source license. The current maintainer (who did not originally create the library) wanted to rewrite the library in order to release it under a more permissive MIT license. Assisted by Claude Code, the maintainer rewrote the library with new code that replicated the library’s functionality.

The original creator of the library felt that this behavior violated the library’s license, effectively stripping the restrictive license from the project. The current maintainer says that, while the new library maintains the functionality of the original, the new library does not copy any of the code from the original library. Since the code, and not the functionality, is what is protected by copyright and controlled by the license, the new version exists outside of the scope of the original license and can legally be licensed under different terms.

While the merits of this argument could be a blog post in and of itself, for the purposes of this post let’s just say that copyright on code pretty narrowly covers the actual code as actually written, and excludes the functionality that the code represents (see, e.g. Google v Oracle). On balance, that is a good thing because it allows people to create their own implementations of functionality without worrying about a copyright lawsuit. It also means that the first person to write code that performs a given function (say, sorting a collection of numbers from lowest to highest) does not get to control every other piece of code that performs the same function for that first person’s entire life plus 70 years after they die. Furthermore, it would be bad if we decided to expand the scope of software copyright in an attempt to make open source software licenses more robust.

The upshot is that this incident demonstrates a new reality where it may be easier to copy the functionality of code in a way that does not infringe that code’s copyright than has generally been assumed. This upends one of the core assumptions underpinning OSS.

OSS and Copyright

This post will not rehash all of OSS and copyright. Suffice it to say that the legal framework of OSS relies on one weird trick. Software is born closed, automatically and completely protected by copyright the moment it is written. Other people need permission (a license) to use that copyright-protected code. Instead of using a software license to keep software proprietary, OSS uses the licenses to impose what the community sees as pro-social obligations on users while broadly inviting reuse.

This entire legal edifice assumes that someone who wants to use open source code needs to copy the code itself (which is protected by copyright, thus requiring a license), not just the conceptual features that the code represents (which are not protected by copyright, thus making a license for that nonexistent copyright irrelevant).

OSHW and Copyright

OSHW is born out of the OSS community and carries forward many of its norms and practices. However, there is an important difference: unlike born-closed software, many parts of OSHW are born open. Many of the functional elements of OSHW are categorically ineligible for copyright protection.

Without that legal protection, OSHW licenses are much less legally effective than OSS licenses at imposing obligations on users (just to be clear, parts of OSHW licenses are still legally enforceable - the situation is just less universal than OSS).

Although the OSHW legal foundation is less robust than its OSS cousin, this community still basically works. In large part this is because, at least internally, the licenses still act as valued social signals to OSHW users. People tend to respect them, and there tend to be social sanctions on community members who violate the spirit of the license regardless of its ultimate legal enforceability.

OSS and OSHW Come Full Circle

It is understandably alarming for the OSS community to find that its core legal foundation may be shifting below its collective feet. The good news is that the OSS community does not need to figure this out on its own. OSHW has been modeling how to navigate this environment for over a decade.

Also, it may be an opportunity to learn if OSS is really just the friends we found along the way. The legal enforceability of OSS licenses is unquestionably important. At the same time, actually litigating license violations is vanishingly rare. This new environment may help us understand how much of the power of OSS comes from the legal stick they carry, and how much comes from the social sanctions that flow from violating the social signal they embody.

Feature image: John Pounds by William Sharp and Ephraim Bouve from the Smithsonian's Open Access collection

3D Printers Cannot Effectively Screen for Gun Parts

Wed, 04 Feb 2026 00:00:00 +0000

This post is a handy reference for the technical reasons why requiring 3D printers to screen for gun parts is not an effective way to reduce guns or gun violence. I am publishing it on the occasion of both New York and Washington State introducing bills to require this type of screening. In addition to a topic that I have been researching for over a decade, the question of how to know if a 3D printer is printing a gun part is something I spent a lot of time working on while overseeing trust and safety at a large 3D printing service provider.

This post is not about debating the larger legitimacy of gun control. It assumes that gun control is a reasonable and legitimate action of governments in order to focus on the technical reasons why requiring 3D printers to identify and refuse to print gun parts does not work.

Broadly speaking, it is responding to requirements that all 3D printers check prints to make sure that they are not gun parts. If the part is a gun part, the printer would refuse to print it.

The short version is that accurately identifying gun parts is incredibly hard, and the hackable nature of desktop 3D printers makes it trivial to circumvent any requirements to try.

Here's the slightly longer version:

Matching Files is Fragile

The first reason that requiring 3D printers to identify gun parts is ineffective is because analyzing 3D files is complicated. Any attempt to identify gun parts will miss many parts that are actually for guns, and may flag a number of parts that have nothing to do with guns (see, e.g. the hero image on this blog post).

Expensive engineering design software is good at evaluating specific properties of a 3D file (like where mechanical stress will occur over a lifetime of use). However, even that software can’t tell you what a part actually does (is that spring for a door, a shock absorber, or a catapult?). This challenge is exacerbated by the fact that guns are just mechanical objects. That means that there are many ways to design any individual part, and many individual parts of guns will resemble mechanical parts with totally benign uses. Put another way, devoid of other context, a switch for a gun safety looks a lot like a switch for a door.

Broadly speaking, there are two ways to think about doing file matching:

Algorithmic Analysis

This approach imagines a piece of software that can analyze a file and determine with some level of certainty if it is a gun part or just a hinge. Assuming that this software exists, which it does not at the time of this writing, it is reasonable to expect that such an analysis would be reasonably computationally expensive.

3D printers do not have the on-board processing power to do this kind of analysis. Requiring that they include chips capable of this kind of analysis would fundamentally change the economics of 3D printer design, akin to requiring that all bikes include jet engines.

Of course, the 3D printer could upload the file to a cloud somewhere and let the processing happen there. However, internet connectivity is not a default feature on desktop 3D printers. You could require that all 3D printers maintain a constant connection to the internet in order to operate but, again, that would fundamentally change how many people use their printer. There are also many legitimate use environments where constant internet connectivity is neither possible nor desirable. And, of course, this raises the question of who is responsible for maintaining that directory and keeping it secure.

Blacklisting

If it is not possible to analyze the true purpose of each file, it might be possible to at least match them against a known database of gun parts, right? This approach also has some serious shortcomings.

First, there is a question of keeping that database up to date on the printer. That would require constant, or at least regular, internet connectivity for the printer. That raises the same issues as discussed in the last section.

Second, also as discussed above, analyzing and matching 3D files is computationally expensive. The most logical way to do that with the processing power of a 3D printer would be to use a hash table of known gun parts, comparing a hash of the file to be printed against the table.

The primary problem with both geometry matching and hash matching is that it is incredibly fragile. A small change that had no impact on the functioning of the part would change its geometry or hash, effectively hiding it from the blacklist. That would make it trivial for anyone to circumvent it. Identifying which changes are functional and which are merely aesthetic is not easy. That is especially true if people are making those changes with the specific goal of tricking the printer into printing a gun part.

3D Printers Print Themselves

The second reason this proposal is ineffective is because 3D printers are made in an incredibly distributed way. There are dozens of ways to make your own 3D printer using open source, user-modifiable parts. Even non-open source printers are highly hackable.

As a result, there is no way to mandate that a technology that starts in a 3D printer remains in a 3D printer. The software that runs most printers is open source, meaning a single update would circumvent any screening measures.

This places 3D printers at the opposite end of the spectrum from 2D printers. Anti-counterfeit systems prevent 2D printers from printing currency. To the extent that these rules are effective (and I’m no expert, but they are often cited in these discussions as successful models), it is because the 2D printing industry is fairly concentrated and proprietary. 2D printer companies are actively hostile to users who want to modify their products, significantly raising the barrier to hacking around any countermeasures.

Desktop 3D printers are the opposite. They all trace their heritage back to open source printers, and users expect to be able to modify, extend, and hack their printers. That means that workarounds for a screening mandate would be easy to develop, distribute, and implement. Many open source software packages might even include the circumvention by default, meaning users would implement it without even actively intending to do so.

3D Printers are General Purpose Machines

This post is focused on the technical challenges with requiring 3D printers to screen every file it prints for gun parts. Nonetheless, it would be incomplete without a brief mention of how potentially invasive this sort of requirement is.

3D printers are general purpose machines that can be used for good or ill. Just as we do not require the phone company to monitor every phone call in order to prevent customers from using phones to commit bank fraud, we should be wary of requiring our 3D printers to monitor every print in order to prevent one possible type of print.

That type of invasion might be reasonable if it was effective. However, for the reasons listed in that post, it is unlikely to prevent even a modestly motivated person from using their printer to create gun parts. If an intervention is both highly invasive and unlikely to be effective, it is probably not an ideal policy.

Feature image: Designs for Gun Parts and Ornament from the Smithsonian Open Access collection. It's not always easy to tell which elements of a gun are functional and which are decorative!

The Prusa Open Community License Embraces IP Maximalism

Fri, 30 Jan 2026 00:00:00 +0000

This post was originally going to be a legal analysis of the Open Community License released by the 3D printer company Prusa Labs right before Christmas. That analysis may still come. (update 3/19/26: It does not need to come. Kyle E. Mitchell did his trademark Line by Line analysis of the license so check it out.)

However, after reviewing it, the legal specifics of the license are less important than the way it represents the relationship between open hardware and IP protections in general. The entire presentation suggests that Prusa has a legal ability to control uses it has no ability to control. In addition to being an “open” license that does not meet any common definition of open, the Open Community License actually advances the cause of a more maximalist IP worldview.

Quick Background

Since 2023 Josef Průša, the eponymous founder of the 3D printing company Prusa Research, has been complaining about the state of open hardware (see, e.g. discussion here and here). These complaints have basically taken the form of asserting that open hardware does not work as a business anymore in blog posts framed as a “call for discussion,” and then ignoring even the most basic clarifying questions designed to understand his concerns so they could be discussed.

At the very end of 2025, Prusa Research announced a new “Open Commiunity License” (OCL). That license attempts to restrict any commercial use of Prusa printers or designs, with the narrow exception of modifications that a commercial user may do to printers they only use internally. This kind of commercial restriction runs counter to the understanding of openness embodied in both the Open Source Definition and the Open Source Hardware Definition. It also purports to grant rights to modify hardware that people already have thanks to concepts like the First Sale Doctrine.

This post isn’t a legal analysis of the license itself, so for now I’ll just say that the license text feels a little underbaked, even if one were to be on board with its purported purpose.

The Larger Issue - How the OCL Embraces IP Maximalism

The bigger issue with the license is that it is framed in a way that suggests Prusa has the ability to control the use of things it has no ability to control. Specifically, that it has rights over functional elements of its printers that are not protectable by copyright.

Not All Hardware is Protected by IP Rights

The thing that makes understanding open source hardware licensing challenging is the fact that hardware is not fully and automatically protected by any sort of IP right. Software is categorically “born closed.” It is completely protected by copyright the moment it is created. That means a) creators need to give formal permission (a license) for anyone else to build upon it, and b) that license covers the entire piece of software.

Some parts of open hardware (like the software that runs it) are also “born closed,” so users need permission (in the form of a license) to build upon it. However, other parts of open hardware (like the functional, physical parts) are “born open”. Those “born open” parts are open by default. There are no intellectual property rights restricting how they are used by others. No one needs a license to do anything with them, including just copying and reselling them. The creator of these elements does not have the legal power to dictate how they are (and are not) reproduced. Some of these elements might be patentable, but that’s a whole other thing that is rarely relevant in open source hardware contexts.

This can feel counterintuitive to anyone raised on open software. In fact, sometimes people suggest expanding IP rights to the functional parts of hardware just so they can then be openly licensed. But (at least in my opinion) it would be perverse to expand IP rights in the name of openness. It is a good thing that many elements of open hardware are open by default.

Understanding the Limits of Licensing

The entire Open Community License enterprise falls into the trap of assuming that every element of a Prusa printer is protected by some kind of right, and that using or building on that element requires permission from Prusa.

Prusa’s original complaints about open hardware were (as best as I could tell) focused on competitors copying functional elements of Prusa printers (like all of the mechanical parts). Prusa claimed that this was because the elements were openly licensed. However, since the functional elements are not protected by any sort of IP right, they weren’t actually openly licensed. In fact, they weren’t licensed at all, because there were no underlying rights to license on any terms. They were just available for anyone, including competitors, to do whatever they wanted with. No amount of closed “no copying” licensing language would change that.

Pretend IP Rights

The Open Community License converts this misunderstanding into legal-looking text. The License’s announcement is tied to the release of the CAD files for the CORE One and CORE One L frames. This announcement image is full of the kind of functional parts that are not eligible for copyright protection[^1]:

To its credit, the license text explicitly limits its coverage to actual, existing IP rights:

OCL pertains to intellectual property applied in licensor‘s products and/or its components

Which is good except that, for the reasons just outlined, many readers (and maybe Prusa itself?) might assume that “intellectual property applied in licensor‘s products” is a much more expansive set of rights than it actually is.

This problem is exacerbated by the examples directory linked to by the license. Presumably, this directory is intended to be something like the human-readable version of the terms.

Those examples are full of functional hardware elements that are simply not protected by intellectual property rights: a fan shroud (Scenario 1), a soldering iron (Scenario 1), a printing toolhead (Scenario 3 & 4), and replacement parts (Scenario 5 & 6). The OCL can’t cover them, because they are categorically ineligible for the types of intellectual property rights that the OCL is designed to license.

As a result, everything about this license rollout, from the graphics, to the blog post explaining it, to the examples of how it should be used, imagines a world where copyright protects things that it simply does not protect. Expanding copyright protection in this way would work against the concepts of sharing and collaboration that form the foundation of open communities.

That is the real problem with the OCL. Prusa is free to tell itself that saying “no copying” will stop competitors, and the internet is already full of half-baked partially open licenses. The real damage comes from conditioning people to think that they need permission to use objects in the public domain.

[^1]: Even if the parts themselves are not eligible for copyright protection, are the CAD files representing them copyrightable? The answer to that is a lawyerly “it depends” (pages 14-17 of this whitepaper explore it a bit - I think the answer in many cases is “probably not”). In some ways that makes the license more of a problem - in the face of ambiguity around the bounds of copyright protection for digital files that represent functional objects, it dumps its weight on the side of broader rights.

Feature image: Political Discussion in a Lumber Shanty from the Smithsonian Open Access collection

Is the Arduino Uno Q Open Source Hardware?

Fri, 24 Oct 2025 00:00:00 +0000

Earlier this month, Arduino announced a new Arduino Uno Q board as part of its acquisition by Qualcomm. Is this new board open source? It is kind of hard to say, which is exactly why the OSHWA Open Source Hardware Certification exists.

What Do We Know?

Arduino is marketing the new Q as “open source”:

And you can download manufacturing files for the board, which are licensed under a CC BY-SA 4.0 license.

However, unlike prior Arduino boards (such as the Uno), Arduino has not released editable design files for the Q. That means that, while some Q files are available and openly licensed, you cannot use those files to modify the board.

Why might this be relevant? The community Open Hardware Definition maintained by OSHWA requires:

The documentation must include design files in the preferred format for making changes, for example the native file format of a CAD program. Deliberately obfuscated design files are not allowed. Intermediate forms analogous to compiled computer code — such as printer-ready copper artwork from a CAD program — are not allowed as substitutes.

I don’t know if Arduino intended to deliberately obfuscate the design files that it released, but the publicly available Q files are basically the “[i]ntermediate forms” called out in that definition. Whatever the intention, Arduino’s release clearly fails the requirements of the community definition.

This means Arduino has a definition of “open source” that differs from the OSHWA definition. The difference might be confusing to some people. What can be done about that?

Enter the OSHWA Certification

This is exactly the type of situation that motivated OSHWA to create the certification program in the first place. No one owns the term “open source,” so it can basically be used on anything to mean anything. Sometimes it is used in different ways because people have a legitimate disagreement about what it should mean. Other times it is used in different ways because people are trying to open wash a product in bad faith. Regardless of the reason, it can be confusing.

Fortunately, while no one owns the term open source, OSHWA does own the open source hardware certification logo, control UIDs, and control the directory. Although anyone can say something is “open source,” only things that meet the community definition of open source can be OSHWA certified as such.

Is someone making a claim to open source that feels questionable? If the hardware is OSWHA certified, you know that their definition of “open source” matches the community definition. If it isn’t certified, it might be worth doing some additional digging.

What About the Chips?

There is one other potentially important difference between the Uno and the Uno Q’s documentation. The Uno’s datasheet lists the ATMega328P as its processor, but does not include openly licensed, editable files for it. That’s consistent with the Certification’s principle of user contribution. Arduino does not include openly licensed, editable files for the ATMega328P because it can’t - Arduino did not design those processors and does not have the legal authority to license them to others. Listing them is all that is required, in part because that is all they really can do.

The Uno Q’s relationship to its processors are very different. Its datasheet lists a number of Qualcomm chips. Since Qualcomm owns Arduino, Arduino/Quamcomm does have the legal authority to release editable versions of those files and openly license them. That makes the Qualcomm chips part of Arduino’s “user contribution”. In order to be certified open, those chips would need to be openly licensed as well.

Sometimes Open Source Just Isn’t

Even in a world of openness ambiguity, sometimes it is very easy to determine if a claim of open source is bogus. Take, for example this question and response in the Q’s FAQs:

If the question is “Is Arduino App Lab open source?,” and the response is “we are working to publish corresponding source code repositories,” then the actual answer to the question is “No.” Or, at a minimum, “not yet”. “Someday we hope to make this open source” is not the same as “open source”. Which is fine! Just, you know, describe the current situation accurately.

Feature image: Electricity for Everybody cover from the Met's Open Access collection

The Most Popular Open Source Hardware Licenses (2016-2025)

Sun, 05 Oct 2025 00:00:00 +0000

What are the most popular open source hardware licenses? How has that popularity changed over time? Is there anything to be learned from the ups and downs of various licenses?

This Open Hardware Month my modern mind, like yours, had these three questions. Fortunately, the OSHWA Open Source Hardware Certification API makes it possible to start answering them.

This post has leaderboards for all of the licenses used for certified hardware, as well as hardware, software, and documentation specific leaderboards. I'm not sure if there is a revelatory take away from them right now, but the leaderboards may be helpful in the future.

If you don't want to read the context about the data, jump right to the leaderboard you care about:

All Licenses
Hardware Licenses
Software Licenses
Documentation Licenses

If you don't want to deal with that API, you can find the raw data from this post (and some tools for working with them) in this repo.

The Nature of This Data and How It Evolves Over Time

Before getting to the leaderboards, I want to put the data into context.

This data comes from OSHWA's Open Hardware Certification Directory. As part of the certification application form, OSHWA asks for information about three separate licenses:

the license for the hardware,
the license for the documentation, and
the license for the software (if any)

(here's a quick a dirty guide to open source hardware licensing with a bit more)

This structure is designed to give creators flexibility. If they want to use a single license for the entire bundle, they can do so. Alternatively, if they want to use element-specific licenses, they can do so as well.

Some people use this flexibility to choose licenses designed with each element of the bundle in mind. For example, they will use a Creative Commons license for the project documentation, a well known open source software license for the software, and a hardware-specific license for the hardware.

Others just use a single license to cover everything. Sometimes that is fine — the CERN licenses are designed to be a single license to cover all elements of open hardware. Other times it is fine-ish — most open source software licenses were not written with hardware in mind. Using them for hardware isn't great, but they are certainly better than nothing.

This can get moderately more complex when people use the CERN open hardware licenses for the hardware, and other licenses for other elements. The CERN licenses are designed to cover everything in the project bundle. When people use additional licenses for other elements (say, an open source software license for the software), I think the best reading is that they are actually dual licensing that element under both licenses. Of course, I doubt most people spend very much time thinking about that, and I don't think it is particularly relevant to the analysis here.

Finally, there is no guarantee that the choices registered in the Certification Directory match the license(s) used in the repo or other documentation. The certification review process requires that the repo and documentation contain licenses that meet the Open Hardware Definition. If the repo contains licenses that differ from the licenses identified in the application, I think it is reasonable to treat the hardware as licensed under both licenses simultaneously.

The Data Evolves

While this post contains data all the way back to 2016, the categories represented in the data are not static.

The directory started with somewhat informal and imprecise license categories (GPL or CC-BY). In 2022 OSHWA upgraded to SPDX identifiers for the licenses. These identifiers are standardized ways to identify licenses, and are more specific than the terms being used earlier. OSHWA retained some non-SPDX identifiers as legacy options (for example, GPL or CERN) but moved them to the bottom of the dropdown menu, below "other," to discourage their use when an SPDX alternative existed. That means that you can trace GPL back to 2016, but GPL-3.0-or-later only starts in 2022.

In addition to this evolution of terminology, in 2021 OSHWA added the then newly-released CERN v2 licenses. That means all of the CERN licenses prior to 2021 are CERN v1.

The trends are also slightly skewed in 2020 and 2021. OSHWA saw a general increase in certifications during these pandemic years, lead by a concerted effort by one party (Adafruit) to certify a large number of pieces of hardware. The number of certifications obtained by Adafruit during that period are likely enough to skew license patterns to match its practices for those years.

Finally, the act of compiling data for this post made me realize that OSHWA did not include MIT licensing options for hardware and documentation. Whatever its possible limitations as a license applied to these things, it is often used by creators who simply add a single license to their repo. Therefore, MIT is now an option for those elements. This will likely reduce the number of other license selections over time.

All Licenses

This first group aggregates all of the licenses used across all categories (hardware, software, and documentation). This aggregation makes it more likely that licenses popular with creators who pick one license for all three components will be at the top. Historically, these have tended to be well known open source software and Creative Commons licenses. However, we are seeing the persistent growth of the CERN licenses as they are more widely adopted.

All Licenses 2025 (so far)

License	Total	Rank	Previous Rank
MIT	85	1	3 ▲
CC-BY-SA-4.0	83	2	1 ▼
GPL-3.0-or-later	74	3	4 ▲
CERN-OHL-S-2.0	70	4	5 ▲
Other	68	5	2 ▼
CERN-OHL-P-2.0	50	6	9 ▲
CC BY-SA	48	7	6 ▼
CC-BY-4.0	40	8	8
No software	33	9	7 ▼
CERN-OHL-W-2.0	25	10	11 ▲
GPL-3.0-only	24	11	10 ▼
GPL	18	12	12
Apache	7	13	15 ▲
CERN	4	14	18 ▲
CC BY	3	15	17 ▲
LGPL	3	16	19 ▲
CC 0	3	17	21 ▲
CC0-1.0	3	18	14 ▼
TAPR	2	19	16 ▼
CERN-OHL-1.2	1	20	13 ▼
Solderpad	1	21

All Licenses 2024

License	Total	Rank	Previous Rank
CC-BY-SA-4.0	237	1	7 ▲
Other	108	2	3 ▲
MIT	103	3	2 ▼
GPL-3.0-or-later	100	4	10 ▲
CERN-OHL-S-2.0	90	5	9 ▲
CC BY-SA	90	6	1 ▼
No software	51	7	5 ▼
CC-BY-4.0	31	8	11 ▲
CERN-OHL-P-2.0	28	9	12 ▲
GPL-3.0-only	25	10	13 ▲
CERN-OHL-W-2.0	19	11	15 ▲
GPL	15	12	8 ▼
CERN-OHL-1.2	14	13	18 ▲
CC0-1.0	11	14	16 ▲
Apache	10	15	14 ▼
TAPR	9	16	6 ▼
CC BY	9	17	17
CERN	5	18	4 ▼
LGPL	2	19	21 ▲
Mozilla	2	20
CC 0	1	21	19 ▼

All Licenses 2023

License	Total	Rank	Previous Rank
CC BY-SA	485	1	3 ▲
MIT	401	2	2
Other	256	3	1 ▼
CERN	195	4	15 ▲
No software	114	5	7 ▲
TAPR	110	6	20 ▲
CC-BY-SA-4.0	93	7	4 ▼
GPL	77	8	10 ▲
CERN-OHL-S-2.0	72	9	5 ▼
GPL-3.0-or-later	62	10	8 ▼
CC-BY-4.0	36	11	6 ▼
CERN-OHL-P-2.0	28	12	9 ▼
GPL-3.0-only	20	13	12 ▼
Apache	14	14	17 ▲
CERN-OHL-W-2.0	12	15	11 ▼
CC0-1.0	11	16	16
CC BY	10	17	14 ▼
CERN-OHL-1.2	10	18	13 ▼
CC 0	6	19
Solderpad	3	20	18 ▼
LGPL	1	21	19 ▼

All Licenses 2022

License	Total	Rank	Previous Rank
Other	115	1	4 ▲
MIT	98	2	2
CC BY-SA	85	3	1 ▼
CC-BY-SA-4.0	74	4
CERN-OHL-S-2.0	57	5	8 ▲
CC-BY-4.0	39	6
No software	38	7	6 ▼
GPL-3.0-or-later	36	8
CERN-OHL-P-2.0	34	9	12 ▲
GPL	26	10	5 ▼
CERN-OHL-W-2.0	20	11	14 ▲
GPL-3.0-only	14	12
CERN-OHL-1.2	9	13	9 ▼
CC BY	9	14	7 ▼
CERN	8	15	3 ▼
CC0-1.0	7	16
Apache	4	17	11 ▼
Solderpad	2	18	10 ▼
LGPL	2	19	15 ▼
TAPR	1	20	13 ▼

All Licenses 2021

License	Total	Rank	Previous Rank
CC BY-SA	311	1	1
MIT	232	2	2
CERN	195	3	4 ▲
Other	186	4	3 ▼
GPL	67	5	7 ▲
No software	60	6	5 ▼
CC BY	32	7	6 ▼
CERN-OHL-S-2.0	17	8
CERN-OHL-1.2	16	9
Solderpad	11	10	12 ▲
Apache	10	11	11
CERN-OHL-P-2.0	8	12
TAPR	8	13	10 ▼
CERN-OHL-W-2.0	8	14
LGPL	7	15	8 ▼
CC 0	7	16	9 ▼
Mozilla	1	17

All Licenses 2020

License	Total	Rank	Previous Rank
CC BY-SA	844	1	2 ▲
MIT	708	2	6 ▲
Other	621	3	1 ▼
CERN	397	4	4
No software	147	5	5
CC BY	60	6	7 ▲
GPL	59	7	3 ▼
LGPL	14	8	10 ▲
CC 0	9	9	11 ▲
TAPR	6	10	9 ▼
Apache	4	11	8 ▼
Solderpad	2	12

All Licenses 2019

License	Total	Rank	Previous Rank
Other	130	1	1
CC BY-SA	90	2	2
GPL	68	3	4 ▲
CERN	37	4	5 ▲
No software	35	5	3 ▼
MIT	16	6	6
CC BY	11	7	10 ▲
Apache	8	8	9 ▲
TAPR	5	9	8 ▼
LGPL	3	10	7 ▼
CC 0	2	11

All Licenses 2018

License	Total	Rank	Previous Rank
Other	159	1	1
CC BY-SA	62	2	2
No software	30	3	3
GPL	22	4	5 ▲
CERN	13	5	4 ▼
MIT	6	6	6
LGPL	5	7
TAPR	3	8
Apache	2	9	8 ▼
CC BY	2	10	7 ▼
GPL-3.0-only	2	11

All Licenses 2017

License	Total	Rank	Previous Rank
Other	80	1	1
CC BY-SA	20	2	2
No software	10	3	5 ▲
CERN	10	4	6 ▲
GPL	8	5	3 ▼
MIT	7	6	4 ▼
CC BY	5	7	7
Apache	1	8	8

All Licenses 2016

License	Total	Rank
Other	144	1
CC BY-SA	60	2
GPL	21	3
MIT	13	4
No software	7	5
CERN	6	6
CC BY	4	7
Apache	2	8
LGPL	2	9
TAPR	2	10

Hardware Licenses

These charts track the growth of the licenses applied to hardware. As mentioned above, the strength of Other on the list likely represents creators who chose a single open source software license for their entire project. The hardware license dropdown does not include most open source software licenses, so those creators will choose Other here. With MIT included as an option as of August of 2025, 2025 and 2026 data will hopefully begin to disambiguate that category.

Both CERN and Creative Commons licenses remain popular choices over time. While older hardware-oriented licenses such as TAPR and Solderpad do not have the same level of popularity, they continue to have users.

Hardware Licenses 2025 (so far)

License	Total	Rank	Previous Rank
CERN-OHL-S-2.0	52	1	2 ▲
Other	46	2	1 ▼
CERN-OHL-P-2.0	35	3	4 ▲
CC-BY-SA-4.0	25	4	3 ▼
GPL-3.0-or-later	19	5	7 ▲
CERN-OHL-W-2.0	17	6	5 ▼
CC-BY-4.0	5	7	8 ▲
GPL-3.0-only	4	8	10 ▲
CERN	4	9	11 ▲
MIT	3	10
TAPR	2	11	9 ▼
CERN-OHL-1.2	1	12	6 ▼
Solderpad	1	13
CC0-1.0	1	14	12 ▼

Hardware Licenses 2024

License	Total	Rank	Previous Rank
Other	87	1	1
CERN-OHL-S-2.0	77	2	4 ▲
CC-BY-SA-4.0	60	3	5 ▲
CERN-OHL-P-2.0	19	4	6 ▲
CERN-OHL-W-2.0	15	5	8 ▲
CERN-OHL-1.2	14	6	9 ▲
GPL-3.0-or-later	13	7	7
CC-BY-4.0	10	8	10 ▲
TAPR	9	9	3 ▼
GPL-3.0-only	6	10	11 ▲
CERN	5	11	2 ▼
CC0-1.0	4	12	14 ▲
GPL	1	13	12 ▼

Hardware Licenses 2023

License	Total	Rank	Previous Rank
Other	211	1	1
CERN	195	2	8 ▲
TAPR	110	3	14 ▲
CERN-OHL-S-2.0	52	4	2 ▼
CC-BY-SA-4.0	32	5	4 ▼
CERN-OHL-P-2.0	20	6	3 ▼
GPL-3.0-or-later	13	7	9 ▲
CERN-OHL-W-2.0	10	8	5 ▼
CERN-OHL-1.2	10	9	7 ▼
CC-BY-4.0	7	10	6 ▼
GPL-3.0-only	4	11	11
GPL	3	12	10 ▼
Solderpad	3	13	13
CC0-1.0	2	14	12 ▼

Hardware Licenses 2022

License	Total	Rank	Previous Rank
Other	83	1	2 ▲
CERN-OHL-S-2.0	36	2	4 ▲
CERN-OHL-P-2.0	26	3	6 ▲
CC-BY-SA-4.0	25	4
CERN-OHL-W-2.0	12	5	8 ▲
CC-BY-4.0	9	6
CERN-OHL-1.2	9	7	3 ▼
CERN	8	8	1 ▼
GPL-3.0-or-later	7	9
GPL	3	10
GPL-3.0-only	3	11
CC0-1.0	2	12
Solderpad	2	13	5 ▼
TAPR	1	14	7 ▼

Hardware Licenses 2021

License	Total	Rank	Previous Rank
CERN	195	1	2 ▲
Other	133	2	1 ▼
CERN-OHL-1.2	16	3
CERN-OHL-S-2.0	14	4
Solderpad	11	5	4 ▼
CERN-OHL-P-2.0	8	6
TAPR	8	7	3 ▼
CERN-OHL-W-2.0	7	8

Hardware Licenses 2020

License	Total	Rank	Previous Rank
Other	552	1	1
CERN	397	2	2
TAPR	6	3	3
Solderpad	2	4

Hardware Licenses 2019

License	Total	Rank	Previous Rank
Other	93	1	1
CERN	37	2	2
TAPR	5	3	3

Hardware Licenses 2018

License	Total	Rank	Previous Rank
Other	86	1	1
CERN	13	2	2
TAPR	3	3

Hardware Licenses 2017

License	Total	Rank	Previous Rank
Other	37	1	1
CERN	10	2	2

Hardware Licenses 2016

License	Total	Rank
Other	79	1
CERN	6	2
TAPR	2	3

Software Licenses

It should come as no surprise that traditional open source software licenses dominate this list, with MIT and GPL at the top. Given how relatively popular the CERN licenses are for hardware, and the fact that the CERN licenses include software within its definition of "source," it is notable how low the CERN licenses rank in these charts. This may mean that people are deciding to use a different, additional license for their software. It may also mean that OSHWA certifiers are more fluent in open source software licenses, and are therefore comfortable with the idea of picking a different license for their software.

The other notable entry on the list is the No software option. This likely reflects two factors. First, many certified projects are relatively simple boards that do not need additional firmware (or simply use widely available open source firmware maintained by others). Second, there is a lot of certified open source hardware that is not electronics! I'm looking at you, Touch Grass.

Software Licenses 2025 (so far)

License	Total	Rank	Previous Rank
MIT	79	1	1
GPL-3.0-or-later	35	2	2
No software	33	3	3
GPL	15	4	7 ▲
GPL-3.0-only	14	5	6 ▲
CC-BY-SA-4.0	13	6	4 ▼
Apache	7	7	5 ▼
CERN-OHL-S-2.0	5	8	11 ▲
Other	4	9	8 ▼
LGPL	3	10	12 ▲
CC-BY-4.0	3	11	10 ▼
CERN-OHL-W-2.0	3	12	14 ▲
CERN-OHL-P-2.0	1	13	9 ▼

Software Licenses 2024

License	Total	Rank	Previous Rank
MIT	103	1	1
GPL-3.0-or-later	71	2	4 ▲
No software	51	3	2 ▼
CC-BY-SA-4.0	43	4	9 ▲
Apache	10	5	5
GPL-3.0-only	10	6	7 ▲
GPL	10	7	3 ▼
Other	6	8	6 ▼
CERN-OHL-P-2.0	4	9	11 ▲
CC-BY-4.0	4	10	10
CERN-OHL-S-2.0	3	11	8 ▼
LGPL	2	12	14 ▲
Mozilla	2	13
CERN-OHL-W-2.0	1	14	12 ▼

Software Licenses 2023

License	Total	Rank	Previous Rank
MIT	401	1	1
No software	114	2	2
GPL	68	3	4 ▲
GPL-3.0-or-later	32	4	3 ▼
Apache	14	5	9 ▲
Other	12	6	6
GPL-3.0-only	9	7	5 ▼
CERN-OHL-S-2.0	7	8	8
CC-BY-SA-4.0	6	9	7 ▼
CC-BY-4.0	4	10	12 ▲
CERN-OHL-P-2.0	2	11	11
CERN-OHL-W-2.0	1	12	10 ▼
CC0-1.0	1	13	14 ▲
LGPL	1	14	13 ▼

Software Licenses 2022

License	Total	Rank	Previous Rank
MIT	98	1	1
No software	38	2	3 ▲
GPL-3.0-or-later	23	3
GPL	20	4	2 ▼
GPL-3.0-only	9	5
Other	9	6	4 ▼
CC-BY-SA-4.0	8	7
CERN-OHL-S-2.0	7	8	8
Apache	4	9	5 ▼
CERN-OHL-W-2.0	3	10
CERN-OHL-P-2.0	2	11
CC-BY-4.0	2	12
LGPL	2	13	6 ▼
CC0-1.0	1	14

Software Licenses 2021

License	Total	Rank	Previous Rank
MIT	232	1	1
GPL	67	2	3 ▲
No software	60	3	2 ▼
Other	14	4	4
Apache	10	5	6 ▲
LGPL	7	6	5 ▼
Mozilla	1	7
CERN-OHL-S-2.0	1	8

Software Licenses 2020

License	Total	Rank	Previous Rank
MIT	708	1	3 ▲
No software	147	2	2
GPL	59	3	1 ▼
Other	25	4	5 ▲
LGPL	14	5	6 ▲
Apache	4	6	4 ▼

Software Licenses 2019

License	Total	Rank	Previous Rank
GPL	68	1	3 ▲
No software	35	2	2
MIT	16	3	4 ▲
Apache	8	4	6 ▲
Other	5	5	1 ▼
LGPL	3	6	5 ▼

Software Licenses 2018

License	Total	Rank	Previous Rank
Other	35	1	1
No software	30	2	2
GPL	22	3	3
MIT	6	4	4
LGPL	5	5
Apache	2	6	5 ▼
GPL-3.0-only	2	7

Software Licenses 2017

License	Total	Rank	Previous Rank
Other	21	1	1
No software	10	2	4 ▲
GPL	8	3	2 ▼
MIT	7	4	3 ▼
Apache	1	5	5

Software Licenses 2016

License	Total	Rank
Other	42	1
GPL	21	2
MIT	13	3
No software	7	4
Apache	2	5
LGPL	2	6

Documentation Licenses

The documentation license charts are essentially a mirror image of the software license charts. Well known Creative Commons licenses dominate, with notable appearances by popular open source software licenses that are presumably applied globally to all elements of the hardware. The CERN licenses are also well represented, with a similar proviso to the software section: CERN licenses applied to hardware also cover any documentation required to make, test, or prepare the hardware for use. That's not quite as expansive as its coverage with regard to software, but it still probably sweeps in a decent portion of most documentation.

Documentation Licenses 2025 (so far)

License	Total	Rank	Previous Rank
CC BY-SA	48	1	2 ▲
CC-BY-SA-4.0	45	2	1 ▼
CC-BY-4.0	32	3	3
GPL-3.0-or-later	20	4	4
Other	18	5	5
CERN-OHL-P-2.0	14	6	10 ▲
CERN-OHL-S-2.0	13	7	6 ▼
GPL-3.0-only	6	8	8
CERN-OHL-W-2.0	5	9	12 ▲
CC BY	3	10	7 ▼
CC 0	3	11	13 ▲
MIT	3	12
GPL	3	13	11 ▼
CC0-1.0	2	14	9 ▼

Documentation Licenses 2024

License	Total	Rank	Previous Rank
CC-BY-SA-4.0	134	1	2 ▲
CC BY-SA	90	2	1 ▼
CC-BY-4.0	17	3	4 ▲
GPL-3.0-or-later	16	4	5 ▲
Other	15	5	3 ▼
CERN-OHL-S-2.0	10	6	6
CC BY	9	7	7
GPL-3.0-only	9	8	9 ▲
CC0-1.0	7	9	8 ▼
CERN-OHL-P-2.0	5	10	11 ▲
GPL	4	11	10 ▼
CERN-OHL-W-2.0	3	12	13 ▲
CC 0	1	13	12 ▼

Documentation Licenses 2023

License	Total	Rank	Previous Rank
CC BY-SA	485	1	1
CC-BY-SA-4.0	55	2	2
Other	33	3	4 ▲
CC-BY-4.0	25	4	3 ▼
GPL-3.0-or-later	17	5	8 ▲
CERN-OHL-S-2.0	13	6	5 ▼
CC BY	10	7	6 ▼
CC0-1.0	8	8	10 ▲
GPL-3.0-only	7	9	12 ▲
GPL	6	10	11 ▲
CERN-OHL-P-2.0	6	11	7 ▼
CC 0	6	12
CERN-OHL-W-2.0	1	13	9 ▼

Documentation Licenses 2022

License	Total	Rank	Previous Rank
CC BY-SA	85	1	1
CC-BY-SA-4.0	41	2
CC-BY-4.0	28	3
Other	23	4	2 ▼
CERN-OHL-S-2.0	14	5	5
CC BY	9	6	3 ▼
CERN-OHL-P-2.0	6	7
GPL-3.0-or-later	6	8
CERN-OHL-W-2.0	5	9	6 ▼
CC0-1.0	4	10
GPL	3	11
GPL-3.0-only	2	12

Documentation Licenses 2021

License	Total	Rank	Previous Rank
CC BY-SA	311	1	1
Other	39	2	3 ▲
CC BY	32	3	2 ▼
CC 0	7	4	4
CERN-OHL-S-2.0	2	5
CERN-OHL-W-2.0	1	6

Documentation Licenses 2020

License	Total	Rank	Previous Rank
CC BY-SA	844	1	1
CC BY	60	2	3 ▲
Other	44	3	2 ▼
CC 0	9	4	4

Documentation Licenses 2019

License	Total	Rank	Previous Rank
CC BY-SA	90	1	1
Other	32	2	2
CC BY	11	3	3
CC 0	2	4

Documentation Licenses 2018

License	Total	Rank	Previous Rank
CC BY-SA	62	1	2 ▲
Other	38	2	1 ▼
CC BY	2	3	3

Documentation Licenses 2017

License	Total	Rank	Previous Rank
Other	22	1	2 ▲
CC BY-SA	20	2	1 ▼
CC BY	5	3	3

Documentation Licenses 2016

License	Total	Rank
CC BY-SA	60	1
Other	23	2
CC BY	4	3

Feature image: Shop Scene from the Smithsonian Open Access collection

Locked Down Etextbooks Are Also Bad in Italy

Fri, 03 Oct 2025 00:00:00 +0000

The Italian Competition and Market Authority is currently investigating behavior in Italy’s textbook industry. I recently filed a brief comment flagging issues that might be worth exploring in the etextbook space.

The Authority’s Preliminary Report (Executive Summary in English - thanks AGCM!) gives an overview of what they have been looking into. The full Preliminary Report spends time documenting limitations that the small number of italian textbook publishers are placing on etextbooks and digital materials associated with regular textbooks (see paragraphs 250-272). This includes locking readers into proprietary reading software that limits functionality (like annotating), severely restricting printing, and making it all but impossible to share portions of textbooks with others. This behavior is familiar from the Anti-Ownership Ebook Economy whitepaper from a few years ago.

The Authority has the ability to make fairly robust interventions in the market, which could make things interesting. In my comment, I focused on three main points:

Ways in which the transition to digital has allowed publishers to rebalance power between publishers and readers,
Reminding the Authority that ebooks (and all digital goods) can, in fact, be sold in addition to being licensed, and
Licensed markets can still be much more flexible than the one that currently exists in Italy

We’ll see what happens next once the Authority completes its review.

Feature image: Design for the letters Y and Z of a primer: Yacht/ Zéphir (Yachts driven by Zephyrs) from the Smithsonian Open Access collection

Music Competition Without Copyright

Tue, 16 Sep 2025 00:00:00 +0000

What does competition in the world of music look like without copyright? We may be on the cusp of finding out.

Over the summer Emanuel Maiberg published a story on 404 Media about Spotify publishing AI-Generated songs attributed to dead artists that have nothing do to with the artists. The story captures the dystopia of managing cultural data at scale, but also contains this interesting (to me) note about trying to track down the source of the not-from-the-artist songs:

There’s a copyright mark at the bottom of the Spotify page for the AI-generated “Together” from a company called Syntax Error.

Why is this interesting? Because, as things stand right now, AI generated works are not eligible for copyright protection. Anyone could download and repost an AI generated song on their own Spotify artist page without infringing on any copyright.

This may not matter very much for this particular song, but it isn’t hard to imagine a situation where multiple AI-powered artists are pumping out the hits. If that becomes a reality, anyone can copy RobotBand’s Robot Party Hit #1, post it to their own artist page (or youtube channel or tiktok account or whatever) and start monetizing it without infringing on copyright.

What could the originator of the song do? Maybe not that much.

Copyright?

If the song is AI generated, the human team that runs the original "artist" account can’t bring a copyright infringement claim. The song is not protected by copyright so it is in the public domain. That means no copyright infringement lawsuit, or even sending a DMCA takedown targeting the uploader. You don’t even need to pretend that you made the copy via psycho-acoustic simulation

Of course, the team may argue that the song is collaboratively written between them and AI, so the human contributed elements get copyright protection. That argument has had mixed success thus far, and is fairly fact-dependent. So I don't want to dismiss the possibility out of hand, but that would pull the song outside the scope of this blog post.

Trademark?

I may not be infringing on any copyrights if I copy Robot Party Hit #1 and release it on my own Spotify artist page, but am I infringing on RobotBand’s trademark? There is a claim in trademark law called “reverse passing off” where you sell someone else’s goods under your own name. Is that happening here? Maybe? But the Supreme Court has been wary of attempts to use trademark to control things in the public domain.

Beyond that, the USPTO actually has a page all about trademarking band names. That page says that goods featuring musical recordings can be registered under International Class 009. But those registrations aren’t for the song itself. Some sounds can be registered as source identifiers (more examples from the USPTO) but, again, those sound marks are things like the NBC chimes - not a pop song.

DMCA (1201)?

What about a DMCA Section 1201 claim? That provision prevents circumventing technical protection measures (aka DRM) to access a work. I would probably need to circumvent a technical protection measure to download RobotBand’s song from Spotify in the first place. Could RobotBand bring a 1201 claim against me?

Nope. 1201’s prohibitions against circumventing a technological measure only apply to measures “that effectively control[] access to a work protected under this title,” which is to say a work that is protected by copyright law. The whole premise of this post is that the song is not protected by copyright law, so no 1201 problem.

ToS?

What about Spotify’s Terms of Service? Even if it does not violate Section 1201 or copyright law, downloading a song directly from Spotify likely violates its Terms of Service.

This could be a problem for the downloader, but it is also a problem for RobotBand. If the downloader is violating Spotify’s Terms of Service, that’s not something that RobotBand can deal with directly. Spotify could decide to sue the downloader for violating its ToS. It would not be so easy for RobotBand to do the same thing (although maybe they are a third party beneficiary with an enforceable interest)?

Payola?

This might be the most straightforward solution: if every Spotify artist can release Robot Party Hit #1, the most successful one might be the one who pays Spotify for the most prominent placement.

But even that raises some interesting questions about pricing. If the winning version of Robot Party Hit #1 could expect $1.00 in Spotify royalties, a competitive market would drive the amount an artist is willing to pay Spotify for that winning spot up to $0.99. Unless, of course, there were collateral ways to monetize being the most prominent source of Robot Party Hit #1. Or Spotify figured out that it was more profitable to just run the song under their own house band name. What would those ways look like? I’m not sure.

This is all very back-of-the-envelope stuff, and I have no idea how (or if) any of it will manifest. But it is an interesting thought experiment, and one that might play out in the real world before too long.

Feature image: Musician and Dog from the Smithsonian Open Access collection

Which CERN Open Hardware License Should I Use?

Fri, 08 Aug 2025 00:00:00 +0000

Trying to decide which open hardware license to use? Not super interested in actually reading the text of licenses? You have come to the right place. There are a bunch of caveats at the bottom of this post, but let’s get to the heart of things.

You Probably Want to Use a CERN License

While there are number of open hardware licenses, CERN (yes, that CERN) has released what is the most modern and sophisticated suite of them. If you are looking for a license that will basically do what you expect without thinking too much about it, and don’t have an existing preference for another license, this is where you should start.

CERN’s Version 2.0 suite includes three flavors of licenses:

CERN-OHL-P (permissive) (text user guide)
CERN-OHL-W (weakly reciprocal) (text user guide)
CERN-OHL-S (strongly reciprocal) (text user guide)

Which one should you use?

You should use CERN-OHL-P if…

you want people to give you credit for creating your hardware, and not require very much else. P’s main requirement is that anyone who uses or builds upon your hardware keep the original “notices” intact. What are “notices”? Mostly the acknowledgements that you created the original version, as well as the disclaimer of warranties. Beyond that, they can more or less do as they please.

Open Source Source Software License Equivalents

P is conceptually similar to licenses like MIT or BSD.

You should use CERN-OHL-W if …

you want people to:

give you credit for creating your hardware AND
openly license their own modifications to your hardware BUT
not require that larger projects incorporating your hardware become openly licensed too.

In addition to keeping notices, W’s “weak” reciprocity means that any modifications need to be openly licensed as well. That reciprocity is weak because it does not extend to situations where your smaller hardware is incorporated into larger hardware.

For example, imagine you created a small piece of hardware that controls a robotic eye socket. If someone modified your robot eye socket hardware, their new version would have to be openly licensed. However, if they plugged your robot eye socket hardware into their own Giant Death Robot, the rest of the Giant Death Robot would not need to be openly licensed just because it incorporated your open element.

Open Source Source Software License Equivalents

W is conceptually similar to licenses like the LGPL.

You should use CERN-OHL-S if…

you want people to:

give you credit for creating your hardware AND
openly license their own modifications to your hardware AND
require that larger projects incorporating your hardware become openly licensed too.

The reciprocity in S is strong because it extends to any hardware that incorporates your hardware. If the Giant Death Robot incorporated your CERN-OHL-S licensed eye socket, the entire robot would need to be released under that license as well.

Open Source Source Software License Equivalents

W is conceptually similar to licenses like the GPL.

More Information

This blog post is short and just skims the surface of these licenses. If you want more detail, CERN itself has a great rationale document explaining why they created this version of the licenses, and FAQ related to them. There are also user guides for each license, and a separate best practices document from their Open Source Program Office.

ChooseALicense.com also has pages for the P, W, and S licenses.

And, of course, OSHWA has a whole suite of materials about how to think about licensing and open source hardware (click on the “licensing” tab), as well as a best practices document.

Finally, you can just read the licenses themselves.

Caveats

There are two important caveats to this post.

First, even though I am a lawyer, I am not your lawyer and this post is not legal advice. If you have questions about the specifics of licensing your hardware, trust your instincts and talk to a lawyer who can actually be your lawyer.

Second, analogies between open source software licensing and open source hardware licensing are helpful but imperfect. The most practical impact of this imperfection is that creators of hardware may not always be able to legally enforce licensing obligations (like a requirement for open Giant Killer Robots) on downstream users. On balance this is a positive thing because it marks the limits of copyright, but it can create some confusion. There is more information about these limits here and here.

Open source hardware licensing is still valuable! It just works slightly differently than open source software licenses. The best way to think about open source hardware licenses is that they:

Remove potential legal barriers to good actors
Send strong social signals about how you want your hardware to be used
May impose obligations on other users, but those obligations are not guaranteed to be legally enforceable in all situations (again, this is a situation where talking to a lawyer can give you real clarity).

Feature image: Shop Scene from the Smithsonian Open Access collection

Are AI Bots Knocking Cultural Heritage Offline?

Wed, 25 Jun 2025 00:00:00 +0000

Last week the GLAM-E Lab released a new report Are AI Bots Knocking Cultural Heritage Offline?. The short answer seems to be “yes”. The longer answer fills a report.

The report exists because we started seeing one-off accounts from online cultural heritage collections that swarms of bots were knocking the collections offline. The bots were overwhelming the site as they scraped it for data to include in the datasets used to train AI models. The goal of the report is to start to understand if these stories were outliers, or just the early rumblings of something bigger.

After talking to dozens of cultural institutions around the world, it is pretty clear that the early descriptions were the early rumblings of something bigger. The online collections are starting to strain, and things might be worse before they get better.

While this is bad, I do think there is some room for optimism. In the medium- to long-term, it is in everyone’s interest to keep these collections online. The entities scraping the collections want them to remain available so that they can keep scraping them, and the entities that support the collections want them to remain available because it is part of their mission. The current practice of swarming large numbers of bots in short periods of time (thus creating an overwhelming amount of traffic) could easily be spread out over a sustainable longer period of time. As the players creating these datasets stabilizes, it is not hard to imagine incentives aligning to adopt some sort of crawl-delay standard.

I also think this is an interesting problem because it is (at least conceptually) severable from more complex debates around the relationship between these collections and generative AI more broadly. Those debates – which the report describes broadly as “policy” debates – center on the nature of open collections, what it means for the commons to be integrated into models, and how (or if) copyright is relevant to that conversation. In contrast, this problem is more technical in nature: how do we keep collections online and available in a sustainable way?

The report has a lot more detail on what collections are experiencing right now. I hope it acts as a useful snapshot of a moment in time that can be used as a reference point in the future.

Does an AI Dataset of Openly Licensed Works Matter?

Thu, 12 Jun 2025 00:00:00 +0000

A team just announced the release of the Common Pile, a large dataset for training large language models (LLMs). Unlike other datasets, Common Pile is built exclusively on “openly licensed text.” On one hand, this is an interesting effort to build a new type of training dataset that illustrates how even the “easy” parts of this process are actually hard. On the other hand, I worry that some people read “openly licensed training dataset” as the equivalent of (or very close to) “LLM free of copyright issues.”

There is an active fight over whether or not training an LLM on data infringes on the copyright in that data. If the activity is protected by fair use (in the US) the license on the work does not matter because the trainer does not need permission from the rightsholder. If the activity is not protected by fair use, the license on the work matters a lot. The only way to train without infringing would be to do so within the scope of a license (open, closed, or otherwise).

In response to this, there are a number of efforts to build openly licensed datasets. The theory is that, if it turns out that training models requires permission from the data rightsholders, open data comes with that permission built in.

There are a few problems, or at least complications, with this approach. I am not suggesting that the Common Pile team in particular has failed to wrestle with these. Instead, this is a generalized list of problems that have come up across conversions around open training datasets.

Openly licensed does not mean free from restrictions. Very few open licenses are public domain dedications. At a minimum, most of them require some sort of attribution to the original creator.
It is not clear what attribution means in the case of LLMs or their outputs. At least conceptually, including attribution information in a dataset is fairly straightforward - it’s just metadata. That is less straightforward when it comes to the models themselves. What does it mean to give attribution to the 2 trillion tokens used to train a model? Attribution is even harder when it comes to outputs. What’s the best way for an output to provide attribution for the 2 trillion tokens involved in training the model that produced it? And these are just the easy cases. These questions get harder the more you think about them.
Do we even want to import attribution practices into training datasets? The core concept of attribution has proven to be incredibly useful across a range of open communities. However, it may not be the right solution to every problem. I keep coming back to a post by Kate Downing that points out that attribution requirements for open source software does not necessarily scale very well. If we know attribution does not scale well at the scale of open source software, do we want to bring it into the exponentially larger LLM context? Maybe? But also maybe not? It strikes me as a question that deserves more thought before we just assume it makes sense.

If there is not a way to comply with requirements of an open license, is spending time building an openly licensed training dataset worthwhile?

The answer may very well be “yes”. However, I worry that there is a tendency to jump directly from “this is an openly licensed dataset” to “we can use it without worrying about copyright”. At a minimum, there is value in articulating how an openly licensed dataset would interact with a goal of creating a model free from copyright-based constraints. Of course, I’m always going to say that people need to spend more time thinking about the copyright aspects of their work…

Coming back to the Common Pile paper specifically, as I mentioned at the top, it does a great job of showing how even easy things are hard. Faced with the challenge of building an openly licensed dataset, it is intuitive to start with platforms that host a lot of openly licensed content. Section 2 of the paper is all about the traps waiting for you on those platforms. What about people who post things under an open license when they are not the rightsholders? Which licenses count as open? What about collection-level licenses that do not reflect the licensing of the included works?

This stuff is hard enough to do by hand that I wrote a whole blog post about clearing a single image from a training dataset. What should it mean when someone makes the inevitable mistakes at scale? If the dataset has 2 billion tokens, how many not-actually-openly-licensed tokens should spoil the set? 10? 10 million? What if the 10 are owned by Disney?

Hero Image: A portion of "Kriegsanleihe" from the Smithsonian Open Access Collection

Pi-Powered Berlin BVG Alerts

Sat, 08 Mar 2025 00:00:00 +0000

Moving from NYC to Berlin gave me an excuse to update my old Pi-Powered MTA Subway Alerts project for the BVG. Now, as then, the goal of the project is to answer the question “if I leave my house now, how long will I have to wait for my subway train?”. Although, in this case, instead of just answering that question about the subway train, it also answers it for trams.

The full repo is available here.

The project uses a raspberry pi zero to connect to the BVG real time arrival data with neopixels. The neopixels give you an indication of how far trains are away from the station. Importantly, the alerts are not based on the absolute time until the train arrives at the station (”A train will arrive at the station in 5 minutes”). Instead, the alerts are aware of how long it takes to walk to the station from my apartment and are therefore based on the time from the station when you get there (”If you leave now and walk to the station, there will be a train arriving in the station 5 minutes after you get there.”).

For example, the strip coming down from the top represents the southbound M10 tram. The light at the bottom of that strip (the light closest to the center) will be on when the tram is coming "now," with "now" being defined as "if you leave the apartment now and start walking towards the station, the tram will be at the platform when you get there." Similarly, "2 minutes" means "you can wait 2 minutes to leave" or "you will wait at the station for 2 minutes if you leave now."

Everything is basically the same as the MTA version of the project, except that I am using a strip of LEDs instead of individually soldering them. This is much easier!

Install Neopixels on Pi

There are some tricks to setting up the neopixels to work on the pi. Here are the steps, which are spread across a few adafruit explainers:

Install blinka library to be able to use circutpython : https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/installing-circuitpython-on-raspberry-pi (You need to turn on the virtual environment every time: source env/bin/activate)
install neopixel library: https://learn.adafruit.com/neopixels-on-raspberry-pi/python-usage
do the things required to use sudo for the neopixel library: https://learn.adafruit.com/python-virtual-environment-usage-on-raspberry-pi/usage-with-sudo (sudo -E env PATH=$PATH python3 neo_test.py)
make it run at startup: https://learn.adafruit.com/python-virtual-environment-usage-on-raspberry-pi/automatically-running-at-boot

The Code

The code starts with a bunch of settings, including the station you are pulling data about, how long it takes to get from wherever you are to the platforms, and lists for the lines you are tracking.

grabber()

After that, the code is basically two functions. grabber() gets all of the departure times related to the lines and puts them in the lists. Before putting each departure time in the list, it adjusts it based on the travel time. For example, if your tram_walk_time is 6 and a tram is scheduled to leave in 10 minutes, grabber() will add it to the list as 4 because, by the time you walk to the station, the train will be leaving in 4 minutes.

If you are customizing this, you will need to update all of the if statements that parse the train info so they are pulling data for the correct lines and directions. For example, here is the if statement for the U5:

if i['line']['name'] == 'U5':
     if i['direction'] == 'Hönow':
          u5_eastbound.append(get_modified_departure_time(i['when'], i['line']['productName']))
     elif i['direction'] == "S+U Hauptbahnhof" or "Hauptbahnhof":
          u5_westbound.append(get_modified_departure_time(i['when'], i['line']['productName']))
     else:
          error_direction = i['direction']
          print(f'unexpected U5 direction: {error_direction}')

first it finds all of the entries for the U5:

if i['line']['name'] == 'U5':

then it looks for trains in the direction of Hönow:

if i['direction'] == 'Hönow':

then it runs the get_modified_departure_time() function to get the modified departure time (the actual departure time modified by how long it takes to get to the station) and appends it to the u5_eastbound list created at the top of the script.

The same thing happens for trains headed towards Hauptbahnhof, with an error message if something goes wrong.

Once grabber() is done, each of the line lists are full of modified times for trains.

lighter()

The second function, lighter() uses the lists to light up the neopixels. The logic for which lights turn on based on the train time is in this block of code:

for i in arrival_list:
     if 0 <= i <= 1:
          #light the corresponding light
          pixels[light_1] = light_color
          #remove the light from the list so it does not go black
          if light_1 in light_list: light_list.remove(light_1)
     elif 2 <= i <= 3:
          pixels[light_2] = light_color
          if light_2 in light_list: light_list.remove(light_2)
     elif 4 <= i <= 7:
          pixels[light_3] = light_color
          if light_3 in light_list: light_list.remove(light_3)
     elif 8 <= i <= 12:
          pixels[light_4] = light_color
          if light_4 in light_list: light_list.remove(light_4)
     elif 13 <= i <= 20:
          pixels[light_5] = light_color
          if light_5 in light_list: light_list.remove(light_5)
     else:
          pass

You can set the bands to be whatever you want by changing the values on the elif lines. For example

elif 2 <= i <= 3:
     pixels[light_2] = light_color
     if light_2 in light_list: light_list.remove(light_2)

means that if the train arrival time is between 2 and 3 minutes away (elif 2 <= i <= 3:), the second light for the line will turn on the appropriate color (pixels[light_2] = light_color). You could change elif 2 <= i <= 3: to elif 1 <= i <= 10: if you wanted a wider band or whatever.

The Loop

Now that the functions are set, the script just loops.

First it checks the current time:

now_time = datetime.now()

I only need the lights running during the day, so it then checks to see if the current time is between 8am and 10pm:

if 8 <= now_time.hour < 22:

If it is, it runs grabber() and then lighter() for all of the lines. In addition to giving lighter() the line argument, it identifies which actual pixel in the strip is the "first," "second," etc. pixel for that color. The strip is continuous, so the 15th pixel in an absolute sense might be the first pixel in the U5 westbound set of lights.

lighter(u5_westbound, 'u5', 15, 16, 17, 18, 19)

If it is not during the day, the pixels all turn off:

else:	
     #turn them off 
     for i in range(number_of_pixels):
          pixels[i] = (0,0,0)
     print('lights out')

Finally, the script waits for 10 seconds before doing it all again:

time.sleep(10)

that seems long enough to keep the data reasonably accurate without hammering the bvg servers.

Bluesky Bot to Translate Local News

Fri, 10 Jan 2025 00:00:00 +0000

I made a bot that automatically translates bluesky tweets* from a list of accounts into english. It is written in python.

I recently relocated to Berlin. Since I don’t speak german (yet?), I’ve been looking for ways to stay up to date with local news. There are a handful of english-language publications that cover Berlin and Germany, and I appreciate all of them. However, by necessity, they are not resourced to be comprehensive local news resources.

As you would expect, there is also a robust local german-language press. I read their sites, but since I haven’t found a way to turn on auto-translate at the domain level, there is friction in waiting to translate each story (yes, this thing is partially motivated by the comically first world problem of having to click an extra button for a robot to translate an article for me).

Bluesky has become a good way for me to get an ambient sense of what’s going on in the world, with pointers to articles that can give me more context. However, the reporters for the local press tweet in german. Fortunately, bluesky has a pretty open and robust API. What if I made a bot that posts translated tweets so they just integrate into the rest of my doom scrolling?

Workflow

You could build a bot like this by attaching to the bluesky firehose, filtering for the accounts you care about, and then going from there. However, as ‘firehose’ suggests, that requires receiving and filtering the entire stream of all bluesky posts. Fortunately, all bluesky accounts are also RSS feeds. That means I can use existing python libraries to pull data from them selectively.

The workflow for the bot starts with a list of accounts. It is an actual bluesky list that the bot account maintains, although it could be any public bluesky list.

When the python script starts, it creates objects for each of the users in the list and saves the current time. Then, every 2 minutes it checks the RSS feed for each of the accounts in the list. If the latest post in the RSS feed is newer than the time the script started, the script:

extracts the text of the tweet
sends the extracted text to the google translate API (if you have hit the daily limit on google, it rolls over to azure)
builds a new tweet that includes the source handle (with a link to the account - not a mention because I assume that would be annoying), the tweet text (including any links), and a link to the original tweet
resets the “is the latest post time newer than” time to the time of that post, so it knows not to deal with the account again until there is an even newer post

As of now, the bot does not support RT/comments or images because those do not show up in the RSS feeds.

The Code

The full repo is here.

Importing Secrets

The script itself starts by importing a bunch of libraries, including a local library. That library is a separate file called secrets.py. As the name suggests, this is where user-specific secrets live.

If you are using this yourself, you can open example-secrets.py:

translation_api_key = 'YOUR GOOGLE TRANSLATE API KEY'
user_name = 'ACCOUNT NAME (NO @ SYMBOL)'
password = 'PASSWORD'
azure_key = 'YOUR AZURE KEY'
azure_location = 'YOUR AZURE LOCATION'
azure_endpoint = 'YOUR AZURE ENDPOINT'

add your personal variables, and save it as secrets.py. The user_name and password are for the bluesky account you want to do the tweeting (make sure you have an app-specific password for this, not your general bluesky account password). translation_api_key is for the google translate account that will be doing the translating. THe azure related variables are for the azure account.

Variables and Initial Setup

The next chunk of code sets up some initial variables. It sets the language to translate to, imports the api keys, and initializes the bluesky client. The last thing it does is identify the list of accounts to be followed. For example, my bot follows this list: https://bsky.app/profile/berlin-news-en.bsky.social/lists/3lg424mfsl42l. Using native bluesky lists makes it easy to add new accounts to the bot.

Azure Translation Setup

The next section sets up headers and variables for the Azure translation. Both Google and Azure have free tiers of their translation API. Since tweets are definitionally small amounts of data, it should be easy to stay below the limits. The bot is currently set up to start with google and then roll over to Azure once the limit is set, but you could also just switch the sequence.

Getting the Users

The first thing that the code really does is create a bunch of user objects. Each object represents a user and has elements: user_name, last_post_time, rss_url, target_profile_url, and DID. These objects are added to the user_holder list. The functions in this section get the usernames from the list, pull the relevant RSS feed urls (which is buried in the source code for each user profile page), and sets the last_post_time. For reasons that I do not fully understand, the RSS feed of a small subset of public bluesky accounts returns a 403 error. If the rss url does not exist, or if it does exist but only throws an error, the account is not added to the user_holder list:

     if rss_url == 'error':
          print("did not create object for " +i + " because the link did not exist")
     elif feedparser.parse(rss_url).status == 403:
          print("did not create object for " +i + " because the link threw a 403 error")
     else:'

          user_holder.append(User(i, last_post_time, rss_url, target_profile_url, user_DID))
          #this is just a better way to confirm things are working at startup
          print(f'created object for {i}')

It also repeats this action at the start of every loop, so it will pick up accounts that have been added to the list while it is running

Get Tweets, Translate Them, and Post

When the script starts, it sets the last post time for each account at that moment. Every 2 minutes, it checks to see if there is a tweet that was posted more recently than that last post time. If so, pulls the text of the new tweet, sends it to be translated, puts together a new tweet, sends it out, and updates the last post time accordingly. The functions that do that are reasonably well labeled, but there are some things worth flagging:

The translation APIs have problems with quotes and hashes, so they are replaced before they are sent to translation (uncleaned_translated_text)
Since I've set a daily character translation limit in the google translation API, it will throw an error after hitting the limit. That's why the try - except in the translate_tweet_text function works.
There is also some code to handle things like URLs, which case problems with translation (especially when the text of the tweet needs to be broken up)
In an attempt to minimize overly-long tweets, it replaces full urls with a hyperlinked link, and also tags mentioned accounts so that you can click through to them
The new tweet includes the username of the original tweeter. That can make it too long to fit into a single tweet. The script will check the length of the new tweet and break it up into two tweets of necessary. It does this by trying to send the tweet and, if doing so throws an error, using one_tweet_to_two_tweets to turn it into two tweets.

Running

The script will loop every 2 minutes until it crashes. Each loop it will provide an update on new accounts (usually no new accounts in list), how many times it has looped since the start (loop_counter is now 39), and how many tweets it has sent out since the start (change_counter is now 3). It uses change_counter for the last message because each time it sends a tweet it updates the last_post_time for that account.

I've found this to be relatively stable for the past few months. The biggest problem I have right now is that when it crashes it just stops tweeting. That means it usually takes me a few days to realize that it's gone.

One other strange thing I've noticed is that other accounts are responding to some of the tweets (see https://bsky.app/notifications). I more or less assume that these are bots designed to search out any keywords, but I have no idea what's really going on there.

All posts to text-based social media platforms are tweets. When Twitter became X, ‘tweet’ became a generic term. That’s my personal canon.

Feature image: German mail coach model from the Smithsonian Open Access Collection.

New Open GLAM Toolkit & Open GLAM Survey from the GLAM-E Lab

Fri, 13 Dec 2024 00:00:00 +0000

This post originally appeared on the Engelberg Center blog

Today the GLAM-E Lab, a collaborative project between the Engelberg Center and the University of Exeter (UK), is releasing a number of tools and resources for the open GLAM (Galleries, Libraries, Archives, and Museum) community.

First, the GLAM-E Lab has launched an Open GLAM Toolkit! This suite of tools, developed directly with GLAM organizations, can be used by any cultural organization to develop their own access program and release collections for public reuse. The toolkit even includes templates for model internal and external open access policies for setting up new workflows and website policies.

Second, today the GLAM-E Lab has also launched a website-based version of the Open GLAM Survey. The Survey’s new format makes it much easier to find, explore, and analyze open GLAM organizations around the world than was previously possible via the Google Spreadsheet format.

Third, both of these are only possible because of our collaborators’ engagement. The GLAM-E Lab model is to work directly with GLAM organizations to remove legal barriers to creating open access programs, and convert that work into the standard toolkits that other organizations can use. We set a goal to work with 24 different GLAM organizations by the end of 2024, and we’ve even exceeded that goal!

Finally, all of this work led to the GLAM-E Lab winning Wikimedia UK’s Partnership of the Year Award for 2024!

You can watch our announcement video on YouTube and find more details below on these announcements. Of course, if you or someone else would be interested in working with us in 2025, please let us know!

OpenGLAM Toolkit

The Open GLAM Toolkit is built on everything that we have learned from working with GLAM-E Lab collaborators. When used together, the toolkit resources will help cultural organizations identify, prepare, and publish their digital collections for open access using public domain or other machine readable statements. It includes:

The Onboarding Document introduces users to the GLAM-E Lab method of building an open access program. It gives you a clearer picture of what open means in practice for you, your institution, your collections, and your community.
Assessing and Mitigating Risk provides an overview of how to set and apply risk tolerances and takedown procedures for images and data.
The Copyright Clearance Handbook for Public Domain Publication of Digital Collections and Copyright Clearance Log guides users through the process of clearing copyright with the goal of assigning the CC0 1.0 Universal Public Domain Dedication when it is appropriate and lawful to do so. Once copyright is cleared, they can then add the creator or work to the Copyright Clearance Log to document the copyright status.
The Image and Metadata Handbook for Wikimedia Commons and Sandbox Template for Wikimedia Commons Metadata Management guides users through the process of organizing their images and metadata for upload to Wikimedia Commons.
Selecting an Alternative License or Label addresses which machine readable statements to use when CC0 cannot be applied.
The Glossary provides a list of terms used across GLAM-E Lab resources.

OpenGLAM Survey 2.0

Version 2.0 of the OpenGLAM Survey brings the OpenGLAM Survey to a new, more user-friendly interface. You can sort organizations by type, licenses and the platforms used. The new interface also makes it easier for us to expand the survey and keep its data up to date.

We’ve Collaborated with More than 24 Organizations!

The GLAM-E Lab model is simple: work directly with individual organizations to remove legal barriers to open access programs, and turn what we learn during that work into standard tools and documents that organizations of any size can use.

Of course, all of this depends on having organizations that are open to tackling collections management issues with us in the first place. That’s why we are so excited to wrap up 2024 having worked with over 24 organizations on rights related issues and questions on open access. You can find the list of collaborators on the GLAM-E site.

hero image: Gereedschappen voor het vervaardigen van een mezzotint from the Rijksmuseum collection.

What Does an Open Source Hardware Company Owe The Community When it Walks Away?

Thu, 21 Nov 2024 00:00:00 +0000

This week Prusa Research, once one of the most prominent commercial members of the open source hardware community, announced its latest 3D printer. The printer is decidedly not open source.

That’s fine? My support of, and interest in, open source hardware is not religious. I think open source hardware can be an incredibly effective tool to achieve a number of goals. But no tool is fit for all purposes. If circumstances change, and open source hardware no longer makes sense, people and companies should be allowed to change their strategies as long as they are clear that is what they are doing. Hackaday does a good job of covering the Prusa-specific developments, and Phil has covered other examples (I hesitate to call it a ‘larger trend’ because I don’t think that’s quite right) on Adafruit.

Still, I do believe a company that builds itself on open hardware owes the community an honest reckoning as it walks out the door. Call it one last blast of openness for old time’s sake.

Specifically, I think the company should explain why openness does not work for them anymore. And not just by waiving their hands while chanting vaguely about unfair copying or cloning. They should seriously engage with the issue, explaining how their approach was designed, what challenges it faced, and why open strategies were not up to the task for overcoming those strategies.

This discussion and disclosure is not a punishment for walking away from open, or an opportunity for the community to get a few last licks in. Instead, it is about giving the community more information because that information might be useful to it. Open source hardware is about learning from each other, and how to run an open hardware business is just as important a lesson as how to create an open hardware PCB.

What Could This Look Like?

Last year Průša (the person) raised concerns about the state of open source hardware, framing his post as kicking off a “discussion.” Members of the community took that invitation seriously. I responded with a series of clarifying questions and comments. So did my OSHWA co-board member Thea Flowers, and Phil at Adafruit. Průša is under no obligation to respond to any one of these (me yelling “debate me!” on the internet does not create an obligation on the person to actually respond).

However, kicking off a self-styled discussion, having a bunch of people respond, and then doing . . . nothing does not feel like the most good faith approach to exploring these questions. None of the questions in the response posts were particularly aggressive or merely rhetorical - they were mostly calls for more clarity and specificity in order to inform a more thoughtful discussion.

Without that clarity, we are stuck in a vague space that does not really help anyone understand things better. As the hackaday article astutely points out:

The company line is that releasing the source for their printers allows competitors to churn out cheap clones of their hardware — but where are they?

Let’s be honest, Bambu didn’t need to copy any of Prusa’s hardware to take their lunch money. You can only protect your edge in the market if you’re ahead of the game to begin with, and if anything, Prusa is currently playing catch-up to the rest of the industry that has moved on to faster designs. The only thing Prusa produces that their competitors are actually able to take advantage of is their slicer, but that’s another story entirely. (And of course, it is still open source, and widely forked.)

If moving from open to closed prevents cheap clones, how does that actually work? That would be useful information to the entire open source hardware community! If it does not prevent cheap clones, why use that as a pretext? Also, useful information to the community!

Feature image: Political Discussion in a Lumber Shanty from the Smithsonian Open Access collection

Keep 3D Printers Unlocked (the win! 2023)

Fri, 01 Nov 2024 00:00:00 +0000

Last summer I submitted a request that the Copyright Office renew an existing rule that allows users to break DRM that prevents them from using materials of their choice in 3D printers. As of October 28th, that rule has been renewed for another three years.

This is good news! Copyright law should not allow 3D printing manufacturers to force users to only use approved materials. Wins in copyright policy world are rare, so let's celebrate one when it comes.

This request was part of a larger every-three-year process involving dozens of requests to allow people to do things that are not prohibited by regular copyright law, but are prohibited by a special provision of copyright law that prohibits breaking digital locks (even for otherwise legal purposes!).

This time around, that larger process was a bit of a mixed bag. The good news is that many of the existing exemptions were renewed. The less good news is that some of the new exceptions were approved on highly restricted terms, making them much less useful.

What happens now? 3D print with whatever material you want, free of fear of a copyright lawsuit (at least over using unapproved material in your printer - what you print can still get you into trouble). Three years from now, we’ll do this dance yet again.

Licensing Deals Between AI Companies and Large Publishers are Probably Bad

Mon, 26 Aug 2024 00:00:00 +0000

Licensing deals between AI companies and large publishers may be bad for pretty much everyone, especially everyone who does not directly receive a check from them.

Although the initial copyright lawsuits from large content companies like Getty Images and music labels are still very much ongoing (with new ones being filed regularly), recently we’ve also seen a series of licensing deals between large content owners and AI companies.

Setting aside the wisdom of the deal for any individual content company, I worry that these licensing deals represent a bad outcome for just about everyone else. Most of the companies entering into these agreements represent a relatively large amount of cultural power (that can be leveraged into public pressure), and a relatively small corpus of works (relative to the amount of works required to train a model), backed up with enough legal power to qualify as a plausible threat to an AI company. That puts them in a position to demand compensation that is out of proportion to their actual contribution to any given model.

The deals that flow from this dynamic allow a small number of companies to claim a disproportionate amount of compensation for their relatively modest contributions to a training dataset. In doing so, the licenses establish a precedent that may undermine the fair use defense for unlicensed training of models, making it harder for smaller competitors to enter the AI market.

This might be a positive development if these deals also increased the likelihood that everyone who created data used to train models would receive significant compensation.* However, these deals likely marginally decrease the likelihood of that outcome by allowing the media companies signing these deals to soak up most of the available licensing dollars before the vast majority of people and companies who created data in the training datasets are involved. The most likely outcome could be one similar to Spotify, where large record labels and a handful of high-profile artists receive significant compensation, while everyone else receives fractions of pennies (or no pennies).

Licensing Dollar Roll Up

It is easy for anyone who wants to be paid a licensing fee by AI model trainers to see these deals as a positive development. They may set a precedent that data must be licensed, and a market rate for data that applies to everyone else.

However, at this stage there does not appear to be any reason to see these deals as setting a standard for anything other than large (or large-ish) media companies and rightsholders. These deals do not set benchmarks for independent artists, or for anyone without the existing cultural and legal clout to demand them. After all, the terms of these deals aren’t even public.

It may be better to understand these deals as the large media companies and rightsholders jumping to the front of the line in order to soak up as much available licensing money as possible. Their incentive is to maximize the percentage of the licensing pool that they receive - not to set a standard on behalf of everyone else, or to grow the pie for others. In fact, every dollar of value that someone outside of the deal can claim is a dollar the large media companies cannot include in their own deal with the AI companies.

The result is that the large media companies leverage “creators should be paid” rhetoric to roll up all of the available licensing dollars, while making it marginally harder for anyone else to be paid for being part of the training data.

Which seems bad! As a bonus, these deals may undermine the fair use defense that allows the models to be created in the first place.

Blocking Competition

The copyright lawsuits over data used to train models all turn on whether or not the training is covered by fair use. If the act of training models on data is fair use, the trainers do not need permission from the data rightsholders (I think this is both the better reading of the law and the better policy outcome). If the act of training is not fair use, the trainers will need permission from every rightsholder of every bit of data they use to train their models.

Determining fair use involves applying a four factor test, one of which is the effect of the use on the potential market for the data. I’m confident that the AI company lawyers are crafting these agreements with an eye towards avoiding establishing a market for AI training data (available public information on the deals suggest that they are framed in terms of making it easier to access the data through APIs or other bulk data transfers, not a license to the data itself). Nonetheless, the existence of these deals does probably marginally increase the likelihood that courts would decide that there is a functioning market for licensing training data.

If that were the case, and courts found that the majority of the other fair use factors pushed against a finding of fair use, that would mean that only companies with enough money to license training data at scale could train new AI models. I think this would probably be a bad policy outcome because it could effectively block new market entrants in AI. And working out the licensing process would be somewhere between complicated and impossible.

All of which makes these deals bad for pretty much everyone. They are bad for any creators who are not being directly paid by them, bad for anyone who would welcome new competition in AI, and bad for anyone who generally thinks that non-consumptive uses of information on the internet should be protected by fair use.

*I currently believe that compensating everyone who created data used to train models is a bad idea, but I understand why it is an attractive option to many people.

Hero Image: A nun frightened by a ghost playing a guitar; page 65 from the "Images of Spain" Album (F)

Is There A Coherent Theory of Attributing AI Training Data?

Mon, 15 Jul 2024 00:00:00 +0000

It feels like any time I have a conversation about attributing data used to train AI models, the completely understandable impulse to want attribution starts to break when confronted with some practical implementation questions.

This is especially true in the context of training data that comes from open communities. These communities rely on some sort of open license that requires attribution (say, CC BY or MIT), and have been built on a set of norms that place a high value on attribution. Regardless of whether or not complying with the license is legally required in these scenarios, many members of the community view attribution as a key element of its social contract.

Since is already solving a number of problems in these communities, it is not hard to imagine a situation where attribution could solve some additional social and political problems related to the growth of these models. These problems tend to be most acute around LLMs and generative AI, but are also relevant to a broader set of AI/ML models.

This post is my attempt to describe some of the practical implementation issues that come to mind when talking about attribution and AI training datasets. It is not intended to be a list of things that advocates for attribution “must fix” before attribution makes sense, or a list of reasons why attribution is impossible. It also is not intended to advocate for or against the value or legal necessity of attribution for AI training data.

Instead, it is a list of things that I would like to figure out before being convinced that attribution is something worth pursuing. At the end, it also flags one lesson from existing open source software licensing that makes me somewhat more skeptical of this approach.

The Simple Model

Let’s start with the simple model of how large, foundational models are trained.

If you wanted to train one of these models, you might start with something like Common Crawl, a repository of 2.7 billion web pages, or LAION-400-Million, a collection of 400 million images paired with their captions. You could throw these datasets into the pot with millions of dollars of computational power, plus some time, and get your very own AI model (again, this is the simple model of how all of this works).

You know all of the data and datasets you used to train the model, so when you release the model you include a readme.txt file that has 3 billion or so entries listing all of the sources you used. Problem solved?

What Works About This Approach

You have given attribution! Each bit of information you used to train the model is right there in the list, alongside the 3 billion other things that went into the pot.

What Doesn’t Work About This Approach

Maybe this solves the problem? Or maybe not?

Everything maps to everything

One problem with this approach is that an undifferentiated list of all of the training data might not be the kind of attribution people are looking for. On some level, if you are training a model from scratch, every data point contributes equal to the creation of that model and every given output of the model.

However, it is also easy to come to an intuitive belief that some data might be more important than others when it comes to a specific output (there are also more quantitative ways one might come to this conclusion). Also, what if it is possible to have a model unlearn a specific bit of data and then continue to perform the same way it performed before unlearning that bit of data? If your model starts generating poetry, the training data that is just a list of calculus problems and solutions might feel less important than pages of poems.

Does that mean that your attribution should prioritize some data points over others when it comes to specific outputs? How could you begin to rank this? Is there a threshold below which something shouldn’t be listed at all? Is there a point where some training data should get so much credit that it gets some sort of special recognition? Would you make this evaluation on a per-model basis, or on a per-output basis?

Is this meaningful attribution?

Being listed as one of 3 billion data points used to train a model is attribution in a literal sense, but is it attribution in a meaningful sense? Should that distinct matter?

The Creative Commons license requires that a licensor give “appropriate credit,” which is defined mostly in the information it contains, not the form that attribution takes. The CC Wiki contains further best practices for attribution, while being upfront that “Because each use case is different, you can decide what form of attribution is most suitable for your specific situation.”

Regardless of whether or not the 3 billion line readme.txt file is legally compliant with a CC license, there may be a significant number of creators who feel that it does not meaningfully address their wishes. Of course, it will also always be impossible to address the wishes of all 3 billion creators anyway. To the extent that attribution is a social/political solution instead of a legal solution, not addressing the wishes of some critical mass of those creators will significantly reduce its utility. Open Future’s Alignment Assembly on AI and the Commons is interesting to consider in this context. Regardless, if listing people in a 3 billion line file does not meet the expectations of a critical mass of people, is it worth imposing as an expectation?

There is a similar, yet also somewhat distinct, version of this question when it comes to open source software. Under most open source software licenses, attribution is including specific text in a file bundled with the code. However, as discussed more at the end of this post, even that can be of questionable utility at scale.

Is this just a roadmap for lawsuits?

Is disclosing everything you used to train your model just a roadmap for lawsuits? This question is a bit harder to answer. IF training models require the permission of the rightsholder AND the 3 billion entry readme.txt does not meet a permissive license’s attribution requirements, then training on data that requires attribution without providing that attribution is infringement. But that’s a big IF.

If it is fair use to train AI models on unlicensed data, listing the training data won’t be a roadmap for lawsuits because creators don’t have a copyright claim to bring against trainers.

Also, current experience suggests that lawsuits aren't waiting for this particular roadmap anyway.

That means that the roadmap question may be best answered by examining the underlying fair use question, not by weighing the value of attribution. And the fair use fate of AI training is probably much more relevant to it than the attribution compliance question. So I’m going to call this concern both worth flagging and out of scope of this post.

The More Complicated Models

The simple model is just that - a simplified way of thinking about model training. Some of the things that happen in real-world training further complicate things (for a great illustration of many of these relationships, check out Christo Buschek & Jer Thorp’s Models All The Way Down).

Models Trained by Models

As these models are trained on large datasets, it probably should not come as a surprise that trainers are using other AI models to structure, parse, and prepare datasets before they are used to train the model. These structuring, parsing, and preparing models are contributing to the final output model, at least in some ways.

Should the attribution for the final model include all of the data used to train those models as well? Should it differentiate between data used to train the “helper” models and the primary models? How recursively should that obligation extend? What should it mean if the users of the trainer models do not have access to the data used to train those models?

Models Tuned by Models

Large, foundational models are now being tuned to do all sorts of specific tasks. This tuning can include building on an open model like Llama, or importing your own dataset to build a custom RAG.

In cases like this, should attribution include all of the data from the foundational model, plus all of the customized training data? If someone is doing their own tuning without access to a complete list of the training data, is releasing the list of the data they used enough? Should tuning a model built on attributed data create an obligation to release your own tuning data?

Models Optimized by People Who Built Other Models

To me, this is one of the most conceptually interesting situations, and one that highlights the various ways that “learn” is used in these conversations.

The first two scenarios in this section describe some sort of direct lineage between models. However, there are also less direct, more human-mediated linkages. If a team builds model A, they will bring whatever they learned in that process to building model B. That’s true even if model A isn’t “used” to build model B in some sort of literal sense. Should they still attribute the data they used to gain the human knowledge from building model A in the release notes for model B?

This is not a hypothetical scenario. For example, OpenAI describes a “research path” linking GPT, GPT-2, GPT-3, and GPT4, explaining that they take what they learn in developing each model and apply it to the next one:

A year ago, we trained GPT-3.5 as a first “test run” of the system. We found and fixed some bugs and improved our theoretical foundations. As a result, our GPT-4 training run was (for us at least!) unprecedentedly stable, becoming our first large model whose training performance we were able to accurately predict ahead of time.

If your data was used to create GPT-3.5, which taught OpenAI something about training models that allow them not to have to use your data to train GPT-4, have you still made a creditable contribution to GPT-4? How far back should we follow this chain of logic?

Lessons Learned from Open Source Software

AI is not the first time that open communities have had to wrestle with the limits of attribution requirements, or with long, nested attribution documents. While there are examples of these across open communities, the most relevant examples probably come from open source software.

Software is made of other software. Most pieces of software contain a number of other pieces of open source software with licenses that require attribution. In practice, this takes the form of super long text files tucked into software releases.

As Kate Downing points out, the value of the attribution requirement in modern software seems to be pretty low. Software may come with pages and pages of attributions that comply with the license requirement (Downing links to a not-particularly-unique example where the attribution document is 15,385 pages long), but it is unclear if the existence of that document is much more than a compliance chore for a responsible maintainer.

To give another illustration of how long and recursive these documents can be, while drafting this post I also had to update the bios on my printer. The tool I was using required me to agree to the license, and then listed what would have been many pages of attribution. This happened to be the last attribution listed (and therefore the only one I actually saw):

~~How important is the attribution requirement to Ty Coon, President of Vice and creator of some component of my printer driver update utility? Hard to say.~~ update 7/15/24: as pointed out by Luis Villa on mastodon, Ty Coon is in the sample attribution statement at the bottom of earlier versions of the GPL. This occasionally creates confusion outside of this blog. The one snippet of the code I saw when using the utility was not even the (fake) name of one of its many contributors - it was just the end of the appendix to the license they used, pushing their actual name outside of my terminal window.

Given this history, would it be productive to import this practice into training AI models? I’m skeptical.

update 7/17/24: Back in 2016, Luis Villa also wrote a series of blog posts about a very similar attribution problem that argued against trying to use copyleft for databases. If you made it this far, they are very much worth checking out, because most of those problems reappear in the context of AI.

Hero Image: Pidgeon Hole. A Convent Garden Contrivance to Coop up the Gods

Make Government-Funded Hardware Open Source by Default

Fri, 26 Apr 2024 00:00:00 +0000

Earlier this year the Federation of American Scientists (FAS), Center for Open Science, and the Wilson Center held an open science policy sprint to source and develop actionable policy ideas aimed at improving scientific transparency, equity, and innovation. Some heroic editing from the FAS team (especially Jordan Dworkin and Grace Wickerson) helped transform "uh, if the government pays for hardware it should be open source" into the actual proposal below. You can see the original version in situ here.

While scientific publications and data are increasingly made publicly accessible, designs and documentation for scientific hardware — another key output of federal funding and driver of innovation — remain largely closed from view. This status quo can lead to redundancy, slowed innovation, and increased costs. Existing standards and certifications for open source hardware provide a framework for bringing the openness of scientific tools in line with that of other research outputs. Doing so would encourage the collective development of research hardware, reduce wasteful parallel creation of basic tools, and simplify the process of reproducing research. The resulting open hardware would be available to the public, researchers, and federal agencies, accelerating the pace of innovation and ensuring that each community receives the full benefit of federally funded research.

Federal grantmakers should establish a default expectation that hardware developed as part of federally supported research be released as open hardware. To retain current incentives for translation and commercialization, grantmakers should design exceptions to this policy for researchers who intend to patent their hardware.

Details

Federal funding plays an important role in setting norms around open access to research. The White House Office of Science and Technology Policy (OSTP)’s recent Memorandum Ensuring Free, Immediate, and Equitable Access to Federally Funded Research makes it clear that open access is a cornerstone of a scientific culture that values collaboration and data sharing. OSTP’s recent report on open access publishing further declares that “[b]road and expeditious sharing of federally funded research is fundamental for accelerating discovery on critical science and policy questions.”

These efforts have been instrumental in providing the public with access to scientific papers and data — two of the foundational outputs of federally funded research. Yet hardware, another key input and output of science and innovation, remains largely hidden from view. To continue the move towards an accessible, collaborative, and efficient scientific enterprise, public access policies should be expanded to include hardware. Specifically, making federally funded hardware open source by default would have a number of specific and immediate benefits:

Reduce Wasteful Reinvention. Researchers are often forced to develop testing and operational hardware that supports their research. In many cases, unbeknownst to those researchers, this hardware has already been developed as part of other projects by other researchers in other labs. However, since that original hardware was not openly documented and licensed, subsequent researchers are not able to learn from and build upon this previous work. The lack of open documentation and licensing is also a barrier to more intentional, collaborative development of standardized testing equipment for research.

Increase Access to Information. As the OSTP memo makes clear, open access to federally funded research allows all Americans to benefit from our collective investment. This broad and expeditious sharing strengthens our ability to be a critical leader and partner on issues of open science around the world. Immediate sharing of research results and data is key to ensuring that benefit. Explicit guidance on sharing the hardware developed as part of that research is the next logical step towards those goals.

Alternative Paths to Recognition. Evaluating a researcher’s impact often includes an assessment of the number of patents they can claim. This is in large part because patents are easy to quantify. However, this focus on patents creates a perverse incentive for researchers to erect barriers to follow on study even if they have no intention of using patents to commercialize their research. Encouraging researchers to open source the hardware developed as part of their research creates an alternative path to evaluate their impact, especially as those pieces of open source hardware are adopted and improved by others. Uptake of researchers’ open hardware could be included in assessments on par with any patented work. This path recognizes the contribution to a collective research enterprise.

Verifiability. Open access to data and research are important steps towards allowing third parties to verify research conclusions. However, these tools can be limited if the hardware used to generate the data and produce the research are not themselves open. Open sourcing hardware simplifies the process of repeating studies under comparable conditions, allowing for third-party validation of important conclusions.

Recommendations

Federal grantmaking agencies should establish a default presumption that recipients of research funds make hardware developed with those funds available on open terms. This policy would apply to hardware built as part of the research process, as well as hardware that is part of the final output. Grantees should be able to opt out of this requirement with regards to hardware that is expected to be patented; such an exception would provide an alternative path for researchers to share their work without undermining existing patent-based development pathways.

To establish this policy, OSTP should conduct a study and produce a report on the current state of federally funded scientific hardware and opportunities for open source hardware policy.

As part of the study, OSTP should coordinate and convene stakeholders to discuss and align on policy implementation details — including relevant researchers, funding agencies, U.S. Patent and Trademark Office officials, and leaders from university tech transfer offices.
The report should provide a detailed and widely applicable definition of open source hardware, drawing on definitions established in the community — in particular, the definition maintained by the Open Source Hardware Association, which has been in use for over a decade and is based on the widely recognized definition of open source software maintained by the Open Source Initiative.
It should also lay out a broadly acceptable policy approach for encouraging open source by default, and provide guidance to agencies on implementation. The policy framework should include recommendations for:
- Minimally burdensome components of the grant application and progress report with which to capture relevant information regarding hardware and to ensure planning and compliance for making outputs open source
- A clear and well-defined opportunity for researchers to opt out of this mandate when they intend to patent their hardware

The Office of Management and Budget (OMB) should issue a memorandum establishing a policy on open source hardware in federal research funding. The memorandum should include:

The rationale for encouraging open source hardware by default in federally funded scientific research, drawing on the motivation of public access policies for publications and data
A finalized definition of open source hardware to be used by agencies in policy implementation
The incorporation of OMB’s Open Source Scientific Hardware Policy, in alignment with the OSTP report and recommendations

Conclusion

The U.S. government and taxpayers are already paying to develop hardware created as part of research grants. In fact, because there is not currently an obligation to make that hardware openly available, the federal government and taxpayers are likely paying to develop identical hardware over and over again.

Grantees have already proven that existing open publication and open data obligations promote research and innovation without unduly restricting important research activities. Expanding these obligations to include the hardware developed under these grants is the natural next step.

Hero image: Crop of Andrew Carnegie, Smithsonian Open Access Collection

Licenses are Not Proxies for Openness in AI Models

Tue, 26 Mar 2024 00:00:00 +0000

Earlier this year, the National Telecommunications and Information Administration (NTIA) requested comment on a number of questions related to what it is calling “open foundational models.” This represents the US Government starting to think about what “open” means in the context of AI and machine learning.

The definition of open in the context of AI and machine learning is more complicated than it is in software, and I assume that many people are going to submit many interesting comments as part of the docket.

I also submitted a short comment. It focused on a comparatively narrow issue: whether or not it makes sense to use licenses as an easy way to test for openness in the context of AI models. I argued that it does not, at least not right now.

There are many situations where licenses are used as proxies for “open”. A funder might require all software to be released under an OSI-approved open source software license, or that a journal article be released under a Creative Commons license. In these cases, using the license is essentially an easy way to confirm that the thing being released really is open.

At a basic level, these systems work because of two things: 1) the thing being licensed is relatively discrete, and 2) the licenses used are mature and widely adopted within the community.

Open source hardware acts as a helpful contrast to these other examples. Unlike a software repo or journal article, what constitutes “hardware” can be complex - it might include the hardware itself, digital design files, documentation/instructions, and software. All of these may be packaged differently in different places.

Each of these elements may also have a different relationship with intellectual property protections, especially copyright. We have some mature open hardware licenses, but they are relatively recent and even they embody questions and gray areas related to what they do and do not control when it comes to any specific piece of hardware.

My comment suggests that open ML models are much more like open hardware than open software. The community does not really have a consensus definition of what “open” even means in the context of AI models (freely available weights? code? training data?), let alone how (and if) those elements might need to be licensed.

In light of this, it would be unwise to build a definition of open foundational models that would allow “just use this license” to be an easy way to comply. There might be a day when consensus definitions are established and licenses are mature. Until then, any definition of open should require a more complex analysis than simply looking at a license.

Header image: Physical Examination from the Smithsonian's National Portrait Gallery