Describe the compatible properties for the Cisco CrayAR SoC.
Cc: [email protected]
Cc: Marcin Wierzbicki <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Rob Herring <[email protected]>
Signed-off-by: Daniel Walker <[email protected]>
---
.../devicetree/bindings/arm/cisco/crayar.yaml | 27 +++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/cisco/crayar.yaml
diff --git a/Documentation/devicetree/bindings/arm/cisco/crayar.yaml b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
new file mode 100644
index 000000000000..0ee4e6313ab0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/cisco/crayar.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cisco CrayAR based Platforms
+
+maintainers:
+ - [email protected]
+
+description:
+ Cisco CrayAR boards with CrayAR SOC
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Cisco CrayAR Argos evaluation board
+ items:
+ - const: cisco,crayar-argos
+ - const: cisco,crayar
+
+additionalProperties: true
+
+...
--
2.25.1
On 06/04/2023 00:30, Daniel Walker wrote:
> Describe the compatible properties for the Cisco CrayAR SoC.
>
> Cc: [email protected]
> Cc: Marcin Wierzbicki <[email protected]>
> Cc: Krzysztof Kozlowski <[email protected]>
> Cc: Rob Herring <[email protected]>
Please drop the autogenerated scripts/get_maintainer.pl CC-entries from
commit msg. There is no single need to store automated output of
get_maintainers.pl in the git log. It can be easily re-created at any
given time, thus its presence in the git history is redundant and
obfuscates the log.
If you need it for your own patch management purposes, keep it under the
--- separator.
> Signed-off-by: Daniel Walker <[email protected]>
> ---
> .../devicetree/bindings/arm/cisco/crayar.yaml | 27 +++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/cisco/crayar.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/cisco/crayar.yaml b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
> new file mode 100644
> index 000000000000..0ee4e6313ab0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
How many (or not many) platforms do you expect from Cisco? We mostly
have one file per SoC manufacturer.
> @@ -0,0 +1,27 @@
> +# SPDX-License-Identifier: GPL-2.0-only
Dual license.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/cisco/crayar.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cisco CrayAR based Platforms
> +
Best regards,
Krzysztof
On Thu, Apr 06, 2023 at 09:12:34AM +0200, Krzysztof Kozlowski wrote:
> On 06/04/2023 00:30, Daniel Walker wrote:
> > Describe the compatible properties for the Cisco CrayAR SoC.
> >
> > Cc: [email protected]
> > Cc: Marcin Wierzbicki <[email protected]>
> > Cc: Krzysztof Kozlowski <[email protected]>
> > Cc: Rob Herring <[email protected]>
>
> Please drop the autogenerated scripts/get_maintainer.pl CC-entries from
> commit msg. There is no single need to store automated output of
> get_maintainers.pl in the git log. It can be easily re-created at any
> given time, thus its presence in the git history is redundant and
> obfuscates the log.
>
> If you need it for your own patch management purposes, keep it under the
> --- separator.
I added these, so it's not script output. I can move them under the separator.
The reason for that was to make sure people who commented get Cc'd.
> > Signed-off-by: Daniel Walker <[email protected]>
> > ---
> > .../devicetree/bindings/arm/cisco/crayar.yaml | 27 +++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/cisco/crayar.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/cisco/crayar.yaml b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
> > new file mode 100644
> > index 000000000000..0ee4e6313ab0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
>
> How many (or not many) platforms do you expect from Cisco? We mostly
> have one file per SoC manufacturer.
We have two SoC's one called CrayAR and another called Craw. I've submitted the
Craw dts file before , but I've not resubmitted it. Under Craw I think we have
at least two, but more likely five variations. CrayAR we have one variation with
at least one more planned.
So we would plan over time to add two dtsi files and three to four dts files to
this directory. Then more over time.
Daniel
On 06/04/2023 17:15, Daniel Walker (danielwa) wrote:
> On Thu, Apr 06, 2023 at 09:12:34AM +0200, Krzysztof Kozlowski wrote:
>> On 06/04/2023 00:30, Daniel Walker wrote:
>>> Describe the compatible properties for the Cisco CrayAR SoC.
>>>
>>> Cc: [email protected]
>>> Cc: Marcin Wierzbicki <[email protected]>
>>> Cc: Krzysztof Kozlowski <[email protected]>
>>> Cc: Rob Herring <[email protected]>
>>
>> Please drop the autogenerated scripts/get_maintainer.pl CC-entries from
>> commit msg. There is no single need to store automated output of
>> get_maintainers.pl in the git log. It can be easily re-created at any
>> given time, thus its presence in the git history is redundant and
>> obfuscates the log.
>>
>> If you need it for your own patch management purposes, keep it under the
>> --- separator.
>
> I added these, so it's not script output. I can move them under the separator.
> The reason for that was to make sure people who commented get Cc'd.
So read my message again. There is no reason to add these entries for
people who are listed as maintainers, because you are supposed to CC
maintainers always.
>
>>> Signed-off-by: Daniel Walker <[email protected]>
>>> ---
>>> .../devicetree/bindings/arm/cisco/crayar.yaml | 27 +++++++++++++++++++
>>> 1 file changed, 27 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/arm/cisco/crayar.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/cisco/crayar.yaml b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
>>> new file mode 100644
>>> index 000000000000..0ee4e6313ab0
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
>>
>> How many (or not many) platforms do you expect from Cisco? We mostly
>> have one file per SoC manufacturer.
>
> We have two SoC's one called CrayAR and another called Craw. I've submitted the
> Craw dts file before , but I've not resubmitted it. Under Craw I think we have
> at least two, but more likely five variations. CrayAR we have one variation with
> at least one more planned.
>
> So we would plan over time to add two dtsi files and three to four dts files to
> this directory. Then more over time.
So just keep them in one file maybe.
Best regards,
Krzysztof
On Thu, Apr 06, 2023 at 06:50:53PM +0200, Krzysztof Kozlowski wrote:
> On 06/04/2023 17:15, Daniel Walker (danielwa) wrote:
> > On Thu, Apr 06, 2023 at 09:12:34AM +0200, Krzysztof Kozlowski wrote:
> >> On 06/04/2023 00:30, Daniel Walker wrote:
> >>> Describe the compatible properties for the Cisco CrayAR SoC.
> >>>
> >>> Cc: [email protected]
> >>> Cc: Marcin Wierzbicki <[email protected]>
> >>> Cc: Krzysztof Kozlowski <[email protected]>
> >>> Cc: Rob Herring <[email protected]>
> >>
> >> Please drop the autogenerated scripts/get_maintainer.pl CC-entries from
> >> commit msg. There is no single need to store automated output of
> >> get_maintainers.pl in the git log. It can be easily re-created at any
> >> given time, thus its presence in the git history is redundant and
> >> obfuscates the log.
> >>
> >> If you need it for your own patch management purposes, keep it under the
> >> --- separator.
> >
> > I added these, so it's not script output. I can move them under the separator.
> > The reason for that was to make sure people who commented get Cc'd.
>
> So read my message again. There is no reason to add these entries for
> people who are listed as maintainers, because you are supposed to CC
> maintainers always.
Maintainers change over time.. I'd rather not have to keep track of who the
maintainers are at any given time.
I won't delete this, but I offered to move it under the separator.
> >
> >>> Signed-off-by: Daniel Walker <[email protected]>
> >>> ---
> >>> .../devicetree/bindings/arm/cisco/crayar.yaml | 27 +++++++++++++++++++
> >>> 1 file changed, 27 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/arm/cisco/crayar.yaml
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/arm/cisco/crayar.yaml b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
> >>> new file mode 100644
> >>> index 000000000000..0ee4e6313ab0
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
> >>
> >> How many (or not many) platforms do you expect from Cisco? We mostly
> >> have one file per SoC manufacturer.
> >
> > We have two SoC's one called CrayAR and another called Craw. I've submitted the
> > Craw dts file before , but I've not resubmitted it. Under Craw I think we have
> > at least two, but more likely five variations. CrayAR we have one variation with
> > at least one more planned.
> >
> > So we would plan over time to add two dtsi files and three to four dts files to
> > this directory. Then more over time.
>
> So just keep them in one file maybe.
If/when I submit again with anther chip we can discuss it at that time.
Daniel
On 06/04/2023 20:32, Daniel Walker (danielwa) wrote:
>>>>> +++ b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
>>>>
>>>> How many (or not many) platforms do you expect from Cisco? We mostly
>>>> have one file per SoC manufacturer.
>>>
>>> We have two SoC's one called CrayAR and another called Craw. I've submitted the
>>> Craw dts file before , but I've not resubmitted it. Under Craw I think we have
>>> at least two, but more likely five variations. CrayAR we have one variation with
>>> at least one more planned.
>>>
>>> So we would plan over time to add two dtsi files and three to four dts files to
>>> this directory. Then more over time.
>>
>> So just keep them in one file maybe.
>
> If/when I submit again with anther chip we can discuss it at that time.
Or you can do it now.
Best regards,
Krzysztof
On Thu, Apr 06, 2023 at 08:56:06PM +0200, Krzysztof Kozlowski wrote:
> On 06/04/2023 20:32, Daniel Walker (danielwa) wrote:
> >>>>> +++ b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
> >>>>
> >>>> How many (or not many) platforms do you expect from Cisco? We mostly
> >>>> have one file per SoC manufacturer.
> >>>
> >>> We have two SoC's one called CrayAR and another called Craw. I've submitted the
> >>> Craw dts file before , but I've not resubmitted it. Under Craw I think we have
> >>> at least two, but more likely five variations. CrayAR we have one variation with
> >>> at least one more planned.
> >>>
> >>> So we would plan over time to add two dtsi files and three to four dts files to
> >>> this directory. Then more over time.
> >>
> >> So just keep them in one file maybe.
> >
> > If/when I submit again with anther chip we can discuss it at that time.
>
> Or you can do it now.
What do you want to talk about exactly ? You said keep everything in one file, doesn't this
already fit your suggestion ? I'm only submitting one file.
What are you envisioning Cisco to do ?
Daniel
On 06/04/2023 21:15, Daniel Walker (danielwa) wrote:
> On Thu, Apr 06, 2023 at 08:56:06PM +0200, Krzysztof Kozlowski wrote:
>> On 06/04/2023 20:32, Daniel Walker (danielwa) wrote:
>>>>>>> +++ b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
>>>>>>
>>>>>> How many (or not many) platforms do you expect from Cisco? We mostly
>>>>>> have one file per SoC manufacturer.
>>>>>
>>>>> We have two SoC's one called CrayAR and another called Craw. I've submitted the
>>>>> Craw dts file before , but I've not resubmitted it. Under Craw I think we have
>>>>> at least two, but more likely five variations. CrayAR we have one variation with
>>>>> at least one more planned.
>>>>>
>>>>> So we would plan over time to add two dtsi files and three to four dts files to
>>>>> this directory. Then more over time.
>>>>
>>>> So just keep them in one file maybe.
>>>
>>> If/when I submit again with anther chip we can discuss it at that time.
>>
>> Or you can do it now.
>
> What do you want to talk about exactly ? You said keep everything in one file, doesn't this
> already fit your suggestion ? I'm only submitting one file.
That is supposed to be one file named like: cisco.yaml
If you ever need to have separate maintainers, then split it.
Best regards,
Krzysztof
On Fri, Apr 07, 2023 at 08:51:12AM +0200, Krzysztof Kozlowski wrote:
> On 06/04/2023 21:15, Daniel Walker (danielwa) wrote:
> > On Thu, Apr 06, 2023 at 08:56:06PM +0200, Krzysztof Kozlowski wrote:
> >> On 06/04/2023 20:32, Daniel Walker (danielwa) wrote:
> >>>>>>> +++ b/Documentation/devicetree/bindings/arm/cisco/crayar.yaml
> >>>>>>
> >>>>>> How many (or not many) platforms do you expect from Cisco? We mostly
> >>>>>> have one file per SoC manufacturer.
> >>>>>
> >>>>> We have two SoC's one called CrayAR and another called Craw. I've submitted the
> >>>>> Craw dts file before , but I've not resubmitted it. Under Craw I think we have
> >>>>> at least two, but more likely five variations. CrayAR we have one variation with
> >>>>> at least one more planned.
> >>>>>
> >>>>> So we would plan over time to add two dtsi files and three to four dts files to
> >>>>> this directory. Then more over time.
> >>>>
> >>>> So just keep them in one file maybe.
> >>>
> >>> If/when I submit again with anther chip we can discuss it at that time.
> >>
> >> Or you can do it now.
> >
> > What do you want to talk about exactly ? You said keep everything in one file, doesn't this
> > already fit your suggestion ? I'm only submitting one file.
>
> That is supposed to be one file named like: cisco.yaml
> If you ever need to have separate maintainers, then split it.
Ok.
Daniel
On Thu, Apr 06, 2023 at 09:12:34AM +0200, Krzysztof Kozlowski wrote:
> > @@ -0,0 +1,27 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
>
> Dual license.
>
What are my choices here? I see this,
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Which appears to be what your suggesting. I also see this,
# SPDX-License-Identifier: GPL-2.0
I'd rather use the later.
Daniel
On 07/04/2023 18:04, Daniel Walker (danielwa) wrote:
> On Thu, Apr 06, 2023 at 09:12:34AM +0200, Krzysztof Kozlowski wrote:
>>> @@ -0,0 +1,27 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only
>>
>> Dual license.
>>
>
> What are my choices here? I see this,
>
> # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Yes, the one suggested by the checkpatch. Did you run it?
>
> Which appears to be what your suggesting. I also see this,
>
> # SPDX-License-Identifier: GPL-2.0
>
> I'd rather use the later.
Why? Bindings should be licensed under BSD, so what is the reason to
make here exception?
Best regards,
Krzysztof
On Mon, Apr 10, 2023 at 05:28:03PM +0200, Krzysztof Kozlowski wrote:
> On 07/04/2023 18:04, Daniel Walker (danielwa) wrote:
> > On Thu, Apr 06, 2023 at 09:12:34AM +0200, Krzysztof Kozlowski wrote:
> >>> @@ -0,0 +1,27 @@
> >>> +# SPDX-License-Identifier: GPL-2.0-only
> >>
> >> Dual license.
> >>
> >
> > What are my choices here? I see this,
> >
> > # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>
> Yes, the one suggested by the checkpatch. Did you run it?
I don't recall if I did or not.
> >
> > Which appears to be what your suggesting. I also see this,
> >
> > # SPDX-License-Identifier: GPL-2.0
> >
> > I'd rather use the later.
>
> Why? Bindings should be licensed under BSD, so what is the reason to
> make here exception?
I'm sure I can re-license my submissions. I'd have to look into it.
Dainel
On Mon, Apr 10, 2023 at 05:09:15PM +0000, Daniel Walker (danielwa) wrote:
> On Mon, Apr 10, 2023 at 05:28:03PM +0200, Krzysztof Kozlowski wrote:
> > On 07/04/2023 18:04, Daniel Walker (danielwa) wrote:
> > > On Thu, Apr 06, 2023 at 09:12:34AM +0200, Krzysztof Kozlowski wrote:
> > >>> @@ -0,0 +1,27 @@
> > >>> +# SPDX-License-Identifier: GPL-2.0-only
> > >>
> > >> Dual license.
> > >>
> > >
> > > What are my choices here? I see this,
> > >
> > > # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >
> > Yes, the one suggested by the checkpatch. Did you run it?
>
> I don't recall if I did or not.
>
> > >
> > > Which appears to be what your suggesting. I also see this,
> > >
> > > # SPDX-License-Identifier: GPL-2.0
> > >
> > > I'd rather use the later.
> >
> > Why? Bindings should be licensed under BSD, so what is the reason to
> > make here exception?
>
> I'm sure I can re-license my submissions. I'd have to look into it.
I'm _not_ sure.
On 10/04/2023 19:51, Daniel Walker (danielwa) wrote:
> On Mon, Apr 10, 2023 at 05:09:15PM +0000, Daniel Walker (danielwa) wrote:
>> On Mon, Apr 10, 2023 at 05:28:03PM +0200, Krzysztof Kozlowski wrote:
>>> On 07/04/2023 18:04, Daniel Walker (danielwa) wrote:
>>>> On Thu, Apr 06, 2023 at 09:12:34AM +0200, Krzysztof Kozlowski wrote:
>>>>>> @@ -0,0 +1,27 @@
>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>
>>>>> Dual license.
>>>>>
>>>>
>>>> What are my choices here? I see this,
>>>>
>>>> # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>
>>> Yes, the one suggested by the checkpatch. Did you run it?
>>
>> I don't recall if I did or not.
>>
>>>>
>>>> Which appears to be what your suggesting. I also see this,
>>>>
>>>> # SPDX-License-Identifier: GPL-2.0
>>>>
>>>> I'd rather use the later.
>>>
>>> Why? Bindings should be licensed under BSD, so what is the reason to
>>> make here exception?
>>
>> I'm sure I can re-license my submissions. I'd have to look into it.
>
> I'm _not_ sure.
This is a new file - it did not exist in v1 - thus you had to write it.
If you wrote it, you (or your employer) hold all copyrights, so yes, you
(or your employer) can relicense it.
I cannot imagine the case why employer would not like to have dual
license here (it's beneficial to him, so employer would be acting
against himself), but if you need to convince him, you can just say,
that contributing to Open Source project means accepting the licenses in
that project. The license for new bindings in this project is (GPL-2.0
or BSD-2), like pointed by checkpatch.
Best regards,
Krzysztof
On Wed, Apr 05, 2023 at 03:30:27PM -0700, Daniel Walker wrote:
> Describe the compatible properties for the Cisco CrayAR SoC.
>
> Cc: [email protected]
> Cc: Marcin Wierzbicki <[email protected]>
> Cc: Krzysztof Kozlowski <[email protected]>
> Cc: Rob Herring <[email protected]>
> Signed-off-by: Daniel Walker <[email protected]>
checkpatch.pl complains that the author and Sob emails don't match.
On Wed, Apr 12, 2023 at 08:50:50AM -0500, Rob Herring wrote:
> On Wed, Apr 05, 2023 at 03:30:27PM -0700, Daniel Walker wrote:
> > Describe the compatible properties for the Cisco CrayAR SoC.
> >
> > Cc: [email protected]
> > Cc: Marcin Wierzbicki <[email protected]>
> > Cc: Krzysztof Kozlowski <[email protected]>
> > Cc: Rob Herring <[email protected]>
> > Signed-off-by: Daniel Walker <[email protected]>
>
> checkpatch.pl complains that the author and Sob emails don't match.
I'll address it , assuming I send another series.
Daniel
On Wed, Apr 12, 2023 at 09:24:48AM +0200, Krzysztof Kozlowski wrote:
> On 10/04/2023 19:51, Daniel Walker (danielwa) wrote:
> > On Mon, Apr 10, 2023 at 05:09:15PM +0000, Daniel Walker (danielwa) wrote:
> >> On Mon, Apr 10, 2023 at 05:28:03PM +0200, Krzysztof Kozlowski wrote:
> >>> On 07/04/2023 18:04, Daniel Walker (danielwa) wrote:
> >>>> On Thu, Apr 06, 2023 at 09:12:34AM +0200, Krzysztof Kozlowski wrote:
> >>>>>> @@ -0,0 +1,27 @@
> >>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>
> >>>>> Dual license.
> >>>>>
> >>>>
> >>>> What are my choices here? I see this,
> >>>>
> >>>> # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>>
> >>> Yes, the one suggested by the checkpatch. Did you run it?
> >>
> >> I don't recall if I did or not.
> >>
> >>>>
> >>>> Which appears to be what your suggesting. I also see this,
> >>>>
> >>>> # SPDX-License-Identifier: GPL-2.0
> >>>>
> >>>> I'd rather use the later.
> >>>
> >>> Why? Bindings should be licensed under BSD, so what is the reason to
> >>> make here exception?
> >>
> >> I'm sure I can re-license my submissions. I'd have to look into it.
> >
> > I'm _not_ sure.
>
>
> This is a new file - it did not exist in v1 - thus you had to write it.
> If you wrote it, you (or your employer) hold all copyrights, so yes, you
> (or your employer) can relicense it.
>
> I cannot imagine the case why employer would not like to have dual
> license here (it's beneficial to him, so employer would be acting
> against himself), but if you need to convince him, you can just say,
> that contributing to Open Source project means accepting the licenses in
> that project. The license for new bindings in this project is (GPL-2.0
> or BSD-2), like pointed by checkpatch.
Yes, my employer holds the copyright. However, corporations don't work in the way
you imagine. There is no one "owner" to speak to about re-licensing. The people
who determine the license is an army of lawyers, with an extensive approval
process.
What benefit does a BSD license hold for my employer over GPL v2 ?
Here the licenses currently used by the bindings,
1 # SPDX-License-Identifier: BSD-2-Clause
1 # SPDX-License-Identifier: (GPL-2.0-only)
1 # SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
1 # SPDX-License-Identifier: (GPL-2.0-or-later)
3 # SPDX-License-Identifier: (GPL-2.0+ OR X11)
4 # SPDX-License-Identifier: GPL-2.0-or-later
4 # SPDX-License-Identifier: (GPL-2.0 OR MIT)
6 # SPDX-License-Identifier: (GPL-2.0)
7 # SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
7 # SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
11 # SPDX-License-Identifier: GPL-2.0+
12 # SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
12 # SPDX-License-Identifier: (GPL-2.0+ OR MIT)
33 # SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
47 # SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
56 # SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
102 # SPDX-License-Identifier: GPL-2.0-only
350 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
511 # SPDX-License-Identifier: GPL-2.0
610 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
1570 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Can you explain why so many are allowed to use GPL v2 , but my company is not
allowed? Shouldn't these all be dual licensed if the project only allows dual
license?
It's very likely that new bindings will be made by making a copy of other
bindings, then make modifications. If my company copied bindings which are GPL
v2, then we are required to honor the license of the prior binding
and that means we legally aren't allowed to relicense under BSD AFAIK.
Also the documentation for the bindings here Documentation/devicetree/
changesets.rst
dynamic-resolution-notes.rst
index.rst
kernel-api.rst
of_unittest.rst
overlay-notes.rst
usage-model.rst
all the rst files are GPL v2 and not dual license.
Daniel
On 12/04/2023 17:04, Daniel Walker (danielwa) wrote:
> On Wed, Apr 12, 2023 at 09:24:48AM +0200, Krzysztof Kozlowski wrote:
>> On 10/04/2023 19:51, Daniel Walker (danielwa) wrote:
>>> On Mon, Apr 10, 2023 at 05:09:15PM +0000, Daniel Walker (danielwa) wrote:
>>>> On Mon, Apr 10, 2023 at 05:28:03PM +0200, Krzysztof Kozlowski wrote:
>>>>> On 07/04/2023 18:04, Daniel Walker (danielwa) wrote:
>>>>>> On Thu, Apr 06, 2023 at 09:12:34AM +0200, Krzysztof Kozlowski wrote:
>>>>>>>> @@ -0,0 +1,27 @@
>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>
>>>>>>> Dual license.
>>>>>>>
>>>>>>
>>>>>> What are my choices here? I see this,
>>>>>>
>>>>>> # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>
>>>>> Yes, the one suggested by the checkpatch. Did you run it?
>>>>
>>>> I don't recall if I did or not.
>>>>
>>>>>>
>>>>>> Which appears to be what your suggesting. I also see this,
>>>>>>
>>>>>> # SPDX-License-Identifier: GPL-2.0
>>>>>>
>>>>>> I'd rather use the later.
>>>>>
>>>>> Why? Bindings should be licensed under BSD, so what is the reason to
>>>>> make here exception?
>>>>
>>>> I'm sure I can re-license my submissions. I'd have to look into it.
>>>
>>> I'm _not_ sure.
>>
>>
>> This is a new file - it did not exist in v1 - thus you had to write it.
>> If you wrote it, you (or your employer) hold all copyrights, so yes, you
>> (or your employer) can relicense it.
>>
>> I cannot imagine the case why employer would not like to have dual
>> license here (it's beneficial to him, so employer would be acting
>> against himself), but if you need to convince him, you can just say,
>> that contributing to Open Source project means accepting the licenses in
>> that project. The license for new bindings in this project is (GPL-2.0
>> or BSD-2), like pointed by checkpatch.
>
>
> Yes, my employer holds the copyright. However, corporations don't work in the way
> you imagine. There is no one "owner" to speak to about re-licensing. The people
> who determine the license is an army of lawyers, with an extensive approval
> process.
Yes, I understand this. But also how corporations work should not really
be my problem. Especially that many of them were able to relicense even
existing work, not mentioning new work. New work is piece of cake
comparing with army of lawyers for existing, released work! Yet they
could...
>
> What benefit does a BSD license hold for my employer over GPL v2 ?
As BSD is permissive, it does not force the employer or its customer to
release the derived works to customers. GPL requires it (simplifying
now). The employer and its customer have now choice. Dual license gives
more choices. More choices is beneficial for the company or its
customers, isn't?
>
> Here the licenses currently used by the bindings,
>
> 1 # SPDX-License-Identifier: BSD-2-Clause
> 1 # SPDX-License-Identifier: (GPL-2.0-only)
> 1 # SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
> 1 # SPDX-License-Identifier: (GPL-2.0-or-later)
> 3 # SPDX-License-Identifier: (GPL-2.0+ OR X11)
> 4 # SPDX-License-Identifier: GPL-2.0-or-later
> 4 # SPDX-License-Identifier: (GPL-2.0 OR MIT)
> 6 # SPDX-License-Identifier: (GPL-2.0)
> 7 # SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> 7 # SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
> 11 # SPDX-License-Identifier: GPL-2.0+
> 12 # SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
> 12 # SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> 33 # SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> 47 # SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
> 56 # SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> 102 # SPDX-License-Identifier: GPL-2.0-only
> 350 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> 511 # SPDX-License-Identifier: GPL-2.0
> 610 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> 1570 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>
> Can you explain why so many are allowed to use GPL v2 , but my company is not
> allowed? Shouldn't these all be dual licensed if the project only allows dual
> license?
The rule is for new bindings. All new bindings are forced to follow this
rule. Why do you think we treat Cisco special? Who else was allowed? Can
we be specific?
Linking here existing bindings is not really an argument. What does it
prove?
>
> It's very likely that new bindings will be made by making a copy of other
> bindings, then make modifications. If my company copied bindings which are GPL
> v2, then we are required to honor the license of the prior binding
> and that means we legally aren't allowed to relicense under BSD AFAIK.
So copy some bindings which are dual-licensed... Since this is new work,
you can do it.
>
> Also the documentation for the bindings here Documentation/devicetree/
>
> changesets.rst
> dynamic-resolution-notes.rst
> index.rst
> kernel-api.rst
> of_unittest.rst
> overlay-notes.rst
> usage-model.rst
>
> all the rst files are GPL v2 and not dual license.
These are not bindings, so I do not understand your argument. What do
you prove? That non-bindings do not have to use bindings rules? Yes,
they are not bindings...
Anyway, I feel like we are making some useless circles and wasting quite
a lot of energy on trivial rule. I tried to explain it, but if you do
not like it - it's your choice. It will be a NAK.
Best regards,
Krzysztof
On Wed, Apr 12, 2023 at 06:13:57PM +0200, Krzysztof Kozlowski wrote:
> On 12/04/2023 17:04, Daniel Walker (danielwa) wrote:
> > On Wed, Apr 12, 2023 at 09:24:48AM +0200, Krzysztof Kozlowski wrote:
> >> On 10/04/2023 19:51, Daniel Walker (danielwa) wrote:
> >>> On Mon, Apr 10, 2023 at 05:09:15PM +0000, Daniel Walker (danielwa) wrote:
> >>>> On Mon, Apr 10, 2023 at 05:28:03PM +0200, Krzysztof Kozlowski wrote:
> >>>>> On 07/04/2023 18:04, Daniel Walker (danielwa) wrote:
> >>>>>> On Thu, Apr 06, 2023 at 09:12:34AM +0200, Krzysztof Kozlowski wrote:
> >>>>>>>> @@ -0,0 +1,27 @@
> >>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>>
> >>>>>>> Dual license.
> >>>>>>>
> >>>>>>
> >>>>>> What are my choices here? I see this,
> >>>>>>
> >>>>>> # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>>>>
> >>>>> Yes, the one suggested by the checkpatch. Did you run it?
> >>>>
> >>>> I don't recall if I did or not.
> >>>>
> >>>>>>
> >>>>>> Which appears to be what your suggesting. I also see this,
> >>>>>>
> >>>>>> # SPDX-License-Identifier: GPL-2.0
> >>>>>>
> >>>>>> I'd rather use the later.
> >>>>>
> >>>>> Why? Bindings should be licensed under BSD, so what is the reason to
> >>>>> make here exception?
> >>>>
> >>>> I'm sure I can re-license my submissions. I'd have to look into it.
> >>>
> >>> I'm _not_ sure.
> >>
> >>
> >> This is a new file - it did not exist in v1 - thus you had to write it.
> >> If you wrote it, you (or your employer) hold all copyrights, so yes, you
> >> (or your employer) can relicense it.
> >>
> >> I cannot imagine the case why employer would not like to have dual
> >> license here (it's beneficial to him, so employer would be acting
> >> against himself), but if you need to convince him, you can just say,
> >> that contributing to Open Source project means accepting the licenses in
> >> that project. The license for new bindings in this project is (GPL-2.0
> >> or BSD-2), like pointed by checkpatch.
> >
> >
> > Yes, my employer holds the copyright. However, corporations don't work in the way
> > you imagine. There is no one "owner" to speak to about re-licensing. The people
> > who determine the license is an army of lawyers, with an extensive approval
> > process.
>
> Yes, I understand this. But also how corporations work should not really
> be my problem. Especially that many of them were able to relicense even
> existing work, not mentioning new work. New work is piece of cake
> comparing with army of lawyers for existing, released work! Yet they
> could...
>
> >
> > What benefit does a BSD license hold for my employer over GPL v2 ?
>
> As BSD is permissive, it does not force the employer or its customer to
> release the derived works to customers. GPL requires it (simplifying
> now). The employer and its customer have now choice. Dual license gives
> more choices. More choices is beneficial for the company or its
> customers, isn't?
I don't think we derive value from this because Cisco only sells chips internally, not
externally.
>
> >
> > Here the licenses currently used by the bindings,
> >
> > 1 # SPDX-License-Identifier: BSD-2-Clause
> > 1 # SPDX-License-Identifier: (GPL-2.0-only)
> > 1 # SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
> > 1 # SPDX-License-Identifier: (GPL-2.0-or-later)
> > 3 # SPDX-License-Identifier: (GPL-2.0+ OR X11)
> > 4 # SPDX-License-Identifier: GPL-2.0-or-later
> > 4 # SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > 6 # SPDX-License-Identifier: (GPL-2.0)
> > 7 # SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> > 7 # SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
> > 11 # SPDX-License-Identifier: GPL-2.0+
> > 12 # SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
> > 12 # SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > 33 # SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > 47 # SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
> > 56 # SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> > 102 # SPDX-License-Identifier: GPL-2.0-only
> > 350 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > 511 # SPDX-License-Identifier: GPL-2.0
> > 610 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > 1570 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >
> > Can you explain why so many are allowed to use GPL v2 , but my company is not
> > allowed? Shouldn't these all be dual licensed if the project only allows dual
> > license?
>
> The rule is for new bindings. All new bindings are forced to follow this
> rule. Why do you think we treat Cisco special? Who else was allowed? Can
> we be specific?
>
> Linking here existing bindings is not really an argument. What does it
> prove?
It shows the "rule" is not consistent. Sometime GPL v2 is ok, sometimes not.
Here's is the last GPL v2 only binding added,
commit f9b8556d5799b612404e19b21dd7624d551f71df
Author: Johan Jonker <[email protected]>
Date: Thu Dec 22 15:28:53 2022 +0100
dt-bindings: usb: convert fcs,fusb302.txt to yaml
Convert fcs,fusb302.txt to yaml.
Changed:
Add vbus-supply property
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Herring <[email protected]>
This was only a few months ago. It's a new yaml file with a new license line, made
from an existing text file. I can see how maybe this uses parts of the GPL v2
txt files so you could not relicense to BSD.
here's one less than a year ago,
commit bdeb3cf013d0d1d09ff3bf66ba139ab259dab3a4
Author: Dmitry Baryshkov <[email protected]>
Date: Mon Jul 4 20:24:48 2022 +0300
dt-bindings: clock: separate bindings for MSM8916 GCC device
Separate bindings for GCC on Qualcomm MSM8916 platforms. This adds new
clocks/clock-names properties to be used for clock links.
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Marijn Suijten <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
uses one line from a text file that's GPL v2.
>
> >
> > It's very likely that new bindings will be made by making a copy of other
> > bindings, then make modifications. If my company copied bindings which are GPL
> > v2, then we are required to honor the license of the prior binding
> > and that means we legally aren't allowed to relicense under BSD AFAIK.
>
> So copy some bindings which are dual-licensed... Since this is new work,
> you can do it.
Writing the binding is already done. It's hard to go back.
Is this dual license mandate documented someplace, because it seems like a
massive trap.
> >
> > Also the documentation for the bindings here Documentation/devicetree/
> >
> > changesets.rst
> > dynamic-resolution-notes.rst
> > index.rst
> > kernel-api.rst
> > of_unittest.rst
> > overlay-notes.rst
> > usage-model.rst
> >
> > all the rst files are GPL v2 and not dual license.
>
> These are not bindings, so I do not understand your argument. What do
> you prove? That non-bindings do not have to use bindings rules? Yes,
> they are not bindings...
>
> Anyway, I feel like we are making some useless circles and wasting quite
> a lot of energy on trivial rule. I tried to explain it, but if you do
> not like it - it's your choice. It will be a NAK.
I'm pointing out that your dual license mandate has problems. Another issue is
you have dts files exclusively GPL v2, and the dt bindings have dts fragments
which then have to be relicensed under BSD.
Are you as well going to nak our dts files? Or are those ok without bindings ?
Daniel
On 12/04/2023 19:01, Daniel Walker (danielwa) wrote:
>>
>> Yes, I understand this. But also how corporations work should not really
>> be my problem. Especially that many of them were able to relicense even
>> existing work, not mentioning new work. New work is piece of cake
>> comparing with army of lawyers for existing, released work! Yet they
>> could...
>>
>>>
>>> What benefit does a BSD license hold for my employer over GPL v2 ?
>>
>> As BSD is permissive, it does not force the employer or its customer to
>> release the derived works to customers. GPL requires it (simplifying
>> now). The employer and its customer have now choice. Dual license gives
>> more choices. More choices is beneficial for the company or its
>> customers, isn't?
>
> I don't think we derive value from this because Cisco only sells chips internally, not
> externally.
My answer was generic: dual license is beneficial for a company. Not
specific: dual license is beneficial for Cisco. It might be the case you
do not have benefits from dual license, but you also do not loose anything.
Anyway, if SW release (for such chip) ever reaches external customer,
then it matters. GPL compliance is for some lawyers huge pain and scary
stuff, although should not be...
>
>>
>>>
>>> Here the licenses currently used by the bindings,
>>>
>>> 1 # SPDX-License-Identifier: BSD-2-Clause
>>> 1 # SPDX-License-Identifier: (GPL-2.0-only)
>>> 1 # SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
>>> 1 # SPDX-License-Identifier: (GPL-2.0-or-later)
>>> 3 # SPDX-License-Identifier: (GPL-2.0+ OR X11)
>>> 4 # SPDX-License-Identifier: GPL-2.0-or-later
>>> 4 # SPDX-License-Identifier: (GPL-2.0 OR MIT)
>>> 6 # SPDX-License-Identifier: (GPL-2.0)
>>> 7 # SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
>>> 7 # SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
>>> 11 # SPDX-License-Identifier: GPL-2.0+
>>> 12 # SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
>>> 12 # SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>> 33 # SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>>> 47 # SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
>>> 56 # SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
>>> 102 # SPDX-License-Identifier: GPL-2.0-only
>>> 350 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>> 511 # SPDX-License-Identifier: GPL-2.0
>>> 610 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>> 1570 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>
>>> Can you explain why so many are allowed to use GPL v2 , but my company is not
>>> allowed? Shouldn't these all be dual licensed if the project only allows dual
>>> license?
>>
>> The rule is for new bindings. All new bindings are forced to follow this
>> rule. Why do you think we treat Cisco special? Who else was allowed? Can
>> we be specific?
>>
>> Linking here existing bindings is not really an argument. What does it
>> prove?
>
> It shows the "rule" is not consistent. Sometime GPL v2 is ok, sometimes not.
>
> Here's is the last GPL v2 only binding added,
>
> commit f9b8556d5799b612404e19b21dd7624d551f71df
> Author: Johan Jonker <[email protected]>
> Date: Thu Dec 22 15:28:53 2022 +0100
>
> dt-bindings: usb: convert fcs,fusb302.txt to yaml
This is not a new binding. Read again the title.
>
> Convert fcs,fusb302.txt to yaml.
>
> Changed:
> Add vbus-supply property
>
> Signed-off-by: Johan Jonker <[email protected]>
> Reviewed-by: Rob Herring <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> Signed-off-by: Rob Herring <[email protected]>
>
>
> This was only a few months ago. It's a new yaml file with a new license line, made
> from an existing text file. I can see how maybe this uses parts of the GPL v2
> txt files so you could not relicense to BSD.
It's not a new binding. The license was GPLv 2.0, so it would have to be
relicensed with agreement of all copyright holders.
>
> here's one less than a year ago,
>
> commit bdeb3cf013d0d1d09ff3bf66ba139ab259dab3a4
> Author: Dmitry Baryshkov <[email protected]>
> Date: Mon Jul 4 20:24:48 2022 +0300
>
> dt-bindings: clock: separate bindings for MSM8916 GCC device
>
> Separate bindings for GCC on Qualcomm MSM8916 platforms. This adds new
> clocks/clock-names properties to be used for clock links.
>
> Reviewed-by: Krzysztof Kozlowski <[email protected]>
> Reviewed-by: Marijn Suijten <[email protected]>
> Signed-off-by: Dmitry Baryshkov <[email protected]>
> Signed-off-by: Bjorn Andersson <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
>
>
> uses one line from a text file that's GPL v2.
It was probably based on old binding (from which it separated) which was
GPL-2.0. As derivative work it had to be also GPL-2.0.
However that binding actually should be relicensed, because we have the
right to do it for Qualcomm. Also mistakes happen, on submitters side
and reviewers as well. Feel free to find all mistakes I did in review.
There will be tons of them. Only the one who does not review, makes no
mistakes.
>>>
>>> It's very likely that new bindings will be made by making a copy of other
>>> bindings, then make modifications. If my company copied bindings which are GPL
>>> v2, then we are required to honor the license of the prior binding
>>> and that means we legally aren't allowed to relicense under BSD AFAIK.
>>
>> So copy some bindings which are dual-licensed... Since this is new work,
>> you can do it.
>
> Writing the binding is already done. It's hard to go back.
You can go back any time. Just "rm -fr" and write again. Since there is
no other copyright holder than you (and/or your employer), you can do
pretty much anything you wish with it.
>
> Is this dual license mandate documented someplace,
Run checkpatch and do not send patches which fail.
> because it seems like a
> massive trap.
Trap? Of what? Srsly... I heard GPL is a trap, but never about dual or
BSD license.
>
>>>
>>> Also the documentation for the bindings here Documentation/devicetree/
>>>
>>> changesets.rst
>>> dynamic-resolution-notes.rst
>>> index.rst
>>> kernel-api.rst
>>> of_unittest.rst
>>> overlay-notes.rst
>>> usage-model.rst
>>>
>>> all the rst files are GPL v2 and not dual license.
>>
>> These are not bindings, so I do not understand your argument. What do
>> you prove? That non-bindings do not have to use bindings rules? Yes,
>> they are not bindings...
>>
>> Anyway, I feel like we are making some useless circles and wasting quite
>> a lot of energy on trivial rule. I tried to explain it, but if you do
>> not like it - it's your choice. It will be a NAK.
>
> I'm pointing out that your dual license mandate has problems. Another issue is
> you have dts files exclusively GPL v2,
It's not a problem... but even if it was, why do you not want to
dual-license them as well?
> and the dt bindings have dts fragments
> which then have to be relicensed under BSD.
Point me to the DTS fragment in this patch. I could not find it.
>
> Are you as well going to nak our dts files? Or are those ok without bindings ?
1. All compatibles must be documented, so if your DTS does not follow
this rule I will NAK.
2. New platforms are supposed to have zero dtbs_check warnings, which is
depending on above (1) plus enforces DT schema conversion.
Best regards,
Krzysztof
On Wed, Apr 12, 2023 at 07:18:51PM +0200, Krzysztof Kozlowski wrote:
> On 12/04/2023 19:01, Daniel Walker (danielwa) wrote:
> >>
> >> Yes, I understand this. But also how corporations work should not really
> >> be my problem. Especially that many of them were able to relicense even
> >> existing work, not mentioning new work. New work is piece of cake
> >> comparing with army of lawyers for existing, released work! Yet they
> >> could...
> >>
> >>>
> >>> What benefit does a BSD license hold for my employer over GPL v2 ?
> >>
> >> As BSD is permissive, it does not force the employer or its customer to
> >> release the derived works to customers. GPL requires it (simplifying
> >> now). The employer and its customer have now choice. Dual license gives
> >> more choices. More choices is beneficial for the company or its
> >> customers, isn't?
> >
> > I don't think we derive value from this because Cisco only sells chips internally, not
> > externally.
>
> My answer was generic: dual license is beneficial for a company. Not
> specific: dual license is beneficial for Cisco. It might be the case you
> do not have benefits from dual license, but you also do not loose anything.
>
> Anyway, if SW release (for such chip) ever reaches external customer,
> then it matters. GPL compliance is for some lawyers huge pain and scary
> stuff, although should not be...
GPL v2 has benefits in that the sources must be release. Cisco would lose that
under a BSD license.
> >>>
> >>> It's very likely that new bindings will be made by making a copy of other
> >>> bindings, then make modifications. If my company copied bindings which are GPL
> >>> v2, then we are required to honor the license of the prior binding
> >>> and that means we legally aren't allowed to relicense under BSD AFAIK.
> >>
> >> So copy some bindings which are dual-licensed... Since this is new work,
> >> you can do it.
> >
> > Writing the binding is already done. It's hard to go back.
>
> You can go back any time. Just "rm -fr" and write again. Since there is
> no other copyright holder than you (and/or your employer), you can do
> pretty much anything you wish with it.
>
> >
> > Is this dual license mandate documented someplace,
>
> Run checkpatch and do not send patches which fail.
checkpatch actually contributes to the problem because it doesn't tell you not
to use GPL v2 bindings as a base for new bindings prior to making the binding.
It tells you after you already made the binding.
> > because it seems like a
> > massive trap.
>
> Trap? Of what? Srsly... I heard GPL is a trap, but never about dual or
> BSD license.
It's a trap because people may use GPL v2 bindings as a basis for new bindings,
then get told later to relicense (either by checkpatch or you), something that
maybe difficult or not possible to do after the fact, or worse they relicense in
violation of the GPL v2 license.
> >
> >>>
> >>> Also the documentation for the bindings here Documentation/devicetree/
> >>>
> >>> changesets.rst
> >>> dynamic-resolution-notes.rst
> >>> index.rst
> >>> kernel-api.rst
> >>> of_unittest.rst
> >>> overlay-notes.rst
> >>> usage-model.rst
> >>>
> >>> all the rst files are GPL v2 and not dual license.
> >>
> >> These are not bindings, so I do not understand your argument. What do
> >> you prove? That non-bindings do not have to use bindings rules? Yes,
> >> they are not bindings...
> >>
> >> Anyway, I feel like we are making some useless circles and wasting quite
> >> a lot of energy on trivial rule. I tried to explain it, but if you do
> >> not like it - it's your choice. It will be a NAK.
> >
> > I'm pointing out that your dual license mandate has problems. Another issue is
> > you have dts files exclusively GPL v2,
>
> It's not a problem... but even if it was, why do you not want to
> dual-license them as well?
It's not my choice.
> > and the dt bindings have dts fragments
> > which then have to be relicensed under BSD.
>
> Point me to the DTS fragment in this patch. I could not find it.
I'm saying generally many dts fragments are included inside the dt binding files
as examples. So examples can't be relicensed unless it's coming from the
original copyright holder.
> >
> > Are you as well going to nak our dts files? Or are those ok without bindings ?
>
> 1. All compatibles must be documented, so if your DTS does not follow
> this rule I will NAK.
> 2. New platforms are supposed to have zero dtbs_check warnings, which is
> depending on above (1) plus enforces DT schema conversion.
So your response is yes, you will nak even dts files licensed correctly in order
to enforce your dual licensing scheme on dt bindings.
It's kind of unbelievable that the Linux community rejects even correctly
licensed device tree files.
Daniel