linux-spdx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: J Lovejoy <opensource@jilayne.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Richard Fontana <rfontana@redhat.com>,
	linux-spdx@vger.kernel.org
Subject: Re: Meta-question on GPL compliance of this activity
Date: Wed, 22 May 2019 18:52:01 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1905221840570.1770@nanos.tec.linutronix.de> (raw)
In-Reply-To: <86651BE5-1F89-445C-ABDA-FDBFBF177409@jilayne.com>

[-- Attachment #1: Type: text/plain, Size: 4543 bytes --]

Jilayne,

On Wed, 22 May 2019, J Lovejoy wrote:
> > On May 22, 2019, at 8:16 AM, Thomas Gleixner <tglx@linutronix.de> 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

  reply	other threads:[~2019-05-22 16:52 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-06 19:58 [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE Thomas Gleixner
2019-05-21 17:58 ` Meta-question on GPL compliance of this activity Richard Fontana
2019-05-21 18:59   ` J Lovejoy
2019-05-21 21:08   ` Bradley M. Kuhn
2019-05-22  9:40     ` Thomas Gleixner
2019-05-22 13:30     ` Greg KH
2019-05-23  4:41       ` Bradley M. Kuhn
2019-05-23  5:42         ` Thomas Gleixner
2019-05-22 16:14     ` J Lovejoy
2019-05-22 21:10       ` John Sullivan
2019-05-23  1:19         ` J Lovejoy
2019-05-23  6:06           ` Thomas Gleixner
2019-05-29 20:57           ` John Sullivan
2019-05-29 21:30             ` Greg KH
2019-06-01  3:22               ` John Sullivan
2019-06-01  9:31                 ` Greg KH
2019-06-01  4:21               ` Richard Fontana
2019-05-24  4:33       ` Richard Fontana
2019-05-24  5:20         ` Greg KH
2019-05-24 20:24           ` Allison Randal
2019-05-25  1:07             ` Richard Fontana
2019-05-27 21:23               ` Allison Randal
2019-05-25 16:56             ` Greg KH
2019-05-27 21:54               ` Allison Randal
2019-05-28  7:21                 ` Dominik Brodowski
2019-05-22 13:27   ` Greg KH
2019-05-22 14:16     ` Thomas Gleixner
2019-05-22 16:33       ` J Lovejoy
2019-05-22 16:52         ` Thomas Gleixner [this message]
2019-05-22 17:00           ` J Lovejoy
2022-06-06 20:11 ` [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE Richard Fontana
2022-06-06 20:17   ` Thomas Gleixner
2022-06-07 18:12     ` Bradley M. Kuhn
2022-06-07 23:05       ` Thomas Gleixner
2022-06-08  8:33         ` Allison Randal
2022-06-08 14:04           ` Bradley M. Kuhn
2022-06-08 14:59             ` Allison Randal
2022-06-08 17:18               ` Bradley M. Kuhn
2022-06-08 18:54                 ` Richard Fontana
2022-06-08 19:29                   ` Bradley M. Kuhn
     [not found]                     ` <02f4021f-63a5-4796-d790-2bacd37b90d2@jilayne.com>
2022-06-09  0:31                       ` Bradley M. Kuhn
2022-06-09  4:51                         ` J Lovejoy
2022-06-09 15:03                           ` Bradley M. Kuhn
2022-06-09  2:35                       ` Richard Fontana
2022-06-06 20:31   ` Bradley M. Kuhn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.1905221840570.1770@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-spdx@vger.kernel.org \
    --cc=opensource@jilayne.com \
    --cc=rfontana@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).