Hector Martin

https://social.treehouse.systems/@marcan

If it ain't broke, I'll fix it! · he/him

I'm porting Linux to Apple Silicon Macs at Asahi Linux.

GitHub Sponsors: http://github.com/sponsors/marcan
Patreon: http://patreon.com/marcan
Asahi Linux: https://asahilinux.org

Public Key

npub1qk9x6yrvten3jqyvundn7exggm90fxf9yfarj5eaz25yd7aty8hqe9azpx

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsqtzndzpk9ueceqzxwfkelvnyydjh5nyjjy73e2v7392zxlw4jrmspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsqrs7nk

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1qk9x6yrvten3jqyvundn7exggm90fxf9yfarj5eaz25yd7aty8hqe9azpx

Show more details

Last Notes

2024-09-05 21:01:20 GMT

How did my post about the PayPal phishing email get 700 boosts lol. Fedi is wild.

2024-09-05 20:57:03 GMT

- reply

That's correct.
I did forward the email to them, no idea if they'll care though.

2024-09-05 20:53:20 GMT

- reply

That's what password managers are for. If it were a fake domain it wouldn't have had my username filled in from the cookie, and my password manager wouldn't have offered me to autofill the password.

2024-09-05 14:59:32 GMT

- reply

It's actually how PayPal payment requests work, I just tested it. It seems they take the recipient email, cut it off at the TLD, use the left part as "name" and the right part as "surname". There's a suspicious space there. It's PayPal doing all this, I tested it myself.

2024-09-05 14:57:49 GMT

- reply

Yeah, and there was a suspicious space as in "fake@address. com"
So I thought the attackers must have done something funny with the name/surname info, but it's even dumber than that. I just tested it by sending a payment request to myself... and it's PayPal doing that.
Conclusion: The email template in PayPal takes in name/surname fields, and then for the payment request emails someone decided to write code that just... randomly chops off the TLD off of the recipient, uses the left part as "name" and the right part as "surname"... ??????
🤦‍♂️🤦‍♂️🤦‍♂️🤦‍♂️

2024-09-05 14:42:32 GMT

- reply

It is a legitimate email sent by paypal.com to an email address, just not my email address. The payment request in and of itself is illegitimate, but real and actually processed through paypal.com

2024-09-05 14:40:24 GMT

- reply

I checked the URL first, and used a private browsing window. If merely *clicking* on a link from an email (and not doing anything with the resulting page) is dangerous then the relevant service/site has bigger problems, because any website anywhere can redirect you to any URL they want.

2024-09-05 14:38:38 GMT

- reply

The email is legit, it's just addressed to another email address. You can legitimately receive this email from PayPal addressed to you.

2024-09-05 10:57:25 GMT

- reply

My email client displays To: [email protected] of course, but that's easy to miss.
The email body also starts with Hello, [email protected]... in tiny barely readable grey-on white text. 🤦‍♂️

2024-09-05 10:55:05 GMT

- reply

I had that happen with Venmo, I still have no way to get rid of it.

2024-09-05 10:54:41 GMT

- reply

The envelope sender after the redirect ends up being a microsoft-hosted address, so that passes SPF on my end. I guess this is all "working as intended" since forwarding emails is supposed to work (otherwise mailing lists wouldn't work).

2024-09-05 10:49:04 GMT

Heh, just got an interesting scam email. It's a payment request from paypal.com for something random that has nothing to do with me.
It's a legitimate email, the body links all go to the right place, the sender is [email protected]. It passed all DKIM checks and antispam checks.
The trick? It's not addressed to me. They got PayPal to send a legitimate payment request to a special address which then forwarded the email to me, through Outlook/Microsoft servers before reaching mine (so they have good reputation too).
When you click the payment link, you get a legitimate PayPal login and payment request with this little tagline:
> We'll link [email protected] to your PayPal account when you log in.
So not only do they not check that the email that the request was sent to is the actual account owner, they will "helpfully" link it in and consider this action as equivalent to an email address ownership confirmation! What are the implications of this? Who knows! Maybe it means they could issue password resets via that address then?
Scary, though I guess not unsurprising security fail from PayPal.

2024-08-29 17:28:01 GMT

- reply

I got around to testing this and no, edge palmdet still sucks on Apple trackpads. Even with the fixed trackpad dimensions, at least on 16" models, it causes noticeable deadzone behavior on the left/right/top and stuff like touches being completely ignored if they come in from those edges and move towards the center slowly enough. That's not acceptable.
@npub1ysq…xd3s can you test libinput with this reverted?
https://gitlab.freedesktop.org/libinput/libinput/-/commit/4a8b5e6ec445b507fc0b1ef9842a60bf13c58772
If it fixes your issues then we need to file a bug on libinput to make edge palmdet less aggressive so it can be enabled again. If it doesn't then libinput needs some other algorithm or tweak to help palmdet for the tap-to-click case on Apple.

2024-08-29 08:58:06 GMT

- reply

FWIW Linux already boots on the M3 to some extent (given an appropriate device tree), we just haven't gotten around to working on platform bring-up yet since other things take priority.
Besides basic bring-up and firmware ABI differences for DCP/etc the main issue you're going to run to is the GPU shader ISA is completely different to M1/M2. You'll probably have to leave that one to Alyssa & Lina to sort out.

2024-08-29 08:54:31 GMT

- reply

To run macOS under the hypervisor you need to replace the macOS kernel in an existing install with m1n1 manually using kmutil, you can't run it from a separate m1n1 install (because it would not be in the correct OS context and would have no idea what root partition to use and you'd likely run into SEP issues too, never mind that even if you used a separate install it would have to use the same exact macOS version for the stub partition or else you'd get firmware/kernel/userspace ABI mismatches and fireworks).

2024-08-29 08:51:41 GMT

- reply

iBoot1/iBoot2 are no longer encrypted since macOS Sequoia (just updated the wiki page).

2024-08-26 17:27:11 GMT

- reply

Note that this is *not* an attempt to praise all of Telegram and in particular any specific behaviors of the underlying company and developers.
I'm just saying the UX is by far the best I've used, nothing more.

2024-08-26 17:23:08 GMT

- reply

Signal does E2EE as well as it can be done, but due to its laser focus on E2EE it misses out on functionality that is not practical to build with E2EE.
Matrix is precisely an example of trying to E2EE everything while having more features and ending up with a mess as a result.
And yeah the Signal desktop client is... rather questionable. Telegram is way better.

2024-08-26 09:03:00 GMT

- reply

Because the SuperSpeed lanes don't pass through the Type C chip, they connect directly to the PHY. The Type C chip only deals with the power control, CC lines, and muxing sideband signals.
It is possible to externally mux the lanes and have the Type C controller control that mux, but that would be expensive and redundant, since if you have a unified PHY for USB with dual lane support swapping lanes in silicon is basically free (and better for signal integrity). So nobody uses an external mux if they can help it for full spec controllers.

2024-08-26 08:59:23 GMT

- reply

I used to use it (on x86) to run a dev/ops environment for an event VM cluster at home. We'd take backups from production VM servers and VMs after closing and I'd run them in one VM per physical server, with the same IP connectivity setup as prod so it would just work. Then I could work on things at home and dump them back on prod next time.
It was all running from a single USB SSD and set up in a way that I could USB boot it on any machine, so it also served as an emergency backup environment. If everything went wrong, we could boot it on a random laptop and continue minimum service from that.
The nested VMs definitely had *some* perf impact but it wasn't a showstopper.

2024-08-26 08:43:03 GMT

- reply

Because typically the USB Type C controller and the USB Host Controller are two completely separate chips and pieces of hardware with no ability to communicate with each other directly since they have completely different goals and implementation details.
So it's up to the host driver to query the Type C controller for orientation status and tell the Host Controller/PHY how to set up its lane muxes to match.
Yes this is the bane of people writing Linux drivers like us, it means we have to coordinate across something like 5 Linux driver subsystems to make all of this worok.

2024-08-26 08:39:48 GMT

- reply

Yup. Definitely the Electron thing.

2024-08-26 08:37:49 GMT

- reply

I'm all for Signal and E2EE and distributed systems and all that, but... Telegram is, by far, the least-bullshit most-fun messenger I've ever used. Everything just seems to work, it's lean, has native open source client apps, a big pile of features *that are cohesively integrated* and *work*, API/bot support, useful stuff like automatic translation (premium feature, but that's understandable since translation APIs aren't free), etc.
Other platforms would do well to learn from it.

2024-08-26 08:33:57 GMT

Say what you want about Telegram, but it has one of the best data export/backup features I've ever seen.
Fully client-driven, with real-time progress display (and even the ability to manually skip large file downloads on-the-fly).
The output is a bunch of plain HTML pages with just 200 lines of pure JS (no frameworks) for some minor interactivity features, that loads instantly and looks roughly like the Telegram client itself, easy to browse and search.
The JSON is one big blob with all the same data in a trivial format. The text encoding is interesting: Telegram supports rich text, but instead of in-line HTML-style markup, in the JSON it's encoded as JSON objects representing the different spans of text with different format. Very clean.
https://cache.treehouse.systems/media_attachments/files/113/027/359/054/213/816/original/32984911e6073d9e.png
https://cache.treehouse.systems/media_attachments/files/113/027/393/114/175/783/original/069c0737571b021b.png

2024-08-25 20:02:12 GMT

- reply

It's hardware for the USB 2 pins (they are just connected through usually). It's software for the USB 3 pins (lanes swap around).
So cheap noncompliant Chinese stuff without a mux for the USB 3 lanes ends up enumerating as USB 2 High Speed in one orientation and USB 3 SuperSpeed in the other.

2024-08-25 16:04:01 GMT

- reply

This might only happen on non-ProMotion displays, we haven't tested ProMotion ones. Totally possible that they aren't affected since they have a very different backlight control system.
So I guess the exact opposite of last time when they broke ProMotion only.

2024-08-25 15:54:22 GMT

DCP firmware backwards compat strikes again.
Apple really can't get this right, can they?
https://social.treehouse.systems/users/AsahiLinux/statuses/113023466601365851

2024-08-25 11:33:40 GMT

- reply

We disabled the palm rejection code in libinput for Apple trackpads because it was making some machines completely unusable due to (I think) trackpad size mismatches. I *think* this is fixed now but someone needs to test it and see if it can be re-enabled again.

2024-08-25 10:30:45 GMT

Pro tip: If you send me an email advocating for bigotry to try to change how I run my projects, all you're going to do is earn yourself an entry in my killfile. 👋

2024-08-20 09:50:58 GMT

- reply

If the software itself is being illegally distributed/modified and you are aware of that fact, I'm pretty sure you can get in trouble for that.

2024-08-20 09:41:59 GMT

I should spend more time writing documentation...
https://social.treehouse.systems/users/AsahiLinux/statuses/112990528901633785

2024-08-20 09:40:40 GMT

- reply

Licenses cannot prevent you from using a product if you are unaware of the license. I can burn a CD with some music I made, put a license file in some raw empty space on a data partition that says you can't listen to it, give it to you. If I try to sue you because you listened to it, the courts are going to laugh me out the door because there was no way you could have known of the existence of the license.
This is the purpose of click-through EULAs. Without them, there is no way for the user to be aware of the usage restrictions. Indeed some of their terms may not be enforceable in some jurisdictions, but that is a different question. The point is that if it's not a click-through EULA and you can't prove the end-user must be aware of the license, *none* of it is enforceable.

2024-08-20 09:36:17 GMT

- reply

This doesn't really matter for the purposes of my argument though. Even if you interpret copyright licenses as contracts, contracts are only enforceable if they are accepted by all parties. It is copyright law that forces that acceptance for actions governed by copyright law.
The "default state" is there is no contract and no end-use restrictions, but also no license to copy or distribute. Whether what I describe as a "pure copyright" license is interpreted in some jurisdictions as a contract is irrelevant. If that contract attempts to enforce usage restrictions, it has to be delivered as an EULA to be enforceable since end users need to be able to see it and agree to it. If it does not, this is not necessary, because acceptance of the contract is only necessary to perform actions which would otherwise not be allowed by copyright law.

2024-08-19 20:03:47 GMT

- reply

You still need a click-through for that interpretation to work. It would be preposterous for a usage contract/license to be enforceable if the person using the software never got to see it.
But automatic copyright protection *is* universal, and governed by the Berne Convention for the Protection of Literary and Artistic Works.
So ultimately whether a license is a contract or not is irrelevant here. Copyright / "author's rights" / whatever your jurisdiction calls it is automatic. Usage restrictions are not, and are not enforceable if the license/contract is not actually presented to or visible to the user.

2024-08-19 15:22:33 GMT

- reply

Yeah, we literally install recoveryOS for Asahi because we have to (platform reqs) so it's silly not to use it and slowly grow it into more of a boot recovery environment for *us* too.

2024-08-19 15:16:52 GMT

- reply

The endgame here is to have a thing in the Asahi Installer that can boot an existing install under qemu on macOS, or a rescue image, so you can fix (most) boot issues. If that is using text console passthrough (stdio) it should be accessible via the host macOS.
Then we can mostly just ignore the a11y story for our boot chain since it's largely hidden anyway. Though identifying what a problem is could be a challenge, but there's no practical solution for that inline (no, we're not adding a whole audio engine and screen reader into m1n1/u-boot...). It would make more sense to set up some kind of "breadcrumb" system that logs to a file or NVMe partition something that you can then inspect from macOS (bonus points for using the macOS kernel dump format and triggering the macOS error report dialog directly lol).

2024-08-19 09:24:26 GMT

- reply

That wasn't the problem, the firmware isn't even initializing the USB drive.

2024-08-19 09:22:43 GMT

- reply

Lol HP.
https://social.treehouse.systems/@marcan/112987950943153077

2024-08-19 09:22:15 GMT

- reply

This has nothing to do with the distro. The firmware isn't even initializing the USB drive.

2024-08-19 09:21:50 GMT

- reply

So it didn't work in UEFI CSM (Hybrid) mode. Then I tried UEFI non-CSM mode, which did work, but of course broke the existing Windows install that is using legacy boot.
Then I went back to UEFI CSM mode and it works now (????)
And then I toggled some BIOS settings and it stopped working, even putting them back didn't help. I had to go back to non-CSM mode to make it work again, and then again it stuck in CSM mode.
x86 world, are you doing OK?
(This is an HP laptop FWIW)

2024-08-19 09:02:45 GMT

Trying to boot Fedora on a boring old x86 laptop... so I used Fedora Media Writer to write the image to USB, then hit F9 for boot options.
The drive doesn't show up as a boot option.
BIOS is set to legacy mode, no secure boot, nothing. It just doesn't even try to read from the USB drive.
I guess installing Asahi on Macs is officially easier than installing Linux on PCs... at least some PCs, anyway.

2024-08-18 16:20:26 GMT

- reply

And at the end of the day this devolves to: no low-funding individual ever benefited or will benefit from the AGPL/EUPL since they won't be able to litigate it in practice. It only causes pain and confusion. The major people benefiting from these licenses are the "AGPL+CLA+commercial version" VC-backed leeches who get to claim their product is FOSS when they have all the power and hold all the cards.

2024-08-18 16:17:59 GMT

- reply

My point is that if these licenses weren't considered FOSS, this gambit wouldn't work because CLA or not, those companies wouldn't be able to offer "free software" that none of their competitors can actually fork/deploy/use on ~equal footing and build a competing commercial product out of. They'd have to use a nonfree source-available license (and not get any of the brownie points and FOSS contributions) or accept that by using a FOSS license, anyone else can fork their code and deploy their own proprietary variant SaaS, losing the "commercial version" exclusivity.

2024-08-18 16:12:08 GMT

- reply

I suspect that would be a nightmare to pull off successfully and cleanly... and such a restriction still violates the principles of Free Software (even if it remains a copyright license; being a copyright license is a *requirement* to be FOSS but obviously not *sufficient*).
The AGPL tried a similar hack by targeting restricting *modification* instead and ended up with a horrible mess. Nobody should ever use that license, it's terrible.

2024-08-18 16:05:49 GMT

- reply

1) The reality is that licenses like the AGPL (and potentially the EUPL, though it's not that popular yet) are being abused by enterprises that want to appear hip and FOSS-friendly by releasing their CLA'd to hell product under license terms that they are not subject to (as the copyright owners) while offering a "commercial" version where they make all the money, and the onerous terms of these licenses make it easy for them to go after third-party usage or stifle real FOSS forks, essentially creating a "source available" product that masquerades as FOSS and even leeches on the FOSS community by accepting CLA'd contributions.
2) A lot of AGPL and EUPL software is not actually a network service, and some companies ban such licenses across the board (for good reason), despite them offering nothing to that class of software. So then they just devolve into "fuck large corps" licenses without any actual benefit to the FOSS-iness of the software itself, and that can backfire and end up pushing away contributors.

2024-08-18 16:00:50 GMT

- reply

The EUPL comes with its own definition of "distribution" or "communication" as including "providing access to its essential functionalities at the disposal of any other natural or legal person".
Therefore, under a copyright interpretation where that concept isn't part of distribution/copyright law itself, since it is a self-contained definition in the license anyway, it becomes an EULA-shaped license term.
Then the remaining question is whether that is enforceable as an EULA in the context of the entire license and its requirelents (c.f. what I said about Linux distros etc).
Someone else pointed out that Article 10 literally alludes to a click-through EULA format as acceptable for the license. Maybe the license authors actually intended to write an EULA.

2024-08-18 15:51:03 GMT

- reply

If it does not hold up in court, that's the "does not work" part of my argument.

2024-08-18 15:49:06 GMT

- reply

Where do you even draw the line? How much of the software functionality has to be "controllable" by the user for it to be "distributing"? How much do you have to "wrap" it for it to stop counting?

2024-08-18 15:45:39 GMT

- reply

Again, would love to see any *EU* precedent for this working like this.
But even then, if this indeed is a EU-only interpretation, that would be valuable information to share with people (i.e. EUPL does not protect against SaaS anywhere outside Europe).

2024-08-18 15:42:41 GMT

- reply

(And I disagree with that argument and would love to see it work in front of a judge, which I've yet to see.)

2024-08-18 15:41:27 GMT

- reply

Right, and your job is to show me how SaaS is a "performance" in the same sense as a musical performance (even though they are evidently very, very different because a musical performance has a copyrightable output that embodies the original copyrightable work, and a SaaS execution does not). ;)

2024-08-18 15:40:00 GMT

- reply

Most SaaS *end-users* interact with, yes. But a huge part of the AGPL/EUPL/etc debacle concerns backend serving technologies that don't do that.

2024-08-18 15:37:50 GMT

- reply

I mentioned that in a follow-up reply to OP. The specific case of web apps is a can of worms that is legally above my head and I will not make any comments about it, I'll leave that one to the lawyers. The HTML/CSS/JS themselves are definitely copyrightable; how that interacts with copyright law when a webapp is hosted in terms of obligations by the hoster, I have no idea.

2024-08-18 15:34:56 GMT

- reply

I didn't even notice that part lol.
The funny thing is it does not *require* that the software have such a button, nor that distributors offer the software with such a button, so this leads to my suspicion that the reality is the EUPL is completely toothless and cannot stop SaaS.

2024-08-18 15:33:02 GMT

- reply

And the point is that's not true. If you write a document with Microsoft Word and export it as PDF, Microsoft doesn't own copyright over your document, only you do. This is extremely well established, and the SaaS use case does not change it.

2024-08-18 15:31:25 GMT

- reply

You're looking at this the wrong way. How much sheet music resembles code doesn't matter. The point is that **music**, as in **a melody, a sequence of musical notes**, is copyrightable. Playing sheet music results in... music. "Playing" a computer program doesn't result in anything copyrightable (in general).

2024-08-18 15:28:46 GMT

- reply

Yes, but that doesn't matter, that's just an encoding. What is copyrighted is 1) the resulting sequence of notes from playing the sheet music (this is what survives when you play it), and 2) the specific sheet music in terms of layout on the page/etc (this just relates to the sheet music itself, e.g. photocopying it or re-transcribing it one to one).

2024-08-18 15:26:42 GMT

- reply

I know that, I just want to see actual evidence that an actual judge has used this interpretation somewhere, regardless of whether the legal system considers it precedent for future cases.

2024-08-18 15:21:19 GMT

- reply

Uh, no. *Music itself* is copyrighted. The notes. Playing music isn't "executing" sheet music in the software sense, it is *interpreting* sheet music where the output (your performance) continues to contain the same notes, which are copyrighted. Melodies are explicitly copyrightable.
The software equivalent would be running the server app under an execution tracer that streams back every instruction executed to the user, but that's again not how SaaS works.

2024-08-18 15:12:17 GMT

- reply

Some people are replying that "communication to the public" is a copyright concept that applies to SaaS usage of software.
I have yet to see any legal citations or precedent that this is the case.
Copyright law concerns *works*. It does not concern *running programs*, it concerns the *programs themselves*. All the restrictions on *running programs* come from EULA clauses, if any.
When you "perform" a song for the public, the public perceives a version of the copyrighted work (the song), which could then be recorded again (fixated) and become a derivative work.
When you "communicate" a movie by showing it in a theater, the public perceives the original work (the movie), which could be filmed again (hello ts rips), and become a copy of the work.
When you host some software as SaaS, the public does **not** perceive the original work (the software source/binary), only the results of its execution. Copying or fixating the data returned from the SaaS service does **not** result in a derivate work or copy of the original work, and is not protected by copyright.
There is a very big fundamental difference here, and if any judge anywhere has decided it's inconsequential and SaaS is "performing" or "communicating" software I'm all ears.
But until someone comes up with some serious citations for this, I'm going to say it's complete bunk, because denying the difference here is nonsensical.

2024-08-18 15:05:28 GMT

- reply

Can you please cite legal precedent for this interpretation?
When you "transmit" a "work" you are transmitted *what is copyrighted*. What is copyrighted is the work itself. This is what happens when you, say, show a movie to an audience. The audience perceives *the copyrighted work itself*.
When you "make available" software to the public you are *not* transmitting the copyrighted work itself. You are making available the *result* of *executing* the copyrighted work itself.
You can violate copyright by filming a movie in a theater. You cannot violate copyright by reproducing the output of a query to a SaaS service (at least not the software's copyright anyway, the data could be separately copyrighted).
This distinction is evidently legally relevant and it is irresponsible to dismiss it and claim it does not exist.

2024-08-18 14:42:22 GMT

- reply

That's the RAM copy question I linked.
TL;DR it hasn't been sufficiently litigated and it's a can of worms nobody really wants to touch, but if litigated in a high-profile case, it's highly unlikely that the outcome would be that copyright applies to that case, because it would undermine much of how the modern world works.

2024-08-18 14:37:31 GMT

- reply

Indeed it "could be argued", but as far as I know it hasn't been argued, and it is a very difficult thing to argue. "Public performance" of a copyrighted musical work implies transmitting that work over the air to an audience: the work itself is transmitted. Hosting a service doesn't do that.

2024-08-18 12:56:01 GMT

- reply

No, the AGPL has a different problem. The FSF has been misleading everyone into *believing* it has an anti-SaaS usage restriction, but it doesn't.
What it does have is an anti-SaaS *modification* restriction, which bites people a very different way. It is indeed a pure copyright license, but also nonfree due to this fact.
It is entirely safe to install and run AGPL software as-is as an end user, and you don't need to take any steps to offer source code to anyone. However, it is extremely difficult to modify AGPL software and abide by the terms of its license. ~All Linux distributions shipping AGPL software are *themselves* in violation (not their users) if they have any AGPL packages they apply patches to without a source offer URL/mechanism update (or creation, if it does not exist already). This happens in practice extremely often.
More detail here: https://social.treehouse.systems/@marcan/112973100810673010

2024-08-18 12:52:27 GMT

- reply

Because that's not how copyright works. You seem to wish it worked that way, maybe it would make some sense for it to work that way under limited situations. But it doesn't.
We're arguing in circles here, so unless you bring some evidence that your completely unconventional interpretation of copyright law actually has prior court interpretation art, I'm just going to stop replying now.
BTW, I don't "defend" SaaS. I merely assert that protecting against SaaS requires going outside the Free Software Definition. I fully endorse people who want to ban SaaS usage without source offers. They just can't call their software Free Software by conventional definitions.

2024-08-18 12:06:56 GMT

- reply

That's my point: these licenses should never have been considered "FOSS" and should not be accepted for distro inclusion without license prompts (in the Gentoo case, removal from @FREE; in the Fedora case, removing such software entirely)

2024-08-18 12:03:31 GMT

- reply

That's not how copyright law works. It is widely accepted that while computer programs are copyrighted, that copyright does not extend to their input and output. Otherwise Microsoft could claim copyright over your Word documents. For a network server, the network connection is the input and output. Nothing about a program being a server magically transforms the act of running it into "distribution". As far as I know there is absolutely zero legal precedent for that, and it would cause a major change in how we interpret copyright, with wide-ranging effects on the whole industry.

2024-08-18 11:59:57 GMT

- reply

I'm aware, and my point is that if that is true, the EUPL is a non-free EULA. It's one or the other.
Given how clumsily worded the EUPL is on this front, I'm not particularly trusting of its authors, TBH.
Further reading on why this is a huge mess: https://social.treehouse.systems/@marcan/112982874941526943

2024-08-18 11:50:56 GMT

One of the *fundamental* qualities of FOSS is that FOSS licenses are *purely copyright licenses*. What this means is that their terms apply solely when software is copied or modified, which are actions which are controlled by copyright law, but *not* when you merely use the software yourself.
This is a well-understood concept. The FSF [explains this](https://www.gnu.org/licenses/gpl-faq.en.html#ClickThrough ) in the context of the GPL. @npub16uv…lz0y also [wrote about this](https://flameeyes.blog/2020/03/23/the-gpl-is-not-an-eula/ ) (hi, I found your relevant blog post first this time! :P).
This has *significant* implications, it's not just a curiosity. A license that imposes conditions on mere *usage* requires some form of click-through setup. Not having that would cause those usage terms to be thrown out by most courts, as there is no way for the user to be informed of the EULA and their obligations under it. You cannot agree to what you are unaware of.
This is a *critical* legal distinction, because these EULA terms work *outside* of the framework of copyright law. Copyright law itself requires no click-through EULA: you can violate copyright law even if you are unaware of the terms and conditions, and it is the distributor's or editor's responsibility to comply with all appropriate licensing and copyright requirements when engaging in those actions. But mere *usage* of software that you have lawfully obtained does not invoke copyright law (modulo technicalities about "running software being a copy to RAM", but that's a whole separate [can of worms](https://open.mitchellhamline.edu/cgi/viewcontent.cgi?article=1037&context=cybaris ) with conflicting legal precedent, and the practical fact that if mere RAM copies are in fact copyright infringement then all of us would be committing copyright infringement every day, all day, in a huge number of situations).
Put simply: a piece of software entirely devoid of a license agreement can be hosted on the creator's website, and the default protections of copyright law apply. You are not allowed to redistribute it, but you are allowed to download it and run it for your own personal usage.
This distinction is encoded in the policies of many distribution FOSS projects, like Linux distributions. For example, [Fedora only allows FOSS licenses](https://docs.fedoraproject.org/en-US/legal/license-approval/ ), and Gentoo [accepts all "FREE"] licenses by default(https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/license_groups). This is representative of a very important point: neither of those distributions requires you to read or accept any of those licenses. The assumption is that anything considered "free" is purely a copyright license and that you, as a user, can just go and install distro packages and not read any licenses and be perfectly fine, and nothing you do short of redistributing the software itself could possibly violate them.
But now we have a problem. Notice how both the Fedora and Gentoo allowed license lists include the EUPL. But the EUPL Article 5, if interpreted literally and assuming no other license conditions override it, imposes restrictions on mere usage: it is an EULA. If you download and use EUPL software, and then run it on a server, then the license *requires* you to ensure that users of your server are offered the complete and correct source code to the software running on your server.
But how are you, as a user, supposed to know that? If you install software on Fedora or Gentoo the normal way, the system doesn't even tell you what license the software is distributed under, much less ask you to accept its terms. It's not supposed to be necessary, because FOSS licenses are supposed to be licenses and not EULAs.
Now, since there is no license prompt, if a user were to actually do this, things get really weird. Let's say you run Gentoo or Fedora, install an EUPL package, and run it on a server without ensuring there is a source offer to its users, particularly in cases where the server action does not distribute the code itself (this gets messy with webapps with HTML/JS/CSS, so let's assume this is a simple database server). Now you are violating Article 5 of the EUPL... but you never agreed to said license terms, so courts are highly unlikely to find you liable for it.
So who is liable? Are the distros? Is it a distro's job to ensure that end-user relevant license agreement terms are shown to users of its packaged software? Nobody knows... but then we reach the logical conclusion: either the EUPL is toothless because it is being treated as a non-EULA and users aren't being required to agree to its terms... or distributions themselves are in violation by not ensuring it is displayed to users.
Linux distros might want to think twice about OSI's idea of FOSS licenses and whether they really want to carry software licensed under licenses with clear usage restrictions, regardless of what OSI says is free or not.
Or perhaps the EUPL just doesn't protect against SaaS in practice, regardless of what its authors may claim.

2024-08-17 20:23:16 GMT

- reply

Right. But what you can't do is put a term in the license that all users, or all distributors downstream, must pay you.

2024-08-17 20:14:31 GMT

- reply

You're mixing things up really badly there. Article 3 is *only* a requirement that if you distribute a binary, you also distribute source. It is *not* a requirement that source be publicly available, e.g. you can just directly distribute source privately and not have it public. It also does nothing to disclaim anything in Article 5 or require the existence of a source code offer mechanism a la AGPL (which would serve, if functional, to implement Article 5 for the user).
Article 5 puts all the onus of source offer in a SaaS setting on the user. It doesn't matter if they've modified anything or not. If the software itself isn't self-offering up an accurate copy of its own source code, the user has to make sure they do that themselves. And as a restriction on usage, that's an EULA now.

2024-08-17 20:07:34 GMT

- reply

No, that's a distribution fee, not a usage fee.

2024-08-17 19:51:18 GMT

Someone had me look at the EUPL as a license that is supposedly free and OSI certified and closes the SaaS loophole and... IANAL but I don't like what I see.
https://social.treehouse.systems/@marcan/112979037685332699
I firmly believe it is not possible for a license to be both Free Software (specifically, respecting Freedom Zero: The freedom to run the program as you wish, for any purpose) and close the SaaS loophole at the same time.
Either you interpret the EUPL such that it closes the SaaS loophole, or you interpret it such that it upholds Freedom Zero. You can't have both.
Unfortunately, Freedom Zero is absent from the OSI definition of free software, which allows the EUPL to be OSI certified. This is a glaring omission from the Open Source Definition, as it quite literally allows EULAs (you can attach a requirement that all users pay a usage fee to a license and, if you read carefully, that doesn't violate any of the OSI OSD requirements!).
TL;DR either the EUPL is just another FOSS license that doesn't close the SaaS loophole, or it is a nonfree EULA. You can't have your cake and eat it too, regardless of what OSI says.

2024-08-17 19:35:04 GMT

- reply

I don't buy the EUPL claims. The whole "SaaS" fix seems to be based on this convoluted set of definitions:
- Article 3 requires source offer for "providing" the work. It specifically calls out Executable Code, but SaaS usage does not in fact "provide" executable code.
- Article 2 allows "communicating to the public", but it is unclear how this somehow qualifies as "providing" the work unconditionally.
- Article 1 defines "communication" as, among other things "providing access to its essential
functionalities at the disposal of any other natural or legal person".
- Finally, Article 5 does somewhat tie this together with "When distributing or communicating copies of the Work, the Licensee will provide a machine-readable copy of the Source Code or indicate a repository where this Source will be easily and freely available for as long as the Licensee continues to distribute or communicate the Work.". This might be enough to do the job, but it also becomes a restriction on *usage* since "communicating" is defined to include a subset of usage.
In addition, Article 2 allows you to "use the Work in any circumstance and for all usage", and I fail to see how that doesn't cover SaaS usage.
This whole thing is a flimsy contradicting mess as far as closing the SaaS hole goes, I wouldn't bet my code on it. Thankfully, unlike the AGPL, at least it isn't a compliance nightmare for mere contributors.
I do not believe it is legally possible to properly close the SaaS loophole and remain OSI compliant. If the Article 5 wording is legally sound and does that, this license should have never been OSI certified either as it becomes an EULA. You can't just redefine terms to include what is considered "usage" in common parlance and then claim you aren't restricting "usage" because you called it something else. If Article 5 is solid, it imposes a restriction on mere *users* (someone who doesn't modify the Work still has to ensure a source offer exists and is accurate if they install it and serve it), which makes the license into an EULA and decidedly not OSI compliant.

2024-08-17 14:48:37 GMT

- reply

In theory yes, but since the AGPL offers nothing for such a driver, using it is pointless and only adds uncertainty. See e.g. how multiple teams of lawyers at FAANGs have argued that there is a legal case to be made for strong virality, and then the network condition could start to apply. Indeed none of this is tested in court.
But my point still stands, the way the AGPL attempts to go about doing this is just a so-clever-it's-dumb hack and compliance is a nightmare. Every Linux distro shipping AGPL software *today* is violating the AGPL of some projects by shipping packages compiled with patches without updating the source offer URL to a repo incorporating those patches. This is a real, ongoing problem.

2024-08-17 14:42:04 GMT

- reply

If it's not a network server/app, just don't. Use GPL (or something else).
If you want it to be genuinely FOSS, you have to give up the dream of closing the SaaS loophole. In that case, again GPL/etc.
If you still want to close the SaaS loophole and are willing to be non-FOSS (because closing the SaaS loophole properly and without stupid tricks requires that) then you'll have to choose one of the stronger, non-OSI licenses on that front. I'm not particularly well versed in the available options though.

2024-08-17 13:58:04 GMT

- reply

Es lo que más testing tiene y los devs son muy majos y nos arreglan los bugs que nos afectan rápido, así que sí :)

2024-08-17 13:45:15 GMT

- reply

Worth noting: At Asahi, we do sometimes volunteer to help upstream projects with issues that affect our platform. We do this at our own discretion, often prioritizing projects we ship as the reference experience (which for Fedora Asahi Remix is KDE Plasma and the rest of the ecosystem stack it depends on, plus stock apps etc). We don't do this for every possible platform-related bug, only issues where we feel we can contribute a meaningful fix as outsiders. Sometimes we just file bugs upstream and let the upstream developers fix things themselves.
We don't have the bandwidth to literally help fix every platform-related issue, it would consume all of our time.
So us not fixing bugs for Vaxry and Hyprland is not unique, e.g. I also don't personally debug issues in GNOME either, I'd tell them to talk to the relevant fd.o folks for help. I don't know all the subtle details of kmsro/gbm/Wayland interaction myself, there are people much better equipped to handle those questions than me.
Vaxry getting himself banned from fd.o is his own problem though.

2024-08-17 13:33:46 GMT

- reply

As far as I know, yes.

2024-08-17 13:29:15 GMT

- reply

I'm just going to say, in my experience, people who *publicly* espouse views such that bigotry should be included in inclusivity more often than not have much darker skeletons in their private closet. You learn to recognize these patterns, and I'm sure the person who executed the ban was reading between the lines.

2024-08-17 13:21:00 GMT

- reply

The person in question is Polish.

2024-08-17 13:20:04 GMT

- reply

The aforementioned Hyprland author believes that everyone should be welcome in his community, even if they are literally Adolf Hitler, as long as they don't talk politics there.
So yeah.

2024-08-17 13:15:44 GMT

- reply

The Linux Graphics core community is very small. There are only a small handful of compositor backends out there, things move quickly, and institutional knowledge is concentrated in a relatively small amount of people. Documentation is often out of date or incomplete because things move quickly.
It is certainly possible to work everything out yourself without help... but it's much harder than just asking, which is why alienating yourself from the community is a really dumb move.

2024-08-17 11:09:20 GMT

- reply

No, if the GPU driver is not linked in a way that would subject the network side of the software to the AGPL terms, there is absolutely *nothing* that would stop someone from using and modifying an AGPL GPU driver and deploying it in conjunction with a network service and not offering source. The license is very, very clear that Section 13 only applies modification and cases where the AGPLed software itself is capable of network interaction.

2024-08-17 11:06:08 GMT

- reply

Actual FOSS lawyers agree with me that the preamble has zero legal significance.
https://www.rosenlaw.com/oslbook.htm
https://cache.treehouse.systems/media_attachments/files/112/977/036/051/332/547/original/4f1d34b4d0a65e64.jpg

2024-08-17 10:43:00 GMT

- reply

"Likely available separately" sounds like a pretty flimsy premise to base your entire license's raison d'etre on. There are many ways a work could have been conveyed to person B without at the same time making it publicly available to all users of person B's service.

2024-08-17 10:35:55 GMT

- reply

Unfortunately the preamble is not legal text and means nothing, it's just a way for the FSF to distract from their horrible hack and further muddy the interpretation.

2024-08-17 10:08:31 GMT

- reply

I dunno, nobody seems to have trouble joining and having a good time as long as they aren't an edgelord who supports harassing minorities and *checks notes* genocide.
https://fosstodon.org/@drewdevault/111363547103465966

2024-08-17 09:50:28 GMT

- reply

Teeechnically if Git is the distribution medium you could argue that its metadata is just as good as editing the file directly. But yeah, then the issue is that metadata isn't always there.
The AGPL definitely isn't the only FOSS license with provisions that people don't follow on a regular basis, but it's a particularly onerous case because it's just a really really badly designed clause and is actively misleading everyone about what it does, which is the whole point of the license.

2024-08-17 09:23:08 GMT

- reply

That interpretation flies in the face of the parenthetical immediately after:
> (if your version supports such interaction)
Which makes it crystal clear that this is about support and capability, not actual usage.

2024-08-17 09:09:25 GMT

Apparently the new Hyprland compositor backend breaks
on Asahi (and probably also every other kmsro system and system with interesting buffer format restrictions, like Mali/Qualcomm/etc).
The author isn't sure what they're doing wrong. Of course, the solution is for them to talk to the Freeresktop/Mesa/DRM community, which is where all the knowledgeable people about all these subtleties are...
Oh wait 🙃
Getting banned from the Linux Graphics community: not recommended if you want to be writing a Wayland compositor.
Either way, this isn't an Asahi problem, so please don't file bugs with us.

2024-08-17 08:33:55 GMT

- reply

You are arguing against the intent of the people who *wrote* the AGPL, by perpetuating the myth that the AGPL restricts usage.
Seriously, go read up on the history of the AGPL. What I said is correct, the intent, and how it was written, because *the whole thing is a legal hack to avoid having to restrict usage because that would make it nonfree*.
The AGPL clause in question very carefully talks only about modification and even explicitly calls out "support" for network access. It doesn't matter how the software is deployed. The clause is very clearly, explicitly, and deliberately a restriction on modification only regarding the functionality of the software, and has zero bearing on usage, because it takes effect when the software is *modified* only well before it has a chance to be deployed or used in any way.
People just don't want to believe it is because indeed it is a ridiculous way to do this. But the FSF is ridiculous like that.

2024-08-17 08:30:17 GMT

- reply

I explained exactly how a link to a GitHub repo breaks the GitHub flow if you want to comply with the license.
Sure, it works, except it doesn't in practice because nobody remains compliant with that method.

2024-08-17 08:27:08 GMT

- reply

This ☝️
And yes, the same problem exists in other distros.

2024-08-16 18:45:54 GMT

- reply

The restriction applies as long as it can *potentially* be used over a network, that is, as long as it has network features (e.g. is a server or web app).
You can indeed remove such features and make it purely local-only and ignore that license term then, but that's not typically very useful.

2024-08-16 18:40:22 GMT

- reply

It's specifically a condition on *modification* (if you modify the program...), nothing else. It is written to feel like a usage restriction, but what it actually is is a modification restriction.

2024-08-16 18:25:15 GMT

- reply

No, this is an AGPL misconception that won't die. What it actually does is impose a restriction on *modification*.
Specifically, it says that if you modify the software you have to *cause* it to make its source code available or offered to network users. You are not allowed to modify the software without making *that* modification first.
Absolutely nobody complies with this properly.
Nothing in the AGPL alters the distribution terms whatsoever. The FSF did it like this because they know if they did that, it would be blatantly non-FOSS.
Alas, this goes against the spirit of the OSI definition #3 (it restricts derived works). So it still should have never been called FOSS.

2024-08-12 20:40:43 GMT

- reply

Nah.

2024-08-12 19:43:36 GMT

Targeted PSA: there's a power outage in a certain datacenter I host stuff at. If you're wondering why $stuff is down, that's probably it. If you aren't wondering then it probably doesn't affect you.
Main personal impact is my email and IRC bouncer are down.

2024-08-11 15:24:44 GMT

Today in "why do I get all the cursed bugs": https://bugs.kde.org/show_bug.cgi?id=491579
No crazy low level stuff this time, just a really annoying corner case in environment variable handling specifically in KDE Plasma...
I had to debug it by looking at /proc/*/environ to see at which process the environment variables start to go wrong, and then putting dumping scripts in /etc/xdg/plasma-workspace/env to understand how startplasma processes things.