Subject: Re: Motif default
To: None <tech-pkg@netbsd.org>
From: Greg Troxel <gdt@ir.bbn.com>
List: tech-pkg
Date: 06/14/2007 08:57:08
(Despite replying to your first message, I did read the rest first.)


  a while ago OpenMotif was changed to include the license as it is
  strictly partial OSS. The permission for use are only granted on Open
  Source platforms.

I think you are referring to my commit of 2006/05/14, revision 1.46 of
pkgsrc/x11/openmotif.  I believe that this change was fixing a bug as
the openmotif package never previously had an open-source license.

  Due to the way the license framework currently works, this means that
  we can't provide binary packages for any program depending on
  OpenMotif. This includes e.g. Xpdf and others.

This isn't how it is supposed to work.  I have tried to fix up the
guide, but I agree that it's still underdocumented.

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.

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.

NO_{SRC,BIN}_ON_{FTP,CDROM} are to encode that one can't

FTP: redistribute at no charge over the Internet

CDROM: redistribute, together with other programs, at a reasonable
       distribution fee, usually on CD/DVD


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.

  Both the old bulk build code, the Python based prototype and pbulk don't
  upload a package if either restricted or no_bin_on_ftp is set. This is
  might be more restrictive than necessary, but I wouldn't want to change
  this without a full license audit.

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.

  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.

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.

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

  (b) Add a small make fragment for each license. This fragment should
  decide whether CAN_DISTRIBUTE_SRC and CAN_DISTRIBUTE_PKG should be set,
  depending on the platform, the license, a "commerical-use" variable and
  a manual list of allowed licenses.

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.

It would be perfectly reasonable to add a RESTRICTED_EXCEPT_PLATFORM
variables that sets RESTRICTED unless platform matches.  Then the
openmotif Makefile could be simplified.

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.

  Consider for example the CDs we hand out during LinuxTag and other
  events. That's a CD, but non-commercial. So what I do want to get is
  that the bulk builder can make a broad decision like
  "default ftp.netbsd.org" set w/o non-commercial packages, but also
  include packages if he is using them internally.

Really one can safely (assuming no bugs) include any package without
NO_BIN_ON_CDROM.  And one can also include packages that permit copies
on free CDs but not pay CDs.

Please don't use the word 'non-commercial', as it assumes that there is
some crisp category of software licensing - but this crispness doesn't
really exist.  And even if it did, it's the wrong test for including on
a CD-ROM - if the copyright holder has granted permission, it's
legal, and if they haven't, it's not (in Berne Convention countries,
IANAL, TINLA).

So if we want to make and hand out CDs, we could 

a) add a third variable NO_BIN_ON_FREECDROM, or perhaps
OK_BIN_ON_FREECDROM, defaulting to NO if NO_BIN_ON_CDROM is set, so that
packages whose licenses prohibit for-pay CDROM inclusion but allow free
CDROM distribution can be encoded

b) decide that NO_BIN_ON_FTP should be set if free distribution,
regardless of media, is prohibited.  I argue against this - we really
want the broadest collection of pakages possible up for FTP.

  It is not so much about reducing the amount of work necessary to deal
  with a license. I want to centralise the decision making, so that to add
  a "redistribution profile" only one place has to be evaluted.

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.


  Not consistently. Some of those packages set RESTRICTED, others set
  NO_BIN_ON_FTP. I wouldn't be surprised if some don't do either.
  Examples are:
  textproc/cdif
  sysutils/tdir
  sysutils/sysinfo
  sysutils/su2
  sysutils/fs-kit
  security/srp_client
  security/rsaref
  security/msf
  security/hydra

  Many of those are non-commerical-only. I would argue that we violate the
  tdir-license by not distributing the CHANGELOG.

I had thought that I had purged all the "no-commercial-use" license
tags.  It's a bug in each package that sets no-commercial-use, and that
needs to be fixed, but it's not a structural problem.

The msf license doesn't grant permission to redistribute, so that
package needs all four NO_*_ON_* set.  (just fixed).


  From: Dieter Baron <dillo@danbala.tuwien.ac.at>

  IIUC, RESTRICTED is used to set NO_{BIN,SRC}_ON_{FTP,CD}, and should
  not be used otherwise.  Especailly, it does not imply a certain kind
  of restriction.

I agree.  Anything that tests RESTRICTED (other than pkglint) is broken.

   What I see need for is:

   - We can distribute it for free, via ftp or on CDs we give away.
   - We can distribute it for a fee, like selling CDs.

It's not clear how many packages will have licenses that allow free ftp
but not free CD.  The key question is choosing the granularity.


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.