California’s Digital Age Assurance Act, and FOSS

• These solely represent my own interpretation and opinions. Some parts might be wrong — actually — some parts will be wrong. Please tell me somewhere.

• I am not a lawyer. This is provided solely for the purposes of general information and does not constitute legal advice, guidance, or counsel. No attorney-client relationship is established by the provision of this information, and no reliance should be placed on this information in lieu of seeking professional legal advice. All information is provided “as is”, without warranty of any kind, either express or implied.

• Statutes are often interpreted in context and in light of the problem they were written to address, and the stakeholders and organizations that they were intended to target. Nevertheless, it is not appropriate for FOSS projects to simply ignore such statutes solely because of the belief that they were intended for large proprietary software corporations.

• I mainly use Alpine, so I’m only familiar with Alpine packaging and package distributions. I assume that most traditional distributions, such as Debian, Arch, Fedora, etc., are similar. I am not at all familiar with Nix, Guix, or immutable distributions, and what I say may or may not apply to them.

Questions presented

How does California’s Digital Age Assurance Act (AB-1043) apply to FOSS distributions, distro-operated package repositories and other stakeholders within the FOSS ecosystem?

I’ll split this up into a few parts:

1. Whether those actors fall within the statute’s defined categories;
2. Whether the same actor can and/or likely will, occupy multiple categories at once;
3. To what extent do the statute’s exceptions and limitations apply; and
4. How the statute’s operative duties apply to FOSS software distribution.

Summary

• The Act is broad enough that a traditional FOSS distribution can plausibly be both an operating system provider, and through its package repositories, a covered application store.
• Repository operators for desktop applications such as Flathub are particularly at risk to being a covered application store.
• Upstream FOSS application projects may be considered developers, and some intermediaries who package/patch the software may also be plausibly considered developers because of the broad terms of “owns, maintains, or controls”.
• The statute contains exceptions but are narrow and do not obviously exclude ordinary distro repositories.
• It is difficult or infeasible for FOSS distros/developers to abide by these statutes.

Coverage

Traditional distros are plausible operating system providers

Section 1798.500(g) states:

“Operating system provider” means a person or entity that develops, licenses, or controls the operating system software on a computer, mobile device, or any other general purpose computing device.

This definition does not require the actor to sell hardware, run a cloud identity platform (like most proprietary operating systems increasingly require), or be integrated in any particular commercial way. It only really asks whether the actor develops, licenses, or controls operating-system software.

A traditional FOSS distro does fit this. A distro develops a release, chooses and maintains official ports/packages, sets defaults, publishes installation media or other types of images, etc. Those do line up naturally with “develops” and “controls”. There is no statutory language that discriminates based on whether the system is community-run, nonprofit, commercial, or otherwise.

Traditional distro repos are plausible covered application stores

Section 1798.500(e)(1) states:

“Covered application store” means a publicly available internet website, software application, online service, or platform that distributes and facilitates the download of applications from third-party developers to users of a computer, a mobile device, or any other general purpose computing that can access a covered application store or can download an application.

Ordinary distro repositories and associated package-distribution services satisfy much of that language:

• They are publicly available.
• They are platforms or online services in the ordinary sense.
• They distribute software from third-party developers.
• They facilitate download and installation through repository metadata, package managers, etc.
• They plainly distribute at least some packages that are unquestionably applications in the ordinary sense, e.g., Firefox.

The most obvious counterargument is that ordinary distro repositories distribute many things besides applications: dynamic libraries, headers, runtimes, firmware, system services, debugging artifacts, and other components. But, section 1798.500(e)(1) does not require that a platform distribute only applications; it requires that the platform distribute and facilitate the download of applications from third-party developers. A mixed repository can still satisfy that definition if applications are among what it distributes.

1798.500(e)(2) states that:

“Covered application store” does not mean an online service or platform that distributes extensions, plug-ins, add-ons, or other software applications that run exclusively within a separate host application.

That’s quite a narrow carveout. It targets distribution channels whose relevant software runs only within another host application; arguably, GNU Elpa could fall into this category. However, this does not remove ordinary distro repositories, because such repositories distribute a broad range of programs (be it GUI or CLI or TUI), developer tools, system packages, etc., many of which do not run exclusively within a separate host application. I find the statute’s limitation to be too narrow to do much work for ordinary distro repos.

Application should be read broadly enough to include many GUI, CLI, and developer tools, but not all software artifacts

1798.500(c) states that:

“Application” means a software application that may be run or directed by a user on a computer, a mobile device, or any other general purpose computing device that can access a covered application store or download an application.

It plainly covers conventional GUI end-user software such as browsers, office suites, media players, graphical IM clients, and editors.

In my opinion, it also naturally extends to many command-line and developer-facing programs, because those too are software run or directed by a user: shells, CLI utilities, compilers, interpreters, terminal editors, package managers, and similar tools fit comfortably within the phrase. The enacted text does not impose a graphical-user-interface limitation, and nothing in section 1798.500(c) narrows “application” to consumer-facing software only.

Of course, it cannot be read without limit either; “run or directed by a user” would probably exclude, e.g., shared objects¹, headers, debug symbols, firmware, etc., which would generally not be run or directed by a user in and of themselves, in the ordinary sense of this language.

I find that this distinction does not materially weaken coverage of ordinary repositories. Even if dynamic libraries and similar components fall outside “application”, ordinary distro repositories still distribute substantial numbers of packages that likely fall within the term. A mixed repository therefore remains a plausible covered application store so long as it distributes and facilitates download of many third-party applications.

FOSS developers are plausibly developers defined in this statute

Section 1798.500(f) states that:

“Developer” means a person that owns, maintains, or controls an application.

While the legal ownership of an application in FOSS may be fragmented among multiple persons/entities, or for other reasons difficult to define, maintenance and control may still exist in an ordinary and meaningful sense.

FOSS development activities such as reviewing and merging changes, triaging and resolving tickets, fixing bugs, tagging releases, updating dependency versions, etc., is ordinarily considered maintenance. Nothing in 1798.500(f) suggests that “maintains” should be limited to commercial entities, or exclusive/proprietary code owners. Thus, an upstream FOSS maintainer/committer is a strong candidate for developer status even without exclusive ownership/control. If a person or project is genuinely responsible for maintaining the application over time, that actor fits the most natural reading of the statutory term.

However, I find no clear definition of “control”; it is often the case that developers only distribute source code and no binaries; users and distributions are able to provide whatever patches they wish. The entire premise of the Free Software movement is that the user is supposed to be able to control the software. I would skip “control” for now because “maintains” seems sufficient.²

However, someone who occasionally submits patches, fixes isolated bugs, or contributes code without ongoing maintenance or other authorities, likely doesn’t fit into maintenance or control. The statute does not define “maintains,” but ordinary usage suggests more than sporadic contribution.

The analysis becomes more complicated where downstream distro patches are involved. Suppose an upstream project maintains the original application, but a distribution carries a persistent downstream patch set, changes defaults or behavior, builds the distributed binary, and controls its update cadence in the repository. In that case, upstream remains a strong developer candidate because it still maintains the core application. But the downstream distro maintainer, or possibly the distro project itself, may also plausibly “maintain” or partly “control” the application as delivered to users through that distribution channel.

The remaining statutory exceptions are narrow and do not obviously remove ordinary distributions

Section 1798.504(f) excludes:

• A broadband internet access service;
• A telecommunications service; and
• The delivery or use of a physical product.

These don’t fit what general-purpose distributions or typical FOSS application projects do.

Section 1798.504(g) further provides that:

This title does not impose liability on an operating system provider, a covered application store, or a developer that arises from the use of a device or application by a person who is not the user to whom a signal pertains.

A limitation of liability in this specific circumstance does not carve us out of the coverage of the statute overall.

Infeasibility

Account setup interfaces may not even be in control of the distribution

Section 1798.501(a)(1) requires the operating system provider to provide an accessible interface at account setup requiring the account holder to indicate the birth date, age, or both, of the user of the device.

That requirement assumes there is some reasonably identifiable event called “account setup”. On many FOSS systems, that assumption is unstable. Account creation may occur:

• before installation where accounts are defined on a central auth server;
• before installation via a user’s customizations to their installation medium;
• during the installation of the operating system;
• after installation through a desktop settings page;
• through command-line utilities such as useradd;
• by directly editing /etc/passwd and/or similar files; or
• never, if we try something like building a non-UNIX-like operating system on top of Linux that has no concept of users, only UIDs, and passes file descriptors around as capabilities. Or many other conceivable designs that have no concept of a “user”.

In many environments, it is difficult to identify any singular event that clearly deserves to be called “account setup” for the purposes of 1798.501(a)(1). If compliance must exist across all realistic ways that users and administrators create accounts, the statute appears to demand a significantly broader and much more invasive degree of control over account-creation than many general-purpose distros could realistically exercise.

The primary user of the device might not even be the user using the application

Section 1798.500(i) does not define the relevant user as the current user, the logged-in user, or the account running the application. It defines the user as the child who is the primary user of the device.

This would not be a FOSS-specific issue. I doubt this was carefully drafted with multi-user systems in mind in the first place. Assume that the primary user of the device is an adult, but there are other users that are considered children under this statute. This statute would mandate that applications receive an adult age signal when they request so via the API, regardless of which user account is actually running the application.