lkml.org 
[lkml]   [2015]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SPDX-License-Identifier
On 02.02.2015 17:06, Greg Kroah-Hartman wrote:
> On Mon, Feb 02, 2015 at 04:43:14PM +0100, Stefan Roese wrote:
>> On 21.02.2014 17:18, Michal Simek wrote:
>>> On 02/21/2014 05:12 PM, Felipe Balbi wrote:
>>>> On Fri, Feb 21, 2014 at 05:04:26PM +0100, Michal Simek wrote:
>>>>> On 02/21/2014 05:04 PM, Greg Kroah-Hartman wrote:
>>>>>> On Fri, Feb 21, 2014 at 07:38:16AM +0100, Michal Simek wrote:
>>>>>>> BTW: u-boot started to use SPDX-License-Identifier
>>>>>>> which will be nice to start to use.
>>>>>>
>>>>>> I agree, feel free to start sending patches to use this type of
>>>>>> identifier for drivers.
>>>>>
>>>>> But we probably need to add that Licenses to one location.
>>>>> Documentation/Licenses?
>>>>
>>>> Just add to the drivers themselves, just like u-boot is doing. A simple:
>>>>
>>>> $ git grep -e SPDX-License-Identifier
>>>>
>>>> will tell you filename and license. Or did I misunderstand your question ?
>>>
>>> But for doing this it is probably necessary to have location where
>>> you will place that licenses and you will explain what it is how
>>> it is done by Wolfgang in this commit.
>>>
>>> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=eca3aeb352c964bdb28b8e191d6326370245e03f
>>>
>>> Then yes, adding one line is enough.
>> I would like to revive this thread regarding SPDX license identifiers in the
>> Linux kernel. And check how to best start / proceed with the integration
>> now.
>
> Why do you want to do this?

The main idea behind these SPDX license tags in the source files is,
that it makes license clearing for projects easier. As those tags
simplify the automated tools that scan all source files of projects, in
this case the Linux kernel. One of the problems with the current
licenses in the files is, that even the same licenses are referred to by
a number of slightly varying text blocks (full, abbreviated, different
indentation, line wrapping and/or white space, with obsolete address
information, ...) which makes automatic processing a nightmare.

Please note that we don't want to "disturb" any kernel developers in
their work with this SPDX license ID addition. The licenses will not be
changed in any way. We only want to make life easier for users that need
to run such automated license clearing tools on the source code that
they embed / ship / deploy. And this one additional line in the header
is here definitely helpful.

>> Greg, if you are open to patches adding this one-line SPDX license tag to
>> the source code, how should I begin with such a task in your opinion? Should
>> I add those tags for just one driver directory (e.g. drivers/base/*) first?
>> And send those patches to the list(s) for review. Or do you have other
>> suggestions on how to start with this task?
>
> Is one tag per directory sufficient? Is one tag per file sufficient?
> How about one tag per package? If package, then isn't a single tag for
> the whole kernel source tree sufficient, as we all know the overall
> license for the kernel source tree.

We really need one tag per file. Of course the resulting license for the
Linux kernel is clear. But there are many things to take into account
here. Some of them are (I'm not telling you something new, I know - just
a summary of arguments):

- The Linux source code is not homogeneous and neither perfect nor
without errors. Who ensures that all parts of the kernel really
are GPLv2 compatible?

- Some parts of the Linux source code are also used by other projects.
Or are derived from other projects. Because of this they are
explicitly licensed under different licenses than the GPLv2
(compatible to it though of course). Or are dual-licensed. So that
they can be used by these other projects.

For example "Documentation/SubmittingDrivers" mentions:

The code must be released to us under the
GNU General Public License. We don't insist on any kind
of exclusive GPL licensing, and if you wish the driver
to be useful to other communities such as BSD you may well
wish to release under multiple licenses.
See accepted licenses at include/linux/module.h

Because of this it is really important to know the exact license(s) for
each and every file. And they can vary very much. Here some examples:

GPL v3 or later:

Documentation/filesystems/cifs/winucase_convert.pl
scripts/dtc/dtc-parser.tab.c_shipped
scripts/dtc/dtc-parser.tab.h_shipped
scripts/kconfig/zconf.tab.c_shipped
scripts/genksyms/parse.tab.h_shipped
scripts/genksyms/parse.tab.c_shipped
drivers/staging/lustre/lustre/include/lustre_dlm_flags.h

So there seems to be problem with this lustre code.

Dual BSD/GPL:

crypto/aes_generic.c
crypto/cts.c
crypto/fcrypt.c
drivers/block/skd_main.c
drivers/block/xen-blkback/blkback.c
...

Dual MIT/GPL:

lib/glob.c

Dual MPL/GPL:

drivers/ide/ide-cs.c
drivers/isdn/hisax/elsa_cs.c
drivers/isdn/hisax/sedlbauer_cs.c
drivers/mtd/ftl.c
drivers/net/ethernet/xircom/xirc2ps_cs.c
...

and so on...

So we have many different licenses and perhaps even incompatible ones in
the kernel right now. The SPDX license tags can definitely help sorting
this out. And as mentioned above, will make the life for users running
automated license clearing tools easier.

Thanks,
Stefan



\
 
 \ /
  Last update: 2015-02-04 18:01    [W:0.135 / U:0.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site