[Fedora-infrastructure-list] Re: Fedora's FLOSS principles (was: coverity code checker in Extras)

[Axel Thimm]

On Wed, Aug 30, 2006 at 03:05:47PM -0500, Josh Boyer wrote:
> On Wed, 2006-08-30 at 21:57 +0200, Axel Thimm wrote:
> > On Wed, Aug 30, 2006 at 01:29:36PM -0400, Max Spevack wrote:
> > > + It's not open source, but there is no free alternative that can do the 
> > > same thing.
> > 
> > I don't want to spoil anything and I'm not the activest FLOSS
> > agitators, but I see a conflict of goals and tools.
> > 
> > The kernel-uses-bitkeeper-technology created more noise than it served
> > good and bitkeeper was closer to open source than coverity while Linus
> > was less pondering on FLOSS principles than the Fedora goals do, so
> > projecting that to the future I see endless threads about the
> > pure-FLOSS Linux using non-FLOSS tools.
> > 
> > There is an argument often brought up in these situations which goes
> > like "since no FLOSS alternative exists, we need to use that". But the
> > same is true about ipw* firmwares/closed source daemons, closed source
> > 3D graphics and so on. There is even discussion of not allowing
> > external kernel modules, even fully FLOSSed ones, in Fedora to
> > demonstrate Fedora's embracement and loyality to FLOSS.
> 
> Not quite.  Yes, Fedora's mantra is upstream in regards to kernel
> modules simply because it benefits everyone in the long run.   But the
> current issue stems from maintenance in the long run and resource issues
> for the Core kernel devs.  Please don't confuse that with FLOSS
> zealotry.
> 
> > 
> > If we want to open the backdoor to non-FLOSS bits we will be blamed on
> > being selective and non-open ourselves serving only our needs at hand.
> > 
> > Don't get me wrong, as I said I'm no FLOSS die-hard agitator, and I
> > would personally welcome a code checker. But it does conflict with
> > Fedora's manifesto and will create a flood of noise and bad marketing.
> 
> There are two major items you're ignoring.
> 
> 1) Coverity is not required by any means.  Your bitkeeper analogy is
> flawed because it was the _only_ SCM tool being used for the kernel.  It
> was essentially a gate.

That's debatable. From a user's POV the SCM used is not seen. And
precicely because of the reasons you outline and the FLOSS ideology of
several kernel developers there were gateways to other SCMs as well as
simple diff&patch submissions.

> 2) Fedora isn't shipping coverity.  It doesn't taint the distribution in
> any way.

That doesn't matter, the kernel tarballs didn't contain bitkeeper,
too. The cause does not justify the means.

Furthermore the fact that you mentioned in other posts to this thread,
that FC uses beehive which is closed source, has its truth and shame,
but whenever this was (seldomly) addressed in the past people kept
saying that they would iron it out and open-source it. Meanwhile there
emerged better open source technologies on the market, so the demand
and motivation to do so is low. But I'm sure that in principle RH
would go through the effort to open-source it if it was worth while,
just as they did with much larger formerly closed source projects like
gfs and ds.

Anyway to cut a long story short it boilds down to a matter of
principles. Ask yourself *why* Fedora has a certain FLOSS ideology
that disallows for example packaging and shipping of non-FLOSS
software and the answer will be applying to why Fedora should not be
using/supporting non-FLOSS in any other way. See also the discussion
of using non-open media formats on redhat.com. It all spins around a
chosen core ideology.

Again: Don't mistake me for a FLOSS zealot, I'm just seeing these
issues coming up. As I see it it will either lead to confirming the
strict endorsement of FLOSS ideology and officially refuse any
non-FLOSS contributions or it will lead to a softening of Fedora's
definition of FLOSS goals to allow for using non-FLOSS technology.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20060831/be77154a/attachment.bin