In article <20070614092444.GA28774@britannica.bec.de> Joerg wrote:
: On Thu, Jun 14, 2007 at 11:12:10AM +0200, Dieter Baron wrote:
: > : The real fix is to:
: > : (a) Replace all manual NO_BIN_ON_FTP and RESTRICTED definitions with
: > : proper LICENSE entries.
: > : (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.
: > 
: >   We differentiate between distributing via ftp and on CDs we sell for
: > a reason.  We should keep this distinction.
: > 
: >   Also, while setting the restrictions centrally per license is
: > conceptually cleaner, it only pays off if we have enough restrictive
: > licenses that are used by multiple packages each.

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

  Yes, that is good.

: I know why we differentiate between FTP and CD, but my point is that the
: current choices are very arbitrary and under-documented.

: Consider for example the CDs we hand out during LinuxTag and other
: events. That's a CD, but non-commercial.

  I agree that the names are suboptimal, and that documentation lacks.
Switching to the new licensing framework is a good opportunity to fix
that.

  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.

  Do you see any other uses we need to differentiate?

  What do you think of the variable names CAN_DISTRIBUTE_SRC,
CAN_DISTRIBUTE_PKG, CAN_SELL_SRC, CAN_SELL_PKG?

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

  I don't quite understand what you mean here.

  First, what exactly are non-commercial packages?  Packages allowed
for non-commercial use only?  Restrictions on use should play no role
in what we upload to nbftp, nor what we put on (official) CDs.  That
is the user's concern, and he has to accept the license before
installing.  (And if pkg_add still does not enforce this, that should
be fixed.)


: >   Sounds reasonable.  Do we have an estimate on how many packages work
: > with openmotif but not with lesstif?

: I have no idea.

  Then I veto the switch to lesstif.  I don't want to ship non-working
binary packages, and that might well be the result.