Re: California law CA AB1043

Most of all approaches here seems to be ducktaping the problem, surely, in
a few years the majority of regions will have that enforcement in some
capacity so either freebsd will dissolve from holding ethical grounds or
need to whack and mole 500 (hyperbole) different protocols and systems but
kills the bsd license, or the rule is changed to bios level, aka freebsd is
not affected at all.

El vie, 27 feb 2026, 17:09, Theron <[email protected]> escribió:

> On 2/26/26 14:40, Karl Denninger wrote:
>
> On 2/26/2026 14:01, Lucas Holt wrote:
>
> On 2/26/26 1:48 PM, Tomek CEDRO wrote:
>
> How about refusing to bend to bureaucratic tyranny and respond with
> ban from the Open-Source side in such cases right from start?
>
> I'm not sure what that would even look like.  Do we make a new modified
> BSD license that includes a clause preventing the use of software in any
> jurisdiction with similar age verification laws?  If a developer is outside
> the US, they can probably just ignore this. Inside the US, without a clause
> banning use, I am concerned that I or say the freebsd foundation could be
> sued or fined by the state of California.
>
> 1798.500(g) says:
>
> (g) “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.
>
> "Controls" does not apply since it can be redistributed and there is no
> "entity" that holds a license (since the MIT license is non-exclusive in
> all respects.)  Nor is "develops" an identifiable entity to which
> jurisdiction can attach in a public open-source system where anyone can
> submit improves, pathches, code and similar.  Therefore it is likely that
> interpretation would turn on who *distributes *in a given case, thus
> blackballing all IPs that geolocate to California would appear to me to be
> a very effective middle finger especially if coupled with an explicit
> written refusal in the Release Documentation (or on request to go there via
> the web, etc from said golocation) -- the project explicitly disavows any
> such use however it cannot (due to the MIT license) actually prohibit use.
> The project CAN refuse distribution however and that demonstrates clear
> intent.
>
> 1798.501(a) is very close to impossible to enforce in an open-source
> system never mind 1798.502 which attempts to affirmatively require same *even
> though no update has been made voluntarily *-- that is, to *enforce *an
> update, which the FreeBSD project has never done nor has it any existing
> way to do so with current installations.  If I never run "git pull", "pkg
> upgrade" or "freebsd-update" as an administrator then what?
>
> While the project ultimately has to deal with this I would argue the only
> reasonable response is "Bite me!" to any request to project servers coming
> out of California.
>
>
> I expect that initiatives to revise the license over this issue or to
> change the project's approaches to software distribution are dead on
> arrival.
>
> What smaller technical and/or documentation changes, if any, are needed to
> ensure that it is as difficult and expensive as possible for a regulator to
> demonstrate that any aspect of FreeBSD meets the definitions as written in
> the bill?
>
> On 2/27/26 10:42, obiwac wrote:
>
> The key there would turn on jurisdiction; the project (unless its changed) is not incorporated in California (Colorado I believe) as a 501(c)(3) and operates under Section 509 (private foundations.)
>
>
> fwiw, some Colorado lawmakers are trying to push through a similar
> bill (SB26-051):
> https://leg.colorado.gov/bills/SB26-051
>
> (and it's written in all-caps, so you know it's serious ;))
>
> Although I don't know if FreeBSD's pkg repos count as a "covered
> application store", both in SB26-051 or CA AB1043, and their
> definition is a little difficult for me to understand (what is a "host
> application"?). And ianal of course.
>
>
> I believe it is intentionally vague, such that approximate compliance or
> response to regulatory action is feasible only for the large and
> well-resourced players, while also giving them an excuse to demand identity
> information, whereas it burdens their smaller competitors.
>
>