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: "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.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 19:10:22 -0600

On Nov 04, Seth Alan Woolley [seth AT positivism.org] wrote:
> On Fri, Nov 04, 2005 at 04:46:34PM -0600, Jeremy Blosser (emrys) wrote:
> > 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.

Whether or not it needs patches to be "usable" is rather a matter of
opinion, and of course the author's own opinion is going to be the deciding
one in whether or not the patch is added upstream. The relevant part to a
license discussion is whether upstream attempts to disallow creating or
distributing those patches. DJB and UW both don't restrict patch
distribution, and there's no practical limit to what we can with their
stuff if we want.

Even more relevant to this conversation though is the fact that QPL 1 has
functionally the *same patch terms* as DJB or UW, yet it is on the FSF
"Free-but-not-GPL" list. So using their list you'd get to support
patch-only QPL 1 code, but not patch-only UW or DJB code.

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

I didn't see a response to this, and I think the definition of "support" is
pretty critical to what you're proposing.

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

I left the rest out because anything I said to that would just be a
religious argument about licensing, and I'm trying to avoid going there in
this thread and focus instead on the primary stuff you're asking to change,
as best as I can grok it. That's rather difficult when this is a thread
about licensing, but I would prefer to keep my responses centered on "why
should I support this change". I'm rather familiar with the suggested
religious reasons and don't accept them, but I'm willing to hear out the
other ones. I responded to the part I did respond to because it rather did
read like an appeal to authority to me, even in the full context, and
that's an independent reason that I also reject. Sorry if I mistook your
meaning.

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

I might go along with (1) if you come up with a specific formulation of a
proposal, depending on the exact definitions of "free" and "support" used.
I've said all I have to say about (2).

In any case, given the lack of support from TLs this proposal appears to be
getting I'd probably suggest we just drop it for now and get back to trying
to get a website running again and a 1.0 out. I'm not trying to belittle
something you obviously think is important but for my part I think I need
to focus on other stuff right now.

Attachment: pgpYt8QAX50fC.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page