[ho_schi]

Yep. One of the things which the FSF did right was the GPL. They didn’t tried like programmers hack against bad things which never works in long term.

The bad people will change the API, lock the bootloader, implement a problematic standard (ACPI, SecureBoot) or add more DRM.

We cannot solve political issues (law) with technical solutions (programming). If we don’t like locked iPhones, the solution is a law. If we don’t like tracking, the solution is a law. But the EU Cookie-Directive of failed? Because malicious compliance, they made a business case out of it instead of ending it (cookies for logins are fine). And if we want public APIs, local computing and open-source the solutions are laws.

The FSF uses the law :)

Let us go a step further, change it.

[gjsman-1000]

> One of the things which the FSF did right was the GPL

And the GPL is dying. Every year fewer projects are maintained under the GPL standard. Violations abound anyway. The MIT License and other permissive licenses; or commercially restrictive licenses like the SSPL, are the new go-to; because the GPL didn’t think about SaaS or “Tivoization” until it was too late.

[Croftengea]

AGPL is the way.

[gjsman-1000]

AGPL is a lawyer’s nightmare. Not just because of the restrictions - but because it’s very, very sloppily put together.

Does connecting a AGPL-licensed database to your website make your whole website AGPL? What is the line between an innocent connection, or a viral integration?

What happens if you add a proprietary protocol to the database specifically for your app? Do you need to open source it, if that database is/isn’t publicly accessible? Why wouldn’t it be considered? Your project dependencies certainly aren’t directly publicly available, yet you agree the AGPL applies there.

Some have quoted the FSF about how “internal data structures” should be the distinction. But even that is something a lawyer could seriously bend - is JSON from your database, that only your app understands, such a structure?

The license is ridiculously vague in this regard. Not that it matters anyway - almost all of the big AGPL projects offer alternative proprietary licenses to paying customers, so it’s really more of a source available license.

[alright2565]

Let's look at this paragraph, which is the only real difference between the GPL & AGPL, because I think the English is perfectly clear and understandable:

> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

> Does connecting a AGPL-licensed database to your website make your whole website AGPL?

The user doesn't interact with the database, so no. Since the app server is not linking to the database, it also isn't subject to the AGPL from that direction.

> What is the line between an innocent connection, or a viral integration?

Exactly the same as the GPL, since that section has not changed.

> What happens if you add a proprietary protocol to the database specifically for your app? Do you need to open source it, if that database is/isn’t publicly accessible?

If the user can access the database, you must provide them with the combined source code under the AGPL. If the user cannot access the database, you do not need to do anything.

> Why wouldn’t it be considered? Your project dependencies certainly aren’t directly publicly available, yet you agree the AGPL applies there.

You are linking against those dependencies. Therefore the whole work is under the AGPL, through the same mechanism as the GPL. Now that the entire work is under the AGPL, you must provide users who access it over the network the source code.

> Some have quoted the FSF about how “internal data structures” should be the distinction.

See this is a real source of ambiguity. But it is an ambiguity that applies to every *GPL license, not just the AGPL. But it's really not as big of a deal as you make it out to be, using the documented public network APIs obviously is not linking.

[gjsman-1000]

> I think the English is perfectly clear and understandable.

Because you are not a lawyer. The points I’ve made have been cited by actual lawyers. Your opinion as a technologist blinds you to the degree of legal ambiguity.

https://opensource.google/documentation/reference/using/agpl...

https://writing.kemitchell.com/2021/01/24/Reading-AGPL

Also, the very fact that these opinions exist shows this license is not safe. There’s never a correct interpretation that will perfectly win the day eventually, only rulings. As the AGPL has never been in court before, things could quickly go sideways.

As my second link, written by an actual lawyer, puts it: “Inebriated aliens might as well have beamed it down from space as a kind of practical joke.”

[alright2565]

> https://opensource.google/documentation/reference/using/agpl...

If you have some background knowledge of Google's architecture, this explains exactly why the AGPL is banned there: all code is built from one monorepo where everything is linked together.

> https://writing.kemitchell.com/2021/01/24/Reading-AGPL

This completely agrees with what I said. At it's core, the A part of the AGPL only kicks in if:

> “you modify the Program” and > “your [modified] version supports such interaction [remotely through a computer network]”

Yes he calls out various potential problems and a potential loophole, but those same problems are also present in the regular GPL!

[devman0]

The AGPL also turns what was distribution license (GPLv3) in to a EULA which kind of contradicts freedom zero of the GNU philosophy.

[DyslexicAtheist]

I was with you until secureboot.

At least on my Debian I retain full control using the shim and my own enrolled keys. So seems less an issue with the technology but perhaps with how some vendors (that are already locking you in anyway) use secureboot?

from https://wiki.debian.org/SecureBoot

>> Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for as a trust root for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.

[candiddevmike]

In theory the benefits of secureboot around attestation and hashing/measuring of boot components do not require a secure/verifiable chain of custody. You could self verify using PCRs. The boot loader signing aspects were always for control and restricting devices, IMO.

[blueflow]

> The boot loader signing aspects were always for control and restricting devices

Not surprising, given the huge role Microsoft had in developing this.

You can't enroll your MOK without booting up, and you can't boot up if Microsoft hasn't signed your bootloader/kernel... It used to be an no-brainer and now its difficult.

[dathinab]

this is simply not true

only using self verifying of PCRs is not an effective protecting against most attacks. (Against which a secure boot chain is supposed to help.)

Sure it depends a bit on what you want from secure boot. But in general if you need PCRs you also need to make sure only verified code can run. If you don't, you likely don't need PCRs either, and some simple flawed secure module key storage would work as good.

In a certain way having a trust verification of the boot loader is the most important part. Everything after that depends on how the boot loader is implemented, through having PCRs is still helpful.

Through this is where secure boot failed (very hard), as long as you don't enroll your own keys you are not really getting a secure boot chain. Something which IMHO is fundamental requirement for any company laptops and similar. (Or, instead of using custom PKs, you are MS and disable all 3rd party keys and disable any BIOS option to add/enroll 3rd party keys, like they did on some older ARM devices).

I.e. IMHO a secure boot chain and protocols related to it are a must have, but the current implementation is garbage, especially for most Windows users.

If you want to know in which direction things could be done you could look a ARM Mac Books more specifically the documentation Asahi Linux created for it. Through just the direction not the exact design.

Basically for PCs (even in huge companies with MDA) you don't need global trust chains, just local per-system trust automatically setup on first boot after "reset" and making sure a "reset" is roughly like a wipe (by using full disk encryption) is all you need (and want). The devil is in the details, but it isn't really that hard to make it work.

[raxxorraxor]

Personally I don't get any benefits from secure boot and it is already used to verify the alleged integrity of systems. Not sure how using your own keys would work for remote attestation, it probably wouldn't. Healthy experience with the industry and the market tells me the future if such systems are widely adapted. And that would be a net negative for software freedom that is beyond the security gains, which can be reached through other means as well.