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.