Joerg Sonnenberger <joerg@britannica.bec.de> writes:

>> 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 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.

>> 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.

This is easy; we can edit the guide.  The basic notion is that "FTP"
means "available over the Internet at no charge" and "CDROM" means "on
media as part of a collection of mostly open source software at a
reasonable copying fee".

> 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.

>> 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.

You can certainly refrain from making the change, but I think we aren't
having a policy change, just fixing a bug.

>> 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.

That's still a bug in my view; this use is not about licensing and
ability to redistribute and it's confusing and unhelpful to merge them.
It's easy enough to add NETBSD_DISTFILE_MASTER, or perhaps easier to
accept the duplication.

>> 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.

Again, we are not changing policy - the policy has been in place for a
long time.  The uploads are simply using the wrong variable.

>> 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 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.

>> 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.

If the license is missing, it's very easy: just set all 4 NO_*_ON_*.
But my point is that in nearly every case, the "license" is inseparable
from the package.  And if the license isn't contained within or
referenced in the package, then I think the package has to have all 4 be
NO.  It's not like there are 30 non-free licenses in common use.

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?

>> 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.

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

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.)

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.

These are really almost orthogonal concerns, and in my view naturally
lead to the LICENSE and NO_*_ON_* schemes we have.  I agree that one
could record NO_*_ON_* once per license, but not that it would be
helpful in practice.

> 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.

For OpenMotif builds for free systems, I don't see any reason not to
distribute binary packages.

How many packages set RESTRICTED but not NO_BIN_ON_FTP?  Of those, how
many set both CDROM variables but neither FTP variable?