Public SourceMage Discussion List

[seth AT swoolley.homeip.net]

On Tue, Apr 25, 2006 at 05:06:39PM -0500, Jeremy Blosser (emrys) wrote:
> 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).

It has a list such as this and I'm fine with this proposal.  That we 
have a policy that it is a bug is enough for me to continue my work.

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

They don't actually conflict there.  The SC can be interpreted 
consistently if you assume that by main code and support non-free, they 
mean "we give high priority (main support) to free code, but low 
priority (support with resources) to rejected".

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

^Wsome

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

thanks.

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

It would be nice if we clarified this.

> 
> > 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'm supposed to push for moving broken spells to working spells.  So 
yes, I can file a bug to get it working, but failing its working, we 
usually keep the "working" version in stable.  I guess I'm unlucky that 
we never had a working version to keep in stable.  By the way, perhaps 
the policy for broken spells in stable that are unavoidable should be 
similar to this policy.

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

Typically free but dependent on non-free was put into z-rejected.  free 
but for now dependent on non-free (until it can be fixed) was a grey 
area.

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

We should leave them in stable since that's how we treat regressed 
spells that we can't have a version fixed in stable for now, to be 
consistent.

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

Thanks for the response, I think I'm satisfied with your responses and 
what to do, but I still would like an official sub-policy on the details 
like this worked out.  I propose, following this conversation:

free but dependent on non-free but not feasably freeable -> z-rejected
free but dependent on non-free but feasably freeable -> main w/bug
feasable being up to the grimoire lead.

Seth