[Dev] about cloud services

Nicolás Reynolds fauno at endefensadelsl.org
Tue Jan 20 15:45:30 GMT 2015


yesterday we were talking in the irc channel about mozilla-searchplugins
and if they should be different in [libre] and [nonprism].

since [nonprism] makes sure no program depends on proprietary services,
icarious posed[0] that mozilla-searchplugins as it is should be moved to
[nonprism], while [libre] should contain only default search engines,
like any other browser in non-[nonprism] repos.

i think this would be a regression, since duckduckgo[1] as default
search engine and disabling google services (like "safe"browsing) was
one of the first features we implemented back when parabola consisted of
a blacklist and a repo with linux-libre and icecat.

so to make things clear, i think a distinction should be made between
recommending or depending on proprietary/anti-privacy services that run
entirely as remote services, like google search as default search engine
or google unsafebrowsing, which should be removed in non-[nonprism]
repos, and proprietary services that are accessed using free software,
like proprietary protocols included in pidgin, having icedove or mua's
have shortcuts to configure gmail, etc., which should be implemented
only in [nonprism].

of course this should be analyzed case per case (see the firefox hello
issue on labs), but i think such distinction would prevent scalation a
la "remove all contact with the unfree internet!", which could be a nice
experiment, but not the scope of non-[nonprism], no?

there's a fine line between freedom #0 and development decisions after
all :)

what do you think?


[0]: if i misunderstood you, please tell me so
[1]: i know ddg is yet another proprietary service...

--
http://partidopirata.com.ar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 602 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20150120/b31ec6bc/attachment.sig>


More information about the Dev mailing list