LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Rafał Miłecki]

Hi,

Due to some maintainers *preferring* BSD-compatible license for DTS
files [0], I was writing mine using ISC. I had no very special reason
for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
ISC as I read about its "removal of language deemed unnecessary".

I took a moment to look at the new SPDX thing and noticed that:
1) File license-rules.rst provides "LICENSES/other/ISC" as an example
2) License file LICENSES/other/ISC doesn't exist
3) ISC is listed as an *example* under the "Not recommended licenses"

First of all, as ISC is used by some files in the Linux kernel, I
think it's worth adding to the LICENSE/*/ISC.

Secondly, it isn't 100% clear to me if ISC is preferred or not
recommended. File license-rules.rst suggests the later by listing it
as an example for "Not recommended". It's just an example though, so
I'm not 100% sure without seeing it in either: "preferred" or "other"
directories. Also if anyone finds it "Not recommended", can we get a
short explanation why is it so, please?

[0] https://lkml.org/lkml/2016/5/4/707

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Rafał Miłecki]

Hi,

Due to some maintainers *preferring* BSD-compatible license for DTS
files [0], I was writing mine using ISC. I had no very special reason
for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
ISC as I read about its "removal of language deemed unnecessary".

I took a moment to look at the new SPDX thing and noticed that:
1) File license-rules.rst provides "LICENSES/other/ISC" as an example
2) License file LICENSES/other/ISC doesn't exist
3) ISC is listed as an *example* under the "Not recommended licenses"

First of all, as ISC is used by some files in the Linux kernel, I
think it's worth adding to the LICENSE/*/ISC.

Secondly, it isn't 100% clear to me if ISC is preferred or not
recommended. File license-rules.rst suggests the later by listing it
as an example for "Not recommended". It's just an example though, so
I'm not 100% sure without seeing it in either: "preferred" or "other"
directories. Also if anyone finds it "Not recommended", can we get a
short explanation why is it so, please?

[0] https://lkml.org/lkml/2016/5/4/707

-- 
Rafał

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Greg Kroah-Hartman]

On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote:
> Hi,
> 
> Due to some maintainers *preferring* BSD-compatible license for DTS
> files [0], I was writing mine using ISC. I had no very special reason
> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
> ISC as I read about its "removal of language deemed unnecessary".
> 
> I took a moment to look at the new SPDX thing and noticed that:
> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example

Yeah, bad example, we should fix that text up.  Care to send a patch? :)

> 2) License file LICENSES/other/ISC doesn't exist
> 3) ISC is listed as an *example* under the "Not recommended licenses"

Yes, please don't use it if at all possible.

> First of all, as ISC is used by some files in the Linux kernel, I
> think it's worth adding to the LICENSE/*/ISC.

I see it is only used in a very small number of dts files.  Why not just
use BSD-2-Clause instead?  What do you find in ISC that is not available
to you with just BSD?

> Secondly, it isn't 100% clear to me if ISC is preferred or not
> recommended. File license-rules.rst suggests the later by listing it
> as an example for "Not recommended". It's just an example though, so
> I'm not 100% sure without seeing it in either: "preferred" or "other"
> directories. Also if anyone finds it "Not recommended", can we get a
> short explanation why is it so, please?

The license is functionally equalivant to BSD-2, so why would you want
to add more complexity here and have two licenses that are the same be
"recommended"?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Greg Kroah-Hartman]

On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote:
> Hi,
> 
> Due to some maintainers *preferring* BSD-compatible license for DTS
> files [0], I was writing mine using ISC. I had no very special reason
> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
> ISC as I read about its "removal of language deemed unnecessary".
> 
> I took a moment to look at the new SPDX thing and noticed that:
> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example

Yeah, bad example, we should fix that text up.  Care to send a patch? :)

> 2) License file LICENSES/other/ISC doesn't exist
> 3) ISC is listed as an *example* under the "Not recommended licenses"

Yes, please don't use it if at all possible.

> First of all, as ISC is used by some files in the Linux kernel, I
> think it's worth adding to the LICENSE/*/ISC.

I see it is only used in a very small number of dts files.  Why not just
use BSD-2-Clause instead?  What do you find in ISC that is not available
to you with just BSD?

> Secondly, it isn't 100% clear to me if ISC is preferred or not
> recommended. File license-rules.rst suggests the later by listing it
> as an example for "Not recommended". It's just an example though, so
> I'm not 100% sure without seeing it in either: "preferred" or "other"
> directories. Also if anyone finds it "Not recommended", can we get a
> short explanation why is it so, please?

The license is functionally equalivant to BSD-2, so why would you want
to add more complexity here and have two licenses that are the same be
"recommended"?

thanks,

greg k-h

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Luis R. Rodriguez]

On Sun, Apr 29, 2018 at 07:26:17AM +0200, Greg Kroah-Hartman wrote:
> I see it is only used in a very small number of dts files.  Why not just
> use BSD-2-Clause instead?  What do you find in ISC that is not available
> to you with just BSD?

ISC license is a simplified version of the BSD license due to the Berne
convention. It was also used for wireless drivers to help the BSD community in
particular OpenBSD who had picked that license for new contributions claimed
simplification of the BSD-2-Clause. Because of this reason many BSD communities
feel super comfortable with picking up kernel code in Linux under this license.

Granted, I'm on no longer a fan of promoting permissive licenses as it didn't
buy us cross-collaboration at all. We tried.

But it would be unfair to advice against a license unless a reason is stated in
favor of another BSD license. Why is the ISC license worse than the
BSD-2-Clause?

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Luis R. Rodriguez]

On Sun, Apr 29, 2018 at 07:26:17AM +0200, Greg Kroah-Hartman wrote:
> I see it is only used in a very small number of dts files.  Why not just
> use BSD-2-Clause instead?  What do you find in ISC that is not available
> to you with just BSD?

ISC license is a simplified version of the BSD license due to the Berne
convention. It was also used for wireless drivers to help the BSD community in
particular OpenBSD who had picked that license for new contributions claimed
simplification of the BSD-2-Clause. Because of this reason many BSD communities
feel super comfortable with picking up kernel code in Linux under this license.

Granted, I'm on no longer a fan of promoting permissive licenses as it didn't
buy us cross-collaboration at all. We tried.

But it would be unfair to advice against a license unless a reason is stated in
favor of another BSD license. Why is the ISC license worse than the
BSD-2-Clause?

  Luis

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Luis R. Rodriguez]

On Sun, Apr 29, 2018 at 07:03:15AM +0000, Luis R. Rodriguez wrote:
> On Sun, Apr 29, 2018 at 07:26:17AM +0200, Greg Kroah-Hartman wrote:
> > I see it is only used in a very small number of dts files.  Why not just
> > use BSD-2-Clause instead?  What do you find in ISC that is not available
> > to you with just BSD?
> 
> ISC license is a simplified version of the BSD license due to the Berne
> convention. It was also used for wireless drivers to help the BSD community in
> particular OpenBSD who had picked that license for new contributions claimed
> simplification of the BSD-2-Clause. Because of this reason many BSD communities
> feel super comfortable with picking up kernel code in Linux under this license.
> 
> Granted, I'm on no longer a fan of promoting permissive licenses as it didn't
> buy us cross-collaboration at all. We tried.
> 
> But it would be unfair to advice against a license unless a reason is stated in
> favor of another BSD license. Why is the ISC license worse than the
> BSD-2-Clause?

Here's a good 'ol discussed reason as to why to prefer the 2-clause BSD
I suppose, and also to consider dual licensing actually:

http://lkml.kernel.org/r/20120408155709.1c817f1f@pyramind.ukuu.org.uk

So essentially tested over time, runtime considerations, and whatever the FSF
decides today may change tomorrow. So best to be safe. The dual licensing
strategy also helps with "unanticipated incompatibility".

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Luis R. Rodriguez]

On Sun, Apr 29, 2018 at 07:03:15AM +0000, Luis R. Rodriguez wrote:
> On Sun, Apr 29, 2018 at 07:26:17AM +0200, Greg Kroah-Hartman wrote:
> > I see it is only used in a very small number of dts files.  Why not just
> > use BSD-2-Clause instead?  What do you find in ISC that is not available
> > to you with just BSD?
> 
> ISC license is a simplified version of the BSD license due to the Berne
> convention. It was also used for wireless drivers to help the BSD community in
> particular OpenBSD who had picked that license for new contributions claimed
> simplification of the BSD-2-Clause. Because of this reason many BSD communities
> feel super comfortable with picking up kernel code in Linux under this license.
> 
> Granted, I'm on no longer a fan of promoting permissive licenses as it didn't
> buy us cross-collaboration at all. We tried.
> 
> But it would be unfair to advice against a license unless a reason is stated in
> favor of another BSD license. Why is the ISC license worse than the
> BSD-2-Clause?

Here's a good 'ol discussed reason as to why to prefer the 2-clause BSD
I suppose, and also to consider dual licensing actually:

http://lkml.kernel.org/r/20120408155709.1c817f1f@pyramind.ukuu.org.uk

So essentially tested over time, runtime considerations, and whatever the FSF
decides today may change tomorrow. So best to be safe. The dual licensing
strategy also helps with "unanticipated incompatibility".

  Luis

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Rafał Miłecki]

On 29 April 2018 at 07:26, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote:
>> Due to some maintainers *preferring* BSD-compatible license for DTS
>> files [0], I was writing mine using ISC. I had no very special reason
>> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
>> ISC as I read about its "removal of language deemed unnecessary".
>>
>> I took a moment to look at the new SPDX thing and noticed that:
>> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example
>
> Yeah, bad example, we should fix that text up.  Care to send a patch? :)

Sure. I see that license-rules.rst also refers to LICENSES/other/ZLib
which also doesn't exist.

As "other" directory contains only GPL-1.0 and MPL-1.1 I guess one of
these should be referenced.


>> 2) License file LICENSES/other/ISC doesn't exist
>> 3) ISC is listed as an *example* under the "Not recommended licenses"
>
> Yes, please don't use it if at all possible.
>
>> First of all, as ISC is used by some files in the Linux kernel, I
>> think it's worth adding to the LICENSE/*/ISC.
>
> I see it is only used in a very small number of dts files.  Why not just
> use BSD-2-Clause instead?  What do you find in ISC that is not available
> to you with just BSD?

As said, I read about its "removal of language deemed unnecessary". I
assumed that the simpler license text the better.


>> Secondly, it isn't 100% clear to me if ISC is preferred or not
>> recommended. File license-rules.rst suggests the later by listing it
>> as an example for "Not recommended". It's just an example though, so
>> I'm not 100% sure without seeing it in either: "preferred" or "other"
>> directories. Also if anyone finds it "Not recommended", can we get a
>> short explanation why is it so, please?
>
> The license is functionally equalivant to BSD-2, so why would you want
> to add more complexity here and have two licenses that are the same be
> "recommended"?

I don't insist on it, I'm trying to figure out what's the best for the
Linux community.

On the other hand I could ask why do we want more complexity by having
MIT license. It's very similar to the BSD-2-Clause after all. AFAIK
the only minor differences are that:
1) MIT clearly allows sublicensing
2) BSD 2-Clause clearly requires distributing *binaries* with
copyrights + license text

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Rafał Miłecki]

On 29 April 2018 at 07:26, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote:
>> Due to some maintainers *preferring* BSD-compatible license for DTS
>> files [0], I was writing mine using ISC. I had no very special reason
>> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
>> ISC as I read about its "removal of language deemed unnecessary".
>>
>> I took a moment to look at the new SPDX thing and noticed that:
>> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example
>
> Yeah, bad example, we should fix that text up.  Care to send a patch? :)

Sure. I see that license-rules.rst also refers to LICENSES/other/ZLib
which also doesn't exist.

As "other" directory contains only GPL-1.0 and MPL-1.1 I guess one of
these should be referenced.


>> 2) License file LICENSES/other/ISC doesn't exist
>> 3) ISC is listed as an *example* under the "Not recommended licenses"
>
> Yes, please don't use it if at all possible.
>
>> First of all, as ISC is used by some files in the Linux kernel, I
>> think it's worth adding to the LICENSE/*/ISC.
>
> I see it is only used in a very small number of dts files.  Why not just
> use BSD-2-Clause instead?  What do you find in ISC that is not available
> to you with just BSD?

As said, I read about its "removal of language deemed unnecessary". I
assumed that the simpler license text the better.


>> Secondly, it isn't 100% clear to me if ISC is preferred or not
>> recommended. File license-rules.rst suggests the later by listing it
>> as an example for "Not recommended". It's just an example though, so
>> I'm not 100% sure without seeing it in either: "preferred" or "other"
>> directories. Also if anyone finds it "Not recommended", can we get a
>> short explanation why is it so, please?
>
> The license is functionally equalivant to BSD-2, so why would you want
> to add more complexity here and have two licenses that are the same be
> "recommended"?

I don't insist on it, I'm trying to figure out what's the best for the
Linux community.

On the other hand I could ask why do we want more complexity by having
MIT license. It's very similar to the BSD-2-Clause after all. AFAIK
the only minor differences are that:
1) MIT clearly allows sublicensing
2) BSD 2-Clause clearly requires distributing *binaries* with
copyrights + license text

-- 
Rafał

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Greg Kroah-Hartman]

On Sun, Apr 29, 2018 at 12:15:11PM +0200, Rafał Miłecki wrote:
> On 29 April 2018 at 07:26, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote:
> >> Due to some maintainers *preferring* BSD-compatible license for DTS
> >> files [0], I was writing mine using ISC. I had no very special reason
> >> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
> >> ISC as I read about its "removal of language deemed unnecessary".
> >>
> >> I took a moment to look at the new SPDX thing and noticed that:
> >> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example
> >
> > Yeah, bad example, we should fix that text up.  Care to send a patch? :)
> 
> Sure. I see that license-rules.rst also refers to LICENSES/other/ZLib
> which also doesn't exist.
> 
> As "other" directory contains only GPL-1.0 and MPL-1.1 I guess one of
> these should be referenced.

See the patch set that Thomas has posted to hopefully resolve these
issues.  I think they are all now taken care of with that series.

> >> 2) License file LICENSES/other/ISC doesn't exist
> >> 3) ISC is listed as an *example* under the "Not recommended licenses"
> >
> > Yes, please don't use it if at all possible.
> >
> >> First of all, as ISC is used by some files in the Linux kernel, I
> >> think it's worth adding to the LICENSE/*/ISC.
> >
> > I see it is only used in a very small number of dts files.  Why not just
> > use BSD-2-Clause instead?  What do you find in ISC that is not available
> > to you with just BSD?
> 
> As said, I read about its "removal of language deemed unnecessary". I
> assumed that the simpler license text the better.

Simple up to a point, having loads of different licenses is a mess, as
you are finding out :)

> >> Secondly, it isn't 100% clear to me if ISC is preferred or not
> >> recommended. File license-rules.rst suggests the later by listing it
> >> as an example for "Not recommended". It's just an example though, so
> >> I'm not 100% sure without seeing it in either: "preferred" or "other"
> >> directories. Also if anyone finds it "Not recommended", can we get a
> >> short explanation why is it so, please?
> >
> > The license is functionally equalivant to BSD-2, so why would you want
> > to add more complexity here and have two licenses that are the same be
> > "recommended"?
> 
> I don't insist on it, I'm trying to figure out what's the best for the
> Linux community.
> 
> On the other hand I could ask why do we want more complexity by having
> MIT license. It's very similar to the BSD-2-Clause after all. AFAIK
> the only minor differences are that:
> 1) MIT clearly allows sublicensing
> 2) BSD 2-Clause clearly requires distributing *binaries* with
> copyrights + license text

I think you will find more dual-licensed MIT code in the tree already
than ISC, right?

And really, in the end, the odds of someone taking this code _out_ of
the tree and using it only under a non-GPLv2 license is slim, to none,
so it's best to just stick with the common licenses, as long as they
match what you wish the code to abide by.  As you want to follow what
MIT says, then just use that and all should be good, right?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Greg Kroah-Hartman]

On Sun, Apr 29, 2018 at 12:15:11PM +0200, Rafał Miłecki wrote:
> On 29 April 2018 at 07:26, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote:
> >> Due to some maintainers *preferring* BSD-compatible license for DTS
> >> files [0], I was writing mine using ISC. I had no very special reason
> >> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
> >> ISC as I read about its "removal of language deemed unnecessary".
> >>
> >> I took a moment to look at the new SPDX thing and noticed that:
> >> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example
> >
> > Yeah, bad example, we should fix that text up.  Care to send a patch? :)
> 
> Sure. I see that license-rules.rst also refers to LICENSES/other/ZLib
> which also doesn't exist.
> 
> As "other" directory contains only GPL-1.0 and MPL-1.1 I guess one of
> these should be referenced.

See the patch set that Thomas has posted to hopefully resolve these
issues.  I think they are all now taken care of with that series.

> >> 2) License file LICENSES/other/ISC doesn't exist
> >> 3) ISC is listed as an *example* under the "Not recommended licenses"
> >
> > Yes, please don't use it if at all possible.
> >
> >> First of all, as ISC is used by some files in the Linux kernel, I
> >> think it's worth adding to the LICENSE/*/ISC.
> >
> > I see it is only used in a very small number of dts files.  Why not just
> > use BSD-2-Clause instead?  What do you find in ISC that is not available
> > to you with just BSD?
> 
> As said, I read about its "removal of language deemed unnecessary". I
> assumed that the simpler license text the better.

Simple up to a point, having loads of different licenses is a mess, as
you are finding out :)

> >> Secondly, it isn't 100% clear to me if ISC is preferred or not
> >> recommended. File license-rules.rst suggests the later by listing it
> >> as an example for "Not recommended". It's just an example though, so
> >> I'm not 100% sure without seeing it in either: "preferred" or "other"
> >> directories. Also if anyone finds it "Not recommended", can we get a
> >> short explanation why is it so, please?
> >
> > The license is functionally equalivant to BSD-2, so why would you want
> > to add more complexity here and have two licenses that are the same be
> > "recommended"?
> 
> I don't insist on it, I'm trying to figure out what's the best for the
> Linux community.
> 
> On the other hand I could ask why do we want more complexity by having
> MIT license. It's very similar to the BSD-2-Clause after all. AFAIK
> the only minor differences are that:
> 1) MIT clearly allows sublicensing
> 2) BSD 2-Clause clearly requires distributing *binaries* with
> copyrights + license text

I think you will find more dual-licensed MIT code in the tree already
than ISC, right?

And really, in the end, the odds of someone taking this code _out_ of
the tree and using it only under a non-GPLv2 license is slim, to none,
so it's best to just stick with the common licenses, as long as they
match what you wish the code to abide by.  As you want to follow what
MIT says, then just use that and all should be good, right?

thanks,

greg k-h