Re: [U-Boot] SPDX License status

[Masahiro Yamada]

2017-08-25 16:46 GMT+09:00 Wolfgang Denk :
> Dear Tom,
>
> In message <20170825012557.GK2827@bill-the-cat> you wrote:
>>
>> Actual code we have to take care with anyhow, but it's still up to the
>> person that has to handle the syncing.
>
> Really?  Should we not rather implement a common, consistent policy
> for the whole project?
>
> Our patch submission already include a rule for new code [1]:
>
> If you add new files, please always make sure that these
> contain your copyright note and a GPLv2+
> SPDX-License-Identifier, for example like this:
>
> (C) Copyright 2010  Joe Hacker 
>
> SPDX-License-Identifier:GPL-2.0+
>
> Should we not ask the same for code merged from other projects?
>
> [1] Bullet #3 in 
> http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign
>
> Best regards,
>
> Wolfgang Denk
>
> --


As you may have already noticed, there seemed to be a progress in Linux.

https://lkml.org/lkml/2017/11/2/590



-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] SPDX License status

[Wolfgang Denk]

Dear Tom,

In message <20170825012557.GK2827@bill-the-cat> you wrote:
> 
> Actual code we have to take care with anyhow, but it's still up to the
> person that has to handle the syncing.

Really?  Should we not rather implement a common, consistent policy
for the whole project?

Our patch submission already include a rule for new code [1]:

If you add new files, please always make sure that these
contain your copyright note and a GPLv2+
SPDX-License-Identifier, for example like this:

(C) Copyright 2010  Joe Hacker 

SPDX-License-Identifier:GPL-2.0+

Should we not ask the same for code merged from other projects?

[1] Bullet #3 in 
http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign

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: w...@denx.de
On mules we find two legs behind and two we find before.
We stand behind before we find what those behind be for.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] SPDX License status

[Tom Rini]

On Tue, Aug 22, 2017 at 10:39:40AM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20170821192329.GF17193@bill-the-cat> you wrote:
> > 
> > > Do I interpret this correctly that you think we should NOT insert
> > > SPDX tags into files imported from Linux (or other projects)?  But
> > > how do we keep track of the origin of such files, then?  Git meta
> > > data information is not useful for automatic tracking tools (or are
> > > there such clever tools available by now?)...
> > 
> > Generally speaking, Linux Kernel is what we're pulling stuff from, and
> > that's the project that doesn't care for SPDX tags being introduced, and
> > we know what we sync largely there.  For other projects, some evangelism
> > about SPDX might work.
> 
> I'm afraid a statement like "we know what we sync" is a bit
> shortsighted.  It's simply not sufficient that we know something, we
> should be able to prove it.  Even more, we should document it so
> nobody will ever have to ask us to prove it.
> 
> People using U-Boot in commercial projects have to undergo license
> clearing precedures, and for them such documentation is very
> important.  What's in our heads is not very useful to them in such a
> situation.
> 
> My opinion is that we should add proper SPDX tags to all files that
> we import and that do not yet contain any such information.

We must not pull in files that are not properly licensed to start with.
We must continue (and be better about) enforcing that when files come in
from other projects, or re-sync with them we clearly point to a stable
way to say when and where it came from (ie git hash, tag, release
number).  This type of traceability provides more useful information
than just a license tag.

> > We leave the dts/dtsi files un-touched from upstream, yes.  Thanks!
> 
> What about other files imported from Linux or other projects?  Say
> source code?

Actual code we have to take care with anyhow, but it's still up to the
person that has to handle the syncing.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] SPDX License status

[Wolfgang Denk]

Dear Tom,

In message <20170821192329.GF17193@bill-the-cat> you wrote:
> 
> > Do I interpret this correctly that you think we should NOT insert
> > SPDX tags into files imported from Linux (or other projects)?  But
> > how do we keep track of the origin of such files, then?  Git meta
> > data information is not useful for automatic tracking tools (or are
> > there such clever tools available by now?)...
> 
> Generally speaking, Linux Kernel is what we're pulling stuff from, and
> that's the project that doesn't care for SPDX tags being introduced, and
> we know what we sync largely there.  For other projects, some evangelism
> about SPDX might work.

I'm afraid a statement like "we know what we sync" is a bit
shortsighted.  It's simply not sufficient that we know something, we
should be able to prove it.  Even more, we should document it so
nobody will ever have to ask us to prove it.

People using U-Boot in commercial projects have to undergo license
clearing precedures, and for them such documentation is very
important.  What's in our heads is not very useful to them in such a
situation.

My opinion is that we should add proper SPDX tags to all files that
we import and that do not yet contain any such information.

> We leave the dts/dtsi files un-touched from upstream, yes.  Thanks!

What about other files imported from Linux or other projects?  Say
source code?

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: w...@denx.de
What the gods would destroy they first submit to  an  IEEE  standards
committee.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] SPDX License status

[Tom Rini]

On Mon, Aug 21, 2017 at 05:25:40PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20170819011542.GE17193@bill-the-cat> you wrote:
> > 
> > For all of the dts/dtsi files that we copy in-place from Linux,
> > converting them to SPDX tags would be churn that has to be kept in-place
> > every update, and upstream does not want them (I had a chat with Frank
> > or Rob at some point, I think).
> 
> Do I interpret this correctly that you think we should NOT insert
> SPDX tags into files imported from Linux (or other projects)?  But
> how do we keep track of the origin of such files, then?  Git meta
> data information is not useful for automatic tracking tools (or are
> there such clever tools available by now?)...

Generally speaking, Linux Kernel is what we're pulling stuff from, and
that's the project that doesn't care for SPDX tags being introduced, and
we know what we sync largely there.  For other projects, some evangelism
about SPDX might work.

> > So, when I've run U-Boot through the "old" SPDX-2.0 tools, it was quite
> > happy to diagnose the information on dts files from the kernel
> > correctly, so I don't see changing them to tags as being beneficial.  I
> 
> I tend to disagree here.  THe process of inserting License tags
> makes automatic scanning easier, and it documents that somebody
> looked at this.

For the former, the SPDX tools handle the standard boilerplates fine,
and they have to, since most projects aren't using tags.  For the
latter, given our automated conversion, that's not really true.  And at
the end of the day, the lawyers need to look it over at the end.

> > I would be quite happy to see more patches along the lines of
> > 78e9e71c83cf which correct the missing information in files by pulling
> > in specific changes from their respective upstream (or at least a
> > specific release that contains the change) that corrects this
> > information.  I also suspect this will leave us with a few files that in
> > the kernel today have loose wording and we have to either live with it,
> > or talk to upstream about updating it.
> 
> So what do we do for example with all the .dts / .dtsi files?  Would
> you accept patches to insert SPDX tags for U-Boot?  [I see no chance
> to do this in Linux mainline.]

We leave the dts/dtsi files un-touched from upstream, yes.  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] SPDX License status

[Wolfgang Denk]

Dear Tom,

In message <20170819011542.GE17193@bill-the-cat> you wrote:
> 
> For all of the dts/dtsi files that we copy in-place from Linux,
> converting them to SPDX tags would be churn that has to be kept in-place
> every update, and upstream does not want them (I had a chat with Frank
> or Rob at some point, I think).

Do I interpret this correctly that you think we should NOT insert
SPDX tags into files imported from Linux (or other projects)?  But
how do we keep track of the origin of such files, then?  Git meta
data information is not useful for automatic tracking tools (or are
there such clever tools available by now?)...

> So, when I've run U-Boot through the "old" SPDX-2.0 tools, it was quite
> happy to diagnose the information on dts files from the kernel
> correctly, so I don't see changing them to tags as being beneficial.  I

I tend to disagree here.  THe process of inserting License tags
makes automatic scanning easier, and it documents that somebody
looked at this.

> I would be quite happy to see more patches along the lines of
> 78e9e71c83cf which correct the missing information in files by pulling
> in specific changes from their respective upstream (or at least a
> specific release that contains the change) that corrects this
> information.  I also suspect this will leave us with a few files that in
> the kernel today have loose wording and we have to either live with it,
> or talk to upstream about updating it.

So what do we do for example with all the .dts / .dtsi files?  Would
you accept patches to insert SPDX tags for U-Boot?  [I see no chance
to do this in Linux mainline.]

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: w...@denx.de
Minds are like parachutes - they only function when open.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] SPDX License status

[Tom Rini]

On Thu, Aug 17, 2017 at 10:09:10AM +0200, Wolfgang Denk wrote:

> Dear Tom,
> 
> a quick check reveals that we have a very large number (4,300+) files
> in the U-Boot tree have no SPDX license tags, or - even worse - no
> license information at all.
> 
> I think this should be cleaned up.  And I am aware that this would
> be a lot of effort, and there will be discussions where this is
> needed and where not.
> 
> A few observations:
> 
> - There are some 600+ "Kconfig" files.
> 
> - There are some 500+ ".dts" and ".dtsi" files.  Many of these are
>   copied from the Linux kernel.
> 
> - There are nearly 100 ".cfg" files.
> 
> - There are 1,100+ ".defconfig" files.
> 
> - There are nearly 300 "README" files.
> 
> - There are 549 ".h" and 246 ".c" files.  Again, many of these are
>   copied from the Linux kernel.

So, it's true that it's been a while since I took a U-Boot release and
tossed it at the preferred SPDX-2.0 verifying tool and looked at the
output.  In my defense, I think that was in part because it changed from
an online tool to a local one, and I never got around to setting it up.
But, some advice I did get (I want to say from Karen @ SFC) was that
ignoring "Kconfig" and "Makefile" type files is fine.  I don't recall if
we talked about defconfig files and READMEs, but they too would fit in
that category.

For all of the dts/dtsi files that we copy in-place from Linux,
converting them to SPDX tags would be churn that has to be kept in-place
every update, and upstream does not want them (I had a chat with Frank
or Rob at some point, I think).

> Once upon a time there was an agreement that all files in U-Boot
> shall have proper license information, and that we will use SPDX
> tags for this purpose.  Obviously, this has been largely neglected
> in the past.
> 
> One of the arguments against changtes that I see coming is this:
> "But this file has been copied without changes from project XXX,
> and it must not be changed at all so that it is easy to update it
> when XXX provides new versions."  In many cases, XXX would be the
> Linux kernel.  IIUC this is especially the argument for not touching
> the .dts files, and many architecture header files.
> 
> But if we set ourself the goal to make License compliance for U-Boot
> easy to check, and with largely with automatic tools, then we must
> document the licensing of any imported file _withing_that_file_,
> and in the format defined for this purpose by U-Boot, i. e. using
> SPDX tags.
> 
> Do you agree on this?   Or what is your position?

So, when I've run U-Boot through the "old" SPDX-2.0 tools, it was quite
happy to diagnose the information on dts files from the kernel
correctly, so I don't see changing them to tags as being beneficial.  I
do recall it finding a number of files from the kernel that it either
couldn't deduce or decided was "GPLv1 or later" because of very loose
wording.  This was about 2 years ago, and at least for the few cases I
tracked down, they had been updated in the kernel and I pulled those
updates back in (see 78e9e71c83cf which really really feels like a post
ELCE 'let me dig at this while it's fresh in my mind' commit).

I would be quite happy to see more patches along the lines of
78e9e71c83cf which correct the missing information in files by pulling
in specific changes from their respective upstream (or at least a
specific release that contains the change) that corrects this
information.  I also suspect this will leave us with a few files that in
the kernel today have loose wording and we have to either live with it,
or talk to upstream about updating it.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] SPDX License status

[Wolfgang Denk]

Dear Tom,

a quick check reveals that we have a very large number (4,300+) files
in the U-Boot tree have no SPDX license tags, or - even worse - no
license information at all.

I think this should be cleaned up.  And I am aware that this would
be a lot of effort, and there will be discussions where this is
needed and where not.

A few observations:

- There are some 600+ "Kconfig" files.

- There are some 500+ ".dts" and ".dtsi" files.  Many of these are
  copied from the Linux kernel.

- There are nearly 100 ".cfg" files.

- There are 1,100+ ".defconfig" files.

- There are nearly 300 "README" files.

- There are 549 ".h" and 246 ".c" files.  Again, many of these are
  copied from the Linux kernel.


Once upon a time there was an agreement that all files in U-Boot
shall have proper license information, and that we will use SPDX
tags for this purpose.  Obviously, this has been largely neglected
in the past.

One of the arguments against changtes that I see coming is this:
"But this file has been copied without changes from project XXX,
and it must not be changed at all so that it is easy to update it
when XXX provides new versions."  In many cases, XXX would be the
Linux kernel.  IIUC this is especially the argument for not touching
the .dts files, and many architecture header files.

But if we set ourself the goal to make License compliance for U-Boot
easy to check, and with largely with automatic tools, then we must
document the licensing of any imported file _withing_that_file_,
and in the format defined for this purpose by U-Boot, i. e. using
SPDX tags.

Do you agree on this?   Or what is your position?

How should we clean up that mess?



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: w...@denx.de
As in certain cults it is possible to kill a process if you know  its
true name.  -- Ken Thompson and Dennis M. Ritchie
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot