Date: Tue, 11 Mar 2014 13:27:51 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: Eitan Adler <eadler@freebsd.org> Cc: Mathieu Arnold <mat@freebsd.org>, svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, Emanuel Haupt <ehaupt@freebsd.org>, ports-committers@freebsd.org Subject: Re: svn commit: r345472 - in head/mail: mmr smtpfeed Message-ID: <20140311132751.GA89701@FreeBSD.org> In-Reply-To: <CAF6rxgnimGJV282MKf%2ByuGjoWF-j40e%2BV5Xye5Fv3MB%2BSq-_bA@mail.gmail.com> References: <201402211451.s1LEpO30005480@svn.freebsd.org> <20140310141642.GA92282@FreeBSD.org> <724E420543C93474E8AD21FA@ogg.in.absolight.net> <CAF6rxg=CnfZPHuxY8A3tz94ZntnWdv9wKbxBzCU2aJCAFDjTQA@mail.gmail.com> <20140311063746.GA40426@FreeBSD.org> <CAF6rxgnimGJV282MKf%2ByuGjoWF-j40e%2BV5Xye5Fv3MB%2BSq-_bA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 11, 2014 at 08:28:33AM -0400, Eitan Adler wrote: > On 11 March 2014 02:37, Alexey Dokuchaev <danfe@freebsd.org> wrote: > > On Mon, Mar 10, 2014 at 07:43:09PM -0400, Eitan Adler wrote: > >> LICENSE= is largely useless for actual lawyers, > > > > Can you elaborate on this a bit, for those of us who didn't get their > > feet wet in the legal pool? > > I am not a laywer and don't give legal advice. However, LEGAL can not > be trusted as a source of licensing information. Right, but LEGAL is another beast, and only loosely related to LICENSE framework (most of the ports do not get an entry there at all). By saying "legal pool" I was not referring to our LEGAL file. > For example, BSD style licensees require attribution but who to > attribute is not listed. Yes, this constitutes the first important question: do we need (and if we do, how) to properly reflect copyright (authorship) and distribution terms (license), and relationship thereof. There are several opinions that were raised before, from "drop LICENSE_FILE for anything well-known like BSD, GPLvX or MIT" through "BSD, unlike GPL, requires attribution, so we ought to set LICENSE_FILE for BSD, but not for GPL", and "LICENSE_FILE should be always set". All of these are IANAL-type of opinions, and result in nothing but arguing on the lists (myself included). > > If some well-defined terms of some license can be abbreviated as, say, > > GPLv2, why do we have to provide a full copy in every individual port? > > I did not say that LICENSE_FILE must always be installed. If the > license is byte-for-byte identical to the template, a symlink is fine. Yes, this is one of the common judgments. It raises even more questions: how do deal with CR/LF, typos, inadvertent changes, and other effects of the fact that upstream lacks a lawyer in 99% cases? What if COPYING file is slightly different from license header in *.c files? There are a lot of possible complications here, leaving aside that technically the whole process of "byte-for-byte verification" should be somehow legally-blessed as well. But we're even worse than that: I cannot find a single symlink under /usr/local/share/licenses; yet there are tons of small files that tell me to go "read from the web". o_O > >> but setting LICENSE_FILE can be kind of helpful. > > > > Shouldn't "Kind of" sound too vague to actual lawyers? :) > > I have never gone through the process of license compliance. From > chatting with others who have, I am told that setting LICENSE_FILE can > help with a first pass or some of the basic automatic work. Methinks we have a larger problem to worry about rather than automating work. To start with, there is no clear distinction between copyright and license. I don't know if it can be legally secured for us to augment our standard Ports Tree disclaimer to acknowledge copyright for all the ports' respective owners, but if would help us to stop worrying about attribution in the licenses' text, that would be awesome: allow us to install a link to a verified, verbatim copy (or copies, per different licenses) and ease the burden of byte-for-byte comparison. :) ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140311132751.GA89701>