Today, I received the same email for my Chromium package for Slackware Linux.When I started building Chromium for Slackware, I reached out to Google to formally arrange a Google API key/id/secret combination for use in my Chromium binaries that allow people to login to their Google account *and* use Google sync (passwords, bookmarks, history etc).From the email I received I understand that the ability to use Google Sync will be removed from my API keys used to build this Slackware Chromium browser binary. The value of the Chromium package for endusers will drop right to zero if that is true.I honestly see no reason to continue compiling and packaging Chromium for Slackware if the Google developers present in this group confirm this policy change by Google.Which would be a shame since there is no 32bit Google Chrome and I have been offering 32bit Chromium packages until today for the most recent releases of Slackware. Yes, 32bit OS-es are still being used.Developers, please comment.Eric Hameleers--Op vrijdag 15 januari 2021 om 19:39:29 UTC+1 schreef evan...@foutrelis.com:Does this mean that Chromium builds shipped by Linux distros will no longer have access to Sync (e.g.: saved passwords and bookmarks)?Or would removing "google_default_client_id" and "google_default_client_secret" allow our Chromium builds to continue to function normally?On Fri, 15 Jan 2021 at 20:06, The Google Chrome Team <chrome-...@google.com> wrote:Hi Chromium Developer,
We are writing to let you know that starting March 15, 2021, end users of Chromium and Chromium OS derivatives using
google_default_client_id
andgoogle_default_client_secret
on their build configuration will no longer be able to sign into their Google Accounts.What do I need to know?
During a recent audit, we discovered that some 3rd-party Chromium-based browsers had keys that were allowed to access Google APIs and services that are reserved for Google use only. Chrome Sync is the most notable of these APIs.
In practice, this means that a user would be able to access their personal Chrome Sync data (such as bookmarks) not just with Chrome, but also with a non-Google, Chromium-based browser. Please note that users would only be able to access their own Chrome Sync data, and only a small fraction of users of Chromium based browsers were impacted. We have no reason to believe that user data is being abused or accessed by anyone other than the users themselves.
As part of Google’s efforts to improve user data security, we are removing access from Chromium and Chromium OS derivatives that used
google_default_client_id
andgoogle_default_client_secret
on their build configuration to Google-exclusive APIs starting on March 15, 2021. Guidance for vendors of Chromium derivative products is available on the Chromium wiki.What does this mean for my users?
Users of products that are incorrectly using these APIs will notice that they won't be able to log into their Google Accounts in those products anymore.
For users who accessed Google features (like Chrome Sync) through a 3rd-party Chromium-based browser, their data will continue to be available in their Google Account, and data that they have stored locally will continue to be available locally.
As always, users can view and manage their data through Google Chrome, Chrome OS, and/or on the My Google Activity page, and they can also download their data from the Google Takeout page, and/or delete it from this page.
What do I need to do?
To avoid disruption, follow the instructions for configuring and building Chromium derivatives in the Chromium Wiki (link provided above).
Possible ways to implement this are:
- Removing
google_default_client_id
andgoogle_default_client_secret
from your build configuration.- Passing the
--allow-browser-signin=false
flag at startup.Your projects that may be affected by this change are listed below:
If you have any questions or require assistance, please contact embedd...@chromium.org.
Sincerely,
The Google Chrome Team
© 2021 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043
You have received this mandatory service announcement to update you about important changes to Google services you use.
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/8f555d67-bc0e-48c0-91f4-881fa0ea6a9an%40chromium.org.
Note that the public Terms of Service do not allow distribution of the API keys in any form. To make this work for you, on behalf of Google Chrome Team I am providing you with:
- Official permission to include Google API keys in your packages and to distribute these packages. The remainder of the Terms of Service for each API applies, but at this time you are not bound by the requirement to only access the APIs for personal and development use, and
- Additional quota for each API in an effort to adequately support your users.
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CAEoffTByYuVk%3DOSDfFWjbbLnzKM1Pd%3DfdXR5OP%2B5esHnr6LVbQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CAA407mzzXY-4QsGYB7rTUD3zdux71%3DQx5Z7ZVueLk%3DRT-39bMA%40mail.gmail.com.
HiJust as a note, this will also affect all BSDs shipping chromium.On 2021. Jan 19., at 20:59, Tom Callaway <spo...@gmail.com> wrote:This is a really unfortunate result, especially for those of us (most of us) who have been maintaining chromium for our respective Linux distributions since the beginning.Is there really no way for us to continue to access the Sync (and the other "Google Exclusive" APIs) in our Linux distribution packaged Chromium builds?Tom
--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAA407myqUJjxkpsT4c5hJ1WVA3H_FmUawzM0Gyroxba6%3DSgYuA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CACp8ZrJDzy4LOcU6MSJYocRWLBJR5fOR0GOTsSo2RS%3DXGWst%2Bg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/6EAE783C-6350-4FE9-BC83-AFA5E2E2E6EA%40openbsd.org.
Well, it is obvious that this Google employee called jochen (no idea about his legal status) is adamant at alienating a community of distro packagers who for many years have been providing a service both to distro users (I repeat, the latest Chromium for Slackware is still available as a 32bit build) and to Google themselves (offering people an alternative to the Open Source Firefox and thereby increasing the number of consumers of the Google platform services which will surely have been very profitable).Frankly, I find his statement insulting to us distro packagers and an offense to his colleagues who have collaborated with us for a long time through this Google Group to provide stable native binaries for our distros (thanks guys, really).I can understand that Google wants to do something about abuse of their resources by commercial 3rd parties who ship embedded Chromium in their products and thus saving on infrastructure cost, but we are providing these packages for free, as a community service to users of our Linux distros which are also free. Please explain to me why this is a good thing jochen.This is only going to convince people to switch to Firefox. At least that browser can be built from source without effort, and its users are actively encouraged to use Mozilla Sync. When the advantage for Chromium users to be able to access their data across all platforms (Linux, Windows desktops, Android phones) is taken away from us, there is no point in continuing to provide native distro builds. The value of 'just another browser' is zero.Jochen, should we start telling the users of our distros what is happening and point them to the Mozilla alternative?Also, I am surprised at the deafening silence of our friends of the Google Chromium team. Are we all left to hang out and dry here? Is this an internal political struggle or power grab?I am considering an alternative approach to just stopping with my Slackware packages - and that is to inform my users about the public availability of Google's own API keys, plus the fact that you just have to export them in your shell environment as values for the GOOGLE_API_KEY, GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET variables before you start Chromium.EricOp dinsdag 19 januari 2021 om 21:23:12 UTC+1 schreef robert:
Hi Dirk,Good to hear that you are all in alignment over there at Google, but please address my actual questions, remarks, frustrations and doubts and ignore the sarcasm.EricOp dinsdag 19 januari 2021 om 22:02:00 UTC+1 schreef Dirk Pranke:
jochen@ represents the Chrome team on this (including the Google members of the Chromium team, which includes myself), so we're attempting for this to not be a deafening silence. This change should also not be interpreted as the result of an internal struggle or power grab.-- DirkOn Tue, Jan 19, 2021 at 12:56 PM Eric Hameleers <al...@slackware.com> wrote:Well, it is obvious that this Google employee called jochen (no idea about his legal status) is adamant at alienating a community of distro packagers who for many years have been providing a service both to distro users (I repeat, the latest Chromium for Slackware is still available as a 32bit build) and to Google themselves (offering people an alternative to the Open Source Firefox and thereby increasing the number of consumers of the Google platform services which will surely have been very profitable).
Frankly, I find his statement insulting to us distro packagers and an offense to his colleagues who have collaborated with us for a long time through this Google Group to provide stable native binaries for our distros (thanks guys, really).I can understand that Google wants to do something about abuse of their resources by commercial 3rd parties who ship embedded Chromium in their products and thus saving on infrastructure cost, but we are providing these packages for free, as a community service to users of our Linux distros which are also free. Please explain to me why this is a good thing jochen.
This is only going to convince people to switch to Firefox. At least that browser can be built from source without effort, and its users are actively encouraged to use Mozilla Sync. When the advantage for Chromium users to be able to access their data across all platforms (Linux, Windows desktops, Android phones) is taken away from us, there is no point in continuing to provide native distro builds. The value of 'just another browser' is zero.Jochen, should we start telling the users of our distros what is happening and point them to the Mozilla alternative?
Also, I am surprised at the deafening silence of our friends of the Google Chromium team. Are we all left to hang out and dry here? Is this an internal political struggle or power grab?I am considering an alternative approach to just stopping with my Slackware packages - and that is to inform my users about the public availability of Google's own API keys, plus the fact that you just have to export them in your shell environment as values for the GOOGLE_API_KEY, GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET variables before you start Chromium.
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/658b0ade-e1b8-4dc6-9bdb-d7582d416f63n%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CAEoffTAonpUTmnQiwnrPQRgH6QFd4XbhjGBn9RxFLOtcAXB2mA%40mail.gmail.com.
Hi,
> To reiterate, the APIs were not designed to be used by third-party software, so short of a complete rewrite, there is no unfortunately no option.
This looks to me like a change in approach: in the past, the Chromium project was supportive of Linux distributions building a copy of Chromium from source for people to use.Is that no longer a goal?
Puzzled,Jonathan
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CALjhuieH6fB4KK%3DFNffJxm267BW0sDiN-gAMFoVt9XzXmNfuZg%40mail.gmail.com.
Dirk Pranke wrote:
> There has been no change to the browser source code per se, and you can still build a perfectly functional browser, except that now it can't use Google/Chrome Sync.
>
> We know this affects users on platforms where there isn't a supported version of Chrome, and probably other users as well.
Thanks, Dirk.It sounds like this means two things for packagers:- any high quality package will need to provide affected users with instructions for generating personal API keys. That way, Chromium's support for these features can still be useful, though it would require more fuss to make use of it. This makes the terms behind the API keys less murky, which seems valuable regardless (e.g., for users who plan to make use of their freedom to further modify the package they received from a distributor).- we'll need to find a way to provide a reasonable experience for users who haven't done that yet, and to make this more discoverable.We have a month and a half or so to work on it, which is not ideal but is better than it coming without warning.Thanks,Jonathan
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAOf41NmAU%3DYzsOAUTJ%3D9d378XE%3Dk%3DmYUqDW7TXd-PtpCw1f1MQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/2cd70dcd-1e0b-4186-bc55-9465d2858660n%40chromium.org.
FYI, the 2013 special terms, additional quota, and exact wording of the email I sent to packagers passed the internal approval process, including legal, engineering, and VP-level management.
If this reversal was better communicated, we could have a less confrontational, more productive conversation. I recognize that everyone seeks to do the right thing though: protect user data, and offer users a great web browser experience that is 100% open source.
How about giving users an option to allow Chromium access (opt-in) - is that a possible path forward?
Unfortunately, this is not an option (Jonathan also suggested that somewhere up thread). If I had a better option to offer, believe me, I would have shared that already.
--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CAA407mz6-bWT7n6V%2BYoc2CdheNM4q2-_Cjecc4U%3DhrHy_M2GCA%40mail.gmail.com.
The change we announced impacts the ability to "Sign into Chrome" and consequently first party features that depend on being signed into Chrome. This does not include Safe Browsing, which doesn't depend on being signed into Chrome, and is available to third parties for non-commercial use (cf https://developers.google.com/safe-browsing).
--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAA407my9xjqw2EwUM7LBF4dtjnX2CKVuFN_S7ndFyexF8tmcaw%40mail.gmail.com.
I see relevance in the fact that if I look at my Cloud Console and open the page for Chrome Sync API, what does the the API description say?I quote: "Google Chrome Sync API for use in Chromium."You can keep replying with empty words all day long but in the end you're just throwing all of us Chromium distro packagers under the bus jochen.
This is a (partial) list of APIs Chrome depends on, including APIs available to third parties. The changes we announced affect the OAuth 2.0 client id and secret which are used for signing into Chrome, not the API key.
On Mon, 25 Jan 2021 at 21:16, Jochen Eisinger <joc...@chromium.org> wrote:This is a (partial) list of APIs Chrome depends on, including APIs available to third parties. The changes we announced affect the OAuth 2.0 client id and secret which are used for signing into Chrome, not the API key.You have maintained that our Chromium builds are prohibited from using Google APIs. This includes the API key, in addition to the OAuth 2.0 credentials. Unless you are now saying that the API key is fine to keep (based on which section of the Terms of Service?), then you are directing distribution maintainers to ship Chromium without Safe Browsing (among all the other lost functionality). [1] [2]
You can't randomly pick which credentials you want to limit, which go against the ToS and which are fine. Either Chromium is no longer a viable package for Linux and BSD distributions, or the Chrome team needs to come up with a way to keep these Chromium builds functional. If you don't want to bother with the latter, Chrome's keys can be used instead, which is allowed by the ToS exception given to us in 2013. [3] [4]
you're welcome to continue to use third party Google APIs with your API key
The chromium code should fail gracefully if a given API is missing from the key, or if the API runs out of quota
We never granted permission to use Chrome's API key for third party software.
Also, the OAuth 2.0 integration was introduced in Chrome 69 in 2018.
On Tue, 26 Jan 2021 at 16:06, Jochen Eisinger <joc...@chromium.org> wrote:you're welcome to continue to use third party Google APIs with your API keyAre you sure about that? The Terms of Service seem to prohibit it (unless you take into account the exception from 2013 which you said they didn't have the authority to give). You also wrote that Safe Browsing is free for non-commercial use, for which Chromium used in a work environment might not qualify.Fedora also dropped all keys so I'm guessing their users are now getting Unsafe Browsing after the Chromium 88 update.
The chromium code should fail gracefully if a given API is missing from the key, or if the API runs out of quotaSafe Browsing does not work without an API key so as far as I'm concerned, the Chromium code by itself will only be good for Chromium development after March 15.We never granted permission to use Chrome's API key for third party software.Is Chrome's API key a Google API key? Then we have "permission to include Google API keys in your packages and to distribute these packages".
You said you're not a lawyer and can't give legal advice. I'm not a lawyer either but the above permission seems good enough to me.Also, the OAuth 2.0 integration was introduced in Chrome 69 in 2018.Both Arch's and Chrome's OAuth 2.0 Client IDs date back to (at least) 2013. I'm not sure where you're going with the 2018 year.
Was this 2013 email really backed by a Google Vice President with full company vetting? It seems like the truth of this is agreed upon by all parties. Wow. It's hard for me to imagine a more real-seeming commitment than that.Yet according to the Googlers in this thread, the apparent commitments in these 2013 emails were not real commitments, however real-seeming. (I hope I have accurately summarized the position.) Yet doesn't taking this position seem a little like opening Pandora's Box?If Google continues with this, every Open Source project will have to ask the question that if these emails for Chromium are not considered to be a real commitment by Google, then are Google's commitments to their project real? What would a real commitment from Google even look like, that it might be stronger than these 2013 emails? I don't know what actions each Open Source project might take to protect the Open Source community from Google after that, but certainly any actions taken won't be in Google's favor, and considerable ill-will will be generated towards Google where there was none before.I wonder: Has Google approved this action with full knowledge of the existence of the real-seeming commitments it had made, how denying those commitments might affect its relationship with the larger Open Source community, and how poor relations with the Open Source community might affect more of its customers and products than just Chrome?Perhaps these other aspects should be considered for a while before implementation?
RE: "Again, we're not asking you to change the API key, but to either build without the OAuth 2.0 client id and secret or to disable the Google signin integration. "So we are OK to disable all the API calls marked as private and can still embed the API client_id and secret? We aren't distributing the id and secret as such since its embedded within the binary.
On Wednesday, 27 January 2021 at 15:46:55 UTC joc...@chromium.org wrote:Hey,On Tue, Jan 26, 2021 at 6:34 PM Evangelos Foutras <evan...@foutrelis.com> wrote:On Tue, 26 Jan 2021 at 16:06, Jochen Eisinger <joc...@chromium.org> wrote:you're welcome to continue to use third party Google APIs with your API keyAre you sure about that? The Terms of Service seem to prohibit it (unless you take into account the exception from 2013 which you said they didn't have the authority to give). You also wrote that Safe Browsing is free for non-commercial use, for which Chromium used in a work environment might not qualify.Fedora also dropped all keys so I'm guessing their users are now getting Unsafe Browsing after the Chromium 88 update.I asked the Safe Browsing API team to clarify on their public documentation that the use of the SB API in chromium browsers continues to be permissible.Again, we're not asking you to change the API key, but to either build without the OAuth 2.0 client id and secret or to disable the Google signin integration.The chromium code should fail gracefully if a given API is missing from the key, or if the API runs out of quotaSafe Browsing does not work without an API key so as far as I'm concerned, the Chromium code by itself will only be good for Chromium development after March 15.We never granted permission to use Chrome's API key for third party software.Is Chrome's API key a Google API key? Then we have "permission to include Google API keys in your packages and to distribute these packages".I'm not sure where you're trying to go with this question. I think I've made myself sufficiently clear.You said you're not a lawyer and can't give legal advice. I'm not a lawyer either but the above permission seems good enough to me.Also, the OAuth 2.0 integration was introduced in Chrome 69 in 2018.Both Arch's and Chrome's OAuth 2.0 Client IDs date back to (at least) 2013. I'm not sure where you're going with the 2018 year.Sorry, you're right about the OAuth 2.0 client id existing before. I was referring to the API we currently use to get LSTs (the one we're changing) which was introduced in 2018.
--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/e5d20c24-8231-41e1-864a-b97dd817b83bn%40chromium.org.
OK Jochen. My company need the Chrome Sync API sincerely.For using the restricted API, What should third-party do?
Have to pay? or should become official partner of Google?Could you tell me contact information for payment or partnership?
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/a6c58a3a-d7e9-4b0d-8974-eac23bf65efen%40chromium.org.
On Friday, January 29, 2021 at 6:17:04 AM UTC+9 joc...@chromium.org wrote:
Yes, for Chromium OS you'll indeed need to set the client id and secret to be able to log in with a Google Account. The --allow-browser-signin flag only affects chromium, on chromium os, the browser gets the LST from the OS.Note, however, that the restriction to only use this for development still applies.
@Jochen. Can I ask exact meaning of the restriction?Do you mean that using google_default_client_id google_default_client_secret with the --allow-browser-signin=false flag in Chromium OS is allowed only for development/test? not allowed for Chromium OS derivation distribution?
Q1: Do you mean the flag (--allow-browser-signin=false) only works with standalone Chromium? The flag doesn't work with Chromium which is in CROS?
Q2: Could I ask exact role of Chrome Sync?Is it affects to only Chromium browser (bookmark, history, extension)?Or also affect to user's setting of CROS (language, apps in drawer, wallpaper)?
Q3: How much will Oauth2.0 rate limit be decreased since 2021-03-15?Now (2021-03-05) Oauth rate limits in GCP > OAuth consent screen is ... 100 user cap & 10,000,000 grants per day (request Oauth rate limit increase is available).
I'd like to make one followup, since something else in this thread is bothering me. It's this:> Jonathan: Hope that helps,This may be just a signature line of yours Jonathan, but it occurs to me that in general people don't realize what might help here. If people at Google really want to help, there are a number of things that will make this better. The first and most obvious is to undo this decision. I've outlined why I think it's a bad decision and why Google may not have fully thought out the consequences. However, if Google is determined in this action, there are still some things that Google could do that might help. I'll outline them in a series of steps below.In thinking about these steps, realize that what Google is doing here will be judged. So basically, the steps that might mitigate this action are the same steps that might mitigate a crime as viewed by a judge. Some of these are 1. Recognition, 2. Intent, 3. Contrition, 4. Recompense.1. Recognition. It's necessary for Google to recognize that it's doing something bad here. If Google doesn't recognize it's doing something bad, it's hard to do anything else to fix it. So far in this forum, it seems like the full recognition of the essential badness of this action isn't recognized by Google, and that limits what Google can do to repair the damage. In a court of law for a crime, someone who can't even recognize their crime might be ruled incompetent to serve trial and be sent to an insane asylum. I'm not sure what the corresponding analogy is to this action by Google, but clearly Google needs to admit its fault before other mitigations can occur.2. Intent. So far, it seems that Google is masking its intent regarding why it is doing this. In a murder trial it matters whether it's first degree, second degree, or third degree. If Google is not open about its intent, Google's intent will likely be interpreted as being the most nefarious possible. We might assume, for example, that Google is trying some power play in the browser market, and that actions against Firefox are next. Please don't tell us that this isn't correct and expect anyone to believe it. As we've determined, a Google VP can't be believed, so why would anyone believe a random comment from a Google employee in a discussion? To regain any credibility here, Google needs to put its thoughts, intent, and strategies on the line here to tell us what's really going on.3. Contrition. Some statements from the Google VP level about how they're at least sorry to break their commitments might be helpful in attaining some forgiveness. Right now, it seems like Google has no care and no remorse.4. Recompense. It seems Google has thought little about the effects these unilateral actions might have on others, the damage it might cause, or the steps that Google might take to mitigate or reverse that damage. There's time to figure it out, but perhaps not a lot of time.There may be some other steps that I've omitted. I think however if you follow this criminal analogy those steps can be ferreted out.I think that things said by Google so far in this forum have been mostly harmful, not helpful. In particular, the attempts to defend this action as something reasonable and acceptable are in complete violation of Recognition.Regards,RossOn Sunday, January 31, 2021 at 7:36:51 PM UTC-7 Ross Martin wrote:> Ross: What I understand you to be saying here is that if anyone wants to get a commitment from Google that Google actually keeps, it has to be in official terms> Jonathan: This seems like an extreme reading.This isn't an extreme reading of Google's actions -- it's the only possible reading of them. If you think differently, please give an example of a commitment that Google would feel obliged to keep that's short of a legally binding one. I'm not coming up with anything, and if there's nothing it proves the point.I believe we've established that an official letter from a VP with legal vetting isn't enough to be a commitment that Google will keep. So what's enough? Two VPs? Three? Maybe the President of Google?Maybe if back in 2013 the Chromium developers had negotiated changes to the Official Terms? Of course, Google could just change those terms, so that doesn't work either. Unless perhaps the terms were unalterable. But that means they were legally binding, which goes back to something legally binding being the only commitment that it appears Google will keep.Don't Google's actions here basically proclaim that Google won't honor any non-legally-binding commitments to Open Source? (Or will only honor them at its pleasure, which is the same thing.) Again, if you disagree, give us an example scenario of what the Chromium packagers/developers should have done differently back in 2013 so that Google would now honor its commitment. Give us an example of what any project in Open Source needs to do today to get a commitment that Google would feel obliged to honor in the future.By the way, if you can come up with such an example, how are we to know we can trust it? Could you please get a VP to sign off on it, and get it vetted by legal?From where I sit, it sounds like the Chromium developers got a commitment far beyond what I would expect is normally possible, and yet Google is now violating it anyway. If readings of this action seem extreme, perhaps one should consider that it might not be because of some fault in the reading, but rather because of how extreme Google's action is. An action that doesn't extreme from within Google may seem very extreme looking the other direction.I would also like to make an aside: I ask your pardon, Jochen. What Jonathan said made me realize that it may have sounded like I was blaming you for this message or putting it in your mouth. The apparent message that Google won't honor its commitments seems loud and clear from Google's actions, independently from anything you've said. I realize that you're just the messenger. You're not responsible for this action or for the message that the action sends to Open Source.Regards,RossOn Saturday, January 30, 2021 at 5:41:03 PM UTC-7 jrni...@gmail.com wrote:> What I understand you to be saying here is that if anyone wants to get a commitment from Google that Google actually keeps, it has to be in official terms
This seems like an extreme reading. Jochen was answering questions
about official commitments with answers about official commitments.
That doesn't mean that the only way to work together is via legal
contracts --- on the contrary, it's answering in the same terms as he
was asked.
Hope that helps,
Jonathan
On Sat, Jan 30, 2021 at 8:58 AM Ross Martin <ross....@ieee.org> wrote:
>
> jochen,
>
> I believe I understand what you're saying, but to make sure let me repeat back what you've said in my own words to make sure I've got it.
>
> All commitments that Google makes are valid in the millisecond in which Google makes them, but Google can and should reevaluate its position in the next millisecond and, if it wishes, abrogate any and all of its commitments as the environment inside Google evolves.
>
> Isn't that basically equivalent to what you just said? I've exaggerated it slightly to help show how poorly it might be viewed, but I believe I haven't deviated from the fundamentals of what you've said. This clarification isn't helping Google's position.
>
> Your point that there was never a change in Google's official terms is a valid one, but it's also not a point that favors Google. What I understand you to be saying here is that if anyone wants to get a commitment from Google that Google actually keeps, it has to be in official terms, and also in terms that Google has no rights to unilaterally alter. i.e. it must be a legally binding document drawn up by lawyers, signed, witnessed, registered, etc.. Otherwise, that agreement with Google is essentially worthless, because Google feels it can change it at any time as the environment within Google evolves. Yet how many people in Open Source have such a legally binding agreement with Google, or will ever get one? My guess: none.
>
> So your statements seem equivalent to saying that no one in Open Source can trust Google to abide by any commitments that Google has made or ever will make. Correct?
>
> I personally imagine that what's going on here is the environment inside Google has changed because the VP has changed. The new VP sees no need to keep the old VP's commitments, since they are apparently viewed within Google as commitments of the VP instead of commitments of Google.
>
> What you should perhaps understand is that people external to Google view Google VPs as being important. If someone in Open Source gets an official commitment from a Google VP, they view this as a commitment of Google of the highest order, and not a transient commitment that's just the hot air of one Google VP who's here today and gone tomorrow. It might be good for Google to maintain this external illusion that Google VPs are important, and to at least treat times when Google feels it must go back on its VP's agreements as moments of import.
>
> So as I said this action by Google is going to change the perception that people have of Google, especially within Open Source. The effect will not be limited to Chromium or Chrome, because the worst thing about this isn't its effect on Chromium but its revelation that Google can't be relied upon to keep its agreements. This will affect people's willingness to engage in relationships with Google of any sort without distrust and suspicion. It's a natural consequence of the actions you're announcing.
>
> As I said, there will be far reaching and persistent consequences to this action, to all Google departments that interact with Open Source. Perhaps Google should take a step back and re-evaluate that before acting in a way that will convince everyone that Google is much less trustworthy than they believed.
>
> Regards,
>
> Ross
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/5dc34636-5639-42d3-96ef-7ab44aa6ee35n%40chromium.org.