On Wed, Nov 08, 2017 at 07:11:21AM -0800, Christoph Hellwig wrote: > On Wed, Nov 08, 2017 at 01:35:46PM +0100, Philippe Ombredanne wrote: > > The benefits now and later: > > - no distraction with licensing boilerplate cr*p in patches and files > > - no guessing licensing needed when sending a patch > > - anyone can grep the kernel tree for licensing, no extra tool needed > > - Greg must feel really good about deleting so much things for once > > This patch didn't delete anything, it added random notes. > > I see now Greg deletes things from files he maintains which is even > worse, given that the kernel tree doesn't document anywhere what these > tags actually mean. The documentation of this process is lagging the patches, as usually happens, sorry about that. Thomas is working on a document to describe the process, and what a file should contain, based on the work he has been doing. This was discussed at the kernel summit, and sorry for it not getting out wider than that audience, things take time, which is why I was only touching my subsystems with the "general license cleanups" at the moment until his document was ready. Hopefully a draft of it will go out today, Thomas? > So he deletes a lot of license tags and replaces them with tags he > puts a great significance on, but which aren't defined. A quick googles > shows some Linuxfoundation web page defines them, but they could change > them any time they want, nevermind that we don't even have a reference > to them either. SPDX is an industry-wide accepted set of tags for all licenses, some projects have been using it for years (like Uboot). These are not going to change randomly, and again, the document that Thomas has will describe these in detail. sorry for the confusion, it was not intended at all, but it what happens in time with distributed developers, all working at different rates on different parts of the tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
