From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cudni-0003fh-Fr for guix-patches@gnu.org; Sun, 02 Apr 2017 07:36:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cudnf-0004YX-Ca for guix-patches@gnu.org; Sun, 02 Apr 2017 07:36:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:58268) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cudne-0004Xl-GY for guix-patches@gnu.org; Sun, 02 Apr 2017 07:36:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cudne-00042D-9p for guix-patches@gnu.org; Sun, 02 Apr 2017 07:36:02 -0400 Subject: bug#26312: [PATCH] gnu: Add cifs-utils. Resent-Message-ID: From: Marius Bakke In-Reply-To: References: <20170330.174824.1172310425105438058.post@thomasdanckaert.be> <354af52f-2759-f845-316d-4b4577413a42@tobias.gr> <87lgrkavxy.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> Date: Sun, 02 Apr 2017 13:35:54 +0200 Message-ID: <87wpb3hwit.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Thomas Danckaert Cc: 26312@debbugs.gnu.org --=-=-= Content-Type: text/plain Thomas Danckaert writes: > Marius Bakke writes: > >> Could you mention which files, since it's only three? I also think >> listing both lgpl2.1+ and lgpl3+ is redundant; if these source files >> interact in some way the result is effectively lgpl3+. If the LGPL2.1+ >> code is what is installed, I would pick that since it implies LGPL3+. > > The files are source/util.{h,c} (lgpl2.1+), and source/cifs_spnego.h > (lgpl3+), I'll add that in a comment. > > About the lgpl2.1+ vs lgpl3+ thing, I'm a bit confused about what we > actually want to communicate with the license field (and probably about > license issues in general). As far as I know, all code (lgpl2.1+ and > lgpl3+ files) is installed (compiled). Because the rest of the code is > GPL3+, I think a linked binary (e.g. a substitute from hydra) can only > be distributed as GPL3+? In addition to that, there are 3 source files, > which can are individually licensed as LGPL2.1+ and LGPL3+, which why we > specify a list of licenses, I thought? In that case I don't really > understand why mentioning only lgpl2.1+ would be sufficient (lgpl3+ is > more strict?). I had a short discussion with Ludo over this in #26256[0]. The consensus is that the "license" field should communicate the terms of the end result, i.e. what the user installs. Often a package will install some executable files with a GPL3+ license which are using some library files that are LGPL3+, then both of those should be mentioned. This becomes complicated when there are a mix of licenses as in this case. Then we have to look at which files are using which to determine what applies to the output. In this case, none of the LGPL code appear to be installed on its own. Most of the source is either GPL2+ or GPL3+. So, I would argue that GPL3+ alone is what applies to this package, since it "wins" over LGPL and GPL2 by being stricter. Hope this helps! [0] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26256#86 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAljg4hoACgkQoqBt8qM6 VPoqqgf8CjgAS4259TkaLqGhcClp1GnlU9spAlWaJxL7CE4Y6TwKVHeKGrkElRbb 8bFYWl3qXAaFxqM+Xe1sF4A+t1Q2Rop06uCUp2PEVh71P+YrRBURqCmf2ekipuF/ x0mPB9U9OI2qa8TIFJ6b+JBPZftwtIbao3JGYJUB9xvLF2o8m44mdeEX4PJYIdtL B8ol5zx2p6f8DGjOiSRCoZ6W8RolsVfLvFMNVdv1xQHK4jDRqbJVTYVKvZnI5VLY aYoz7ImdNF3EkpTvZ/xL+K0jHtRj0SF4dIlHmFictkFWZhg7Fh8XK+vst/o7CRmW 2Efaj+4KvpKYEa+fOpyv0uvYn6cphQ== =BDqQ -----END PGP SIGNATURE----- --=-=-=--