It is worth noting that currently packages only get a LICENSE variable
at all if they are not licensed either under an Open Source (per OSI)
or Free (per FSF) license.  So we are talking about

  a) common non-free licenses
  b) one-off license for particular packages

"Johnny C. Lam" <jlam@NetBSD.org> writes:

> This sounds fine, if I understand correctly that widespread or very
> common licenses would still find a home in pkgsrc/licenses -- it would
> only be the one-off licenses, e.g. your fprot-workstation example, that
> would reside in the package directory.

I'd say that licenses in use by more than one package belong in
pkgsrc/licences, exactly, but probably that's a bit too strict both
ways.

A quick glance through pkgsrc/licenses reveals mostly licenses that
apply to a single program.

> I would suggest two refinements:
> 
> (1) Have LICENSE_FILE default to ${PKGDIR}/${LICENSE} so that we have
>      the same naming convention for single-package licenses as what
>      currently exists in pkgsrc/licenses.

So packages with license files stored in pkgsrc/licenses would need to
set LICENSE_FILE?

I would like to see local license files have names that would be
appropriate if in pkgsrc/licenses, so
pkgsrc/security/fprot-workstation-bin/fprot-workstation-license.  I
think this is what jlam means, but I'm not 100% sure.

> (2) In much the same way that there is mk/defaults/options.descriptions
>      file, I think we'll need a similar file that lists the various
>      licences that are used by packages in pkgsrc that may be easily
>      consulted by the user, and probably by any ACCEPTABLE_LICENSES logic
>      in bsd.pkg.mk.

I object to pkgsrc providing summaries of licenses.  The license files
exist in the first place because of non-free programs, and it is
dangerous business to abstract what purports to be a legal document
for someone - a bit too much like legal advice.  Also, different
people have different concerns - some might use a program commercially
(for which there is no widely accepted single definition) and thus not
want to accept licenses that prohibit commercial use.  Others might
object to indemnification, reciprocal patent grants, or assertions
that one is authorized to sign for the company in the case of use in a
workplace.

I expect people who want to build packages (it is arguably a bug that
LICENSE= isn't enforced on installation of binary packages) with
LICENSE= to read the license and make a decision as to whether they
will use the software.  (There is also DJB's take that one doesn't
need a license to use rather than redistribute, and people that want
to accept without reading can certainly do that.)

We used to have LICENSE=fee-based-commercial-use, but I consider that
in and of itself a bug and those are being (or perhaps have been; wiz
is very efficient) replaced by the actual license.




-- 
        Greg Troxel <gdt@ir.bbn.com>