[SciPy-dev] Scikits and stuff

[Nathan Bell]

On Dec 28, 2007 3:56 AM, Travis E. Oliphant <oliphant at enthought.com> wrote:
> do you want it to have.    I see great value in a clear separation
> between GPL-inspired licenses and other licenses.

So does Richard M. Stallman :)

Most users don't care about OSS politics.

> If these are all awash in the scikits namespace, then it is going to be
> more difficult for people who would like to be able to use scikits
> packages but cannot use the GPL to know what they can and can't use.

And therefore a majority of users should be inconvenienced for a small minority?

> It is the 'mind share' I'm interested in as well.  Right now it is
> pretty clear that scipy is BSD (or similarly) licensed.   It would be
> productive if that same kind of advertising were available for scikits.

To some, not many.

> All I'm saying that the distinction between the licenses that impose
> restrictions on what you do with your own code that depends on them and
> licenses that don't do that is important enough to warrant a name-space
> division.

This simply isn't true.  I don't use 'gapt-get' or 'gsourceforge'.
I'd be a bit irritated if I had to fire up gapt-get for X but had to
use apt-get for Y.   Not to mention the potential problem of
collisions (scikits.foo and gscikits.foo).


> > Furthermore, does anyone want to
> > police this sort of policy should 100s of scikits be developed?
> >
> It is much easier to "police" if all you have to do is change the name
> of the package it gets installed in.

So you are going to audit the contents of scikits periodically?  Even
if scikits has hundreds/thousands of packages and contributors?


> Sure, but that same person is more likely not going to touch *any* of
> scikits if there is GPL code released in it's name-space (even if they
> are "separate" packages and especially if they are actually hosted on
> the same svn tree).  It gets too murky for people who need to care to
> spend the time figuring it out --- they'll just go buy the off-the-shelf
> solution even if it isn't as good in some technical sense.

Who are these people?  I can't imagine a business taking 'our word'
for it and blindly using a scikit in their product.  The first time
GPL code slips into a scikit the distinction will become meaningless
and untrustworthy.

The problem I have with 'gscikits' is that if the scikit idea actually
takes off then it will require an army of people to keep scikits free
of encumbered code.  We cannot trust casual contributors to do their
homework and keep GPL out of their scikits.  The distinction is only
as good as the certifier.

-- 
Nathan Bell wnbell at gmail.com