Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] SMGL as GNU-certified Free(R)(TM) Distro?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] SMGL as GNU-certified Free(R)(TM) Distro?
  • Date: Fri, 4 Nov 2005 16:41:46 -0800

On Fri, Nov 04, 2005 at 04:46:34PM -0600, Jeremy Blosser (emrys) wrote:
> On Nov 04, Seth Alan Woolley [seth AT positivism.org] wrote:
> > The list isn't as important as the benefits of actually being free.
> > Being surrounded by vendors who want to create lock-in at work, I don't
> > want to participate in it in a non-paid environment. I can't even come
> > close to assuring quality, not so much in a "I'm sure of this", but if
> > something comes up, I can't fix it myself. I don't have any money for
> > it, so I can't _pay_ a vendor to fix their product to work with
> > sourcemage (which is the normal way to fix a problem in a piece of
> > proprietary software you don't actually have access to). We're
> > officially supporting non-free packages according to the social
> > contract, so I don't have deniability if a problem in non-free software
> > crops up from a QA perspective.
> >
> > If we're not supporting non-free packages, I want it explicit. If we
> > are, I want it explicit as to how much. Right now, we support it so
> > long as it's not a dependency of the core (which has been argued that it
> > has been through perforce). If I can build a support matrix for
> > packages that doesn't include any non-free packages, I'd feel better,
> > ...
>
> You might do better in getting people to agree with you if you would make a
> more formal, less ambiguous proposal. You started out with "let's do these
> things so we can get added to their list", when what it really sounds like
> the bottom line is, you don't want the QA team to be expected to support
> software that isn't Free. Those are not remotely the same thing, and you'd
> probably get a lot more support for the latter than the former.

I actually want both proposals, which is why the initial proposal
includes both. The distinction I provided above was a way to add more
grain to the intermediary positions one could hold.

>
> If we wanted to address this, things we would need to answer include, at a
> minimum:
>
> 1. What does Free mean in this context? Yes, we use the FSF definitions
> for what we'll include in the main grimoires, but the question of what we
> will just distribute and "support" arguably warrants looser definitions.
> The FSF's license comparison doc is not the most objective and consistent
> thing, and if all we want to say WRT QA is "we won't support software we
> don't have the source for", we could still include other licenses.

Can't support DJB code either because I might need to patch it (and
historically it has needed patches to get it to any level of usability
since he hates having to admit his code needs a patch).

Ultimately, if it's not GPL or FSF-compatible (in that we can patch and
aggregate (since aggregation doesn't invoke the GPL) a
FSF-free-compatible but non-GPL program and still be compliant with the
social contract), I'd rather not have to support it, either.

> The UW
> license, for example, doesn't prevent us from viewing pine's source and
> patching it, but it's not considered Free by the FSF.

And I don't want to support something like it that has a whole bunch of
patching limitations. When you take control of the source as much as
they do, they are taking responsibility for their own QA by fiat.

>
> 2. What does "support" mean anyway, especially from the QA perspective
> you're making the argument from? We don't really provide upstream support
> in any official capacity for any packages, GPL or otherwise. We create
> packages that install on systems in as close to an upstream default
> configuration as possible. Sure, we get asked user questions like "how do
> I get xorg/procmail/nvidia's binary drivers working", but once the spells
> are installed I think anyone answering those is doing it on their own time
> and not because the distro is obligated to the user in that regard.
>
> > (The following is a separate and higher level argument from the one
> > above.)
> >
> > ...but I also don't want GNUdists to be able to say I'm supporting
> > non-free software by association with a group. The easy way around this
> > is to not associate the non-free to our group.
>
> The easier way is to determine we're going to do what makes the most sense
> for us and our users and not care about what some other group thinks.

Instead of attacking the part where I refer to another group, you could
refer to the reasons I agreed with the group's logic that you snipped
out. ;) The reference to the group wasn't an appeal to authority, it was
an explanation of which group I would most align with, where I have my
own independent thoughts that line up but aren't the level of doctrine
quite yet. I don't appreciate having my comments ignored because you
can associate them to a group. That would mean I could destroy any
argument of yours by referring to another group that thinks like you do,
which is obviously absurd.

* * *

Ultimately you seem to be most strenuously objecting to the use of the
FSF as a way of defining free. If you would like to make another
definition, that's fine with me, so long as it fits a reasonable
approximation of what I would desire to support (as in continuing
freedom). Perhaps the FSF could then be made to agree that our
definition of free happens to intersect with theirs (or be a subset), in
which case they could call us free. As long as we're actually free, I
don't mind the GNUdistic list/website certification, just as I don't
mind OSI certification. It's just a practical matter for me on the two
things I mentioned: 1) QA support, 2) furthering the freedom of software
by not "promoting" with the group's resources any non-free software.

Seth

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454 E082 99F0 69DC FDCE E733

Attachment: pgpCRMDMCw2BQ.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page