Re: [PATCH] dt-bindings: clock: ti: Convert mux.txt to json-schema

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

 



On Fri, Nov 8, 2024 at 8:48 AM Nishanth Menon <nm@xxxxxx> wrote:
>
> On 15:03-20241108, Roger Quadros wrote:
> > >>> diff --git a/Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml
> > >>> new file mode 100644
> > >>> index 000000000000..b271ab86dde1
> > >>> --- /dev/null
> > >>> +++ b/Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml
> > >>> @@ -0,0 +1,123 @@
> > >>> +# SPDX-License-Identifier: GPL-2.0-only
> > >>
> > >> Surely TI as the only author of the original binding would agree to
> > >> dual-license this?
> > >>
> > > So there is a question mark. So you are waiting for some confirmation
> > > form TI?
> >
> > TI code uses below license clause. So better to stick to that.
> >
> > # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>
> Just my 2 cents:
>
> Just to be clear, as a corporate, as TI contributor we have approval for the
> following two:
>
> For new stuff:  GPL-2.0-only OR MIT
> for legacy stuff, we had GPL-2.0-only.

New kernel drivers would be GPL-2.0-only...

And based on this, TI can't contribute any new bindings.

>
> There are indeed instances of community contributions with
> GPL-2.0-only OR BSD-2-Clause, but that is definitely something community
> is free to do. Looking at history of
> Documentation/devicetree/bindings/clock/ti/mux.txt, I believe, at least
> from TI perspective, we are fine with GPL-2.0-only OR MIT and I think it
> will let other s/w ecosystems consume the same as well.

The choice for bindings are:

GPL-2.0-only
GPL-2.0-only OR BSD-2-Clause

MIT would be fine, but I just don't want proliferation of different
variations. See the .dts licenses for an example of that.

For this case, I would suggest going with GPL-2.0-only. It would be
nice to have blanket permission from TI to dual license any DT
bindings. I have this from several companies. It really only matters
for common bindings that we want to move out of the kernel though.

Rob





[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