Proposal: Revision of policy surrounding 3rd party and non-free software

[Christian Schaller]

Hi Bill and Adam,
Well another part of the PRD here is the goal to try to build something that can provide such a setup.
The idea is to try to build a system around containers (LinuxApps/Docker) which includes the option for
some library bundling (to work around distribution differences and release differences). Our thinking is that
for 3rd party vendors at least this would replace the rpm/deb building.

Next week there is devconf here in Brno (http://www.devconf.cz/). We have people like Lennart Poettering (LinuxApps), 
Alex Larsson (Docker), Richard Hughes (Software app), Aleš Kozumplík (hawkey) and more here during that conference, so I hope to pull together
a BOF session to discuss challenges and solutions in the area of desktop and containers.

Christian

----- Original Message -----
From: "Adam Williamson" <awilliam at redhat.com>
To: "Fedora community advisory board" <advisory-board at lists.fedoraproject.org>
Sent: Wednesday, January 22, 2014 11:25:03 PM
Subject: Re: Proposal: Revision of policy surrounding 3rd party and non-free	software

On Wed, 2014-01-22 at 17:04 -0500, Bill Nottingham wrote:
> Josh Boyer (jwboyer at fedoraproject.org) said: 
> > > Pedantic but (maybe) important distinction: the idea would be to prepopulate
> > > (in some way or another) the software installer application with _specific_
> > > 3rd party repositories (in the mockup, Adobe, Dropbox, Google, Nvidia, and
> > > Steam) -- akin more to having the default Fedora bookmarks include the
> > > download pages at those companies than to a Google search. Or am I
> > > misunderstanding?
> > 
> > The bookmark analogy seems fair to me, yes.  However, it might be
> > feasible to include these "bookmarks" without having them displayed by
> > default and instead requiring a user to toggle a checkbox or such to
> > enable them.
> 
> I'd rather not include any metadata or links to particular repositories in
> Fedora itself:
> 
> - packaging is a really crappy way to have to update a software
>   source list if we were to get some new third party source
> - it's also a really crappy way to *disable* a source from being
>   shown to users if we for some reason need to do so, and do so quickly
>   (waves at spot)
> 
> This is regardless of whether the third-party repo contains free or non-free
> software - the same issues apply to both cases.
> 
> Once we take that step, Adam's suggestion honestly makes the most sense to
> me - a web service exists that third parties can register their repositories
> with. They'd register what format they're providing software in/for (yum
> repos, apt repos, etc.), what OSes/releases they're targeting (Fedora, RHEL,
> Ubuntu, Debian, Arch, whatever), and some metadata (keywords, icons, etc.).

That's not actually what I was suggesting, FWIW. My take on this issue
is the fact they have to build sixteen different repos and sets of
packages in different formats is a big part of the problem, and when I
say 'a free Steam' - or, if you like, 'a pip-alike for apps', or
whatever - I really mean a distribution platform, not just a bit of
glue. It wouldn't work for something very tied to system internals like
nvidia, of course, but that's a special case; the general case of this
topic is something like chrome, and for that case, a distro-agnostic
secondary packaging layer (like all the cool language ecosystems are
building these days) seems a reasonable design. But your proposal is
interesting too.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

_______________________________________________
advisory-board mailing list
advisory-board at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/advisory-board