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.
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?
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):
Ugh. Lemmy just deleted my whole comment because “Cancel” is WAY too easy to press… Dammit. Here’s a reconstruction:
I didn’t expect such a thorough reply! I still think Google is bound by LGPL because Blink is eventually derived from KHTML which was licensed under LGPL. This was based on just some quick Wikipedia “research”, but now here’s some better proof thanks to your links:
The terms and conditions vary from file to file, but are one of:
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
[...]
*OR*
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
[...]
THIS SOFTWARE IS PROVIDED BY APPLE COMPUTER, INC. ``AS IS'' AND ANY
[...]
GNU LIBRARY GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1991 Free Software Foundation, Inc.
[...]
So the license differs from file to file, and importantly, some files are still LGPL. Clicking around sorta randomly I’ve found an example: Page.cpp which starts with this copyright notice:
/*
* Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 Apple Inc. All Rights Reserved.
* Copyright (C) 2008 Torch Mobile Inc. All rights reserved. (http://www.torchmobile.com/)
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License for more details.
*
* You should have received a copy of the GNU Library General Public License
* along with this library; see the file COPYING.LIB. If not, write to
* the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
* Boston, MA 02110-1301, USA.
*/
So from my understanding of (L)GPL (which is the bare minimum understanding and potentially wrong), since some files are LGPL, Google must continue to release the full source code indefinitely, including the files that are licensed under BSD. Well, until the copyright on the LGPL files runs out, but thanks to Disney that’s a very long way away in the US at least. Correct me if that’s wrong.
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. Not to mention Blink is sort of limited in scope and can’t really be taken apart and have its components parted off and replaced with proprietary bits - it’s a web rendering engine, it only works as a complete package. Android is an operating system and the operating system is still FOSS, Google can make the argument that usable default apps aren’t a necessary part of the operating system.
With Blink, but 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. They differentiate their browser through the rest of the browser - UI, extensions store, sync, branding. Those parts of the browser are the equivalent of Google’s proprietary default apps on proprietary Android.
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.
Wikipedia also lists various browsers using Blink, including Falkon and Dooble licensed under GPL and BSD respectively. I haven’t heard of them before, but there. (Again, I’m not doing more research than Wikipedia right now, feel free to do so)
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. ↩︎
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
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):
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?
sedcommand, as you can see, the changes are minimal):Ugh. Lemmy just deleted my whole comment because “Cancel” is WAY too easy to press… Dammit. Here’s a reconstruction:
I didn’t expect such a thorough reply! I still think Google is bound by LGPL because Blink is eventually derived from KHTML which was licensed under LGPL. This was based on just some quick Wikipedia “research”, but now here’s some better proof thanks to your links:
LICENSE_FOR_ABOUT_CREDITS says:
So the license differs from file to file, and importantly, some files are still LGPL. Clicking around sorta randomly I’ve found an example: Page.cpp which starts with this copyright notice:
/* * Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 Apple Inc. All Rights Reserved. * Copyright (C) 2008 Torch Mobile Inc. All rights reserved. (http://www.torchmobile.com/) * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Library General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later version. * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Library General Public License for more details. * * You should have received a copy of the GNU Library General Public License * along with this library; see the file COPYING.LIB. If not, write to * the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, * Boston, MA 02110-1301, USA. */So from my understanding of (L)GPL (which is the bare minimum understanding and potentially wrong), since some files are LGPL, Google must continue to release the full source code indefinitely, including the files that are licensed under BSD. Well, until the copyright on the LGPL files runs out, but thanks to Disney that’s a very long way away in the US at least. Correct me if that’s wrong.
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. Not to mention Blink is sort of limited in scope and can’t really be taken apart and have its components parted off and replaced with proprietary bits - it’s a web rendering engine, it only works as a complete package. Android is an operating system and the operating system is still FOSS, Google can make the argument that usable default apps aren’t a necessary part of the operating system.
With Blink, but 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. They differentiate their browser through the rest of the browser - UI, extensions store, sync, branding. Those parts of the browser are the equivalent of Google’s proprietary default apps on proprietary Android.
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.
Wikipedia also lists various browsers using Blink, including Falkon and Dooble licensed under GPL and BSD respectively. I haven’t heard of them before, but there. (Again, I’m not doing more research than Wikipedia right now, feel free to do so)
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. ↩︎
The website on desktop. Footer says “BE: 0.19.3” so it’s up to date.