Re: California law CA AB1043

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.