Re: YAL (Yet another license)

[Paul Serice <ugs@laci.net>]

Mark Rafn wrote:
> On Fri, 7 May 1999, Paul Serice wrote:
> > Not too long ago, we had a discussion about the Crafty developer
> > forcing the name.  I'm wondering if you think it would be o.k. for him
> > to force the name of only the executable.  It would "just require[] a
> > particular name for one file, not the package" (to quote you out of
> > context :-).
> 
> This kind of question might be looked at in terms of DSFG #9.  Imagine I
> wrote a package that ALSO contained a similar provision (I require the
> executable must be named "notcrafty").  It's clear that the licenses are
> not compatible for the case where someone wants to combine code from the
> two programs.  The same is true for two programs that require the same
> filename for their license.  How do you include both licenses in your
> combination-product?


That's interesting.  I see what you're talking about, and it would
make collaboration among projects almost impossible.

I find your argument persuasive.  It seems I was trying to guarantee
that credit go to the correct persons by restricting the namespace.  It
didn't see any harm it could cause until you pointed it out.  Thanks.

However, it's not obvious that DSFG #9 protects against this.  It looks
to me like the gist of DSFG #9 is that a package cannot dictate which
other packages are distributed with it: "The license must not place
restrictions on other software that is distributed along with the
licensed software."

For example, if the terms of the Crafty license were such that the names
of derived executables had to somehow acknowledge their Crafty heritage,
this would still be a namespace restriction, but the restriction is
hardly an attempt by the Crafty author to say, "No Crafty clone can be
distributed with crafty."

Again, to me, it seems that reading DSFG #9 to protect against all or
most namespace restrictions would be to read too much into DSFG #9.  To
me, DSFG #4 is the paragraph on point, and it does allow for some
restrictions to be placed on the namespace.


Paul Serice