-----BEGIN PGP SIGNED MESSAGE----- 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 stream. > * 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ4NyQACgkQeiVVYja6o6NVTwCfXcizchLq5Nv11fE4tDvuz71W BowAoIoqFb4L7iaBiMKepdcIW9ocKLrD =EJ9F -----END PGP SIGNATURE----- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
