Re: [GNU-linux-libre] Status of google chrome and chromium

[A.J. Venter]

On Thu, Jan 7, 2010 at 10:00 AM, jaromil <address@hidden> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>> Guess I'll stick my oar in here.
>
> hola Karl! :)
>
>> > more on  Chromium / Iron:

There is certainly a lot of information and speculation in these
mails. My conclusions are as follows:
Chromium seems extremely open to patches, when upstream is willing to
work with us, we should be willing to work with upstream - so I think
sending patches to them is better than forking.
If Iron had been forked for because chromium didn't WANT privacy
patches that would be a different matter, but forking so you can make
money out of ad-space is a bit silly in my book (no problem with
making money from advertising, it's just not a good reason to fork a
complex codebase when there is no practical problem improving the
original).

That being said, I agree that private mode should not be a "select"
option, it should be a default which those users who so desire can opt
out of. Presumably some people trust google (or any other corporation
for that matter) more than we do, I don't think we should deny google
the right to let people send them information - that would amount to
censorship on our part, but I do believe harvesting it should require
EXPLICITE consent.

So a patch to make incognito the default and have the option to
disable it in the settings may well be accepted (possibly with a
dialog to ask permission to disable it during the initial setup
wizard, gray area but one I can live with - thoughts ?)
For kongoni, because do source based ports, we could probably apply a
patch like that at install time for the users without chromiums
explicite agreement - but it would be better to have it in upstream in
the first place.

The moreso because I would prefer to avoid a source based port for
chromium and rather do binaries in this case (chromium requires the
user to download and install a suite of build tools that are almost
3Gb in size to build from source - that's a bit impractical for most
users).
It would  just be better if users could use the official tool, if
google's updates (which are mostly bug and security fixes) were
available to them (though I don't agree with them being automatically
installed, updates should go through the distro's repository where
developers can CHECK them first).

But I believe we can, and should, engage with the chromium developers
about these things - it definitely sounds like they'd be open to our
concerns and helping address them. It's worth noting a major movement
within google that aims specifically to address the problems RMS has
pointed out with cloud computing and ensure their web apps are not
problematic for users in these ways (for example  requiring all google
web-apps to have the capacity to easily export your data to a format
you can easily use offline or take to another provider), that keeps
track of the progress of various google projects on these matters.
That the vice president of the FSFE is in fact a google employee.

In short, that while google is by no means a free software company,
they have a track record that is quite friendly to us, and a large
section of the company looks very favorably on our ideals. With a
company like that, engagement and communication is likely to give
better and more suitable results for ourselves and our users than
conflict I believe.
It's important to criticize the non-free status of popular
applications like picasa (or for that matter, their web apps) but it's
also important to recognize where the work they do benefits and
supports us - that is, after all, how we create motivation for them to
benefit and support us more.

-- 
A.J. Venter
Founder and lead developer, Kongoni GNU/Linux
www.kongoni.co.za
www.silentcoder.co.za - Blog