lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20180430000914.GB29548@kroah.com> Date: Sun, 29 Apr 2018 17:09:14 -0700 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: Rafał Miłecki <zajec5@...il.com> Cc: Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>, Jonathan Corbet <corbet@....net>, DOCUMENTATION <linux-doc@...r.kernel.org>, Linus Torvalds <torvalds@...uxfoundation.org>, Andrew Morton <akpm@...uxfoundation.org>, Philippe Ombredanne <pombredanne@...b.com>, Christoph Hellwig <hch@....de>, Russell King <rmk+kernel@...linux.org.uk>, Rob Herring <rob.herring@...aro.org>, Jonas Oberg <jonas@...e.org>, Joe Perches <joe@...ches.com>, linux-xfs@...r.kernel.org, Kate Stewart <kstewart@...uxfoundation.org>, Florian Fainelli <f.fainelli@...il.com>, "Luis R. Rodriguez" <mcgrof@...nel.org> Subject: Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses") On Sun, Apr 29, 2018 at 12:15:11PM +0200, Rafał Miłecki wrote: > On 29 April 2018 at 07:26, Greg Kroah-Hartman > <gregkh@...uxfoundation.org> wrote: > > On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote: > >> Due to some maintainers *preferring* BSD-compatible license for DTS > >> files [0], I was writing mine using ISC. I had no very special reason > >> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen > >> ISC as I read about its "removal of language deemed unnecessary". > >> > >> I took a moment to look at the new SPDX thing and noticed that: > >> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example > > > > Yeah, bad example, we should fix that text up. Care to send a patch? :) > > Sure. I see that license-rules.rst also refers to LICENSES/other/ZLib > which also doesn't exist. > > As "other" directory contains only GPL-1.0 and MPL-1.1 I guess one of > these should be referenced. See the patch set that Thomas has posted to hopefully resolve these issues. I think they are all now taken care of with that series. > >> 2) License file LICENSES/other/ISC doesn't exist > >> 3) ISC is listed as an *example* under the "Not recommended licenses" > > > > Yes, please don't use it if at all possible. > > > >> First of all, as ISC is used by some files in the Linux kernel, I > >> think it's worth adding to the LICENSE/*/ISC. > > > > I see it is only used in a very small number of dts files. Why not just > > use BSD-2-Clause instead? What do you find in ISC that is not available > > to you with just BSD? > > As said, I read about its "removal of language deemed unnecessary". I > assumed that the simpler license text the better. Simple up to a point, having loads of different licenses is a mess, as you are finding out :) > >> Secondly, it isn't 100% clear to me if ISC is preferred or not > >> recommended. File license-rules.rst suggests the later by listing it > >> as an example for "Not recommended". It's just an example though, so > >> I'm not 100% sure without seeing it in either: "preferred" or "other" > >> directories. Also if anyone finds it "Not recommended", can we get a > >> short explanation why is it so, please? > > > > The license is functionally equalivant to BSD-2, so why would you want > > to add more complexity here and have two licenses that are the same be > > "recommended"? > > I don't insist on it, I'm trying to figure out what's the best for the > Linux community. > > On the other hand I could ask why do we want more complexity by having > MIT license. It's very similar to the BSD-2-Clause after all. AFAIK > the only minor differences are that: > 1) MIT clearly allows sublicensing > 2) BSD 2-Clause clearly requires distributing *binaries* with > copyrights + license text I think you will find more dual-licensed MIT code in the tree already than ISC, right? And really, in the end, the odds of someone taking this code _out_ of the tree and using it only under a non-GPLv2 license is slim, to none, so it's best to just stick with the common licenses, as long as they match what you wish the code to abide by. As you want to follow what MIT says, then just use that and all should be good, right? thanks, greg k-h
Powered by blists - more mailing lists