Re: Meta-question on GPL compliance of this activity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jilayne,

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

[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux