svn commit: r320152 - head/net/v6eval

[Bryan Drewery]

On Jun 8, 2013, at 3:07, Hiroki Sato <hrs at FreeBSD.org> wrote:

> Alexey Dokuchaev <danfe at FreeBSD.ORG> wrote
>  in <20130607094637.GA84832 at FreeBSD.org>:
> 
> da> On Fri, Jun 07, 2013 at 05:01:01PM +0900, Hiroki Sato wrote:
> da> > Alexey Dokuchaev <danfe at FreeBSD.ORG> wrote
> da> > da> Can you elaborate on why you insist on standard license file to be
> da> > da> explicitly set instead of using the one from the pool?  I know that
> da> > da> some of us are in the middle of cleaning the ports tree from such
> da> > da> cases.
> da> >
> da> >  Just because it includes copyright notice and not exactly the same as
> da> >  the standard template.  I have converted several ports to use
> da>
> da> Does it make sense to convince upstream to bring their license text to the
> da> standard template?
> 
> This software will never updated because the project was concluded.
> 
> da> >  LICENSE_FILE in order to make the packages include the license files
> da> >  which contain copyright notice, and to remove the license files from
> da> >  PORTDOCS.  Is this usage incorrect?
> da>
> da> This usage is correct: license files should not be part of PORTDOCS, but
> da> I would take it further and say that we should not abuse LICENSE_FILE for
> da> standard licenses.
> 
> I still do not understand what is "abuse" here.  We do not have
> Templates/Licenses/BSD, and a template of BSD license does not make
> sense because it always needs who the copyright holder is.  Something
> like "see this URL" does not work at least for BSD license because it
> requires the copyright notice and conditions *in the distribution*.

Yes. Please do respect the licenses. 

> 
> It is not uncommon that a pre-built package of a small BSD-licensed
> software contains only binaries and a COPYING file.  Even if it is a
> standard BSD license, we need to add the COPYING file to PLIST in
> some way due to the following condition:
> 
> |2. Redistributions in binary form must reproduce the above copyright
> |   notice, this list of conditions and the following disclaimer in
> |   the documentation and/or other materials provided with the
> |   distribution.
> 
> A typical example in ports I maintain is net/cvsync.  It uses
> standard 3-clause BSD license.  Do you think LICENSE_FILE in
> cvsync/Makefile should be removed, too?
> 
> da> >  If this is not allowed, I am wondering why we allow specifying
> da> >  LICENSE_FILE for well-known licenses.
> da>
> da> Nothing is technically not allowed here; right now it is still more of a
> da> matter of personal taste.  I am not sure if denying setting LICENSE_FILE
> da> for well-known licenses is OK, IANAL.  But given the fact that answer to
> da> a question "what's your code's licenses" is typically one word, I do not
> da> support setting LICENSE_FILE for those licenses, when simple BSD/GPL/MIT
> da> seems already being sufficient by common practice.
> 
> What I meant is not technical one.  In my understanding, what is
> allowed for known licenses is clearly described in the following
> sentences in bsd.license.mk:
> 
> # Case 1: license defined in the framework (aka "known").
> #
> # In this case the only allowed variables to set are LICENSE_FILE and
> # LICENSE_DISTFILES. The rest are managed by the framework and are not allowed
> # to change.
> 
> I thought LICENSE_FILE was just for COPYING file when it was in the
> distfile and there was no applicable one in Templates/Licenses.
> 
> For GPL and other licenses which do not require a license text is
> included in the distribution, no LICENSE_FILE is fine.  However,
> licenses like BSD and MIT are different.  If LICENSE_FILE is not
> supposed to be used for including COPYING file when it is a standard
> license, I will remove it from my ports and re-add COPYING file into
> pkg-plist.

For some cases, as you say, the COPYING file is boilerplate and contains no customizations. In those cases it makes sense to use standard. If its been customized with names, years, links, it must be included.

I'm not sure why this issue keeps coming up. These licenses must be respected.

> 
> -- Hiroki