Re: [U-Boot] Individual files dual licenses

2018-01-18 Thread York Sun
On 01/18/2018 11:17 AM, Tom Rini wrote:
> On Thu, Jan 18, 2018 at 06:14:07PM +, York Sun wrote:
>> On 01/18/2018 10:11 AM, Tom Rini wrote:
>>> On Thu, Jan 18, 2018 at 06:09:22PM +, York Sun wrote:
 On 01/18/2018 10:04 AM, Tom Rini wrote:
>>>
>>> With regards to dts files, this is another reason I would like to see
>>> that done as a strict re-sync with Linux rather than a stand-alone
>>> change.  Saying we're importing file X from the kernel at revision Y
>>> makes the license change pretty easy to spot and justify.
>>>
>>
>> For the dts files, they already exist in U-Boot. Can the team still say
>> "importing" from Linux? The files in U-Boot is only a small subset of
>> those in Linux.
>
> Yes, if it's a strict replace file A with contents of the same file from
> Linux, it's re-importing.  I thought these boards had already re-synced
> before but perhaps not?  It's something we do from time to time on other
> platforms.

 In this case, the contents of dts files are different from those in
 Linux. The only thing imported this time is the dual license. Is it
 still considered a re-sync?
>>>
>>> They should not be different at all.  Anything U-Boot centric should be
>>> in an appropriately named -u-boot.dtsi file.  This facilitates keeping
>>> the rest of the dts/dtsi files as exact copies of the ones in the
>>> kernel.
>>>
>>> To put it another way, what is the reason they differ from the kernel?
>>> And could they be changed to not, and use a -u-boot.dtsi (or several) so
>>> that they can be kept in-sync with the kernel?
>>
>> The dts files in Linux are much much bigger. U-Boot only uses a small
>> subset. There are many nodes not used by U-Boot.
> 
> For SPL where we care about size in that regard we have
> CONFIG_OF_SPL_REMOVE_PROPS to trim things down as needed, and it
> shouldn't be a concern for full U-Boot.  
> 
> If your really want to maintain two distinct dts/dtsi files because
> there's some value you see in that, I won't stop you from doing it.  But
> I don't see a unique challenge posed by the NXP platforms just yet
> either.  Thanks!

Got it. I don't know if most platforms use identical dts from Linux. We
started with tiny dts files and haven't seen the benefit to get the full
version. I will let the team decide if we want to copy Linux files over.

York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Individual files dual licenses

2018-01-18 Thread Tom Rini
On Thu, Jan 18, 2018 at 06:14:07PM +, York Sun wrote:
> On 01/18/2018 10:11 AM, Tom Rini wrote:
> > On Thu, Jan 18, 2018 at 06:09:22PM +, York Sun wrote:
> >> On 01/18/2018 10:04 AM, Tom Rini wrote:
> >
> > With regards to dts files, this is another reason I would like to see
> > that done as a strict re-sync with Linux rather than a stand-alone
> > change.  Saying we're importing file X from the kernel at revision Y
> > makes the license change pretty easy to spot and justify.
> >
> 
>  For the dts files, they already exist in U-Boot. Can the team still say
>  "importing" from Linux? The files in U-Boot is only a small subset of
>  those in Linux.
> >>>
> >>> Yes, if it's a strict replace file A with contents of the same file from
> >>> Linux, it's re-importing.  I thought these boards had already re-synced
> >>> before but perhaps not?  It's something we do from time to time on other
> >>> platforms.
> >>
> >> In this case, the contents of dts files are different from those in
> >> Linux. The only thing imported this time is the dual license. Is it
> >> still considered a re-sync?
> > 
> > They should not be different at all.  Anything U-Boot centric should be
> > in an appropriately named -u-boot.dtsi file.  This facilitates keeping
> > the rest of the dts/dtsi files as exact copies of the ones in the
> > kernel.
> > 
> > To put it another way, what is the reason they differ from the kernel?
> > And could they be changed to not, and use a -u-boot.dtsi (or several) so
> > that they can be kept in-sync with the kernel?
> 
> The dts files in Linux are much much bigger. U-Boot only uses a small
> subset. There are many nodes not used by U-Boot.

For SPL where we care about size in that regard we have
CONFIG_OF_SPL_REMOVE_PROPS to trim things down as needed, and it
shouldn't be a concern for full U-Boot.  

If your really want to maintain two distinct dts/dtsi files because
there's some value you see in that, I won't stop you from doing it.  But
I don't see a unique challenge posed by the NXP platforms just yet
either.  Thanks!

-- 
Tom


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


Re: [U-Boot] Individual files dual licenses

2018-01-18 Thread York Sun
On 01/18/2018 10:11 AM, Tom Rini wrote:
> On Thu, Jan 18, 2018 at 06:09:22PM +, York Sun wrote:
>> On 01/18/2018 10:04 AM, Tom Rini wrote:
>
> With regards to dts files, this is another reason I would like to see
> that done as a strict re-sync with Linux rather than a stand-alone
> change.  Saying we're importing file X from the kernel at revision Y
> makes the license change pretty easy to spot and justify.
>

 For the dts files, they already exist in U-Boot. Can the team still say
 "importing" from Linux? The files in U-Boot is only a small subset of
 those in Linux.
>>>
>>> Yes, if it's a strict replace file A with contents of the same file from
>>> Linux, it's re-importing.  I thought these boards had already re-synced
>>> before but perhaps not?  It's something we do from time to time on other
>>> platforms.
>>
>> In this case, the contents of dts files are different from those in
>> Linux. The only thing imported this time is the dual license. Is it
>> still considered a re-sync?
> 
> They should not be different at all.  Anything U-Boot centric should be
> in an appropriately named -u-boot.dtsi file.  This facilitates keeping
> the rest of the dts/dtsi files as exact copies of the ones in the
> kernel.
> 
> To put it another way, what is the reason they differ from the kernel?
> And could they be changed to not, and use a -u-boot.dtsi (or several) so
> that they can be kept in-sync with the kernel?
> 

The dts files in Linux are much much bigger. U-Boot only uses a small
subset. There are many nodes not used by U-Boot.

York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Individual files dual licenses

2018-01-18 Thread Tom Rini
On Thu, Jan 18, 2018 at 06:09:22PM +, York Sun wrote:
> On 01/18/2018 10:04 AM, Tom Rini wrote:
> >>>
> >>> With regards to dts files, this is another reason I would like to see
> >>> that done as a strict re-sync with Linux rather than a stand-alone
> >>> change.  Saying we're importing file X from the kernel at revision Y
> >>> makes the license change pretty easy to spot and justify.
> >>>
> >>
> >> For the dts files, they already exist in U-Boot. Can the team still say
> >> "importing" from Linux? The files in U-Boot is only a small subset of
> >> those in Linux.
> > 
> > Yes, if it's a strict replace file A with contents of the same file from
> > Linux, it's re-importing.  I thought these boards had already re-synced
> > before but perhaps not?  It's something we do from time to time on other
> > platforms.
> 
> In this case, the contents of dts files are different from those in
> Linux. The only thing imported this time is the dual license. Is it
> still considered a re-sync?

They should not be different at all.  Anything U-Boot centric should be
in an appropriately named -u-boot.dtsi file.  This facilitates keeping
the rest of the dts/dtsi files as exact copies of the ones in the
kernel.

To put it another way, what is the reason they differ from the kernel?
And could they be changed to not, and use a -u-boot.dtsi (or several) so
that they can be kept in-sync with the kernel?

-- 
Tom


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


Re: [U-Boot] Individual files dual licenses

2018-01-18 Thread York Sun
On 01/18/2018 10:04 AM, Tom Rini wrote:
>>>
>>> With regards to dts files, this is another reason I would like to see
>>> that done as a strict re-sync with Linux rather than a stand-alone
>>> change.  Saying we're importing file X from the kernel at revision Y
>>> makes the license change pretty easy to spot and justify.
>>>
>>
>> For the dts files, they already exist in U-Boot. Can the team still say
>> "importing" from Linux? The files in U-Boot is only a small subset of
>> those in Linux.
> 
> Yes, if it's a strict replace file A with contents of the same file from
> Linux, it's re-importing.  I thought these boards had already re-synced
> before but perhaps not?  It's something we do from time to time on other
> platforms.
> 

In this case, the contents of dts files are different from those in
Linux. The only thing imported this time is the dual license. Is it
still considered a re-sync?

York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Individual files dual licenses

2018-01-18 Thread Tom Rini
On Thu, Jan 18, 2018 at 06:02:44PM +, York Sun wrote:
> On 01/18/2018 09:59 AM, Tom Rini wrote:
> > On Thu, Jan 18, 2018 at 05:25:01PM +, York Sun wrote:
> > 
> >> Tom and Wolfgang,
> >>
> >> Do we have guideline on dual licensing the code in U-Boot? If I collect
> >> consent from all contributors and copyright holders to a particular
> >> file, am I able to re-license the file? If yes, how to determine the
> >> list of contributors?
> > 
> > In general, I think you would use 'git log' to see who contributed to a
> > given file, and make sure that everyone who authored a change signed off
> > on the license change.
> 
> Thanks.
> 
> > 
> > With regards to dts files, this is another reason I would like to see
> > that done as a strict re-sync with Linux rather than a stand-alone
> > change.  Saying we're importing file X from the kernel at revision Y
> > makes the license change pretty easy to spot and justify.
> > 
> 
> For the dts files, they already exist in U-Boot. Can the team still say
> "importing" from Linux? The files in U-Boot is only a small subset of
> those in Linux.

Yes, if it's a strict replace file A with contents of the same file from
Linux, it's re-importing.  I thought these boards had already re-synced
before but perhaps not?  It's something we do from time to time on other
platforms.

-- 
Tom


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


Re: [U-Boot] Individual files dual licenses

2018-01-18 Thread York Sun
On 01/18/2018 09:59 AM, Tom Rini wrote:
> On Thu, Jan 18, 2018 at 05:25:01PM +, York Sun wrote:
> 
>> Tom and Wolfgang,
>>
>> Do we have guideline on dual licensing the code in U-Boot? If I collect
>> consent from all contributors and copyright holders to a particular
>> file, am I able to re-license the file? If yes, how to determine the
>> list of contributors?
> 
> In general, I think you would use 'git log' to see who contributed to a
> given file, and make sure that everyone who authored a change signed off
> on the license change.

Thanks.

> 
> With regards to dts files, this is another reason I would like to see
> that done as a strict re-sync with Linux rather than a stand-alone
> change.  Saying we're importing file X from the kernel at revision Y
> makes the license change pretty easy to spot and justify.
> 

For the dts files, they already exist in U-Boot. Can the team still say
"importing" from Linux? The files in U-Boot is only a small subset of
those in Linux.

York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Individual files dual licenses

2018-01-18 Thread Tom Rini
On Thu, Jan 18, 2018 at 05:25:01PM +, York Sun wrote:

> Tom and Wolfgang,
> 
> Do we have guideline on dual licensing the code in U-Boot? If I collect
> consent from all contributors and copyright holders to a particular
> file, am I able to re-license the file? If yes, how to determine the
> list of contributors?

In general, I think you would use 'git log' to see who contributed to a
given file, and make sure that everyone who authored a change signed off
on the license change.

With regards to dts files, this is another reason I would like to see
that done as a strict re-sync with Linux rather than a stand-alone
change.  Saying we're importing file X from the kernel at revision Y
makes the license change pretty easy to spot and justify.

-- 
Tom


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