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 elsedoesn’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).
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?
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. ↩︎
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.
And
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.
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).
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).
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 © 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?
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. ↩︎