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

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

[Luis R. Rodriguez]

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(+)

diff --git a/include/linux/license.h b/include/linux/license.h
index decdbf43cb5c..ed7c13a6b556 100644
--- a/include/linux/license.h
+++ b/include/linux/license.h
@@ -5,6 +5,7 @@ static inline int license_is_gpl_compatible(const char *license)
 {
 	return (strcmp(license, "GPL") == 0
 		|| strcmp(license, "GPL v2") == 0
+		|| strcmp(license, "copyleft-next") == 0
 		|| strcmp(license, "GPL and additional rights") == 0
 		|| strcmp(license, "Dual BSD/GPL") == 0
 		|| strcmp(license, "Dual MIT/GPL") == 0
diff --git a/include/linux/module.h b/include/linux/module.h
index f777164c238b..24c520ff62e1 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -182,6 +182,7 @@ void trim_init_extable(struct module *m);
  * The following license idents are currently accepted as indicating free
  * software modules
  *
+ *	"copyleft-next"			[copyleft-next 0.3.1 or later]
  *	"GPL"				[GNU Public License v2 or later]
  *	"GPL v2"			[GNU Public License v2]
  *	"GPL and additional rights"	[GNU Public License v2 rights and more]
-- 
2.8.2

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

[Luis R. Rodriguez]

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

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

[Greg KH]

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

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

[Luis R. Rodriguez]

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

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

[H. Peter Anvin]

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.

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

[Paul Bolle]

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

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

[Luis R. Rodriguez]

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

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

[Paul Bolle]

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

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

[Luis R. Rodriguez]

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

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

[Paul Bolle]

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

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

[Luis R. Rodriguez]

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

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

[Paul Bolle]

On di, 2016-06-14 at 11:35 -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.f
> edorahosted.org/thread/JTGV56DDADWGKU7ZKTZA4DLXTGTLNJ57/#SQMDIKBRAVDOC
> T4UVNOOCRGBN2UJIKHZ
> 
> 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(+)

Nit: there's a checkpatch rule for module license idents nowadays, so
this patch needs to update that rule too.


Paul Bolle

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

[Luis R. Rodriguez]

On Wed, Jun 29, 2016 at 10:49:37PM +0200, Paul Bolle wrote:
> On di, 2016-06-14 at 11:35 -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.f
> > edorahosted.org/thread/JTGV56DDADWGKU7ZKTZA4DLXTGTLNJ57/#SQMDIKBRAVDOC
> > T4UVNOOCRGBN2UJIKHZ
> > 
> > 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(+)
> 
> Nit: there's a checkpatch rule for module license idents nowadays, so
> this patch needs to update that rule too.

Sure, thanks for the review, will respin a v2.
 
  Luis

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

[Luis R. Rodriguez]

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

v2:

o extend checkpatch.pl with copyleft-next as well for
  MODULE_LICENSE() check - as suggested by Paul Bolle.

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>
---
 include/linux/license.h | 1 +
 include/linux/module.h  | 1 +
 scripts/checkpatch.pl   | 1 +
 3 files changed, 3 insertions(+)

diff --git a/include/linux/license.h b/include/linux/license.h
index decdbf43cb5c..ed7c13a6b556 100644
--- a/include/linux/license.h
+++ b/include/linux/license.h
@@ -5,6 +5,7 @@ static inline int license_is_gpl_compatible(const char *license)
 {
 	return (strcmp(license, "GPL") == 0
 		|| strcmp(license, "GPL v2") == 0
+		|| strcmp(license, "copyleft-next") == 0
 		|| strcmp(license, "GPL and additional rights") == 0
 		|| strcmp(license, "Dual BSD/GPL") == 0
 		|| strcmp(license, "Dual MIT/GPL") == 0
diff --git a/include/linux/module.h b/include/linux/module.h
index f777164c238b..24c520ff62e1 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -182,6 +182,7 @@ void trim_init_extable(struct module *m);
  * The following license idents are currently accepted as indicating free
  * software modules
  *
+ *	"copyleft-next"			[copyleft-next 0.3.1 or later]
  *	"GPL"				[GNU Public License v2 or later]
  *	"GPL v2"			[GNU Public License v2]
  *	"GPL and additional rights"	[GNU Public License v2 rights and more]
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4904ced676d4..ccb66e201126 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6014,6 +6014,7 @@ sub process {
 						Dual\ BSD/GPL|
 						Dual\ MIT/GPL|
 						Dual\ MPL/GPL|
+						copyleft-next|
 						Proprietary
 					}x;
 			if ($extracted_string !~ /^"(?:$valid_licenses)"$/x) {
-- 
2.8.4

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

[Greg KH]

On Thu, Jun 30, 2016 at 03:53:27PM -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
> 
> v2:
> 
> o extend checkpatch.pl with copyleft-next as well for
>   MODULE_LICENSE() check - as suggested by Paul Bolle.
> 
> 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>

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

[Rusty Russell]

Greg KH <gregkh@linuxfoundation.org> writes:
> On Thu, Jun 30, 2016 at 03:53:27PM -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
>> 
>> v2:
>> 
>> o extend checkpatch.pl with copyleft-next as well for
>>   MODULE_LICENSE() check - as suggested by Paul Bolle.
>> 
>> 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>
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Adding a license here implies we accept that it's actually GPLv2
compatible.  And IANAL.

If such-licensed code gets openly accepted into the kernel, and nobody
complains, I'll send this to Linus.  Not a moment before.

Thanks,
Rusty.

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

[Greg KH]

On Mon, Jul 18, 2016 at 12:56:33PM +0930, Rusty Russell wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> > On Thu, Jun 30, 2016 at 03:53:27PM -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
> >> 
> >> v2:
> >> 
> >> o extend checkpatch.pl with copyleft-next as well for
> >>   MODULE_LICENSE() check - as suggested by Paul Bolle.
> >> 
> >> 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>
> >
> > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> Adding a license here implies we accept that it's actually GPLv2
> compatible.  And IANAL.

Note, at least lawyer has signed off on this.

I'd like to see Richard do so as well.

thanks,

greg k-h

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

[Richard Fontana]

On 07/19/2016 06:38 PM, Greg KH wrote:
> On Mon, Jul 18, 2016 at 12:56:33PM +0930, Rusty Russell wrote:
>> Greg KH <gregkh@linuxfoundation.org> writes:
>>> On Thu, Jun 30, 2016 at 03:53:27PM -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
>>>>
>>>> v2:
>>>>
>>>> o extend checkpatch.pl with copyleft-next as well for
>>>>   MODULE_LICENSE() check - as suggested by Paul Bolle.
>>>>
>>>> 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>
>>>
>>> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> Adding a license here implies we accept that it's actually GPLv2
>> compatible.  And IANAL.
> 
> Note, at least lawyer has signed off on this.
> 
> I'd like to see Richard do so as well.

Signed-off-by: Richard Fontana <fontana@sharpeleven.org>

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

[Rusty Russell]

Greg KH <gregkh@linuxfoundation.org> writes:
>> Adding a license here implies we accept that it's actually GPLv2
>> compatible.  And IANAL.
>
> Note, at least lawyer has signed off on this.
>
> I'd like to see Richard do so as well.

Sure, but as I said before I'm not applying it until we have accepted
in-tree code which needs it.

If there's consensus that the kernel needs to accept YA license, I will
abide by it as module maintainer.  But I won't endorse it myself.

Thanks,
Rusty.

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

[Luis R. Rodriguez]

On Tue, Jul 19, 2016 at 03:38:51PM -0700, Greg KH wrote:
> On Mon, Jul 18, 2016 at 12:56:33PM +0930, Rusty Russell wrote:
> > Greg KH <gregkh@linuxfoundation.org> writes:
> > > On Thu, Jun 30, 2016 at 03:53:27PM -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
> > >> 
> > >> v2:
> > >> 
> > >> o extend checkpatch.pl with copyleft-next as well for
> > >>   MODULE_LICENSE() check - as suggested by Paul Bolle.
> > >> 
> > >> 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>
> > >
> > > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > Adding a license here implies we accept that it's actually GPLv2
> > compatible.  And IANAL.
> 
> Note, at least lawyer has signed off on this.

Clarification: *2 lawyers* at SUSE had Signed-off on this already.

> I'd like to see Richard do so as well.

With Richard that's 3 attorneys now.

I'll proceed to submit some code with this license as you request, Rusty.  Its
however not for modules yet so I would not make use of the
MODULE_LICENSE("copyleft-next") tag yet, however the license will be on top of
a header.

  Luis

Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Alan Cox]

> > (Going back to pick up the specific licence thread)

> > 
> > I'd like to see Richard do so as well.
> With Richard that's 3 attorneys now.

None of whom I believe represent the Linux project or foundation ?

Linus has to make this call, nobody else and he is probablygoing to go
ape if you try and sneak another licence into the kernel without
flagging it up with him clearly first. You need to discuss it with
Linus up front.

> I'll proceed to submit some code with this license as you request,
> Rusty.  Its
> however not for modules yet so I would not make use of the
> MODULE_LICENSE("copyleft-next") tag yet, however the license will be
> on top of
> a header.

We have the GPL/extra rights tag for this already. Also when it's
merged with the kernel we'd I'm sure pick the derivative work under the
GPL option so we'd only need the GPL tag.

There are specific reasons for the extra rights language - it avoids
games like MODULE_LICENSE("BSD") and then giving people just a binary
and it being counted as GPL compliant activity. The same problem exists
in your licence post sunset. That single tag is also why we don't have
to list BSD, MIT, and every variant thereof in the table which saves us
so much pain. If you must have the actual text in the .ko file then put
it in your MODULE_DESCRIPTION().

Outside of the "derivative work" GPL clause they don't quite look
compatible to me as a non-lawyer (eg the definition of "source code"
looks to differ on scripts etc). 



Alan

Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Luis R. Rodriguez]

On Tue, Aug 09, 2016 at 09:04:35PM +0100, Alan Cox wrote:
> > > (Going back to pick up the specific licence thread)
> 
> > > 
> > > I'd like to see Richard do so as well.
> > With Richard that's 3 attorneys now.
> 
> None of whom I believe represent the Linux project or foundation ?
> 
> Linus has to make this call, nobody else and he is probablygoing to go
> ape if you try and sneak another licence into the kernel without
> flagging it up with him clearly first. You need to discuss it with
> Linus up front.

To be clear I first poked the Linux Foundation about this, I went through the
process recommended by them. If there is a process out of place its by no
means an issue on my end.

> > I'll proceed to submit some code with this license as you request,
> > Rusty.  Its
> > however not for modules yet so I would not make use of the
> > MODULE_LICENSE("copyleft-next") tag yet, however the license will be
> > on top of
> > a header.
> 
> We have the GPL/extra rights tag for this already. Also when it's
> merged with the kernel we'd I'm sure pick the derivative work under the
> GPL option so we'd only need the GPL tag.
> 
> There are specific reasons for the extra rights language - it avoids
> games like MODULE_LICENSE("BSD") and then giving people just a binary
> and it being counted as GPL compliant activity. The same problem exists
> in your licence post sunset. That single tag is also why we don't have
> to list BSD, MIT, and every variant thereof in the table which saves us
> so much pain. If you must have the actual text in the .ko file then put
> it in your MODULE_DESCRIPTION().

I'm personally fine with MODULE_LICENSE("GPL") being used with copyleft-next code
and find it sensible.

> Outside of the "derivative work" GPL clause they don't quite look
> compatible to me as a non-lawyer (eg the definition of "source code"
> looks to differ on scripts etc). 

Up to the attorneys then.

  Luis

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Luis R. Rodriguez]

On Tue, Aug 09, 2016 at 10:14:48PM +0200, Luis R. Rodriguez wrote:
> On Tue, Aug 09, 2016 at 09:04:35PM +0100, Alan Cox wrote:
> > > > (Going back to pick up the specific licence thread)
> > 
> > > > 
> > > > I'd like to see Richard do so as well.
> > > With Richard that's 3 attorneys now.
> > 
> > None of whom I believe represent the Linux project or foundation ?
> > 
> > Linus has to make this call, nobody else and he is probablygoing to go
> > ape if you try and sneak another licence into the kernel without
> > flagging it up with him clearly first. You need to discuss it with
> > Linus up front.
> 
> To be clear I first poked the Linux Foundation about this, I went through the
> process recommended by them. If there is a process out of place its by no
> means an issue on my end.
> 
> > > I'll proceed to submit some code with this license as you request,
> > > Rusty.  Its
> > > however not for modules yet so I would not make use of the
> > > MODULE_LICENSE("copyleft-next") tag yet, however the license will be
> > > on top of
> > > a header.
> > 
> > We have the GPL/extra rights tag for this already. Also when it's
> > merged with the kernel we'd I'm sure pick the derivative work under the
> > GPL option so we'd only need the GPL tag.
> > 
> > There are specific reasons for the extra rights language - it avoids
> > games like MODULE_LICENSE("BSD") and then giving people just a binary
> > and it being counted as GPL compliant activity. The same problem exists
> > in your licence post sunset. That single tag is also why we don't have
> > to list BSD, MIT, and every variant thereof in the table which saves us
> > so much pain. If you must have the actual text in the .ko file then put
> > it in your MODULE_DESCRIPTION().
> 
> I'm personally fine with MODULE_LICENSE("GPL") being used with copyleft-next code
> and find it sensible.

Adding Linus now, for some reason I think you added him with an incorrect
domain name, Alan.

  Luis

Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Linus Torvalds]

On Tue, Aug 9, 2016 at 1:14 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>
> I'm personally fine with MODULE_LICENSE("GPL") being used with copyleft-next code
> and find it sensible.

I'd rather have the kernel license be as clear as possible, so I'd
tend to prefer that

  MODULE_LICENSE("GPL")

and then if you want to dual-license it, just put something like "or,
at your option, copyleft-next" in the comment at the top.

That makes it clear that as far as the kernel is concerned, it's
GPLv2, but if somebody finds it useful for other projects, they can
choose to take that file under copyleft-next (whatever version that
would be..).

              Linus

Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Luis R. Rodriguez]

Sorry this is an old topic now but a clarification was requested by AKASHI,
so following up.

On Tue, Aug 09, 2016 at 07:58:27PM -0700, Linus Torvalds wrote:
> On Tue, Aug 9, 2016 at 1:14 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> >
> > I'm personally fine with MODULE_LICENSE("GPL") being used with copyleft-next code
> > and find it sensible.
> 
> I'd rather have the kernel license be as clear as possible, so I'd
> tend to prefer that
> 
>   MODULE_LICENSE("GPL")

Great will use this.

> and then if you want to dual-license it, just put something like "or,
> at your option, copyleft-next" in the comment at the top.

The "or" language can be confusing though.

Even though the following document refers to permissive licenses and using them
on GPL projects it does contain some information about using the "or" clauses
on section 4 which may be relevant here:

https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

So experience seems to show that when the licenses are compatible such "or"
language can be a bit confusing.  My understanding is such "or" language is
really is only necessary or helpful for when you have some sort of incompatible
licenses, and that's not the case here.

> That makes it clear that as far as the kernel is concerned, it's
> GPLv2, but if somebody finds it useful for other projects, they can
> choose to take that file under copyleft-next (whatever version that
> would be..).

Indeed, my goal is to make it clear GPLv2 applies to copyleft-next material
when used on Linux, and grant the right to use the code either on GPLv2 code or
larger copyleft-next code; that's in fact the neat benefit of copyleft-next: it
lets copyleft advance even when projects are stuck on the old copyleft.

Since the license *already explicitly states GPLv2 applies* when copyleft-next
code is used on a larger GPLv2 project I figured the above macro:

	MODULE_LICENSE("GPL")

would suffice to make it even clearer, but to avoid propagating any further
"or" confusion -- I would prefer just using a copyleft-next license header to
suffice for folks use the code on either GPLv2 or copyleft-next code. Ie, the
or clauses would not be needed. Likewise for headers, only the macro would not
be used. That is:

file.c:
/* copyleft-next license header only */
MODULE_LICENSE("GPL")

file.h:
/* copyleft-next license header only */

Linus, is this fine?

  Luis

Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Alan Cox]

> such "or"
> language can be a bit confusing.  My understanding is such "or"
> language is
> really is only necessary or helpful for when you have some sort of
> incompatible
> licenses, and that's not the case here.

The problem is that it takes a lawyer to decide whether the two are
compatible. If you just stuck the kernel one under GPLv2 with a note
that you can get a non-GPL one at URL or as dual licence it would be a
hell of a lot simpler.

There are reasons there is stuff under things like dual BSD/GPL. It
keeps lawyers happier because they don't have to spend time on it and
the rest of us happy because we don't have to talk to lawyers 8)

> Since the license *already explicitly states GPLv2 applies* when
> copyleft-next

Subject to getting your corporate legal team to evaluate it.

It's all hassle and friction.

Alan

Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Luis R. Rodriguez]

On Mon, May 15, 2017 at 04:18:14PM +0100, Alan Cox wrote:
> > such "or" language can be a bit confusing.  My understanding is such "or"
> > language is really is only necessary or helpful for when you have some sort
> > of incompatible licenses, and that's not the case here.
> 
> The problem is that it takes a lawyer to decide whether the two are
> compatible.

At the very least 3 attorneys have reviewed this by now. 2 at SUSE and
one at Red Hat. At least.

> If you just stuck the kernel one under GPLv2 with a note
> that you can get a non-GPL one at URL or as dual licence it would be a
> hell of a lot simpler.
> 
> There are reasons there is stuff under things like dual BSD/GPL.

I recall -- you clarified this to me a while back.

> It keeps lawyers happier because they don't have to spend time on it and
> the rest of us happy because we don't have to talk to lawyers 8)

I see, makes sense.

> > Since the license *already explicitly states GPLv2 applies* when
> > copyleft-next
> 
> Subject to getting your corporate legal team to evaluate it.

But I did, and I did try to go through any other process to vet for it.
The clarity should help us avoid the "dual or" language.

> It's all hassle and friction.

I have done the work though, however I can understand this might mean others
down the chain might need to burn some ink on this. Even if our position is:

"we rather avoid any attorneys burning any ink and we prefer to just always
require this 'dual or' language even for licenses which corporate attorneys
have vetted as compatible"

Wouldn't that still require a bit of ink?

  Luis

Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Alan Cox]

> At the very least 3 attorneys have reviewed this by now. 2 at SUSE
> and
> one at Red Hat. At least.

In the big picture that's irrelevant. An attorney's job is to protect
their client or employer.

> "we rather avoid any attorneys burning any ink and we prefer to just
> always
> require this 'dual or' language even for licenses which corporate
> attorneys
> have vetted as compatible"
> 

Generally no because "You may apply license X or license Y" type
statements are built upon hundreds of years of caselaw, dealt with
regularly already by companies dealing with open source and in general
don't need lawyers to peer at it because there is already clear policy.

The last thing the kernel needs is two, then three, then five then ten
different funky supposedly compatible with GPL licences where it relies
upon someone saying they are compatible.

That has lead to historic problems - long ago people naïvely assumed
BSD 4 clause was GPL compatible. Then the lawyers realised it wasn't
then you have a mess.

If you proposed a chunk of code that was a long term maintenance pain
in the butt Linus would tell you to take a hike. Why is it different
when you are doing the same by trying to introduce weird, un-necessary
licence complexity ?

Alan

Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Theodore Ts'o]

On Wed, May 17, 2017 at 01:27:02AM +0200, Luis R. Rodriguez wrote:
> 
> I have done the work though, however I can understand this might mean others
> down the chain might need to burn some ink on this. Even if our position is:
> 
> "we rather avoid any attorneys burning any ink and we prefer to just always
> require this 'dual or' language even for licenses which corporate attorneys
> have vetted as compatible"
> 
> Wouldn't that still require a bit of ink?

What ink?  As far as the Kernel is concerned, it's dual-licensed GPLv2
and copyleft-next.  So for all Kernel users there isn't any lawyer ink
at all.

The lawyer ink comes from contributors being willing to let their code
contributions being dual-licensed with GPL2 plus a potentially
unfamiliar, new copyright license.  But that's overhead that
contributors would have to deal with in either case.  In fact, if you
try to go single-license copyleft-next, the contributors' corporate
lawyer will need to figure out the GPLv2 compatibility issue, so it's
*more* overhead with the proposed single-copyright license approach.

I'm not sure I understand what you believe to be the benefit of having
kernel modules solely licensed under copyleft-next and relying on
lawyers to say, "no really, it's GPLv2 compatible"?  Could you say
more about that?

	   	    	    	       - Ted

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Luis R. Rodriguez]

On Wed, May 17, 2017 at 12:55:02PM -0400, Theodore Ts'o wrote:
> On Wed, May 17, 2017 at 01:27:02AM +0200, Luis R. Rodriguez wrote:
> > 
> > I have done the work though, however I can understand this might mean others
> > down the chain might need to burn some ink on this. Even if our position is:
> > 
> > "we rather avoid any attorneys burning any ink and we prefer to just always
> > require this 'dual or' language even for licenses which corporate attorneys
> > have vetted as compatible"
> > 
> > Wouldn't that still require a bit of ink?
> 
> What ink?  As far as the Kernel is concerned, it's dual-licensed GPLv2
> and copyleft-next.  So for all Kernel users there isn't any lawyer ink
> at all.

Here you seem to indicate no lawyers would need to be involved.

> The lawyer ink comes from contributors being willing to let their code
> contributions being dual-licensed with GPL2 plus a potentially
> unfamiliar, new copyright license.  But that's overhead that
> contributors would have to deal with in either case.

But here an overhead to developers would be incurred whether or not the or
clause approach would be used, but its unclear if you implied the overhead
is due to attorneys or not.

> In fact, if you
> try to go single-license copyleft-next, the contributors' corporate
> lawyer will need to figure out the GPLv2 compatibility issue, so it's
> *more* overhead with the proposed single-copyright license approach.

This argument I can understand, my question was that if such review is
needed, wouldn't it also be needed if the or clause thing was used?

> I'm not sure I understand what you believe to be the benefit of having
> kernel modules solely licensed under copyleft-next

If Linux kernel modules use copyleft-next license header on files / header
files on Linux, the Linux kernel modules would be licensed as GPLv2 as that
is what the license says. So to be clear the modules would not be licensed
under copyleft-next, it would just be license used for the files. Likewise
for these files built-in, when compiled on Linux as built-in they are all
GPLv2.

> and relying on
> lawyers to say, "no really, it's GPLv2 compatible"?  Could you say
> more about that?

Not sure if you mean my motivation for:

a) preferring copyleft-next, or
b) using a single copyleft-next license instead of the dual language

Either way I'll explain both:

a) Its a great effort to reduce legalese language to a maximum while retaining
GPLv2 compatibility as a goal, while also *enabling* copyleft to advance. To achieve
both I thought was an impossibility, and yet we have an effort which claims to have
reached both. I value copyleft and believe its evolution without church or state
to be important so think we are in a better world with such possibility in
particular because Linux is naturally GPLv2 and I contribute to it.

b) Less boiler plate header, that's all. Pegging a dual thing would kind of
defeat the purpose of the whole effort to make it as crystal clear as possible
copyleft-next is GPLv2 compatible and its efforts to reduce license legalese.
If its possible to avoid why not ask, which is what I've done.

====

Being able to use copyleft-next files with a small boiler plate interchangeably
between projects I work on keeps things simple and takes advantage of key
efforts on compatibility, while allowing me to also advance copyleft on my own
projects.

  Luis

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Theodore Ts'o]

Sorry, I guess I wasn't clear enough.  So there are two major cases,
with three sub-cases for each.

1)  The driver is dual-licensed GPLv2 and copyleft-next

   1A) The developer only wants to use the driver, without making
       any changes to it.

   1B) The developer wants to make changes to the driver, and 
       distribute source and binaries

   1C) The developer wants to make changes to the driver, and 
       contribute the changes back to upstream.

2)  The driver is solely licensed under copyleft-next

   2A) The developer only wants to use the driver, without making
       any changes to it.

   2B) The developer wants to make changes to the driver, and 
       distribute source and binaries

   2C) The developer wants to make changes to the driver, and 
       contribute the changes back to upstream.

In cases 1A and 1B, I claim that no additional lawyer ink is required,
because the code can just be distriuted under the terms of the rest of
the kernel --- namely, the GPLv2.  Even in the case where the
developer has made changes to the driver, the change can be released
only under the GPLv2, with the next result that in modified driver,
only the terms of the GPLv2 are controlling.

In the case of 1C, since the developer is contributing changes back to
upstream, and upstream presumably wants to keep the dual-license
nature of the source file, the developer will need to get permission
from their corporate counsel that it's OK for that company to release
code under the copyleft-next license.  And if the counsel is not
familiar with that license, they may need to research what
implications it might have towards the company's patents, etc.  So
there is extra ink in the case of 1C --- but fortunately, that's a
relatively small set in practice for most drivers.

In the single-license copyleft next case, in all of the cases
corporate counsel will need to be engaged if this is a new license and
they haven't analyzed the license yet.  So my claim is that 2A, 2B,
and 2C will require different amounts of extra, additional lawyer ink.

Does my reasoning make more sense now?

> b) Less boiler plate header, that's all. Pegging a dual thing would kind of
> defeat the purpose of the whole effort to make it as crystal clear as possible
> copyleft-next is GPLv2 compatible and its efforts to reduce license legalese.
> If its possible to avoid why not ask, which is what I've done.

I'll note, wrly, that lawyers can't agree on whether or not any boiler plate on
individual source files is needed at all.  Some might argue that:

MODULE_LICENSE("GPL");

is all that's needed, which is pretty simple.  :-)

							- Ted

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Luis R. Rodriguez]

On Thu, May 18, 2017 at 06:12:05PM -0400, Theodore Ts'o wrote:
> Sorry, I guess I wasn't clear enough.  So there are two major cases,
> with three sub-cases for each.
> 
> 1)  The driver is dual-licensed GPLv2 and copyleft-next
> 
>    1A) The developer only wants to use the driver, without making
>        any changes to it.
> 
>    1B) The developer wants to make changes to the driver, and 
>        distribute source and binaries
> 
>    1C) The developer wants to make changes to the driver, and 
>        contribute the changes back to upstream.
> 
> 2)  The driver is solely licensed under copyleft-next
> 
>    2A) The developer only wants to use the driver, without making
>        any changes to it.
> 
>    2B) The developer wants to make changes to the driver, and 
>        distribute source and binaries
> 
>    2C) The developer wants to make changes to the driver, and 
>        contribute the changes back to upstream.
>
> In cases 1A and 1B, I claim that no additional lawyer ink is required,

I really cannot see how you might have an attorney who wants ink on 2A but not 1A.
I really cannot see how you might have an attorney who wants ink on 2B but not 1B.

> because the code can just be distriuted under the terms of the rest of
> the kernel --- namely, the GPLv2.
>
> Even in the case where the
> developer has made changes to the driver, the change can be released
> only under the GPLv2, with the next result that in modified driver,
> only the terms of the GPLv2 are controlling.
>
> In the case of 1C, since the developer is contributing changes back to
> upstream, and upstream presumably wants to keep the dual-license
> nature of the source file, the developer will need to get permission
> from their corporate counsel that it's OK for that company to release
> code under the copyleft-next license.  And if the counsel is not
> familiar with that license, they may need to research what
> implications it might have towards the company's patents, etc.  So
> there is extra ink in the case of 1C --- but fortunately, that's a
> relatively small set in practice for most drivers.
>
> In the single-license copyleft next case, in all of the cases
> corporate counsel will need to be engaged if this is a new license and
> they haven't analyzed the license yet.  So my claim is that 2A, 2B,
> and 2C will require different amounts of extra, additional lawyer ink.
> 
> Does my reasoning make more sense now?

I see what you are saying now however it seems we disagree on what any
careful attorney might do. I have no knowledge of a single attorney who
have ever had a position to green light 1A or 1B just because of the
magical "or" clause is used.

> > b) Less boiler plate header, that's all. Pegging a dual thing would kind of
> > defeat the purpose of the whole effort to make it as crystal clear as possible
> > copyleft-next is GPLv2 compatible and its efforts to reduce license legalese.
> > If its possible to avoid why not ask, which is what I've done.
> 
> I'll note, wrly, that lawyers can't agree on whether or not any boiler plate on
> individual source files is needed at all.  Some might argue that:
> 
> MODULE_LICENSE("GPL");
> 
> is all that's needed, which is pretty simple.  :-)

Sure, but one of the gains of single licensed files is what you can import
from an outside project, or what you can take out and use in another licensed
project. Since Linux *has* that macro though -- I think it is also also
sufficiently clear that the license that applies when copyleft-next is
used on Linux is GPLv2.

So I am arguing that the MODULE_LICENSE() macro says *much* more than that
silly or clause does given that the license is explicit about license
compatibility when such licensed code is used on larger GPLv2 projects.

  Luis

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[David Lang]

On Fri, 19 May 2017, Luis R. Rodriguez wrote:

> On Thu, May 18, 2017 at 06:12:05PM -0400, Theodore Ts'o wrote:
>> Sorry, I guess I wasn't clear enough.  So there are two major cases,
>> with three sub-cases for each.
>>
>> 1)  The driver is dual-licensed GPLv2 and copyleft-next
>>
>>    1A) The developer only wants to use the driver, without making
>>        any changes to it.
>>
>>    1B) The developer wants to make changes to the driver, and
>>        distribute source and binaries
>>
>>    1C) The developer wants to make changes to the driver, and
>>        contribute the changes back to upstream.
>>
>> 2)  The driver is solely licensed under copyleft-next
>>
>>    2A) The developer only wants to use the driver, without making
>>        any changes to it.
>>
>>    2B) The developer wants to make changes to the driver, and
>>        distribute source and binaries
>>
>>    2C) The developer wants to make changes to the driver, and
>>        contribute the changes back to upstream.
>>
>> In cases 1A and 1B, I claim that no additional lawyer ink is required,
>
> I really cannot see how you might have an attorney who wants ink on 2A but not 1A.
> I really cannot see how you might have an attorney who wants ink on 2B but not 1B.

If something is under multiple licences, and one is a license that is known, you 
can just use that license and not worry (or even think) about what other 
licenses are available.

But if it's a new license, then it needs to be analyzed, and that takes lawyer 
ink.

That's why 1A and 1B are ok, you can ignore copyleft-next and just use GPLv2

David Lang

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Luis R. Rodriguez]

On Thu, May 18, 2017 at 4:08 PM, David Lang <david@lang.hm> wrote:
> On Fri, 19 May 2017, Luis R. Rodriguez wrote:
>
>> On Thu, May 18, 2017 at 06:12:05PM -0400, Theodore Ts'o wrote:
>>>
>>> Sorry, I guess I wasn't clear enough.  So there are two major cases,
>>> with three sub-cases for each.
>>>
>>> 1)  The driver is dual-licensed GPLv2 and copyleft-next
>>>
>>>    1A) The developer only wants to use the driver, without making
>>>        any changes to it.
>>>
>>>    1B) The developer wants to make changes to the driver, and
>>>        distribute source and binaries
>>>
>>>    1C) The developer wants to make changes to the driver, and
>>>        contribute the changes back to upstream.
>>>
>>> 2)  The driver is solely licensed under copyleft-next
>>>
>>>    2A) The developer only wants to use the driver, without making
>>>        any changes to it.
>>>
>>>    2B) The developer wants to make changes to the driver, and
>>>        distribute source and binaries
>>>
>>>    2C) The developer wants to make changes to the driver, and
>>>        contribute the changes back to upstream.
>>>
>>> In cases 1A and 1B, I claim that no additional lawyer ink is required,
>>
>>
>> I really cannot see how you might have an attorney who wants ink on 2A but
>> not 1A.
>> I really cannot see how you might have an attorney who wants ink on 2B but
>> not 1B.
>
>
> If something is under multiple licences, and one is a license that is known,
> you can just use that license and not worry (or even think) about what other
> licenses are available.
>
> But if it's a new license, then it needs to be analyzed, and that takes
> lawyer ink.
>
> That's why 1A and 1B are ok, you can ignore copyleft-next and just use GPLv2

The article I had referred to indicates how there are actually
*several* "or" clauses, and ambiguity between what they might mean.
Hence my surprise attorneys would exist who choose to green light all
code with a magical "or clause".

 Luis

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Theodore Ts'o]

On Thu, May 18, 2017 at 04:29:23PM -0700, Luis R. Rodriguez wrote:
> 
> The article I had referred to indicates how there are actually
> *several* "or" clauses, and ambiguity between what they might mean.
> Hence my surprise attorneys would exist who choose to green light all
> code with a magical "or clause".

By default, copyright law prohibits you from distributing, using, or
sublicensing any copyrighted materials at *all*.  The only reason why
you can is because of copyright license.

If one of the copyright licenses allows you to distribute, use, and/or
sublicense a particular piece of software you want to use, and you are
OK with meeting the requirements of that license, the fact that the
license might be available under a different set of terms is
irrelevant to you.

For example, if I say, "you may only use this piece of software if you
comply with the terms of the GPLv2, ***or*** if you agree to a license
which requires you to pay me ten million dollars and to run around
naked in Times Square, New York City for ten minutes, at high noon,
every Summer Soltice", so long as you are willing to agree to the
GPLv2, the fact that it is dual licensed under some other, completely
new, novel, and probably bogus license, doesn't really matter to a
lawyer who is advising someone who is contemplating using that piece
of software.

Even C compilers understand this concept:

	if (isGPLv2OK || isCopyleftNextOK) {
	   ....
	}

If "isGPLv2OK" is true, the compiler won't even bother evaluating
isCopyleftNextOK....

						- Ted

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Alan Cox]

> I really cannot see how you might have an attorney who wants ink on
> 2A but not 1A.
> I really cannot see how you might have an attorney who wants ink on
> 2B but not 1B.

Because their job is to protect their whomsoever they represent. They
protect them drawing upon case law and providing rules based upon
caselaw so that people don't have to keep bothering them.

The lawyers have caselaw for "either a or b" licensing. They don't have
caselaw for licence compatibility with your licence. Therefore it's a
risk.

> project. Since Linux *has* that macro though -- I think it is also
> also
> sufficiently clear that the license that applies when copyleft-next
> is
> used on Linux is GPLv2.

Show me the caselaw.


You'll note that the people concerned about this are people who work
for large companies and spend our time dealing with lawyers. This is
based upon experience (sometimes painful) not on theory.

Alan

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Luis R. Rodriguez]

On Fri, May 19, 2017 at 12:31:50PM +0100, Alan Cox wrote:
> > I really cannot see how you might have an attorney who wants ink on
> > 2A but not 1A.
> > I really cannot see how you might have an attorney who wants ink on
> > 2B but not 1B.
> 
> Because their job is to protect their whomsoever they represent. They
> protect them drawing upon case law and providing rules based upon
> caselaw so that people don't have to keep bothering them.
> 
> The lawyers have caselaw for "either a or b" licensing. They don't have
> caselaw for licence compatibility with your licence. Therefore it's a
> risk.

Alright, this makes sense.

As noted though there are a few "or" clauses, which upstream file
is a good template to use for copyleft-next ?

  Luis

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Luis R. Rodriguez]

On Fri, May 19, 2017 at 05:09:20PM +0200, Luis R. Rodriguez wrote:
> On Fri, May 19, 2017 at 12:31:50PM +0100, Alan Cox wrote:
> > > I really cannot see how you might have an attorney who wants ink on
> > > 2A but not 1A.
> > > I really cannot see how you might have an attorney who wants ink on
> > > 2B but not 1B.
> > 
> > Because their job is to protect their whomsoever they represent. They
> > protect them drawing upon case law and providing rules based upon
> > caselaw so that people don't have to keep bothering them.
> > 
> > The lawyers have caselaw for "either a or b" licensing. They don't have
> > caselaw for licence compatibility with your licence. Therefore it's a
> > risk.
> 
> Alright, this makes sense.
> 
> As noted though there are a few "or" clauses, which upstream file
> is a good template to use for copyleft-next ?

There seems to be a few "or" clauses. For instance:

a) you can pick either license [0]
b) gpl on Linux, otherwise this other license below [1]

To help uplift copyleft will go with b).

[0] drivers/infiniband/hw/hfi1/driver.c
[1] drivers/block/xen-blkback/blkback.c

  Luis

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Luis R. Rodriguez]

On Fri, May 19, 2017 at 10:59 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> On Fri, May 19, 2017 at 05:09:20PM +0200, Luis R. Rodriguez wrote:
>> On Fri, May 19, 2017 at 12:31:50PM +0100, Alan Cox wrote:
>> > > I really cannot see how you might have an attorney who wants ink on
>> > > 2A but not 1A.
>> > > I really cannot see how you might have an attorney who wants ink on
>> > > 2B but not 1B.
>> >
>> > Because their job is to protect their whomsoever they represent. They
>> > protect them drawing upon case law and providing rules based upon
>> > caselaw so that people don't have to keep bothering them.
>> >
>> > The lawyers have caselaw for "either a or b" licensing. They don't have
>> > caselaw for licence compatibility with your licence. Therefore it's a
>> > risk.
>>
>> Alright, this makes sense.
>>
>> As noted though there are a few "or" clauses, which upstream file
>> is a good template to use for copyleft-next ?
>
> There seems to be a few "or" clauses. For instance:
>
> a) you can pick either license [0]
> b) gpl on Linux, otherwise this other license below [1]
>
> To help uplift copyleft will go with b).
>
> [0] drivers/infiniband/hw/hfi1/driver.c
> [1] drivers/block/xen-blkback/blkback.c

So that yields:

 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License as published by the Free
 * Software Foundation; either version 2 of the License, or at your option) any
 * later version; or, when distributed separately from the Linux kernel or
 * incorporated into other software packages, subject to the following license:
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of copyleft-next (version 0.3.1 or later) as published
 * at http://copyleft-next.org/.

If there are issue please let me know.

  Luis

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Alan Cox]

> So that yields:
> 
>  * This program is free software; you can redistribute it and/or
> modify it
>  * under the terms of the GNU General Public License as published by
> the Free
>  * Software Foundation; either version 2 of the License, or at your
> option) any
>  * later version; or, when distributed separately from the Linux
> kernel or
>  * incorporated into other software packages, subject to the
> following license:
>  *
>  * This program is free software; you can redistribute it and/or
> modify it
>  * under the terms of copyleft-next (version 0.3.1 or later) as
> published
>  * at http://copyleft-next.org/.


Works for me

Alan

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

Hi!

> >> Alright, this makes sense.
> >>
> >> As noted though there are a few "or" clauses, which upstream file
> >> is a good template to use for copyleft-next ?
> >
> > There seems to be a few "or" clauses. For instance:
> >
> > a) you can pick either license [0]
> > b) gpl on Linux, otherwise this other license below [1]
> >
> > To help uplift copyleft will go with b).
> >
> > [0] drivers/infiniband/hw/hfi1/driver.c
> > [1] drivers/block/xen-blkback/blkback.c
> 
> So that yields:
> 
>  * This program is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License as published by the Free
>  * Software Foundation; either version 2 of the License, or at your option) any
>  * later version; or, when distributed separately from the Linux kernel or
>  * incorporated into other software packages, subject to the

You have more )s there than (s.

Can you get rid of the "when distributed separately from the Linux
kernel or incorporated into other software packages," wording? I'm not
exactly sure what it is trying to say, and if it limits the license
below in any way.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Luis R. Rodriguez]

On Thu, May 25, 2017 at 07:05:18PM +0200, Pavel Machek wrote:
> Hi!
> 
> > >> Alright, this makes sense.
> > >>
> > >> As noted though there are a few "or" clauses, which upstream file
> > >> is a good template to use for copyleft-next ?
> > >
> > > There seems to be a few "or" clauses. For instance:
> > >
> > > a) you can pick either license [0]
> > > b) gpl on Linux, otherwise this other license below [1]
> > >
> > > To help uplift copyleft will go with b).
> > >
> > > [0] drivers/infiniband/hw/hfi1/driver.c
> > > [1] drivers/block/xen-blkback/blkback.c
> > 
> > So that yields:
> > 
> >  * This program is free software; you can redistribute it and/or modify it
> >  * under the terms of the GNU General Public License as published by the Free
> >  * Software Foundation; either version 2 of the License, or at your option) any
> >  * later version; or, when distributed separately from the Linux kernel or
> >  * incorporated into other software packages, subject to the
> 
> You have more )s there than (s.

Thanks just removed that pesky )

> Can you get rid of the "when distributed separately from the Linux
> kernel or incorporated into other software packages," wording? I'm not
> exactly sure what it is trying to say, and if it limits the license
> below in any way.

I had to pick an "or language" used already upstream and which folks were OK
with, this was one and I went with it. I prefer it as it makes it clear the
intent is outside of Linux I wish copyleft-next to apply.

  Luis

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

Hi!

> > > So that yields:
> > > 
> > >  * This program is free software; you can redistribute it and/or modify it
> > >  * under the terms of the GNU General Public License as published by the Free
> > >  * Software Foundation; either version 2 of the License, or at your option) any
> > >  * later version; or, when distributed separately from the Linux kernel or
> > >  * incorporated into other software packages, subject to the
> > 
> > You have more )s there than (s.
> 
> Thanks just removed that pesky )
> 
> > Can you get rid of the "when distributed separately from the Linux
> > kernel or incorporated into other software packages," wording? I'm not
> > exactly sure what it is trying to say, and if it limits the license
> > below in any way.
> 
> I had to pick an "or language" used already upstream and which folks were OK
> with, this was one and I went with it. I prefer it as it makes it clear the
> intent is outside of Linux I wish copyleft-next to apply.

Yes, the intent is clear. What is not clear is if the intent is
legally binding.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Luis R. Rodriguez]

On Thu, May 25, 2017 at 1:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> > > So that yields:
>> > >
>> > >  * This program is free software; you can redistribute it and/or modify it
>> > >  * under the terms of the GNU General Public License as published by the Free
>> > >  * Software Foundation; either version 2 of the License, or at your option) any
>> > >  * later version; or, when distributed separately from the Linux kernel or
>> > >  * incorporated into other software packages, subject to the
>> >
>> > You have more )s there than (s.
>>
>> Thanks just removed that pesky )
>>
>> > Can you get rid of the "when distributed separately from the Linux
>> > kernel or incorporated into other software packages," wording? I'm not
>> > exactly sure what it is trying to say, and if it limits the license
>> > below in any way.
>>
>> I had to pick an "or language" used already upstream and which folks were OK
>> with, this was one and I went with it. I prefer it as it makes it clear the
>> intent is outside of Linux I wish copyleft-next to apply.
>
> Yes, the intent is clear. What is not clear is if the intent is
> legally binding.

Code already is upstream (Xen) with this sort of or language. I think
that's sufficient for me, unless of course you have something better
to recommend.

 Luis

Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Richard Fontana]

On Tue, Aug 09, 2016 at 09:04:35PM +0100, Alan Cox wrote:
> Outside of the "derivative work" GPL clause they don't quite look
> compatible to me as a non-lawyer (eg the definition of "source code"
> looks to differ on scripts etc). 

The clause that permits derived works to be licensed under the GPL is
all that's needed for GPL compatibility (in the sense that combined
works of GPL-licensed and copyleft-next-licensed code can be licensed
under the GPL without imposition of any additional restrictions on
downstream recipients).

Richard