[lkml]   [2017]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 1/7] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Thu, Nov 16, 2017 at 4:15 PM, Jonas Oberg <> wrote:
> Hi,
>> One other thing that occurred to me is that documentation files, too,
>> are copyrightable and should have license identifiers.
> Would it make sense to take an incremental approach to this? Get the
> source code and identifiers worked on by Thomas et al through first, then
> think about and fix up potential other issues, like the top level COPYING
> file, or documentation :-)

I could not agree more... code first!
FWIW I scanned the whole docs with scancode as part of this exercise.
They are rather ... messy license-wise, but even though I got through
it eventually they also generally less critical license-wise IMHO.

You can see some details of these scans in [1] though they are not
100% up to date: I did not post every intermediate scans and review
there as things are moving at a fast pace.

There are probably more pressing things to fix such as discrepancies
between a MODULE_LICENSE and the licensing of a file when they do not

Here [2] the top level comment is a plain GPL-2.0 "only" while the
MODULE_LICENSE is a GPL-2.0+ "or later" (based on the plain "GPL"
definition in module.h [3] and this is just one of many examples of this

Or fix the non-standard redefinition of the MODULE_LICENSE macro as
DRIVER_LICENSE as in [2] and found elsewhere with
grep -r . -e "DRIVER_LICENSE"

These break the otherwise nicely grepable MODULE_LICENSE macros
with this kind of warty redirection I stumbled upon while reviewing kernel
license scans:


Philippe Ombredanne
 \ /
  Last update: 2017-11-17 17:18    [W:0.069 / U:6.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site