[U-Boot] Individual files dual licenses
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?
York
On Thu, Jan 18, 2018 at 05:25:01PM +0000, 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.
On 01/18/2018 09:59 AM, Tom Rini wrote:
On Thu, Jan 18, 2018 at 05:25:01PM +0000, 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
On Thu, Jan 18, 2018 at 06:02:44PM +0000, York Sun wrote:
On 01/18/2018 09:59 AM, Tom Rini wrote:
On Thu, Jan 18, 2018 at 05:25:01PM +0000, 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.
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
On Thu, Jan 18, 2018 at 06:09:22PM +0000, 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?
On 01/18/2018 10:11 AM, Tom Rini wrote:
On Thu, Jan 18, 2018 at 06:09:22PM +0000, 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
On Thu, Jan 18, 2018 at 06:14:07PM +0000, York Sun wrote:
On 01/18/2018 10:11 AM, Tom Rini wrote:
On Thu, Jan 18, 2018 at 06:09:22PM +0000, 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!
On 01/18/2018 11:17 AM, Tom Rini wrote:
On Thu, Jan 18, 2018 at 06:14:07PM +0000, York Sun wrote:
On 01/18/2018 10:11 AM, Tom Rini wrote:
On Thu, Jan 18, 2018 at 06:09:22PM +0000, 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
participants (2)
-
Tom Rini -
York Sun