linux-kernel - Re: [PATCH] module: Clarify GPL-Compatible is OK

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 Apr 2012 17:51:51 -0700
From:	"Luis R. Rodriguez" <mcgrof@...jolero.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	rusty@...tcorp.com.au, linux-kernel@...r.kernel.org,
	Keith Packard <keithp@...thp.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Stephen Hemminger <shemminger@...tta.com>,
	"John W. Linville" <linville@...driver.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] module: Clarify GPL-Compatible is OK

On Fri, Apr 6, 2012 at 5:36 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, Apr 6, 2012 at 5:11 PM, Luis R. Rodriguez <mcgrof@...jolero.org> wrote:
>> -MODULE_LICENSE("Dual BSD/GPL");
>> +MODULE_LICENSE("GPL-Compatible");
>
> I really don't see the point.
>
> This makes things *worse*.
>
> "Dual BSD/GPL" actually tells you something: it tells you that you can
> take that code, and use it in a BSD project.
>
> In contrast "GPL-compatible" tells you nothing at all.
>
> So you are actually removing real information, and just making things
> harder for everybody.

Its a good point that we are not declaring the exact license used for
software, and while that is useful the "Dual BSD/GPL" tag is
misleading. As I see it there are four options:

1) Use this as a technical artifact only to ensure symbols we declare
EXPORT_SYMBOL_GPL() will only be used by GPL-Compatible modules. Also
use the GPL-Compatible tag as annotated by this patch to annotate
this. Then add another tag to specific the exact license, which is not
anything of an artifact but just informational to the binary module
but also software developer reviewing code. This last part would
clarify the exact license.

2) We keep extending the list of MODULE_LICENSE() with all the
different GPL-Compatible licenses we are comfortable with. This list
is pretty outdated already. This means we keep chugging along and
adding more licenses.

3) Leave things as is, and clarify this. I think this confuses
developers though, and for sharing purposes it would be nice. Hence
the patch. You have no idea how many e-mails I have had to deal with
to address this. People really think this is impossible. In fact we
had a flamewar eons ago because a few of us didn't know this was
possible to help the BSDs. Not just developers, I think there are even
maintainers not too sure about this.

4) Use the patch and leave it to the person who wants to extract code
to figure out the exact module license.

Option 1) seems to me to provide the best alternative but leaves open
then the question of whether or not we need to keep tabs of accepted
GPLv2 compatible licenses we accept or leave this as informational.
Option 4) handles the technical artifacts we care about but gives some
homework to consumers.

Please let me know if anyone can think of better alternatives.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/