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
