Hey Michael,
Sorry, I have been a bit behind with email.
On Mon, Feb 18, 2019 at 01:12:29AM +1100, Michael Gratton wrote:
> On Sun, 17 Feb, 2019 at 4:58 AM, Michael Terry wrote:
> > Thank you for the clarification! As someone that had been confused
> > about the intent and ended up relying on
Every user has to indeed obtain their personal key, it's the only way to remain
free software with reproducible builds while keeping the feature. Simplenote
for one example is an open source app that can't get accepted in F-Droid
because the data synchronization platform enforces the developer
Hi,
On Mon, 18 Feb 2019 09:52:54 -0600, mcatanz...@gnome.org wrote:
> On Sun, Feb 17, 2019 at 7:20 AM, Sam Thursfield
> wrote:
>
> [...]
>
> > 3. continue distributing a "GNOME key" with the source code, and hope
> > that Google don't mind
>
> I suggest we don't continue to willfully violate
On Mon, 18 Feb 2019 at 15:53, wrote:
...
> I suggest we don't continue to willfully violate Google's terms of
> service now that the issue has been brought to our attention. The only
> reasonable option seems to be to shut down our Google integration. Not
> just from g-o-a, but also the Safe
On Mon, 2019-02-18 at 09:52 -0600, mcatanz...@gnome.org wrote:
> On Sun, Feb 17, 2019 at 7:20 AM, Sam Thursfield
> wrote:
> > 3. continue distributing a "GNOME key" with the source code, and
> > hope
> > that Google don't mind
>
> I suggest we don't continue to willfully violate Google's terms
On Sun, Feb 17, 2019 at 7:20 AM, Sam Thursfield
wrote:
1. require every user of the software to contact Google and obtain
their own client ID, which they provide at runtime to any desktop
software that needs to interact with Google APIs at
Ha ha.
2. require distributors and people who build
> On 17 Feb 2019, at 04:04, mcatanz...@gnome.org wrote:
>
>> On Sat, Feb 16, 2019 at 2:57 PM, Nathan Graule via desktop-devel-list
>> wrote:
>> A solution would be for distribution package maintainers to use the
>> binary tarball as a base instead of sources - this way the build can be
>>
> On 17 Feb 2019, at 18:18, Alexandre Franke wrote:
>
> Hi,
>
>> On Mon, Feb 11, 2019 at 4:46 PM Allan Day wrote:
>> The “documents” source type is primarily used by GNOME Documents to
>> access Google Drive. […]
>> GNOME Documents is able to use the “files” source type as an
>> alternative
Hi,
On Mon, Feb 11, 2019 at 4:46 PM Allan Day wrote:
> The “documents” source type is primarily used by GNOME Documents to
> access Google Drive. […]
> GNOME Documents is able to use the “files” source type as an
> alternative to the documents type, and can be converted so that it can
> continue
On Sun, 17 Feb, 2019 at 4:58 AM, Michael Terry wrote:
Thank you for the clarification! As someone that had been confused
about the intent and ended up relying on GOA in my third party app,
it’s nice to see the intention spelled out so clearly.
Seconded!
Also, Debarshi, sorry for jumping
On Sat, Feb 16, 2019 at 7:58 PM wrote:
> On Sat, Feb 16, 2019 at 11:58 AM, Michael Terry
> wrote:
> > “Developer credentials (such as passwords, keys, and client IDs)
> > are intended to be used by you and identify your API Client. You will
> > keep your credentials confidential and make
On Sat, Feb 16, 2019 at 2:57 PM, Nathan Graule via desktop-devel-list
wrote:
A solution would be for distribution package maintainers to use the
binary tarball as a base instead of sources - this way the build can
be
done with secrets (ie. using GitLab CI and environment variable
secrets) and
A solution would be for distribution package maintainers to use the
binary tarball as a base instead of sources - this way the build can be
done with secrets (ie. using GitLab CI and environment variable
secrets) and sent to distributions for packaging. This certainly puts
GNOME in a unique
On Sat, Feb 16, 2019 at 12:57 PM, mcatanz...@gnome.org wrote:
It's not clear to me how g-o-a can continue to exist, then. Also,
Epiphany's Safe Browsing support. (How do Firefox and Chromium make
this work?)
Turns out it's a new restriction that took effect on January 16, 2019.
So probably
On Sat, Feb 16, 2019 at 11:58 AM, Michael Terry
wrote:
“Developer credentials (such as passwords, keys, and client IDs)
are intended to be used by you and identify your API Client. You will
keep your credentials confidential and make reasonable efforts to
prevent and discourage other API
Thank you for the clarification! As someone that had been confused about the
intent and ended up relying on GOA in my third party app, it’s nice to see the
intention spelled out so clearly.
I just wanted to mention an interesting challenge in having open source apps
handle this themselves.
16 matches
Mail list logo