Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1433987 > unrolled thread

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-06-29 21:10 +0200
    Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible Greg KH <gregkh@linuxfoundation.org> - 2016-06-29 21:50 +0200
      Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-06-29 22:10 +0200
      Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible "H. Peter Anvin" <hpa@zytor.com> - 2016-06-29 22:20 +0200
    Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible Paul Bolle <pebolle@tiscali.nl> - 2016-06-29 23:50 +0200
      Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-06-30 00:10 +0200
        Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible Paul Bolle <pebolle@tiscali.nl> - 2016-06-30 00:50 +0200
          Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-06-30 01:10 +0200
            Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible Paul Bolle <pebolle@tiscali.nl> - 2016-06-30 01:30 +0200
              Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-06-30 01:40 +0200

#1433987 — Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On Tue, Jun 14, 2016 at 11:35:11AM -0700, Luis R. Rodriguez wrote:
> copyleft-next [0] [1] is an openly evolved copyleft license, its an
> effort to evolve copyleft without participation of the Church (TM)
> or State (R), completley openly to the extend development and
> discussion of copyleft-next by participants of the copyleft-next
> project are governed by the Harvey Birdman Rule [2].
> 
> Even though it has been a goal of the project to be GPL-v2 compatible
> to be certain I've asked for a clarification about what makes
> copyleft-next GPLv2 compatible and also asked for a summary of
> benefits. This prompted some small minor changes to make compatiblity
> even further clear and as of copyleft 0.3.1 compatibility should
> be crystal clear [3].
> 
> The summary of why copyleft-next 0.3.1 is compatible with GPLv2
> is explained as follows:
> 
>   Like GPLv2, copyleft-next requires distribution of derivative works
>   ("Derived Works" in copyleft-next 0.3.x) to be under the same license.
>   Ordinarily this would make the two licenses incompatible. However,
>   copyleft-next 0.3.1 says: "If the Derived Work includes material
>   licensed under the GPL, You may instead license the Derived Work under
>   the GPL." "GPL" is defined to include GPLv2.
> 
> In practice this means copyleft-next code in Linux may be licensed
> under the GPL2, however there are additional obvious gains for
> bringing contributins from Linux outbound where copyleft-next is
> preferred. To help review further I've also independently reviewed
> compatiblity with attorneys at SUSE and they agree with the
> compatibility.
> 
> A summary of benefits of copyleft-next >= 0.3.1 over GPLv2 is listed
> below, it shows *why* some folks like myself will prefer it over
> GPLv2 for future work.
> 
> o It is much shorter and simpler
> o It has an explicit patent license grant, unlike GPLv2
> o Its notice preservation conditions are clearer
> o More free software/open source licenses are compatible
>   with it (via section 4)
> o The source code requirement triggered by binary distribution
>   is much simpler in a procedural sense
> o Recipients potentially have a contract claim against distributors
>   who are noncompliant with the source code requirement
> o There is a built-in inbound=outbound policy for upstream
>   contributions (cf. Apache License 2.0 section 5)
> o There are disincentives to engage in the controversial practice
>   of copyleft/ proprietary dual-licensing
> o In 15 years copyleft expires, which can be advantageous
>   for legacy code
> o There are explicit disincentives to bringing patent infringement
>   claims accusing the licensed work of infringement (see 10b)
> o There is a cure period for licensees who are not compliant
>   with the license (there is no cure opportunity in GPLv2)
> o copyleft-next has a 'built-in or-later' provision
> 
> [0] https://github.com/copyleft-next/copyleft-next
> [1] https://lists.fedorahosted.org/mailman/listinfo/copyleft-next/
> [2] https://github.com/richardfontana/hbr/blob/master/HBR.md
> [3] https://lists.fedorahosted.org/archives/list/copyleft-next@lists.fedorahosted.org/thread/JTGV56DDADWGKU7ZKTZA4DLXTGTLNJ57/#SQMDIKBRAVDOCT4UVNOOCRGBN2UJIKHZ
> 
> Cc: copyleft-next@lists.fedorahosted.org
> Cc: Richard Fontana <fontana@sharpeleven.org>
> Signed-off-by: Ciaran Farrell <Ciaran.Farrell@suse.com>
> Signed-off-by: Christopher De Nicolo <Christopher.DeNicolo@suse.com>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> ---
> 
> I've tested its use at run time as well obviously.
> 
>  include/linux/license.h | 1 +
>  include/linux/module.h  | 1 +
>  2 files changed, 2 insertions(+)
> 

Greg, Rusty,

I haven't seen any objections or questions, so just a friendly *poke*.

  Luis

[toc] | [next] | [standalone]

#1434014

On Wed, Jun 29, 2016 at 09:05:47PM +0200, Luis R. Rodriguez wrote:
> On Tue, Jun 14, 2016 at 11:35:11AM -0700, Luis R. Rodriguez wrote:
> > copyleft-next [0] [1] is an openly evolved copyleft license, its an
> > effort to evolve copyleft without participation of the Church (TM)
> > or State (R), completley openly to the extend development and
> > discussion of copyleft-next by participants of the copyleft-next
> > project are governed by the Harvey Birdman Rule [2].
> > 
> > Even though it has been a goal of the project to be GPL-v2 compatible
> > to be certain I've asked for a clarification about what makes
> > copyleft-next GPLv2 compatible and also asked for a summary of
> > benefits. This prompted some small minor changes to make compatiblity
> > even further clear and as of copyleft 0.3.1 compatibility should
> > be crystal clear [3].
> > 
> > The summary of why copyleft-next 0.3.1 is compatible with GPLv2
> > is explained as follows:
> > 
> >   Like GPLv2, copyleft-next requires distribution of derivative works
> >   ("Derived Works" in copyleft-next 0.3.x) to be under the same license.
> >   Ordinarily this would make the two licenses incompatible. However,
> >   copyleft-next 0.3.1 says: "If the Derived Work includes material
> >   licensed under the GPL, You may instead license the Derived Work under
> >   the GPL." "GPL" is defined to include GPLv2.
> > 
> > In practice this means copyleft-next code in Linux may be licensed
> > under the GPL2, however there are additional obvious gains for
> > bringing contributins from Linux outbound where copyleft-next is
> > preferred. To help review further I've also independently reviewed
> > compatiblity with attorneys at SUSE and they agree with the
> > compatibility.
> > 
> > A summary of benefits of copyleft-next >= 0.3.1 over GPLv2 is listed
> > below, it shows *why* some folks like myself will prefer it over
> > GPLv2 for future work.
> > 
> > o It is much shorter and simpler
> > o It has an explicit patent license grant, unlike GPLv2
> > o Its notice preservation conditions are clearer
> > o More free software/open source licenses are compatible
> >   with it (via section 4)
> > o The source code requirement triggered by binary distribution
> >   is much simpler in a procedural sense
> > o Recipients potentially have a contract claim against distributors
> >   who are noncompliant with the source code requirement
> > o There is a built-in inbound=outbound policy for upstream
> >   contributions (cf. Apache License 2.0 section 5)
> > o There are disincentives to engage in the controversial practice
> >   of copyleft/ proprietary dual-licensing
> > o In 15 years copyleft expires, which can be advantageous
> >   for legacy code
> > o There are explicit disincentives to bringing patent infringement
> >   claims accusing the licensed work of infringement (see 10b)
> > o There is a cure period for licensees who are not compliant
> >   with the license (there is no cure opportunity in GPLv2)
> > o copyleft-next has a 'built-in or-later' provision
> > 
> > [0] https://github.com/copyleft-next/copyleft-next
> > [1] https://lists.fedorahosted.org/mailman/listinfo/copyleft-next/
> > [2] https://github.com/richardfontana/hbr/blob/master/HBR.md
> > [3] https://lists.fedorahosted.org/archives/list/copyleft-next@lists.fedorahosted.org/thread/JTGV56DDADWGKU7ZKTZA4DLXTGTLNJ57/#SQMDIKBRAVDOCT4UVNOOCRGBN2UJIKHZ
> > 
> > Cc: copyleft-next@lists.fedorahosted.org
> > Cc: Richard Fontana <fontana@sharpeleven.org>
> > Signed-off-by: Ciaran Farrell <Ciaran.Farrell@suse.com>
> > Signed-off-by: Christopher De Nicolo <Christopher.DeNicolo@suse.com>
> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> > ---
> > 
> > I've tested its use at run time as well obviously.
> > 
> >  include/linux/license.h | 1 +
> >  include/linux/module.h  | 1 +
> >  2 files changed, 2 insertions(+)
> > 
> 
> Greg, Rusty,
> 
> I haven't seen any objections or questions, so just a friendly *poke*.

Shouldn't this go in _with_ a patch that actually adds code that uses
the license?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1434023

On Wed, Jun 29, 2016 at 12:46:35PM -0700, Greg KH wrote:
> On Wed, Jun 29, 2016 at 09:05:47PM +0200, Luis R. Rodriguez wrote:
> > On Tue, Jun 14, 2016 at 11:35:11AM -0700, Luis R. Rodriguez wrote:
> > > copyleft-next [0] [1] is an openly evolved copyleft license, its an
> > > effort to evolve copyleft without participation of the Church (TM)
> > > or State (R), completley openly to the extend development and
> > > discussion of copyleft-next by participants of the copyleft-next
> > > project are governed by the Harvey Birdman Rule [2].
> > > 
> > > Even though it has been a goal of the project to be GPL-v2 compatible
> > > to be certain I've asked for a clarification about what makes
> > > copyleft-next GPLv2 compatible and also asked for a summary of
> > > benefits. This prompted some small minor changes to make compatiblity
> > > even further clear and as of copyleft 0.3.1 compatibility should
> > > be crystal clear [3].
> > > 
> > > The summary of why copyleft-next 0.3.1 is compatible with GPLv2
> > > is explained as follows:
> > > 
> > >   Like GPLv2, copyleft-next requires distribution of derivative works
> > >   ("Derived Works" in copyleft-next 0.3.x) to be under the same license.
> > >   Ordinarily this would make the two licenses incompatible. However,
> > >   copyleft-next 0.3.1 says: "If the Derived Work includes material
> > >   licensed under the GPL, You may instead license the Derived Work under
> > >   the GPL." "GPL" is defined to include GPLv2.
> > > 
> > > In practice this means copyleft-next code in Linux may be licensed
> > > under the GPL2, however there are additional obvious gains for
> > > bringing contributins from Linux outbound where copyleft-next is
> > > preferred. To help review further I've also independently reviewed
> > > compatiblity with attorneys at SUSE and they agree with the
> > > compatibility.
> > > 
> > > A summary of benefits of copyleft-next >= 0.3.1 over GPLv2 is listed
> > > below, it shows *why* some folks like myself will prefer it over
> > > GPLv2 for future work.
> > > 
> > > o It is much shorter and simpler
> > > o It has an explicit patent license grant, unlike GPLv2
> > > o Its notice preservation conditions are clearer
> > > o More free software/open source licenses are compatible
> > >   with it (via section 4)
> > > o The source code requirement triggered by binary distribution
> > >   is much simpler in a procedural sense
> > > o Recipients potentially have a contract claim against distributors
> > >   who are noncompliant with the source code requirement
> > > o There is a built-in inbound=outbound policy for upstream
> > >   contributions (cf. Apache License 2.0 section 5)
> > > o There are disincentives to engage in the controversial practice
> > >   of copyleft/ proprietary dual-licensing
> > > o In 15 years copyleft expires, which can be advantageous
> > >   for legacy code
> > > o There are explicit disincentives to bringing patent infringement
> > >   claims accusing the licensed work of infringement (see 10b)
> > > o There is a cure period for licensees who are not compliant
> > >   with the license (there is no cure opportunity in GPLv2)
> > > o copyleft-next has a 'built-in or-later' provision
> > > 
> > > [0] https://github.com/copyleft-next/copyleft-next
> > > [1] https://lists.fedorahosted.org/mailman/listinfo/copyleft-next/
> > > [2] https://github.com/richardfontana/hbr/blob/master/HBR.md
> > > [3] https://lists.fedorahosted.org/archives/list/copyleft-next@lists.fedorahosted.org/thread/JTGV56DDADWGKU7ZKTZA4DLXTGTLNJ57/#SQMDIKBRAVDOCT4UVNOOCRGBN2UJIKHZ
> > > 
> > > Cc: copyleft-next@lists.fedorahosted.org
> > > Cc: Richard Fontana <fontana@sharpeleven.org>
> > > Signed-off-by: Ciaran Farrell <Ciaran.Farrell@suse.com>
> > > Signed-off-by: Christopher De Nicolo <Christopher.DeNicolo@suse.com>
> > > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> > > ---
> > > 
> > > I've tested its use at run time as well obviously.
> > > 
> > >  include/linux/license.h | 1 +
> > >  include/linux/module.h  | 1 +
> > >  2 files changed, 2 insertions(+)
> > > 
> > 
> > Greg, Rusty,
> > 
> > I haven't seen any objections or questions, so just a friendly *poke*.
> 
> Shouldn't this go in _with_ a patch that actually adds code that uses
> the license?

Sure, I can fold it in another series that adds new code if that is
desirable. Unless I hear back I'll do that then.

  Luis

[toc] | [prev] | [next] | [standalone]

#1434038

On June 29, 2016 12:46:35 PM PDT, Greg KH <gregkh@linuxfoundation.org> wrote:
>On Wed, Jun 29, 2016 at 09:05:47PM +0200, Luis R. Rodriguez wrote:
>> On Tue, Jun 14, 2016 at 11:35:11AM -0700, Luis R. Rodriguez wrote:
>> > copyleft-next [0] [1] is an openly evolved copyleft license, its an
>> > effort to evolve copyleft without participation of the Church (TM)
>> > or State (R), completley openly to the extend development and
>> > discussion of copyleft-next by participants of the copyleft-next
>> > project are governed by the Harvey Birdman Rule [2].
>> > 
>> > Even though it has been a goal of the project to be GPL-v2
>compatible
>> > to be certain I've asked for a clarification about what makes
>> > copyleft-next GPLv2 compatible and also asked for a summary of
>> > benefits. This prompted some small minor changes to make
>compatiblity
>> > even further clear and as of copyleft 0.3.1 compatibility should
>> > be crystal clear [3].
>> > 
>> > The summary of why copyleft-next 0.3.1 is compatible with GPLv2
>> > is explained as follows:
>> > 
>> >   Like GPLv2, copyleft-next requires distribution of derivative
>works
>> >   ("Derived Works" in copyleft-next 0.3.x) to be under the same
>license.
>> >   Ordinarily this would make the two licenses incompatible.
>However,
>> >   copyleft-next 0.3.1 says: "If the Derived Work includes material
>> >   licensed under the GPL, You may instead license the Derived Work
>under
>> >   the GPL." "GPL" is defined to include GPLv2.
>> > 
>> > In practice this means copyleft-next code in Linux may be licensed
>> > under the GPL2, however there are additional obvious gains for
>> > bringing contributins from Linux outbound where copyleft-next is
>> > preferred. To help review further I've also independently reviewed
>> > compatiblity with attorneys at SUSE and they agree with the
>> > compatibility.
>> > 
>> > A summary of benefits of copyleft-next >= 0.3.1 over GPLv2 is
>listed
>> > below, it shows *why* some folks like myself will prefer it over
>> > GPLv2 for future work.
>> > 
>> > o It is much shorter and simpler
>> > o It has an explicit patent license grant, unlike GPLv2
>> > o Its notice preservation conditions are clearer
>> > o More free software/open source licenses are compatible
>> >   with it (via section 4)
>> > o The source code requirement triggered by binary distribution
>> >   is much simpler in a procedural sense
>> > o Recipients potentially have a contract claim against distributors
>> >   who are noncompliant with the source code requirement
>> > o There is a built-in inbound=outbound policy for upstream
>> >   contributions (cf. Apache License 2.0 section 5)
>> > o There are disincentives to engage in the controversial practice
>> >   of copyleft/ proprietary dual-licensing
>> > o In 15 years copyleft expires, which can be advantageous
>> >   for legacy code
>> > o There are explicit disincentives to bringing patent infringement
>> >   claims accusing the licensed work of infringement (see 10b)
>> > o There is a cure period for licensees who are not compliant
>> >   with the license (there is no cure opportunity in GPLv2)
>> > o copyleft-next has a 'built-in or-later' provision
>> > 
>> > [0] https://github.com/copyleft-next/copyleft-next
>> > [1] https://lists.fedorahosted.org/mailman/listinfo/copyleft-next/
>> > [2] https://github.com/richardfontana/hbr/blob/master/HBR.md
>> > [3]
>https://lists.fedorahosted.org/archives/list/copyleft-next@lists.fedorahosted.org/thread/JTGV56DDADWGKU7ZKTZA4DLXTGTLNJ57/#SQMDIKBRAVDOCT4UVNOOCRGBN2UJIKHZ
>> > 
>> > Cc: copyleft-next@lists.fedorahosted.org
>> > Cc: Richard Fontana <fontana@sharpeleven.org>
>> > Signed-off-by: Ciaran Farrell <Ciaran.Farrell@suse.com>
>> > Signed-off-by: Christopher De Nicolo
><Christopher.DeNicolo@suse.com>
>> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
>> > ---
>> > 
>> > I've tested its use at run time as well obviously.
>> > 
>> >  include/linux/license.h | 1 +
>> >  include/linux/module.h  | 1 +
>> >  2 files changed, 2 insertions(+)
>> > 
>> 
>> Greg, Rusty,
>> 
>> I haven't seen any objections or questions, so just a friendly
>*poke*.
>
>Shouldn't this go in _with_ a patch that actually adds code that uses
>the license?
>
>thanks,
>
>greg k-h

I would disagree; I think this is the sort of thing we should enable in the interest of forward compatibility and documentation.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

[toc] | [prev] | [next] | [standalone]

#1434073

On wo, 2016-06-29 at 21:05 +0200, Luis R. Rodriguez wrote:
> I haven't seen any objections or questions, so just a friendly *poke*.

At the end of the day, what matters most is whether a module is GPL v2
compatible. So why are the specific license idents for the various GPL
v2 compatible licenses actually needed?

include/linux/module.h tells us:
    1.   So modinfo can show license info for users wanting to vet their setup
         is free
    2.   So the community can ignore bug reports including proprietary modules
    3.   So vendors can do likewise based on their own policies

Does that require more than just two license idents ("GPL v2 compatible"
and "Proprietary")?


Paul Bolle

[toc] | [prev] | [next] | [standalone]

#1434077

On Wed, Jun 29, 2016 at 2:43 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> On wo, 2016-06-29 at 21:05 +0200, Luis R. Rodriguez wrote:
>> I haven't seen any objections or questions, so just a friendly *poke*.
>
> At the end of the day, what matters most is whether a module is GPL v2
> compatible. So why are the specific license idents for the various GPL
> v2 compatible licenses actually needed?

Long ago I reached similar conclusion and question, and therefore
proposed a simple GPL-Compatible tag then as a replacement [0]. A few
agreed [1], but others had a lot of reasons why we need to be explicit
about tags for new licenses. I recommend the full thread reading if
you are interested about more details, to me perhaps the best
explanation of why we need explicit tags is the points Alan raised
over historic incompatibilities and also of course new
incompatibilities found [2]. Finding compatibility requires work and
due diligence. That work was done here and as such a new tag is added.

[0] https://lkml.kernel.org/r/1333757482-16204-1-git-send-email-mcgrof@frijolero.org
[1] https://lkml.kernel.org/r/20120407002723.GA14568@kroah.com
[2] https://lkml.kernel.org/r/20120408181227.5d9430d9@pyramind.ukuu.org.uk

  Luis

[toc] | [prev] | [next] | [standalone]

#1434109

On wo, 2016-06-29 at 15:01 -0700, Luis R. Rodriguez wrote:
> Long ago I reached similar conclusion and question, and therefore
> proposed a simple GPL-Compatible tag then as a replacement [0]. A few
> agreed [1], but others had a lot of reasons why we need to be explicit
> about tags for new licenses. I recommend the full thread reading if
> you are interested about more details, to me perhaps the best
> explanation of why we need explicit tags is the points Alan raised
> over historic incompatibilities and also of course new
> incompatibilities found [2]. Finding compatibility requires work and
> due diligence. That work was done here and as such a new tag is added.
> 
> [0] https://lkml.kernel.org/r/1333757482-16204-1-git-send-email-mcgrof
> @frijolero.org
> [1] https://lkml.kernel.org/r/20120407002723.GA14568@kroah.com
> [2] 
> 
> https://lkml.kernel.org/r/20120408181227.5d9430d9@pyramind.ukuu.org.uk

Thanks, I wasn't aware of your previous work here.

But perhaps it wasn't clear I was talking only about the license ident:
the machine readable module tag. The tag that allows us to taint a
kernel when a proprietary module is loaded.

Most modules already have a comment in their files detailing the license
of that module. Why should that comment be summarized in the license
ident?

Requiring such a summary in the ident also means that mismatches can
occur: cases where the license ident doesn't actually match the comment
detailing the license of the module.

A choice between, say, "GPL v2 compatible" and "Proprietary" for license
idents allows us to taint the kernel if needed and still allows any GPL
v2 compatible (dual) license to be used for the module.

This requires proper license comments for modules. Most modules already
use those.

It also requires checking whether the license detailed in that comment
really is GPL v2 compatible. I'm guessing some people are actually doing
that. (I can't personally recall any discussion on a patch submitting an
improperly licensed module. But that must have probably already
happened.)


Paul Bolle

[toc] | [prev] | [next] | [standalone]

#1434115

On Thu, Jun 30, 2016 at 12:45:23AM +0200, Paul Bolle wrote:
> On wo, 2016-06-29 at 15:01 -0700, Luis R. Rodriguez wrote:
> > Long ago I reached similar conclusion and question, and therefore
> > proposed a simple GPL-Compatible tag then as a replacement [0]. A few
> > agreed [1], but others had a lot of reasons why we need to be explicit
> > about tags for new licenses. I recommend the full thread reading if
> > you are interested about more details, to me perhaps the best
> > explanation of why we need explicit tags is the points Alan raised
> > over historic incompatibilities and also of course new
> > incompatibilities found [2]. Finding compatibility requires work and
> > due diligence. That work was done here and as such a new tag is added.
> > 
> > [0] https://lkml.kernel.org/r/1333757482-16204-1-git-send-email-mcgrof
> > @frijolero.org
> > [1] https://lkml.kernel.org/r/20120407002723.GA14568@kroah.com
> > [2] 
> > 
> > https://lkml.kernel.org/r/20120408181227.5d9430d9@pyramind.ukuu.org.uk
> 
> Thanks, I wasn't aware of your previous work here.
> 
> But perhaps it wasn't clear I was talking only about the license ident:
> the machine readable module tag. The tag that allows us to taint a
> kernel when a proprietary module is loaded.
> 
> Most modules already have a comment in their files detailing the license
> of that module. Why should that comment be summarized in the license
> ident?

Because run time license counts, please read the full thread and prior
discussions.

  Luis

[toc] | [prev] | [next] | [standalone]

#1434116

On do, 2016-06-30 at 01:01 +0200, Luis R. Rodriguez wrote:
> Because run time license counts, please read the full thread and prior
> discussions.

run time license?


Paul Bolle

[toc] | [prev] | [next] | [standalone]

#1434120

On Wed, Jun 29, 2016 at 4:22 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> On do, 2016-06-30 at 01:01 +0200, Luis R. Rodriguez wrote:
>> Because run time license counts, please read the full thread and prior
>> discussions.
>
> run time license?

https://lkml.kernel.org/r/CAB=NE6X1NFLn6UfPHyNP9_uFTCdYUbtoTP0ds+0YT3_oFCZTSQ@mail.gmail.com

  Luis

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web