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

Groups > linux.kernel > #1641791 > unrolled thread

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

Back to article view | Back to linux.kernel

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

Contents

  Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2]  module.h: add copyleft-next >= 0.3.1 as GPL compatible) Alan Cox <alan@linux.intel.com> - 2017-05-15 17:20 +0200
    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" <mcgrof@kernel.org> - 2017-05-17 01:30 +0200
      Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2]  module.h: add copyleft-next >= 0.3.1 as GPL compatible) Alan Cox <alan@linux.intel.com> - 2017-05-17 15:40 +0200
      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 <tytso@mit.edu> - 2017-05-17 19:00 +0200
        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" <mcgrof@kernel.org> - 2017-05-17 19:50 +0200
          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 <tytso@mit.edu> - 2017-05-19 00:20 +0200
            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" <mcgrof@kernel.org> - 2017-05-19 01:10 +0200
              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 <david@lang.hm> - 2017-05-19 01:30 +0200
                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" <mcgrof@kernel.org> - 2017-05-19 01:30 +0200
                  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 <tytso@mit.edu> - 2017-05-19 17:20 +0200
              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 <alan@linux.intel.com> - 2017-05-19 13:40 +0200
                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" <mcgrof@kernel.org> - 2017-05-19 17:10 +0200
                  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" <mcgrof@kernel.org> - 2017-05-19 20:10 +0200
                    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" <mcgrof@kernel.org> - 2017-05-19 20:10 +0200
                      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 <alan@linux.intel.com> - 2017-05-20 01:00 +0200

#1641791 — Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL 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.

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

[toc] | [next] | [standalone]

#1642896

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

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

#1643363

> 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

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

#1643515

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

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

#1643552 — 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)

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

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

#1644937 — 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)

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

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

#1644948 — 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)

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

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

#1644952 — 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)

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

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

#1644955 — 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)

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

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

#1645675 — 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)

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

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

#1645539 — 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)

> 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

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

#1645673 — 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)

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

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

#1645809 — 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)

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

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

#1645811 — 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)

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

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

#1645993 — 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)

> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web