Re: [PATCH v2 2/2] dt-bindings: cisco: document the CrayAR compatibles

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <jbx6244@xxxxxxxxx>
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 <jbx6244@xxxxxxxxx>
    Reviewed-by: Rob Herring <robh@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/0336a3c4-4a43-c983-11d7-e2ae16187fc8@xxxxxxxxx
    Signed-off-by: Rob Herring <robh@xxxxxxxxxx>


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 <dmitry.baryshkov@xxxxxxxxxx>
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 <krzysztof.kozlowski@xxxxxxxxxx>
    Reviewed-by: Marijn Suijten <marijn.suijten@xxxxxxxxxxxxxx>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
    Signed-off-by: Bjorn Andersson <andersson@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/20220704172453.838303-3-dmitry.baryshkov@xxxxxxxxxx


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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux