On Thu, Jan 7, 2010 at 10:00 AM, jaromil <[email protected]> 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
