Subject: Re: Motif default
To: Greg Troxel <gdt@ir.bbn.com>
From: Dieter Baron <dillo@danbala.tuwien.ac.at>
List: tech-pkg
Date: 06/14/2007 15:23:46
In article <rmizm32ofrv.fsf@fnord.ir.bbn.com> Greg wrote:
: (Despite replying to your first message, I did read the rest first.)
: 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.
It could lead to TNF distributing programs it is not allowed to
distribute, which could lead to legal problems. It is very unlikely
that someone will sue without warning us first, and we will remove the
package (and tag it correctly) if warned, but it's still a
possibility.
Since you are most familiar with the plethora of licenses in pkgsrc,
would you be willing to go over the packages that set RESTRICTED but
not NO_BIN_ON_FTP and check that they are correctly tagged? After
that, we could savely fix the upload script.
: 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.
While I generally agree, there are corner cases. What do you think
about VICE? The program is GPL, but it includes ROM images from the
Commodore 64, which have questionable copyright status. Currently, it
has:
RESTRICTED= ROM image copyright is questionable.
but no license set.
: (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.
: 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.
This sounds like a reasonable compromise. Single package licenses
are usually named after the package they cover, so finding the setting
in the corresponding Makefile should not be hard.
: 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.
: 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.
Indeed.
yours,
dillo