Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] prometheus done -- plus, should we sequester/reject java spells?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: seth AT swoolley.homeip.net
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] prometheus done -- plus, should we sequester/reject java spells?
  • Date: Tue, 25 Apr 2006 20:31:28 -0700

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




Archive powered by MHonArc 2.6.24.

Top of Page