On Sun, Dec 21, 2014 at 06:50:00PM -0500, Jason Cooper wrote:
> On Fri, Dec 19, 2014 at 07:16:16PM +0100, Simon Guinot wrote:
> > On Fri, Dec 19, 2014 at 12:43:00PM -0500, Jason Cooper wrote:
> > > On Fri, Dec 19, 2014 at 06:11:56PM +0100, Gregory CLEMENT wrote:
> > > > On 19/12/2014 18:03, Jason Cooper wrote:
> > > > > On Fri, Dec 19, 2014 at 05:09:16PM +0100, Gregory CLEMENT wrote:
> > > > >> On 19/12/2014 17:02, Jason Cooper wrote:
> > > > >>> On Fri, Dec 19, 2014 at 03:36:13PM +0100, Gregory CLEMENT wrote:
> > > > >>>> On 18/12/2014 20:15, Jason Cooper wrote:
> > > > >>>>> On Thu, Dec 18, 2014 at 06:15:40PM +0100, Gregory CLEMENT wrote:
> > > > >>>>> ...
> > > > >>>>>> Jason at the end it seems you didn't ack or nack the patches were you
> > > > >>>>>> were CC. You expressed some concerns about the GPLv2+ move but I don't know
> > > > >>>>>> if it is something that prevents you to give your acked-by.
> > > > >>>>>
> > > > >>>>> Oops. :) I figured my S-o-B when applying would be sufficient. That
> > > > >>>>> decision was before we decided on Andrew applying patches this time
> > > > >>>>> around...
> > > > >>>>>
> > > > >>>>> For all my dts{i} contributions:
> > > > >>>>>
> > > > >>>>> Acked-by: Jason Cooper <[email protected]>
> > > > >>>>
> > > > >>>> Thanks :)
> > > > >>>>
> > > > >>>>>
> > > > >>>>> Due to all the merge commits over time and whatnot, it's probably best
> > > > >>>>> to put my Ack on all the patches in this series...
> > > > >>>>
> > > > >>>> OK no problem. By the way, I take care of collecting all the acked-by and
> > > > >>>> once it will be done I will either sent the updated patch set with all the
> > > > >>>> acked-by or maybe just I will create a branch to pull if it is easier to handle.
> > > > >>>
> > > > >>> Ok, that'll be up to Andrew.
> > > > >>>
> > > > >>> Once we have the last few stragglers, and assuming there are no more
> > > > >>> NAKs, here's what I'd like to do:
> > > > >>>
> > > > >>> Regrettably, we'll have to revert Simon's dts contributions. I say
> > > > >>
> > > > >> You missed the email he sent yesterday, finally Simon changed his mind
> > > > >> and gave his acked-by.
> > > > >
> > > > > Indeed, that was for the oneliner change in the armada-370-xp.dtsi file.
> > > > > I got a bit ahead of myself, but I'm looking towards kirkwood, orion5x,
> > > > > dove, which brings up:
> > > > >
> > > > > 18ba7e4fe51d ARM: Kirkwood: add DT support for d2 Network v2
> > > > > 2d4cd2cafaea ARM: Kirkwood: allow to use netxbig DTSI for d2net_v2 DTS
> > > > > a96cc303e42a ARM: mvebu: update the SATA compatible string for Armada 370/XP
> > > > > d3dde4df4483 ARM: Kirkwood: update Network Space Mini v2 description
> > > > > 98d4f2acb91a ARM: Kirkwood: DT board setup for CloudBox
> > > > > 4ea931e07d77 ARM: Kirkwood: fix ns2 gpios by converting to pinctrl
> > > > > 7f9871d9d30f ARM: kirkwood: DT board setup for Network Space Mini v2
> > > > > ca7d94524ab3 ARM: kirkwood: DT board setup for Network Space Lite v2
> > > > > ecee1e47ab42 ARM: kirkwood: DT board setup for Network Space v2 and parents
> > > > >
> > > >
> > > > OK I understand your concern now. About dove and kirkwood, did you notice that
> > > > some files didn't have any license?
> > >
> > > Yes.
> > >
> > > > Especially none of the dove files have a license.
> > >
> > > Yes, we'll cross that bridge when we get there. I suspect it then falls
> > > under the over-arching license of the project. Regardless, we'll still
> > > need Acks from all contributors.
> >
> > Hi Jason,
> >
> > What is the problem with keeping the LaCie DTS files under GPLv2+ only ?
>
> Converting armada-* to dual license is just a small part of the
> overarching effort to convert *all* the devicetree files to dual
> license. So, eventually, we'll be doing the same with kirkwood, dove
> and orion5x dts{i} files. Perhaps even during this merge window.
>
> In the long term, we're attempting to provide one neutral place [1] for
> the bootloaders and kernels to pull devicetrees from and contribute
> changes back to.
OK, let's see if I understand correctly.
If I don't agree with the GPLv2+/x11 relicensing, then support for
almost all the LaCie boards will be removed from the Linux kernel (maybe
during the next merge window) ? Is that correct ?
Since all the LaCie boards DTS are at least based on my work (except for
the Orion ED Mini v2), I think there is 12 files concerned here. See the
command output: grep -l lacie *.dts | wc -l.
The oldest of this boards have been supported by the Linux kernel since
the 2.6.32 release. Also some of this boards are still widely used...
You know, it is quite a statement you are sending here: The GPLv2+
licences are not good enough to get an ARM-based board supported by
the Linux kernel, while it has always been the case until now. Are all
the maintainers SoC, ARM SoC, ARM and Linux well aligned with that ?
Is there any way we can keep the LaCie DTS files licenced under GPLv2+
_and_ still distributed with the others. Anyone would be free to choose
to use them (or not), in respect of the licence terms.
Simon
> > In the long term, we're attempting to provide one neutral place [1] for
> > the bootloaders and kernels to pull devicetrees from and contribute
> > changes back to.
>
> OK, let's see if I understand correctly.
>
> If I don't agree with the GPLv2+/x11 relicensing, then support for
> almost all the LaCie boards will be removed from the Linux kernel (maybe
> during the next merge window) ? Is that correct ?
I would NAK such a removal.
Andrew
On Monday 22 December 2014 12:29:33 Simon Guinot wrote:
> On Sun, Dec 21, 2014 at 06:50:00PM -0500, Jason Cooper wrote:
> > On Fri, Dec 19, 2014 at 07:16:16PM +0100, Simon Guinot wrote:
> > > > > Especially none of the dove files have a license.
> > > >
> > > > Yes, we'll cross that bridge when we get there. I suspect it then falls
> > > > under the over-arching license of the project. Regardless, we'll still
> > > > need Acks from all contributors.
> > >
> > > Hi Jason,
> > >
> > > What is the problem with keeping the LaCie DTS files under GPLv2+ only ?
> >
> > Converting armada-* to dual license is just a small part of the
> > overarching effort to convert *all* the devicetree files to dual
> > license. So, eventually, we'll be doing the same with kirkwood, dove
> > and orion5x dts{i} files. Perhaps even during this merge window.
> >
> > In the long term, we're attempting to provide one neutral place [1] for
> > the bootloaders and kernels to pull devicetrees from and contribute
> > changes back to.
>
> OK, let's see if I understand correctly.
>
> If I don't agree with the GPLv2+/x11 relicensing, then support for
> almost all the LaCie boards will be removed from the Linux kernel (maybe
> during the next merge window) ? Is that correct ?
Definitely not during the next merge window. Eventually the plan is
to remove *all* dts files from the kernel, but we're a long way
away from that.
There is already a mirror of the dts files at
http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=summary
which is hosting files that are meant to be shared with Xen, which is
also under the GPL, and supports a lot of the same hardware that Linux
supports, but also depends on passing the correct (modified) dtb blobs
to the Dom0 kernel.
The current setup works ok for Xen, but occasionally there are requests
for having the files shared more broadly, e.g. with FreeBSD and with boot
loaders that might be non-GPL but are used to boot Linux and that want
to ship with a default dtb for a platform they run on.
> Since all the LaCie boards DTS are at least based on my work (except for
> the Orion ED Mini v2), I think there is 12 files concerned here. See the
> command output: grep -l lacie *.dts | wc -l.
>
> The oldest of this boards have been supported by the Linux kernel since
> the 2.6.32 release. Also some of this boards are still widely used...
>
> You know, it is quite a statement you are sending here: The GPLv2+
> licences are not good enough to get an ARM-based board supported by
> the Linux kernel, while it has always been the case until now. Are all
> the maintainers SoC, ARM SoC, ARM and Linux well aligned with that ?
I think you just misunderstood.
> Is there any way we can keep the LaCie DTS files licenced under GPLv2+
> _and_ still distributed with the others. Anyone would be free to choose
> to use them (or not), in respect of the licence terms.
What I suspect will happen is that we end up with multiple repositories
for dts files, e.g. one that contains all files that are GPL-compatible
and another one that contains the subset that is licensed under more
permissive licenses such as the X11 or some BSD license. I don't see
a reason for Linux to stop supporting the former, but it would be nice
to have a larger shared subset.
Arnd
On Mon, Dec 22, 2014 at 10:14:32PM +0100, Arnd Bergmann wrote:
> On Monday 22 December 2014 12:29:33 Simon Guinot wrote:
> > On Sun, Dec 21, 2014 at 06:50:00PM -0500, Jason Cooper wrote:
> > > On Fri, Dec 19, 2014 at 07:16:16PM +0100, Simon Guinot wrote:
> > > > > > Especially none of the dove files have a license.
> > > > >
> > > > > Yes, we'll cross that bridge when we get there. I suspect it then falls
> > > > > under the over-arching license of the project. Regardless, we'll still
> > > > > need Acks from all contributors.
> > > >
> > > > Hi Jason,
> > > >
> > > > What is the problem with keeping the LaCie DTS files under GPLv2+ only ?
> > >
> > > Converting armada-* to dual license is just a small part of the
> > > overarching effort to convert *all* the devicetree files to dual
> > > license. So, eventually, we'll be doing the same with kirkwood, dove
> > > and orion5x dts{i} files. Perhaps even during this merge window.
> > >
> > > In the long term, we're attempting to provide one neutral place [1] for
> > > the bootloaders and kernels to pull devicetrees from and contribute
> > > changes back to.
> >
> > OK, let's see if I understand correctly.
> >
> > If I don't agree with the GPLv2+/x11 relicensing, then support for
> > almost all the LaCie boards will be removed from the Linux kernel (maybe
> > during the next merge window) ? Is that correct ?
>
> Definitely not during the next merge window. Eventually the plan is
> to remove *all* dts files from the kernel, but we're a long way
> away from that.
>
> There is already a mirror of the dts files at
> http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=summary
> which is hosting files that are meant to be shared with Xen, which is
> also under the GPL, and supports a lot of the same hardware that Linux
> supports, but also depends on passing the correct (modified) dtb blobs
> to the Dom0 kernel.
>
> The current setup works ok for Xen, but occasionally there are requests
> for having the files shared more broadly, e.g. with FreeBSD and with boot
> loaders that might be non-GPL but are used to boot Linux and that want
> to ship with a default dtb for a platform they run on.
Minus some details you just provided, that's what I understood in a
first place.
>
> > Since all the LaCie boards DTS are at least based on my work (except for
> > the Orion ED Mini v2), I think there is 12 files concerned here. See the
> > command output: grep -l lacie *.dts | wc -l.
> >
> > The oldest of this boards have been supported by the Linux kernel since
> > the 2.6.32 release. Also some of this boards are still widely used...
> >
> > You know, it is quite a statement you are sending here: The GPLv2+
> > licences are not good enough to get an ARM-based board supported by
> > the Linux kernel, while it has always been the case until now. Are all
> > the maintainers SoC, ARM SoC, ARM and Linux well aligned with that ?
>
> I think you just misunderstood.
Jason said:
"Regrettably, we'll have to revert Simon's dts contributions".
This words changed my understanding. Then, you confirm I don't have to
worry about that ?
>
> > Is there any way we can keep the LaCie DTS files licenced under GPLv2+
> > _and_ still distributed with the others. Anyone would be free to choose
> > to use them (or not), in respect of the licence terms.
>
> What I suspect will happen is that we end up with multiple repositories
> for dts files, e.g. one that contains all files that are GPL-compatible
> and another one that contains the subset that is licensed under more
> permissive licenses such as the X11 or some BSD license. I don't see
> a reason for Linux to stop supporting the former, but it would be nice
> to have a larger shared subset.
I think it would be indeed a good idea to have a repository with some
licence separations.
Thanks for the clarifications.
Simon
On Mon, Dec 22, 2014 at 12:29:33PM +0100, Simon Guinot wrote:
> On Sun, Dec 21, 2014 at 06:50:00PM -0500, Jason Cooper wrote:
> > On Fri, Dec 19, 2014 at 07:16:16PM +0100, Simon Guinot wrote:
> > > On Fri, Dec 19, 2014 at 12:43:00PM -0500, Jason Cooper wrote:
> > > > On Fri, Dec 19, 2014 at 06:11:56PM +0100, Gregory CLEMENT wrote:
> > > > > On 19/12/2014 18:03, Jason Cooper wrote:
> > > > > > On Fri, Dec 19, 2014 at 05:09:16PM +0100, Gregory CLEMENT wrote:
> > > > > >> On 19/12/2014 17:02, Jason Cooper wrote:
> > > > > >>> On Fri, Dec 19, 2014 at 03:36:13PM +0100, Gregory CLEMENT wrote:
> > > > > >>>> On 18/12/2014 20:15, Jason Cooper wrote:
> > > > > >>>>> On Thu, Dec 18, 2014 at 06:15:40PM +0100, Gregory CLEMENT wrote:
> > > > > >>>>> ...
> > > > > >>>>>> Jason at the end it seems you didn't ack or nack the patches were you
> > > > > >>>>>> were CC. You expressed some concerns about the GPLv2+ move but I don't know
> > > > > >>>>>> if it is something that prevents you to give your acked-by.
> > > > > >>>>>
> > > > > >>>>> Oops. :) I figured my S-o-B when applying would be sufficient. That
> > > > > >>>>> decision was before we decided on Andrew applying patches this time
> > > > > >>>>> around...
> > > > > >>>>>
> > > > > >>>>> For all my dts{i} contributions:
> > > > > >>>>>
> > > > > >>>>> Acked-by: Jason Cooper <[email protected]>
> > > > > >>>>
> > > > > >>>> Thanks :)
> > > > > >>>>
> > > > > >>>>>
> > > > > >>>>> Due to all the merge commits over time and whatnot, it's probably best
> > > > > >>>>> to put my Ack on all the patches in this series...
> > > > > >>>>
> > > > > >>>> OK no problem. By the way, I take care of collecting all the acked-by and
> > > > > >>>> once it will be done I will either sent the updated patch set with all the
> > > > > >>>> acked-by or maybe just I will create a branch to pull if it is easier to handle.
> > > > > >>>
> > > > > >>> Ok, that'll be up to Andrew.
> > > > > >>>
> > > > > >>> Once we have the last few stragglers, and assuming there are no more
> > > > > >>> NAKs, here's what I'd like to do:
> > > > > >>>
> > > > > >>> Regrettably, we'll have to revert Simon's dts contributions. I say
> > > > > >>
> > > > > >> You missed the email he sent yesterday, finally Simon changed his mind
> > > > > >> and gave his acked-by.
> > > > > >
> > > > > > Indeed, that was for the oneliner change in the armada-370-xp.dtsi file.
> > > > > > I got a bit ahead of myself, but I'm looking towards kirkwood, orion5x,
> > > > > > dove, which brings up:
> > > > > >
> > > > > > 18ba7e4fe51d ARM: Kirkwood: add DT support for d2 Network v2
> > > > > > 2d4cd2cafaea ARM: Kirkwood: allow to use netxbig DTSI for d2net_v2 DTS
> > > > > > a96cc303e42a ARM: mvebu: update the SATA compatible string for Armada 370/XP
> > > > > > d3dde4df4483 ARM: Kirkwood: update Network Space Mini v2 description
> > > > > > 98d4f2acb91a ARM: Kirkwood: DT board setup for CloudBox
> > > > > > 4ea931e07d77 ARM: Kirkwood: fix ns2 gpios by converting to pinctrl
> > > > > > 7f9871d9d30f ARM: kirkwood: DT board setup for Network Space Mini v2
> > > > > > ca7d94524ab3 ARM: kirkwood: DT board setup for Network Space Lite v2
> > > > > > ecee1e47ab42 ARM: kirkwood: DT board setup for Network Space v2 and parents
> > > > > >
> > > > >
> > > > > OK I understand your concern now. About dove and kirkwood, did you notice that
> > > > > some files didn't have any license?
> > > >
> > > > Yes.
> > > >
> > > > > Especially none of the dove files have a license.
> > > >
> > > > Yes, we'll cross that bridge when we get there. I suspect it then falls
> > > > under the over-arching license of the project. Regardless, we'll still
> > > > need Acks from all contributors.
> > >
> > > Hi Jason,
> > >
> > > What is the problem with keeping the LaCie DTS files under GPLv2+ only ?
> >
> > Converting armada-* to dual license is just a small part of the
> > overarching effort to convert *all* the devicetree files to dual
> > license. So, eventually, we'll be doing the same with kirkwood, dove
> > and orion5x dts{i} files. Perhaps even during this merge window.
> >
> > In the long term, we're attempting to provide one neutral place [1] for
> > the bootloaders and kernels to pull devicetrees from and contribute
> > changes back to.
>
> OK, let's see if I understand correctly.
>
> If I don't agree with the GPLv2+/x11 relicensing, then support for
> almost all the LaCie boards will be removed from the Linux kernel (maybe
> during the next merge window) ? Is that correct ?
No. Nothing will change wrt to the Linux kernel. In my mind, I've
always viewed arch/arm/boot/dts as a separate repo that happens to be
incubating in the Linux kernel tree. Right or wrong, I was referring to
the dts/dtsi/bindings eventually standing on their own. Looking back on
the conversation, I definitely worded it badly. I apologize for that.
> Is there any way we can keep the LaCie DTS files licenced under GPLv2+
> _and_ still distributed with the others. Anyone would be free to choose
> to use them (or not), in respect of the licence terms.
Yes, the difficulty lies in making that distribution *easy* for other
projects. They already have their own dts files, why would they adopt
our work if they have to pick through it?
I suspect the eventual solution (after the dts/bindings are their own
repo) will involve adopting the SPDX-* header tag, and then some
scripting to create separate git branches by license. That would allow
us to keep everything in the repo, make it easy to incorporate /
redistribute based on license, and hopefully reduce the maintenance
burden.
thx,
Jason.
On Tue, Dec 23, 2014 at 01:22:33PM +0100, Simon Guinot wrote:
> On Mon, Dec 22, 2014 at 10:14:32PM +0100, Arnd Bergmann wrote:
> > On Monday 22 December 2014 12:29:33 Simon Guinot wrote:
> > > On Sun, Dec 21, 2014 at 06:50:00PM -0500, Jason Cooper wrote:
> > > > On Fri, Dec 19, 2014 at 07:16:16PM +0100, Simon Guinot wrote:
> > > > > > > Especially none of the dove files have a license.
> > > > > >
> > > > > > Yes, we'll cross that bridge when we get there. I suspect it then falls
> > > > > > under the over-arching license of the project. Regardless, we'll still
> > > > > > need Acks from all contributors.
> > > > >
> > > > > Hi Jason,
> > > > >
> > > > > What is the problem with keeping the LaCie DTS files under GPLv2+ only ?
> > > >
> > > > Converting armada-* to dual license is just a small part of the
> > > > overarching effort to convert *all* the devicetree files to dual
> > > > license. So, eventually, we'll be doing the same with kirkwood, dove
> > > > and orion5x dts{i} files. Perhaps even during this merge window.
> > > >
> > > > In the long term, we're attempting to provide one neutral place [1] for
> > > > the bootloaders and kernels to pull devicetrees from and contribute
> > > > changes back to.
> > >
> > > OK, let's see if I understand correctly.
> > >
> > > If I don't agree with the GPLv2+/x11 relicensing, then support for
> > > almost all the LaCie boards will be removed from the Linux kernel (maybe
> > > during the next merge window) ? Is that correct ?
> >
> > Definitely not during the next merge window. Eventually the plan is
> > to remove *all* dts files from the kernel, but we're a long way
> > away from that.
> >
> > There is already a mirror of the dts files at
> > http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=summary
> > which is hosting files that are meant to be shared with Xen, which is
> > also under the GPL, and supports a lot of the same hardware that Linux
> > supports, but also depends on passing the correct (modified) dtb blobs
> > to the Dom0 kernel.
> >
> > The current setup works ok for Xen, but occasionally there are requests
> > for having the files shared more broadly, e.g. with FreeBSD and with boot
> > loaders that might be non-GPL but are used to boot Linux and that want
> > to ship with a default dtb for a platform they run on.
>
> Minus some details you just provided, that's what I understood in a
> first place.
>
> >
> > > Since all the LaCie boards DTS are at least based on my work (except for
> > > the Orion ED Mini v2), I think there is 12 files concerned here. See the
> > > command output: grep -l lacie *.dts | wc -l.
> > >
> > > The oldest of this boards have been supported by the Linux kernel since
> > > the 2.6.32 release. Also some of this boards are still widely used...
> > >
> > > You know, it is quite a statement you are sending here: The GPLv2+
> > > licences are not good enough to get an ARM-based board supported by
> > > the Linux kernel, while it has always been the case until now. Are all
> > > the maintainers SoC, ARM SoC, ARM and Linux well aligned with that ?
> >
> > I think you just misunderstood.
>
> Jason said:
>
> "Regrettably, we'll have to revert Simon's dts contributions".
>
> This words changed my understanding. Then, you confirm I don't have to
> worry about that ?
Yup. To be clear, this is the part I worded badly. :-/ In my mind, I
was looking at the separate devicetree repo that could be shared
broadly. *Not* the Linux kernel repo.
> > > Is there any way we can keep the LaCie DTS files licenced under GPLv2+
> > > _and_ still distributed with the others. Anyone would be free to choose
> > > to use them (or not), in respect of the licence terms.
> >
> > What I suspect will happen is that we end up with multiple repositories
> > for dts files, e.g. one that contains all files that are GPL-compatible
> > and another one that contains the subset that is licensed under more
> > permissive licenses such as the X11 or some BSD license. I don't see
> > a reason for Linux to stop supporting the former, but it would be nice
> > to have a larger shared subset.
>
> I think it would be indeed a good idea to have a repository with some
> licence separations.
>
> Thanks for the clarifications.
Thanks for sticking with a difficult conversation. Let me know what you
think of the idea I proposed in my other email.
thx,
Jason.