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: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] prometheus done -- plus, should we sequester/reject java spells?
  • Date: Wed, 26 Apr 2006 10:21:13 +0200

On Tue, Apr 25, 2006 at 08:31:28PM -0700, seth AT swoolley.homeip.net wrote:
> 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 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.

As Jeremy wrote in his other reply, it can be interpreted both ways.
What I always assumed that part of the SC means that we'll never require
anything from z-rejected for the iso or for any of our own distro tools.

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

There are a couple different ways a spell can be "broken".
If a spell doesn't build and the upstream is dead, we remove it. That
has always been the policy, though we probably should get some
definition of "upstream is dead" in there.

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

We can't remove them from stable as people (who use z-rejected) have
them installed, removing them would break systems. So they should stay
in the grimoire.

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

That sounds good to me. Feasable in that regard is something that needs
to be evaluated for every spell (or group of spells) imo.
E.g. nvidia-settings requires nvidia_driver, I think it's reasonable to
say that it's not feasable that this will get Free anytime soon.
For java spells, there's the big classpath effort working on a fully
free java environment. So overall freeing java spells is feasable, even
if it will take a lot of time and effort to do it for some of them.

--
Arwed v. Merkatz Source Mage GNU/Linux developer
http://www.sourcemage.org




Archive powered by MHonArc 2.6.24.

Top of Page