On Thu, Jun 14, 2007 at 08:57:08AM -0400, Greg Troxel wrote:
> LICENSE is to be set if a package doesn't have a Free or Open Source
> license.  This does not imply that src/binary can't be distributed.

Right. It doesn't do that, so I'm sorry if I wasn't clear on this.

> RESTRICTED is to be set if there are any restrictions on redistribution
> (that aren't naturally satisfied).  This is not cause to refrain from
> distributing.

It currently is. Check the restricted handling in mk/bulk/upload.

> The reality is that nearly every non-free package has its own terms, and
> therefore we could have 100 different variables for all the various
> situations.  The currrent 2 (x SRC/BIN) are IMHO a reasonable compromise
> and let the encoded restrictions be pretty close to the actual
> restriction in the great majority of cases.

One problem here is that the definitions of what it is intended for are
not spelled out. The other major problem is that some of the variables
are used for unrelated purposes (e.g. local file handling).

Having the important use cases provide a reasonable set is important, it
can be more restrictive than necessary, but should never be the reverse.

> This is wrong.  For our FTP servers, it should simply pay attention to
> NO_BIN_ON_FTP.  Fixing this bug without a 'full audit' seems fine;
> that's really no worse than uploading a bulk build without a full audit
> of every package - the typical problem I've found is that a package is
> non-free but not tagged.  Once someone has paid attention it's usually
> ok.

We are changing the status quo. I consider it inacceptable to do that
without checking what will change first.

>   The real fix is to:
>   (a) Replace all manual NO_BIN_ON_FTP and RESTRICTED definitions with
>   proper LICENSE entries.
> 
> This is wrong, or at least a change I don't favor, because it conflates
> having a non-free license with not being able to redistribute.

No, it doesn't. (a) and (b) are related, they are not supposed to stand
alone. This is about moving *every* package to use the license framework
and keep the decision of what we can do for each license in exactly one
place. I don't want to have to audit the tree to consider what I am most
likely allowed to redistribute.

> It is a bug if a package sets RESTRICTED and doesn't set LICENSE,
> because a free/open source license will by definition have no
> restrictions.

Yes, I agree. I would go a bit farther and say that we most likely want
to hake LICENSE a list and add that even for (F)OSS, but that is a less
pressing issue.

> It is a bug if any NO_*_ON_* set to other then ${RESTRICTED}.

At least no NO_SRC_ON_FTP is set without RESTRICTED, if ftp.netbsd.org
is the master site for the source.

> The problem is that licenses seem to be one each for non-free packages,
> so this seems like more work and moves the license handling away from
> the package.  Also, the whole notion of 'commercial use' is not well
> founded in copyright law - use is not one of the rights reserved to
> copyright holders.  We are refraining from that fray, and asking the
> question "has the copyright holder granted permission to redistribute
> the software in this manner", which is more straightforward.

The copyright holder can limit the redistritution. Limiting the use
based on the purpose is valid in some legislations. I'm reasonable sure
that at least some persons using the bulk build code for offering binary
packages are affected. Changing the status quo without considering the
effects is very wrong IMO.

> I would not object to adding a mk/license/foo-license.mk for a few
> non-free licenses that have redistribution restrictions and are used by
> more than 2 packages.   djbware.mk does something like this now, setting
> the existing variables.

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 have done a number of license cleanups.  In nearly all or maybe all of
> them, it was a package-specific license, and all the work was reading
> the license to understand it.  Putting the variable setting in a .mk is
> not a big deal, but the only cases I know of where that would make sense
> is djbware and SCSL.

Yes, your work is greatly appricated. Yes, it is often enough to read
the license. Often, because the license might be missing or ambigious. I
think it makes sense for most of the "Restricted for XXX use" case as
well.

> Other than docs being a bit lame and some bugs, I don't think anyone has
> put forth an argument that the current scheme is broken and needs
> replacing.  So I object to any policy changes without more discussion.

I am bringing this up because there are two policies here that need
discussion. I don't say that NO_*_ON_* is broken, just that it can be
done cleaner. Attributing the licenses with a simple tag to descripe the
use policy has the additional side effect that automated tools can more
intelligently handle it. Redistribution again is not a property of the
package as a property of the license and the environment it is used in.
This is one of the two policies.

The other question is how to handle OpenMotif in detail and packages
that set RESTRICTED, but not NO_BIN_ON_FTP. I want to be careful about
changing that as well.

Joerg