Draft Product Description for Fedora Workstation

Stephen Gallagher sgallagh at redhat.com
Mon Nov 4 18:32:45 UTC 2013

Hash: SHA1

On 11/04/2013 12:39 PM, Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> You assume that sandboxed apps means we get all the negatives and
>> none of the benefits.  That is unwarranted.  We can adopt the
>> good parts and improve upon it based on the lessons learned from
>> adoption of app stores across multiple operating systems and
>> mobile devices that serve a much broader audience.  We should be
>> willing to let competent contributors who are interested in doing
>> that try it and provide useful feedback when necessary instead of
>> dismissing it on bad assumptions as a knee jerk reaction on our
>> experiences with proprietary software or bad conduct of 
>> particular companies.
> The reason we are so strongly opposed to app stores is that we are
> fairly convinced that the mere fact of having them available WILL: 
> * reduce the number of applications actually available in our
> repositories (because some upstreams will just upload a bundle and
> tell you to use that, and nobody will want to do the work of
> actually getting the package through Fedora review),

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

> * result in more applications adopting non-Free licenses (because
> one of the big pressure factors to adopt an acceptable license has
> always been to get into Fedora and Debian repositories – drop that
> and people will just use whatever restrictive license terms they
> can come up with),

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).

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

> * increase the number of applications that cost money (especially
> if you offer a true app store, i.e. one which allows selling apps
> in them – do you really expect that if you tell people that they
> can sell apps in your store, they will not do it?)

In other words, if people want to make a profit off of their own
personal hard work, they are not entitled to do so? I fail to see this
argument. Last I checked, every proper FOSS license permits the sale
of the software with or without support or warranty. Most of them also
permit anyone else to repackage and ship it with or without warranty
as well.

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.
Honestly, I'd be expecting many upstreams to do that anyway: package a
free version and a pay version that was essentially the "donation"
button. "You can have it for free, but if you like it and want to help
us keep working on it, please buy this one..."

> and thus, it is just not true that having the app store available
> does not affect those of us who opt against using it. It WILL have
> detrimental effects that will hurt all users.

I don't think any of your arguments lead to that conclusion at all, sorry.

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


More information about the devel mailing list