[SM-Discuss] SMGL as GNU-certified Free(R)(TM) Distro?
Seth Alan Woolley
seth at positivism.org
Fri Nov 4 23:58:12 EST 2005
On Fri, Nov 04, 2005 at 07:10:22PM -0600, Jeremy Blosser (emrys) wrote:
> 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.
They aren't essentially the same patch terms. The QPL allows you to
distribute modified binaries not in patch form while DJB doesn't even
allow you to publish modified binaries, period. So I'm not sure what
you're getting at. Any patches we applied to QPL1 stuff would be
perfectly fine (since they are separate), and we could even distribute
modified binaries. Not so with DJB.
> > > 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.
I mean support as in bugzilla and bugs dealing not with ease of use when
one is unable to comprehend the documentation, but that if there's a
problem with an interaction between their system and our underlying
system or a bug that needs to be fixed that requires a simple patch or
some communication with upstream for proper configuration/distribution.
I also mean the use of our website domain to distribute the z-rejected
> > > > (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.
ethics != religion. Why dismiss an ethical discussion that has impact
upon all our lives as a religious discussion? Religious discussions
deal with the unfalsifiable and unscientific. Most ethical discussions,
particularly those in a non-religious context that deals with actual
ramifications of actions, can be dealt with on game theoretic terms
coherently in a modern sociobiological framework without any appeal to
religious authority, which you seem to dislike.
> 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
Since you didn't actually address it, I guess we'll have to take it on
faith that it appears as an appeal to authority.
> > * * *
> > 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).
You've essentially ignored (2). Thanks.
> 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
You just did. The TLs didn't weigh in unsupport for it yet, and how do
you expect them to respond so quickly?
> but for my part I think I need to focus on other stuff right now.
That's fine with me, I just think publicly dismissing (2) without a
public reason is not productive to a public discussion.
No disrespect to anybody that disagrees with my question, I just like to
see rationale behind people's lack of agreement. I also want to
reiterate that while I find it an ethical problem, I don't consider it
an ethical transgression great enough to harm any existing relationships
over, just to make that clear. I also don't think that it's important
enough to prevent 1.0, either. I'm just bringing it up for discussion.
It wasn't even a complete proposal, more of a straw-poll and request for
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20051104/d8133b02/attachment.bin
More information about the SM-Discuss