Draft Product Description for Fedora Workstation

Stephen Gallagher sgallagh at redhat.com
Tue Nov 5 00:09:08 UTC 2013

Hash: SHA1

On 11/04/2013 04:49 PM, Kevin Kofler wrote:
> Stephen Gallagher wrote:
>> Sure, we probably would end up reducing the number of
>> applications available in the standard yum repos. I'm not as
>> convinced as you are that this is a bad thing. Right now, there's
>> really no distinction between what constitutes the operating
>> system and what constitutes the application ecosystem.
>> Given how complex and difficult navigating our packaging process
>> is, I'd be astonished if this didn't result in a large net gain
>> for the application ecosystem. Giving users access to the
>> software they want is the goal of an operating system. It's
>> wonderful if we can accomplish this with 100% technical purity,
>> but unfortunately we live in an imperfect universe where
>> "perfect" is often the enemy of "good enough".
> But the net result for the user would be: * no more centralized
> updates – instead, either there are no automatic updates at all
> (most likely), or the software would have to poll every single
> software source for updates (slooooow),

Or we build an ecosystem similar to an "app store" (which I hate using
because I would suggest that we only offer FOSS solutions through it).
These application could then package themselves as makes sense to
them, but still be offered via a single source with a single updates

> * much more wasted disk space, due to bundling instead of
> dependency resolution,

Sure, I'll grant you that. However, this is a penalty that my
admittedly unscientific polling has shown to be acceptable in many
cases. While the advent of SSDs has reset the cash-for-gigabyte to a
decade ago, for the most part people don't really notice or care about
the few extra megabytes. That's not all people and we certainly should
strive not to be wasteful, but in my opinion there are places where we
can spend the same amount of effort to achieve a greater level of
success (where success is measured in the size of our app ecosystem
and our user base).

> * no more centralized security fixes for libraries (outside of the
> arbitrary "core set"). Thus, an overall negative.

This is the part of your argument that I agree the most with. I come
from a security background; I worked on the SSSD and I've been a
coordinator with a number of upstream projects on how to properly deal
wth CVEs and responsible disclosure. So I agree that this would be a
decrease in overall security.

That said, I think there are ways we can minimize this. For one, we
can improve tooling in order to minimize these risks. While it's
unfortunate if we can't update a single component (xulrunner, for
example) to effect fixes to multiple other packages, we probably can
start maintaining a library of known bundles, that way we at least
know the majority of things that need patching when it comes to that.

Trust me, I've thought long and hard about this, and at the end of it
I finally came to this conclusion: People are doing this anyway. Many
of the popular projects out there are just opting to bundle and
distribute everything that they need in order to bypass distribution
limitations and get their code on more systems. For most of these
projects, we're never going to fix the situation, because there's
really no incentive for them: their current approach gets them on
Fedora, Ubuntu, maybe even the *BSDs.

If people are doing it anyway, we'll achieve better results by
facilitating that and helping them better track the bundles they are
shipping, rather than trying to bludgeon them into using a specific
version we decide to ship (which may be too old or too new).

>> This just doesn't make sense at all. I highly doubt you could
>> find within 24 hours three upstream projects that made the choice
>> to license their code under a FOSS license for the sole reason
>> that it would be carried by Fedora or Debian (exempting of course
>> any project originating within Red Hat, Canonical or the other
>> distribution sponsors).
> Ask spot, he will certainly be able to name you many more than 3
> such projects.
> There were some high-profile examples of code getting relicensed
> due to distro pressure, e.g. the OpenGL-related code covered by the
> SGI Free Software License B (covered by a rewrite of the license
> thanks to the upgrade clause the original license had). Sun
> Microsystems (before being bought out by Oracle) has also
> relicensed more than one piece of software under our pressure
> (which often required a lot of nagging).

Interesting. I will ask Tom about that. I still suspect this is more
the exception than the rule (and probably limited to "software that
Red Hat had a corporate interest in"), but I won't pretend to be able
to back that assertion up.

>> Inclusion in the respository may be a goal for packages that are 
>> already FOSS, but no one decides on a FOSS license just to be
>> part of Fedora.
> I'm not even sure about that, but you also forget the many
> almost-free ones out there, who only removed the offending license
> terms due to pressure from Fedora and/or Debian.

I'm not convinced that this is a situation that would be put at risk
by this idea. If they want to be part of the platform, they'd likely
still push for this.

>> So if there was a FOSS project out there that was only available
>> at cost on an app store, I can pretty much guarantee that someone
>> else would just show up and repackage the source as the free
>> version.
> But see the previous point, the payware would NOT be FOSS, it'd be
> released under some restrictive license which does not allow you to
> redistribute it. So you wouldn't just be forced to pay, but also be
> deprived of your freedoms in the process.

And we don't have to be willing to host it. That's one of the
strengths of an "app store" ecosystem: ultimately, the publisher
decides what is acceptable. If our philosophy is "FOSS-only" (and it
should be), then that's fine. If someone decides to set up a true
for-cash app store as well and enable it to work with Fedora, they can
do that anyway (and now). It still enables more people to consume the
platform we're shipping and gives us an opportunity to convert them to
the free versions of things. I see that as a victory.

Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the devel mailing list