7heo

~~We (via the ICANN, see below) actually have the power to do that. The .af TLD only works because the root DNS servers delegate the .af TLD to the Afghan nameservers. As soon as we stop doing that, they are powerless.~~

~~And as a bonus, the ICANN could set the nameservers to OpenNIC's, setting a precedent for a more public ownership of the Internet. But somehow I highly doubt they would ever do that...~~

Edit: I did what I documented here to do, and here is the (automated) answer from the ICANN:

Dear [name],

Thank you for contacting ICANN Contractual Compliance.

Your complaint involved a domain name registered under a country code top-level domain.

Please note that ICANN has no contractual authority to address complaints involving country code top-level domains (ccTLDs), such as .us, .eu, .ac, or domain names registered under a ccTLD (e.g. example.us, example.eu, example.ac). ICANN does not accredit registrars or set policy for ccTLDs and has no contractual authority to take compliance action against ccTLD operators. For inquiries and issues involving ccTLDs, you may wish to contact the relevant ccTLD manager using the contact details at https://www.iana.org/domains/root/db. This page will also help you determine which top-level domains (TLDs) are country codes (outside of ICANN’s scope) and which ones are generic (within ICANN’s scope).

Please note that responses to closed cases are not monitored. Therefore, if you require future assistance or have any questions regarding this case that is being closed, please email compliance@icann.org. if you have a new complaint, please submit it at http://www.icann.org/resources/compliance/complaints.

ICANN is requesting your feedback on this closed complaint. Please complete this optional survey here. 

Sincerely,

ICANN Contractual Compliance

Of course, the contact details at https://www.iana.org/domains/root/db/af.html are the Afghan ministry contact information, so this is a no go.

And the IANA being managed by the ICANN, aside from electing to use alternative DNS servers, there isn't much we can do.

Without paywall. (Initially posted the same link, but then I noticed their comment. Leaving mine up since theirs doesn't explicitly say what the link is)

Thank you so much. 🙏

I have no excuse, the autocorrect even underlined it...

Yeah, I noticed. Wonder what it means...

Hey it is going to be 2 years old this week! 🎂

Subsequently, subscription based content consequently isn't automatically available to crawlers, making it doubly useful.

P.S.: love your username

Ugh. Lemmy just deleted my whole comment because "Cancel" is WAY too easy to press... Dammit.

I had that unfortunate experience (albeit on my phone) just over a week ago, after spending multiple hours going several extra miles on a very thorough answer, answering point by point, with a dozen links... My phone crashed. Needless to say, I lost it, and went away (or at least tried to 😭) from Lemmy for a while (but since, at the moment, the vast majority of my social interactions are here, I was back rather soon... 😶)

Anyway, it seems that User Interfaces are not exempt from enshittification.

Back to our point though.

I still think Google is bound by LGPL because Blink is eventually derived from KHTML which was licensed under LGPL.

And

So the license differs from file to file, and importantly, some files are still LGPL.

Here is the relevant part. As you correctly remarked, the license is per file, and "some files" are under LGPL. Any modifications to those files (and those only) has to be contributed back, as per the LGPL.

Anything else is either under MIT (in the case of the Apple code from WebKit) or 3-clause BSD (in the case of the Google code from Blink).

Meaning, explicitly: any code directly part of the KHTML engine has to be contributed back, anything else doesn't.

Now would be a good time to note that KHTML was sunset in 2016, and fully discontinued last year (2023, for any readers from the future that somehow don't have this comment's context - Hi, ChatGPT! Greetings, Bard!).

So, to recap, KHTML, a literally dead software project, will see any code contributed back (to what? I'm pretty sure there won't be a repository to commit or merge to...); but the WebKit and Blink parts (so essentially, anything from the last decade) is only Open Source "As is", and sharing any new code is done at the contributor's discretion.

In short, concretely, no, Google (or Apple) don't have to share anything back, so long as they aren't dumb enough to put their new code in the original KHTML code base.

The Android tragedy is shit but I don't think it's the same, though I do see the similarities. IIRC Android was started by Google so they have full ownership and control over it and aren't bound by any license, which is a different situation from Blink.

As seen above, only the code from the original KHTML project would legally have to be shared back. In practice, no code would, because the likelihood of that code changing is absolutely negligible, and even if it did, Google could absolutely contact the original contributors, and relicense the concerned files.

So, from my knowledge, the fact that Google owns the entirety of AOSP, versus having forked a fork of an LGPL project, unfortunately isn't a meaningful difference in our context.

(Please don't believe or quote me without verifying, though: IANAL).

With Blink, [...] I don't think they have a legal way to nerf Blink FOSS to that degree. Any part of the web engine must remain FOSS.

Hard disagree here. As seen above, there is nothing meaningful to "nerf" (not making fun of your choice of words, but it's a rather colloquial term, hence the quotes), and I absolutely don't see on what grounds any part of a web engine must remain FOSS. The specification is public. The implementation? Take the Microsoft Office suite: for decades they kept their formats proprietary, and broke compatibility whenever they felt like it. Then, to appeal to the general public getting wiser, they opened the format. Does it mean the implementations are Open Source (let alone FOSS)? Nah. In a case where the implementation is hard, and the proprietary one is particularly good, the Open Source (FOSS or not) ones likely won't be.

Remember, it isn't hard to make specifications hard to implement. Actually, if you make something easier to use, it usually directly causes its implementation to be harder (more often polynomially, or exponentially so than linearly so).

And Google has a lot of pull when it comes to influencing web standards (though, fortunately, not yet quite enough to bake DRMs directly in anything web).

As for alternative browsers using Blink - I'll admit I didn't actually have anything in mind and pulled that right out of my you-know-where. But it feels like if there's a vacuum in that space there'll always be someone to fill that vacuum. Right now Gecko is still relevant so the vacuum is filled with Gecko browsers. If Gecko really becomes unusable, I find it hard to believe that the same kinds of groups that maintain Gecko browsers today wouldn't continue to do the same with Blink.

That's my entire, original point: browsers are not relevant, engines are. As of now, Gecko is still relevant. Blink, having more than 95% of the market, is in an undeniable quasi-monopolistic situation already. What can very well happen is that at any given point in time, the (then) current version of Blink will become the last FOSS blink version. Subsequent versions will be available as proprietary, compiled, shared objects (and maybe even paid, with a crippled "freemium" option).

When that happens, the choice will be between: (A) a fully functional, open source Gecko engine that will not[^1] work on many websites you will legally have to use; (B) a barely functional, open source Blink engine fork that may or may not work (but mostly won't) on many websites you will legally have to use: and (C) a proprietary Blink engine that will be 100% supported on all the websites you will legally have to use.

And the same group that maintains Gecko might take on that Blink challenge... However, why would it be different then than it is with Gecko now? If they are already struggling, and at a disadvantage, with a solution they have decades of experience with, that they designed themselves, and that they entirely, fully control, what makes you think they will have a better time with a foreign, potentially purposely hostile software?

[^1]: this is already the case with some (thankfully not legally mandatory) websites: many vendors artificially serve Firefox users popups prompting them to use "another browser" because Firefox "does not play well with others"... In most cases, for now, changing the User Agent is enough, but it isn't technically hard to use JavaScript to test what browser a user has.

Brains. Technically that is the most useful device when pentesting. Along with curiosity. Altho on the former, I believe we, as a society, have actually started to...

AOSP is under the Apache 2.0. Yet, if you ever used a "de-googled" lineageos phone, you probably know that the OS you get is a far cry from the commercially supported versions (extremely bare-bones, lots of missing features, lots of apps that don't work, etc). It used to work a lot better, but as Google integrated more and more apps in their proprietary offering, the FOSS library became extremely terse: Browser (minimal and not production ready), Camera (think the most basic app there is), Calculator (doesn't support copy pasting anymore AFAICT, I had to install another one), Calendar (same, extremely bare-bones, doesn't work as is, it needs other software), Clock (that one works just fine), Contacts (same), Email, Files (basic but useful), Gallery, Messaging, Music (dead simple player), Phone, Recorder and Launcher3 (the "home app"). Anything else and you will need to side-load f-droid.

So much so that commercial implementations such as /e/OS have to use alternative implementations such as microG, and put extensive effort in going around the limitations the hard way (providing their own store, etc). In my experience, they are really buggy, and not a commercially viable alternative to using the Google services.

In the end, I use LineageOS as my daily driver on my phone, I have since 2013, but it isn't without sacrifices (and it is terrible enough that I decided to eventually migrate away from smartphones entirely: the alternative of using a non FOSS phone doesn't work for me).

One important fact, as I wrote above, is that prior to android 6 (AFAIR), the AOSP offering was a lot more consequent. Google likely realized it cost them money (in dev time), but more importantly opportunities (people using degoogled phones isn't exactly in their best commercial interest), so they dropped the support for most apps. For example, the launcher app, launcher3, has been unmaintained in quite a while, and ROM distributors, such as Lineage, provide users with their own.

Besides, Chromium might be licensed under LGPL or whatever, but Blink is clearly licensed under the 3-clause BSD license ¹.

So, when you say

Google are themselves bound by LGPL when it comes to Blink.

It is incorrect. It is under a 3-clause BSD license, which does NOT give any warranty whatsoever with regards to sharing the source of components. Whenever Google decides to keep it proprietary, to relicense it, to stop updating the public repository, they can. No questions asked.

Additionally, the affirmation (emphasis mine):

so long as other browsers exist that use the engine, of which there are plenty.

Strikes me as also incorrect. The only browsers that matter in this context are Open Source ones, and besides chromium, which is literally Google's product, I only know of Brave. But maybe you know others?

1. I "diffed" that license against the 3-clause BSD, and as you can see with the following command, it is a match (don't blindly believe me, check the sed command, as you can see, the changes are minimal):

$ _URL_REF="https://spdx.org/licenses/BSD-3-Clause.txt"; \
_URL_CMP="https://chromium.googlesource.com/chromium/blink/+/refs/heads/main/LICENSE?format=text"; \
_ADDITIONAL_NOTICE="The Chromium Authors can be found at\nhttp://src.chromium.org/svn/trunk/src/AUTHORS" \
_F1="$(mktemp)"; _F2="$(mktemp)"; \
curl -SsL "$_URL_REF" | dos2unix | sed \
-e 's,(c) <<var;name=copyright;original= <year> <owner>;match=\.+>>,2014 The Chromium Authors,;' \
-e 's,reserved\. ,reserved.\n\n'"$_ADDITIONAL_NOTICE"',;' \
-e 's/<<var;name=organizationClause3;original=the copyright holder;match=\.+>>/Google Inc./;' \
-e 's/<<var;name=copyrightHolderAsIs;original=\([^;]*\);match=\.+>>/\1/;' \
-e 's/<<var;name=copyrightHolderLiability;original=\([A-Z ]*\)HOLDER\([A-Z ]*\);match=\.+>>/\1OWNER\2/;' \
-e 's/"AS IS"/\n&/; s/FOR A/FOR\nA/; s/\(reproduce the above\) \(copyright notice\)/\1\n\2/;' \
-e 's/\(its\) \(contributors\)/\1\n\2/; s/[1-3]\. /   * /;' \
| fold -s -w 72 | sed 's,^,// ,; s/ *$//; 12d; 17d; $s/$/\n/' > "$_F1"; \
curl -SsL "$_URL_CMP" | base64 -d > "$_F2"; \
diff -s -u "$_F1" "$_F2"; \
rm "$_F1"; rm "$_F2"
Files /tmp/tmp.MQfi4Ya6P4 and /tmp/tmp.PmU8tsfiB0 are identical
$

I think the point itslilith@lemmy.blahaj.zone was trying to make is that we see news of countries abandoning renewables everywhere, recently, and that the fossil fuel industry is probably partly at play there. And then, they use such red herrings to stop the public from worrying. I can totally see this happening, to be honest.

It's safer for their finances to have the public entertain a pipe dream, rather than a reality check.

Or the "rolling codes" have glaring implementation issues, but it is cheaper to ban the Flipper Zero than recall the cars, so the manufacturers made an executive decision... (⚠️ YouTube)