linux-kernel - Re: how much license information inside the kernel ?

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:	Thu, 30 Oct 2008 14:47:07 -0400
From:	Chris Snook <csnook@...hat.com>
To:	devzero@....de
CC:	linux-kernel@...r.kernel.org
Subject: Re: how much license information inside the kernel ?

devzero@....de wrote:
> hi,
> 
> i found that there is a LOT of repeating licensing information in the
> kernel.
> 
> for me,
> 
> find ./linux-2.6.27 -type f -exec cat {} \; |egrep "free software|GNU
> General Public License|Free Software Foundation|version 2 of the
> License|distributed in the hope|WITHOUT ANY WARRANTY|FITNESS FOR A
> PARTICULAR"
> 
> gives a file sized ~3.5M
> 
> That`s more than 1% of the kernel source.
> 
> What about the idea to shorten that licening information to a minimum
> , e.g. by shrinking that to a single, catchy line ,  linking to a
> special licensing file like COPYING or linking to the FSF website ?
> 
> please no flames, i know this idea could be pure dynamite for some
> people - but i thought 3.5M is worth this mail.
> 
> regards roland
> 
> ps: i`m not sure if that has been discussed already, but i didn`t
> find that in the archive. please ignore, otherwise.

It may be 3.5 MB uncompressed, but disk space is cheap, and repeated 
strings compress extremely well to save bandwidth.  If you work with the 
kernel source enough for this to be an issue, you should use git. 
You'll download these license headers once, and never again unless the 
copyright info gets changed by a patch.  From a technical perspective, 
the problem isn't nearly as bad as it looks, and it keeps the lawyers 
happy, so it's really not worth messing with.  There's plenty of 
lower-hanging fruit in unifying drivers for similar hardware, unifying 
32-bit and 64-bit architectures, and other things that make the code 
more maintainable.

-- Chris
--
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/