Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

On Apr 25, seth AT swoolley.homeip.net [seth AT swoolley.homeip.net] wrote:
> On Mon, Apr 24, 2006 at 09:51:56AM -0500, Jeremy Blosser (emrys) wrote:
> > On Apr 22, seth AT swoolley.homeip.net [seth AT swoolley.homeip.net] wrote:
> > 
> > > I'm talking mostly about anything we have that's java-based.  I'm
> > > inclined just to say that java should be its own grimoire (sequestered)
> > > until we can get the spells to actually build/run in gcj or some other
> > > java compiler/runtime.  Thus they're provisionally rejected, in a way
> > > since they can't be built with our system without a rejected spell.
> > 
> > I don't really get the trend to make "sequestered" grimoires for various
> > groups of spells.  Ok, some people don't want games on their system, so
> > maybe that one makes sense (though some of the choices for what does and
> > doesn't go in games are iffy).  But if it's just a matter of large spells
> > people don't want, why don't we have separate perl/gnome/kde/etc.
> > grimoires?  The answer is probably that it's hard enough for us to track
> > and maintain already.
> > 
> > Moving java spells out because they cause a bit of a headache now feels
> > like trying to put them out of sight and out of mind, and I don't think
> > that's the way to get them fixed.
>
> If that's not the way to get them fixed, then what is the way to get 
> them fixed?  Moreover, I care little about actually fixing them -- that 
> burden is upon others.  It shouldn't be my responsibility to make them 
> free when they aren't free now.  I should have the prerogative to 
> consider them rejected until they are no longer rejectable.

The spells we started out talking about (things with a fine license which
require "some java interpreter") are not rejectable by any terms I'm aware
of this distro accepting.  They are broken without assistance from the
admin or the z-rejected grimoire, but that is not the same thing.  Just file
bugs on them as broken because they don't build with just the core
grimoire and leave it to people that care to see them work to fix them.
Put them on prometheus' list of "things we already know are broken, so
don't try building them til they are fixed" (I haven't setup prometheus
anywhere myself but I assume it has such a list).

> You missed the main point, as did others:  Philosophically, they don't
> meet our main grimoire criteria and thus belong in z-rejected.  "In some
> way theoretically free" doesn't mean free.  Are they actually free to
> users of our system?  No they are not.  Remember that porting between
> java runtimes is almost like porting between platforms in C.  It rarely
> goes as expected.  C can simply be written in a more portable way than
> java's portability constraints enforce, so we really can't assume things
> work the way Sun advertizes.

Things which have a free license themselves and don't build on our systems
don't become non-free.  Admins can take other steps, and even broken code
is useful to some people.

> I joined this distro from the beginning because we used the FSF 
> guidelines for free, not the DFSG or the OSI concepts of free.  I will 
> continue to make noise about the lack of freeness of the system if I see 
> that we're not making progress on it.  I don't see any progress with the 
> java-related spells.  At least with p4, we're making progress toward a 
> freeer system, so I have no reason to complain.  We have no volunteers 
> willing to say, "I'm working on freeing the java spells or plan to 
> once I'm done with projects X, Y, and Z."

It's of course your prerogative to make noise about what you care about,
but keep in mind that the most basic philosophy this project has agreed on
is not actually FSF-free, it's choice.  There are other FSF-free distros
out there.  It's not our license policies that set us apart, it's our
attitude toward local admins doing what they want.  I'm not aware of a
roadmap item or accepted bug that says "we aren't free enough".

Yes, we've contracted with each other to release our own things under GPL,
and to make the core system free (though again, we lack a current
definition of that), but we've also contracted with each other and with our
users to support choices to run non-free software.  Where the two things
come into direct conflict (should we keep z-rejected or throw it away, for
example), you are quite likely to find people here who will say choice
wins.  That shouldn't be a surprise.

> Moreover, as I'm QAing the grimoire, I'm not free to QA those spells.  
> You can continue to ignore a problem that doesn't directly affect you.  

Part of my household's income comes from Java application development,
actually.  And I run quite a lot of other software which uses "oh so
horrible" patch licenses.  So I do think it affects me.

> It does directly affect me.  I can't say, with honesty, that we've QAd 
> the whole thing.

You can say you've QAed all of stable and have noted the things that don't
work.  That's an enormous thing to be able to tell our users, and I think
we're heading toward a place where our QA on stable will also set us apart
from other distros, thanks to the work you and others have done.  

But you can also stop there if you want, I doubt anyone is going to mind.
You're not bound to QA z-rejected any more than you're bound to fix all the
bugs prometheus found.  If someone else wants to run prometheus on
z-rejected and/or fix bugs related to it, well, we're a volunteer group.

> I have to hedge it with "except those that aren't really free for which I
> have not accepted the license of some requirement."  I don't know if you
> guys have read the java licenses (they are not all the same), but it's
> not simply that it's unfree.  They are also immensely long.  Every
> license I agree to I keep on file, this includes EULAs.  It goes right
> next to every NDA or contract I've signed.  I'm a very legalistic person,
> but I'm also a minimalist.  The fewer terms, the fewer complications.
> That's one reason I don't download music or participate in fancy DRM
> schemes.  The GPL, while long itself, I feel I can understand and trust.
> I don't have that trust with Sun,

People all have reasons for the choices they make.  We're committed to not
telling them what to choose, as much as we can.

> and I don't think it should be bundled in the regular download, for I
> know people will interpret our Social Contract that we actually have only
> fully-free stuff.

The SC needs clarification, no argument from me.

> Grimoires are easy for us to support.  That's why we have grimoires.  
> We've had grimoires for long enough that another grimoire should be no 
> big deal.  Nobody used the argument that it's not worth our time when we 
> rejected the pine/pico/imap spells, so I can only assume that those who 
> object on that argument now simply do not agree that they violate the 
> intent of our social contract.

They were moved to an existing grimoire, not a new one that IMO lacks a
useful definition.  Your basic argument for moving them boils down to
"because they don't build".  Yes, licenses are involved, but making the
argument that accepting a QA role means you need to say more about them
than "they're broken" and leave it to the grimoire team to fix them is
weak, IMO.

> I think they do and the argument that it's possible that they are free
> doesn't work for me because that's just not how java works for most of
> them.  The only argument I can see for keeping them in the main grimoire
> is that our policy is that unit free but dependent upon a non-free item
> isn't a rejectable spell.  That's not been our sub-policy on rejectable
> spells historically, so I can't see any reason to keep them unless they
> actually are shown to work on a free java.

I don't know what our history of sub-policies on rejectable spells is, but
forcing freely licensed spells out of the main grimoire because they don't
currently build (regardless of reason) is not something I'm ever going to
personally agree to.

I *might* be willing to go along with filing a bug that we don't have a
free way to make them work and forcing them down to devel with a WIP to
that bug until it's resolved, because that's consistent with how we treat
other broken spells.  But that's because I'll accept them as currently
"broken".  Others will no doubt not go that far.  And you might claim
that's pretty similar to the suggestion to put them in their own grimoire,
but you'll note my original response was rather in the vein of "why, and
what are we defining this as", so an approach that clarifies those things
and stays more inside our existing structure works better for me.
Regardless, I think we'd need a clear definition of terms that makes them
"broken" to even start to go there, though.

> At least, if we have a different sub-policy, we should reference the 
> language from the Social Contract to a sub-page that lists the 
> extra-social-contract policies / administrative rules on licensing.

Attachment: pgpQY8fWjztrU.pgp
Description: PGP signature