Subject: Re: x11/openmotify license terms
To: Greg Troxel <gdt@ir.bbn.com>
From: Dieter Baron <dillo@danbala.tuwien.ac.at>
List: tech-pkg
Date: 05/16/2006 09:45:47
In article <rmi3bfa93rx.fsf@fnord.ir.bbn.com> Greg wrote:
: >   BTW: I don't think it makes sense to set NO_SRC_ON_FTP for non open
: > source operating system and not set it on open source operating
: > systems: Either we are allowed to redistribute the sources, or we are
: > not.

: Well....  the license says that the source can be distributed on or
: for open source OSes, so there's this murky bit about intent lurking
: there.  Trying to be respectful to the Open Group and follow their
: wishes (even if not enforceable), I let NO_SRC_ON_FTP be unset on
: NetBSD, etc., and set on Interix/IRIX/etc.  So this means if one ran
: an FTP site on Interix and had a distfile mirror it would be missing.
: I think this would be viewed by the Open Group as the right call.
: Of course, TNF isn't applying force to make anyone do this; the
: Interix-based FTP site gets to locally edit and choose themselves.

  The primary purpose of NO_SRC_ON_FTP is to determine if the dist
file should be placed in ftp.netbsd.org's distfiles directory and thus
also on its mirrors.  Some of those mirrors run non open-source
operating systems.  Thus, if we are not allowed to place the dist file
on ftp servers running on non open-source operating systems, we must
set NO_SRC_ON_FTP unconditionally, otherwise we screw the maintainers
of such mirrors.  (It is unreasonable to expect them to selectively
exclude files while mirroring.)

: >   As for ONLY_FOR_PLATFORM: Currently, the pkgsrc guide is rather
: > vague in which situation it should be used.

: I think that's a bug and that license things should be called out as
: inappropriate because mixing license and technical  is unclean.

  Perhaps, and cleanliness is a worthy goal, but so is simplicity:
Don't add complexity that doesn't solve a real problem.

  So if the new feature is going to be used only for OpenMotif, I
don't think it's worthwhile.  If, however, more packages are affected,
I agree that a cleaner solution should be found.

: > However, if the main concern here is that a bulk builder setting
: > _ACCEPTABLE violates the license simply by building the package, a
: > better solution might be to flag a license as needing explicit
: > acceptance.  If OpenMotif is the only such package, and there is no
: > way for a user to obtain a license permitting building/using the
: > package, setting ONLY_FOR_PLATFORM is probably okay.

: I still think ONLY_FOR_PLATFORM is not right.  Setting _ACCEPTABLE is
: saying "I don't care about licenses; I want to do this anyway."

  _ACCEPTABLE is a hack to allow official bulk builds to include
non-free packages we are allowed to redistribute in binary form.  As
such, it should enable building everything we are allowed to build,
but not put the bulk builder at risk of license violation.

:  In
: the general case that's a bit much.  Doing a bulk build and respecting
: NO_BIN_ON_FTP means that any infringement claim is limited to "you
: downloaded this file from our web site (and we let you) and then built
: it and threw away the result, in order to test if it worked, and we
: claim that's improper".  IANAL, but that's a pretty tough case to make
: for infringement.

  What about packages that don't have NO_BIN_ON_FTP set but have a
dependency that has NO_BIN_ON_FTP set?  Are they currently uploaded?

  If so, part of the result of building the restricted dependency
might be included in the unrestricted package (e. g. when linking
against a shared library) and the case is less clear by far.

: It may be that we want a new variable for bulk builds which is like
: _ACCEPTABLE but only allows packages that don't set NO_BIN_ON_FTP.
: But then we don't get failure reports for those, and I'm unaware of
: any copyright holder being cranky about that while not being cranky
: about their bits being supported by pkgsrc.

  I think a flag on certain licenses that says ``you are not allowed
to even download and build this'' better meets our concerns.  Then
packages with these licenses are only built if the license is
explicitly listed in ACCEPTABLE_LICENSES, not if only _ACCEPTABLE is
set.

					yours,
					dillo