In article <20070614071042.GA4876@britannica.bec.de> Joerg wrote:
: On Thu, Jun 14, 2007 at 08:44:08AM +0200, Dieter Baron wrote:
: >   What exactly is the problem here?  Are you saying we do not provide
: > binary packages for any package with LICENSE set?  If so, I consider
: > that a serious bug.

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

  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.

: Many of those are non-commerical-only.

  That is the user's concern, and does not preclude us from
distributing binary packages via ftp.

: I would argue that we violate the
: tdir-license by not distributing the CHANGELOG.

  We should inlcude it in the binary package, then.

: >   We have a variable that says wether we can distribute binary
: > packages: NO_BIN_ON_FTP.  That is only set for Openmotiv on non-OSS
: > platforms.

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

  I consider this to be a serious bug, as noted before.  But I agree
that simply fixing it without checking which packages rely on the
broken behaviour is even worse.  It is, however, the goal we are
trying to reach.

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

: I think this is not an extreme amount of work, but still quite a bit.
: The time before the branch might not be enough, so I've suggested the
: secure alternative.

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

					yours,
					dillo