From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0793FC282CE for ; Wed, 22 May 2019 16:52:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D3A7E20881 for ; Wed, 22 May 2019 16:52:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729609AbfEVQwK (ORCPT ); Wed, 22 May 2019 12:52:10 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:37369 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729457AbfEVQwK (ORCPT ); Wed, 22 May 2019 12:52:10 -0400 Received: from p5b06daab.dip0.t-ipconnect.de ([91.6.218.171] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hTUTC-0000XH-8R; Wed, 22 May 2019 18:52:02 +0200 Date: Wed, 22 May 2019 18:52:01 +0200 (CEST) From: Thomas Gleixner To: J Lovejoy cc: Greg KH , Richard Fontana , linux-spdx@vger.kernel.org Subject: Re: Meta-question on GPL compliance of this activity In-Reply-To: <86651BE5-1F89-445C-ABDA-FDBFBF177409@jilayne.com> Message-ID: References: <20190522132744.GD28920@kroah.com> <86651BE5-1F89-445C-ABDA-FDBFBF177409@jilayne.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1967848851-1558543922=:1770" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-spdx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spdx@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1967848851-1558543922=:1770 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Jilayne, On Wed, 22 May 2019, J Lovejoy wrote: > > On May 22, 2019, at 8:16 AM, Thomas Gleixner wrote: > > TBH, we are talking about cleaning up this mess for at least a decade and > > the lawyers while promising to help just came up with new fancy licenses or > > did not prevent their engineers from creating these zombies which just > > cause headache. > > I’m sorry, but this is an unhelpful comment and that I personally take > offense to. While I’m sure you have had bad experience with lawyers in > the course of this project (and others) - I have my own set of war > stories as well and have often been vocal about criticizing my fellow > lawyers (in the vain hope I might actually make a difference), placing > blame is just unhelpful. I defintely did not want to offend you or anyone else on this list and I'm really sorry that it ended up this way. My apologies. > Please understand that, for example off the top of my head, ONE (open > source) lawyer in a company with hundreds (or thousands?) of software > developers/engineers cannot control what those engineers do in terms of > licensing information - We can give the best advice and document best > practices until we are blue in the face and people (aka our clients) still > won’t always listen. I understand that, but I saw new license variants crop up in the past years which clearly originated from $corp laywers as they were suddenly used in every new file of that $corp. So yes, there are both ways. > And, we make mistakes and learn along the way, as Greg said in another thread. > > We are in this together and we all feel the pain of this mess in our > given roles, which is why we can all come together here and try to fix it > as best we can, which includes, us lawyers making sure we have covered > any potential risks as best we can as well. I'm grateful for that and I truly appreciate that you and the other lawyers have their eyes on it. > > We need a pragmatic approach and I'm surely aware that there might be > > dragons lurking, but we spent a lot of time on thinking about a sane > > approach and with the review process we are able to filter out the > > problematic cases upfront and then we just need to find a way to deal with > > them in a sensible way. > > > > Just leaving them around is not a solution as explained already in that > > other thread. > > I think everyone agrees here. > > > > > We need quick help from the SPDX/lawyer camp to handle these cases proper, > > unless the copyright holders are willing to remove the magic disclaimers > > and modifications. Surely the latter would be the preferred solution, but > > that's nothing engineers can solve. That's something we happily delegate to > > a lawyer to lawyer conversation. :) > > > > in terms of efficiency of process on this: my thinking is that we are > bound to have files that need cleaning up (for one reason or another) from > the same copyright holders, as well as files that have similar patterns of > cleaning up. When it comes to reaching out to people to get them to help > clean stuff up, I think we’ll get a better response if we collect similar > things and send one (or minimal #) of correspondence, rather than one > here, one there, etc. > And, yes, we may not be able to get the copyright holders to help in all > cases where it would be ideal for a number of reasons (can’t find them, > too many people, etc) - but I think we all agree that is ideal and the > first point to try for the messy files. There seems to be plenty of > low-hanging fruit to work on in the meantime and that’s GREAT progress - > so let’s not lose sight of that either :) Sure. I already started to categorize the disclaimer infected files and one category of the first batch is bound to create headache. That's the stuff which came (probably) from TI via RidgeRun Ltd. and then got copied into random places. There are more of those. > For whatever we can’t get copyright holders to clean up, we will look at > adding SPDX identifiers for. But it’s not worth doing that first and then > having someone clean up the I think we really should do things in parallel. 1) Contact the copyright holders where possible. 2) Prepare some SPDX solution for the cases which are not going to be resolved. See the other mail for a proposal. That way we won't create roadblocks which prevent us to reach a clean state in a timely manner. If crap gets removed, great. If not, we have to deal with it no matter what. Thanks, tglx --8323329-1967848851-1558543922=:1770--