All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] [RFC] SPDX License text updates
@ 2018-01-22 17:06 Tom Rini
  2018-01-22 19:44 ` Wolfgang Denk
  2018-01-22 21:33 ` Lukasz Majewski
  0 siblings, 2 replies; 4+ messages in thread
From: Tom Rini @ 2018-01-22 17:06 UTC (permalink / raw)
  To: u-boot

Hey all,

In another thread Felix Brack brought up that as of version 3.0 of SPDX,
there's a number of deprecated tags (see https://spdx.org/licenses/) and
that we're using at least one of them.

Specifically, "GPL-2.0+" should be "GPL-2.0-or-later".

Now, we have a few options here:
- Deprecated isn't removed.  SPDX specifically says the old links shall
  remain valid, etc, etc.  We could continue to use "GPL-2.0+", etc and
  not have to change (literally) 8000 files.  This will also keep us in
  line with what the Linux kernel currently does.  I also have no idea,
  nor have I looked to see if that's going to change.
- Allow both old and new.  Both are valid, the newer form allows for
  easier tooling and more precise management of options that I'm not
  sure apply to our use cases.
- Switch to the new tags.  A few hour I imagine of playing around with
  sed and then manual fixups and I can probably convert all the existing
  cases to the new syntax (we have some DTS files for example with
  (GPL-2.0+ OR MIT) which would become (GPL-2.0-or-later OR MIT).  But
  then we need some tooling to make checkpatch.pl at least noisy about
  unconverted and to get everyone into the habit of changing and so
  forth.

At this point in time I'm leaning towards the first, and as is often the
case, watching what the kernel does.  Thoughts / comments?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180122/8db2b457/attachment.sig>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [U-Boot] [RFC] SPDX License text updates
  2018-01-22 17:06 [U-Boot] [RFC] SPDX License text updates Tom Rini
@ 2018-01-22 19:44 ` Wolfgang Denk
  2018-01-22 20:11   ` Tom Rini
  2018-01-22 21:33 ` Lukasz Majewski
  1 sibling, 1 reply; 4+ messages in thread
From: Wolfgang Denk @ 2018-01-22 19:44 UTC (permalink / raw)
  To: u-boot

Dear Tom,

In message <20180122170607.GL32220@bill-the-cat> you wrote:
> 
> In another thread Felix Brack brought up that as of version 3.0 of SPDX,
> there's a number of deprecated tags (see https://spdx.org/licenses/) and
> that we're using at least one of them.
> 
> Specifically, "GPL-2.0+" should be "GPL-2.0-or-later".

OK...

> Now, we have a few options here:
> - Deprecated isn't removed.  SPDX specifically says the old links shall
>   remain valid, etc, etc.  We could continue to use "GPL-2.0+", etc and
>   not have to change (literally) 8000 files.  This will also keep us in
>   line with what the Linux kernel currently does.  I also have no idea,
>   nor have I looked to see if that's going to change.
> - Allow both old and new.  Both are valid, the newer form allows for
>   easier tooling and more precise management of options that I'm not
>   sure apply to our use cases.

Both sound not really attractive to me.

> - Switch to the new tags.  A few hour I imagine of playing around with
>   sed and then manual fixups and I can probably convert all the existing

Umm... where do you expect problems?  Running for example

	fgrep -hR GPL-2.0+ * | sort -u | less

gives a realtively short list which looks harmless to me.

>   cases to the new syntax (we have some DTS files for example with
>   (GPL-2.0+ OR MIT) which would become (GPL-2.0-or-later OR MIT).  But

Yes, and why do you think this would be a problem?

We have a few other places that don't match current SPDX
spcification, like all these

	GPL-2.0+        BSD-2-Clause
	GPL-2.0+        BSD-3-Clause
	GPL-2.0+ or X11
	GPL-2.0+        X11
	|____GPL-2.0+

but these cases are few and easy to spot.  I currentlse see neither
the need for "few hour of playing around with sed" nor the need for
manual fxes - a plain string substitution should work just fine, and
we could even clean up the other inconsistencies whil we are at it.

I vote for 3 plus additional cleanup.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The scientists of today think deeply instead of clearly. One must  be
sane  to think clearly, but one can think deeply and be quite insane.
                                                       - Nikola Tesla

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [U-Boot] [RFC] SPDX License text updates
  2018-01-22 19:44 ` Wolfgang Denk
@ 2018-01-22 20:11   ` Tom Rini
  0 siblings, 0 replies; 4+ messages in thread
From: Tom Rini @ 2018-01-22 20:11 UTC (permalink / raw)
  To: u-boot

On Mon, Jan 22, 2018 at 08:44:27PM +0100, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20180122170607.GL32220@bill-the-cat> you wrote:
> > 
> > In another thread Felix Brack brought up that as of version 3.0 of SPDX,
> > there's a number of deprecated tags (see https://spdx.org/licenses/) and
> > that we're using at least one of them.
> > 
> > Specifically, "GPL-2.0+" should be "GPL-2.0-or-later".
> 
> OK...
> 
> > Now, we have a few options here:
> > - Deprecated isn't removed.  SPDX specifically says the old links shall
> >   remain valid, etc, etc.  We could continue to use "GPL-2.0+", etc and
> >   not have to change (literally) 8000 files.  This will also keep us in
> >   line with what the Linux kernel currently does.  I also have no idea,
> >   nor have I looked to see if that's going to change.
> > - Allow both old and new.  Both are valid, the newer form allows for
> >   easier tooling and more precise management of options that I'm not
> >   sure apply to our use cases.
> 
> Both sound not really attractive to me.
> 
> > - Switch to the new tags.  A few hour I imagine of playing around with
> >   sed and then manual fixups and I can probably convert all the existing
> 
> Umm... where do you expect problems?  Running for example
> 
> 	fgrep -hR GPL-2.0+ * | sort -u | less
> 
> gives a realtively short list which looks harmless to me.

Note we also need go convert "GPL-2.0" (and LGPL-...), but yes, that's
only going to add a tiny bit more work.

> >   cases to the new syntax (we have some DTS files for example with
> >   (GPL-2.0+ OR MIT) which would become (GPL-2.0-or-later OR MIT).  But
> 
> Yes, and why do you think this would be a problem?
> 
> We have a few other places that don't match current SPDX
> spcification, like all these
> 
> 	GPL-2.0+        BSD-2-Clause
> 	GPL-2.0+        BSD-3-Clause
> 	GPL-2.0+ or X11
> 	GPL-2.0+        X11
> 	|____GPL-2.0+
> 
> but these cases are few and easy to spot.  I currentlse see neither
> the need for "few hour of playing around with sed" nor the need for
> manual fxes - a plain string substitution should work just fine, and
> we could even clean up the other inconsistencies whil we are at it.

This is the second time today I've not spoken clearly enough, sorry.
Yes, the sed side of correcting "GPL-2.0+", "GPL-2.0" and the LGPL
instances as well to take a minute, and perhaps another hour, hopefully
no more than 2 to correct the multi-license things to follow the license
expression format and update Licenses/README.  I don't think that the
above effort is a problem.

What I do see as at least a minor burden moving forward is catching new
files with an SPDX tag of the old variety.  Whacking checkpatch.pl to
catch that will make sure I don't miss them (since I am running
checkpatch.pl every time now).  I see
https://patchwork.kernel.org/patch/10053699/ exists, and it's easy
enough to extend that to catch old-style GPL-2.0/GPL2.0+/LGPL-2.0+/..
and warn about that.

> I vote for 3 plus additional cleanup.

Noted, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180122/1c9ae162/attachment.sig>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [U-Boot] [RFC] SPDX License text updates
  2018-01-22 17:06 [U-Boot] [RFC] SPDX License text updates Tom Rini
  2018-01-22 19:44 ` Wolfgang Denk
@ 2018-01-22 21:33 ` Lukasz Majewski
  1 sibling, 0 replies; 4+ messages in thread
From: Lukasz Majewski @ 2018-01-22 21:33 UTC (permalink / raw)
  To: u-boot

On Mon, 22 Jan 2018 12:06:07 -0500
Tom Rini <trini@konsulko.com> wrote:

> Hey all,
> 
> In another thread Felix Brack brought up that as of version 3.0 of
> SPDX, there's a number of deprecated tags (see
> https://spdx.org/licenses/) and that we're using at least one of them.
> 
> Specifically, "GPL-2.0+" should be "GPL-2.0-or-later".
> 
> Now, we have a few options here:
> - Deprecated isn't removed.  SPDX specifically says the old links
> shall remain valid, etc, etc.  We could continue to use "GPL-2.0+",
> etc and not have to change (literally) 8000 files.  This will also
> keep us in line with what the Linux kernel currently does.  I also
> have no idea, nor have I looked to see if that's going to change.
> - Allow both old and new.  Both are valid, the newer form allows for
>   easier tooling and more precise management of options that I'm not
>   sure apply to our use cases.
> - Switch to the new tags.  A few hour I imagine of playing around with
>   sed and then manual fixups and I can probably convert all the
> existing cases to the new syntax (we have some DTS files for example
> with (GPL-2.0+ OR MIT) which would become (GPL-2.0-or-later OR MIT).
> But then we need some tooling to make checkpatch.pl at least noisy
> about unconverted and to get everyone into the habit of changing and
> so forth.
> 
> At this point in time I'm leaning towards the first, and as is often
> the case, watching what the kernel does.

+1

>  Thoughts / comments?
> Thanks!
> 



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180122/12fc8c71/attachment.sig>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2018-01-22 21:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-22 17:06 [U-Boot] [RFC] SPDX License text updates Tom Rini
2018-01-22 19:44 ` Wolfgang Denk
2018-01-22 20:11   ` Tom Rini
2018-01-22 21:33 ` Lukasz Majewski

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.