On Fri, Jun 15, 2007 at 09:53:12AM -0400, Greg Troxel wrote:
> 
> The point I was trying to make is that while code presently refrains,
> but the variable being set is not good cause to refrain, according to
> our documented semantics for the variables.

Given the number of disagreements in behaviour, I tend to prefer the
code as authoritive. So in that sense, changing it is a change of
policy, whether or not it was intended is a different question.
Normal users don't care about NO_*_ON_*, just the upload code and
therefore bulk builders do. Changing the effect therefore changes the
policy for the only group that really cares.

> > The other major problem is that some of the variables
> > are used for unrelated purposes (e.g. local file handling).
> 
> If you mean the no-distfile-when-netbsd-is-master, that should be
> changed to be its own variable.  Other people running FTP mirrors of
> pkgsrc stuff should carry the distfile in that case.

Agreed.

> > My point is that the redistribution is an attribute of the license, not
> > the package. So it should go with the license and not the package.
> 
> I agree conceptually; the question is about managing it.  If you want to
> put the license fragment in the package's directory, then it merely
> seems like file proliferation.
> 
> Or do you intend to put the NO_*_ON_* tags in the foo-license file in
> licenses and extract them programmatically?  It would help to see a
> full, concrete proposal for what you would like to see.

Either way is fine with me. Attributing the license files directly has
the advantage of less files, using a makefile fragment on the other hand
makes it easier to use. I haven't written a full proposal because I
didn't want to do it myself :-)

> Are you aware any non-free licenses beyond djbware and SCSL where the
> *exact same* license is used by more than a few closely related packages?

Does the classic BSD license with advertisement clause count? :-) I
don't know.

> I don't think we should get in the business of encoding use.  That's
> outside of copyright law at least in the US.  The points of the current
> scheme (not where variables are, but the semantics) are

Be careful when arguing based on US law, as many (all?) bulk builders
live in the old world.

> 1) to leave the evaluation of the suitability of a non-free license with
>    the user, where it must fundamentally rest since you, I and TNF
>    aren't offering legal advice.  (The suitability of free licenses of
>    course also rests with the user.)

This is fine as long as (2) is kept. Encoding use is important for (2)
though.

> 2) to encode what kinds of distribution are permitted by the license so
>    that the project and mirrors can refrain from distributing packages
>    for which a copyright license to distribute has not been granted.

I do care about the following three cases:
- distributing binary packages on a FTP server
- handing out install/package/live CDs on fairs
- handing out such CDs for a fee
All such cases are fundamental for advocacy, so we should make it
reasonable simple to do that. It might actually include asking a lawyer
for legal advise in specific critical cases (consider mplayer).

Joerg