From owner-freebsd-ports@FreeBSD.ORG Sat Mar 22 22:57:36 2014 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92802ACB; Sat, 22 Mar 2014 22:57:36 +0000 (UTC) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4C2BBFCA; Sat, 22 Mar 2014 22:57:35 +0000 (UTC) Received: from [192.168.0.20] (unknown [130.255.19.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id F3149438BC; Sat, 22 Mar 2014 17:57:17 -0500 (CDT) Message-ID: <532E153B.9030408@marino.st> Date: Sat, 22 Mar 2014 23:56:59 +0100 From: John Marino User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: CyberLeo Kitsana , Kevin Oberman , marino@freebsd.org Subject: Re: LPPL10 license consequences intended? (arabic/arabtex) References: <532DC88A.7010104@marino.st> <532DFDB2.1090200@cyberleo.net> In-Reply-To: <532DFDB2.1090200@cyberleo.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ports@FreeBSD.org Ports" , Nicola Vitale X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: marino@freebsd.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 22:57:36 -0000 On 3/22/2014 22:16, CyberLeo Kitsana wrote: > On 03/22/2014 02:27 PM, Kevin Oberman wrote: >> On Sat, Mar 22, 2014 at 10:29 AM, John Marino wrote: >> >>> In December, Nicola set the license for Arabtex to LPPL10. >>> The result is that the port is no longer packagable: >>> >>>> ====>> Ignoring arabic/arabtex: License LPPL10 needs confirmation, but >>> BATCH is defined >>>> build of /usr/ports/arabic/arabtex ended at Mon Mar 17 16:12:44 PDT 2014 >>> >>> From a quick conversation on IRC, I got the idea that the license was >>> correct and many more Tex packages should also have this license. >>> If/when that happens, does that mean Tex packages are only to be built >>> from source? >>> >>> Is it correct that LPPL10 can't be built in a batch? > > No. You must accept the license before you can build the port, and you > cannot interactively accept a license in non-interactive batch mode. > > See the commments in /usr/ports/Mk/bsd.licenses.mk for what to set in > make.conf to automatically accept certain licenses. I guess I should have been more clear. I know LPPL10 is defined in such a way that packaging in batch mode is not possible. I was questioning if the definition was actually correct, that this Tex port and every Tex port like it will be unpackagable. Kevin Oberman wrote: > I just read over LPPL and it i pretty clear that "Compiled Work" (i.e. the > binary code) may be redistributed: > > 3. You may distribute a Compiled Work that has been generated from a > complete, unmodified copy of the Work as distributed under Clause 2 > above, as long as that Compiled Work is distributed in such a way that > the recipients may install the Compiled Work on their system exactly > as it would have been installed if they generated a Compiled Work > directly from the Work. > > Looking at the port, I see exactly NO modifications to the "Work". This > assumes that arabtex is, itself, part of the official "Distribution" of the > "Current Maintainers". It may be that it is, in fact, a "Derived Work", not > officially blessed by the "Current Maintainers". In that case it could not > be packaged under the terms of clause 3 (quoted above), but other LPPL > ports that are part of the official "Work" could be. > > "Derived Work" may be redistributed as "Compiled Work" if certain > conditions are met. See clause 6 which is quite long and I am not confident > that I understand. (In fact, I'm quite confident that I don't fully > understand it.) > > IANAL, but the text is pretty clear. I just have not spent the time to > confirm whether arabtex is "Work" of the project or "Derived Work" of the > official "Distribution". (Note that quoted terms are legally defined terms > in the license.) Okay, this would imply that LPPL10 either has incorrect default definitions or that a port like Arabtex may have to specifically define it's ability to be packaged assuming it's unmodified from the original work. If the latter is true, every port that uses LPPL10 will need to specifically check that... Thanks for the thoughtful comments so far. John