Re: [PATCH RFC 1/4] LICENSES: Add SIL Open Font License 1.1

Re: [PATCH RFC 1/4] LICENSES: Add SIL Open Font License 1.1

[Bagas Sanjaya]

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

On Thu, Nov 02, 2023 at 03:06:19PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Nov 02, 2023 at 07:00:43PM +0700, Bagas Sanjaya wrote:
> > Add the license text along with appropriate tags for reference and
> > tooling. The text is taken from the text as distributed in Google
> > Fonts's zip files.
> > 
> > As the license itself may or may note be compatible with GPLv2,
> > let's take on the err side and require combining it with
> > GPL-compatible licenses when using the license.
> > 
> > Cc: linux-spdx@vger.kernel.org
> > Cc: Richard Fontana <rfontana@redhat.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> > ---
> >  LICENSES/dual/OFL-1.1 | 107 ++++++++++++++++++++++++++++++++++++++++++
> 
> You add this license, but then never actually reference it in the later
> changes, so it's going to be very confusing as to why it is here.  Any
> way to add it to the font files themselves so our checker tools can
> handle this properly?

There is TTF name string ID called "License". For example, on IBM Plex Sans,
the string value is:

```
This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: http://scripts.sil.org/OFL
```

Checking that string requires scripting fontforge, and since the string value
may differ (but has the same license) across different fonts, scripting it
can be non-trivial.

> 
> And, it's not going to work as a dual-license, you can't just suddenly
> dual-license those font files, right?

I was thinking of putting OFL in LICENSES/exceptions instead due to this
nature.

> 
> >  1 file changed, 107 insertions(+)
> >  create mode 100644 LICENSES/dual/OFL-1.1
> > 
> > diff --git a/LICENSES/dual/OFL-1.1 b/LICENSES/dual/OFL-1.1
> > new file mode 100644
> > index 00000000000000..00b8db08bd0e54
> > --- /dev/null
> > +++ b/LICENSES/dual/OFL-1.1
> > @@ -0,0 +1,107 @@
> > +Valid-License-Identifier: OFL-1.1
> > +SPDX-URL: https://spdx.org/licenses/OFL-1.1
> > +Usage-Guide:
> > +  Do NOT use this license for code, but it's acceptable for fonts (where the
> > +  license is specifically written for them). It's best to use it together
> > +  with a GPL2 compatible license using "OR", as OFL-1.1 texts processed by
> > +  the kernel's build system might combine it with content taken from more
> > +  restrictive licenses.
> > +  To use the SIL Open Font License 1.1, put the following SPDX tag/value pair
> > +  into a comment according to the placement guidelines in the licensing rules
> > +  documentation:
> > +    SPDX-License-Identifier: OFL-1.1
> 
> Where did this Usage-Guide from?

Adapted from LICENSES/dual/CC-BY-4.0.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH RFC 1/4] LICENSES: Add SIL Open Font License 1.1

[Greg Kroah-Hartman]

On Fri, Nov 03, 2023 at 03:11:36PM +0700, Bagas Sanjaya wrote:
> On Thu, Nov 02, 2023 at 03:06:19PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Nov 02, 2023 at 07:00:43PM +0700, Bagas Sanjaya wrote:
> > > Add the license text along with appropriate tags for reference and
> > > tooling. The text is taken from the text as distributed in Google
> > > Fonts's zip files.
> > > 
> > > As the license itself may or may note be compatible with GPLv2,
> > > let's take on the err side and require combining it with
> > > GPL-compatible licenses when using the license.
> > > 
> > > Cc: linux-spdx@vger.kernel.org
> > > Cc: Richard Fontana <rfontana@redhat.com>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> > > ---
> > >  LICENSES/dual/OFL-1.1 | 107 ++++++++++++++++++++++++++++++++++++++++++
> > 
> > You add this license, but then never actually reference it in the later
> > changes, so it's going to be very confusing as to why it is here.  Any
> > way to add it to the font files themselves so our checker tools can
> > handle this properly?
> 
> There is TTF name string ID called "License". For example, on IBM Plex Sans,
> the string value is:
> 
> ```
> This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: http://scripts.sil.org/OFL
> ```
> 
> Checking that string requires scripting fontforge, and since the string value
> may differ (but has the same license) across different fonts, scripting it
> can be non-trivial.

And is that in the files you added?  They are binary so it's hard to
determine this :(

> > 
> > And, it's not going to work as a dual-license, you can't just suddenly
> > dual-license those font files, right?
> 
> I was thinking of putting OFL in LICENSES/exceptions instead due to this
> nature.

Yes, it can not be a dual one.

> > >  1 file changed, 107 insertions(+)
> > >  create mode 100644 LICENSES/dual/OFL-1.1
> > > 
> > > diff --git a/LICENSES/dual/OFL-1.1 b/LICENSES/dual/OFL-1.1
> > > new file mode 100644
> > > index 00000000000000..00b8db08bd0e54
> > > --- /dev/null
> > > +++ b/LICENSES/dual/OFL-1.1
> > > @@ -0,0 +1,107 @@
> > > +Valid-License-Identifier: OFL-1.1
> > > +SPDX-URL: https://spdx.org/licenses/OFL-1.1
> > > +Usage-Guide:
> > > +  Do NOT use this license for code, but it's acceptable for fonts (where the
> > > +  license is specifically written for them). It's best to use it together
> > > +  with a GPL2 compatible license using "OR", as OFL-1.1 texts processed by
> > > +  the kernel's build system might combine it with content taken from more
> > > +  restrictive licenses.
> > > +  To use the SIL Open Font License 1.1, put the following SPDX tag/value pair
> > > +  into a comment according to the placement guidelines in the licensing rules
> > > +  documentation:
> > > +    SPDX-License-Identifier: OFL-1.1
> > 
> > Where did this Usage-Guide from?
> 
> Adapted from LICENSES/dual/CC-BY-4.0.

Which it shouldn't be :(

Anyway, this is independent of the issue if we actually should take
these fonts into the kernel tree, and mandate their use (my opinion is
no, that's not for us to use, and especially for any action that might
cause a web browser to look elsewhere outside of our documentation.)

Also, for documentation, I'm pretty sure that serif fonts is proven to
be "nicer" overall by many studies.

thanks,

greg k-h

Re: [PATCH RFC 1/4] LICENSES: Add SIL Open Font License 1.1

[Bagas Sanjaya]

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

On Fri, Nov 03, 2023 at 09:49:54AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 03, 2023 at 03:11:36PM +0700, Bagas Sanjaya wrote:
> > On Thu, Nov 02, 2023 at 03:06:19PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Nov 02, 2023 at 07:00:43PM +0700, Bagas Sanjaya wrote:
> > > >  LICENSES/dual/OFL-1.1 | 107 ++++++++++++++++++++++++++++++++++++++++++
> > > 
> > > You add this license, but then never actually reference it in the later
> > > changes, so it's going to be very confusing as to why it is here.  Any
> > > way to add it to the font files themselves so our checker tools can
> > > handle this properly?
> > 
> > There is TTF name string ID called "License". For example, on IBM Plex Sans,
> > the string value is:
> > 
> > ```
> > This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: http://scripts.sil.org/OFL
> > ```
> > 
> > Checking that string requires scripting fontforge, and since the string value
> > may differ (but has the same license) across different fonts, scripting it
> > can be non-trivial.
> 
> And is that in the files you added?  They are binary so it's hard to
> determine this :(

Yes.

> 
> > > 
> > > And, it's not going to work as a dual-license, you can't just suddenly
> > > dual-license those font files, right?
> > 
> > I was thinking of putting OFL in LICENSES/exceptions instead due to this
> > nature.
> 
> Yes, it can not be a dual one.

That's right!

What about just saying below in the CSS file that includes the fonts?

```
...
/* Some cool fonts are licensed under OFL 1.1, see
 * LICENSES/exceptions/OFL-1.1 for more information. */
...
```
> > > > +Usage-Guide:
> > > > +  Do NOT use this license for code, but it's acceptable for fonts (where the
> > > > +  license is specifically written for them). It's best to use it together
> > > > +  with a GPL2 compatible license using "OR", as OFL-1.1 texts processed by
> > > > +  the kernel's build system might combine it with content taken from more
> > > > +  restrictive licenses.
> > > > +  To use the SIL Open Font License 1.1, put the following SPDX tag/value pair
> > > > +  into a comment according to the placement guidelines in the licensing rules
> > > > +  documentation:
> > > > +    SPDX-License-Identifier: OFL-1.1
> > > 
> > > Where did this Usage-Guide from?
> > 
> > Adapted from LICENSES/dual/CC-BY-4.0.
> 
> Which it shouldn't be :(
> 
> Anyway, this is independent of the issue if we actually should take
> these fonts into the kernel tree, and mandate their use (my opinion is
> no, that's not for us to use, and especially for any action that might
> cause a web browser to look elsewhere outside of our documentation.)
> 
> Also, for documentation, I'm pretty sure that serif fonts is proven to
> be "nicer" overall by many studies.

Any pointer to them? Or do serif fonts more readable and not causing
eye strain?

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH RFC 1/4] LICENSES: Add SIL Open Font License 1.1

[Greg Kroah-Hartman]

On Sat, Nov 04, 2023 at 07:53:07AM +0700, Bagas Sanjaya wrote:
> On Fri, Nov 03, 2023 at 09:49:54AM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Nov 03, 2023 at 03:11:36PM +0700, Bagas Sanjaya wrote:
> > > On Thu, Nov 02, 2023 at 03:06:19PM +0100, Greg Kroah-Hartman wrote:
> > > > On Thu, Nov 02, 2023 at 07:00:43PM +0700, Bagas Sanjaya wrote:
> > > > >  LICENSES/dual/OFL-1.1 | 107 ++++++++++++++++++++++++++++++++++++++++++
> > > > 
> > > > You add this license, but then never actually reference it in the later
> > > > changes, so it's going to be very confusing as to why it is here.  Any
> > > > way to add it to the font files themselves so our checker tools can
> > > > handle this properly?
> > > 
> > > There is TTF name string ID called "License". For example, on IBM Plex Sans,
> > > the string value is:
> > > 
> > > ```
> > > This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: http://scripts.sil.org/OFL
> > > ```
> > > 
> > > Checking that string requires scripting fontforge, and since the string value
> > > may differ (but has the same license) across different fonts, scripting it
> > > can be non-trivial.
> > 
> > And is that in the files you added?  They are binary so it's hard to
> > determine this :(
> 
> Yes.
> 
> > 
> > > > 
> > > > And, it's not going to work as a dual-license, you can't just suddenly
> > > > dual-license those font files, right?
> > > 
> > > I was thinking of putting OFL in LICENSES/exceptions instead due to this
> > > nature.
> > 
> > Yes, it can not be a dual one.
> 
> That's right!
> 
> What about just saying below in the CSS file that includes the fonts?
> 
> ```
> ...
> /* Some cool fonts are licensed under OFL 1.1, see
>  * LICENSES/exceptions/OFL-1.1 for more information. */
> ...
> ```

That's not in SPDX format :)

Anyway, I think the meta-comment so far is "do we want to include fonts
in the kernel source", right?  For that, I would argue "no, let's not
deal with that mess for now".

thanks,

greg k-h

Re: [PATCH RFC 1/4] LICENSES: Add SIL Open Font License 1.1

[Bagas Sanjaya]

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

On Sat, Nov 04, 2023 at 10:52:06AM +0100, Greg Kroah-Hartman wrote:
> On Sat, Nov 04, 2023 at 07:53:07AM +0700, Bagas Sanjaya wrote:
> > On Fri, Nov 03, 2023 at 09:49:54AM +0100, Greg Kroah-Hartman wrote:
> > > On Fri, Nov 03, 2023 at 03:11:36PM +0700, Bagas Sanjaya wrote:
> > > > On Thu, Nov 02, 2023 at 03:06:19PM +0100, Greg Kroah-Hartman wrote:
> > > > > On Thu, Nov 02, 2023 at 07:00:43PM +0700, Bagas Sanjaya wrote:
> > > > > >  LICENSES/dual/OFL-1.1 | 107 ++++++++++++++++++++++++++++++++++++++++++
> > > > > 
> > > > > You add this license, but then never actually reference it in the later
> > > > > changes, so it's going to be very confusing as to why it is here.  Any
> > > > > way to add it to the font files themselves so our checker tools can
> > > > > handle this properly?
> > > > 
> > > > There is TTF name string ID called "License". For example, on IBM Plex Sans,
> > > > the string value is:
> > > > 
> > > > ```
> > > > This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: http://scripts.sil.org/OFL
> > > > ```
> > > > 
> > > > Checking that string requires scripting fontforge, and since the string value
> > > > may differ (but has the same license) across different fonts, scripting it
> > > > can be non-trivial.
> > > 
> > > And is that in the files you added?  They are binary so it's hard to
> > > determine this :(
> > 
> > Yes.
> > 
> > > 
> > > > > 
> > > > > And, it's not going to work as a dual-license, you can't just suddenly
> > > > > dual-license those font files, right?
> > > > 
> > > > I was thinking of putting OFL in LICENSES/exceptions instead due to this
> > > > nature.
> > > 
> > > Yes, it can not be a dual one.
> > 
> > That's right!
> > 
> > What about just saying below in the CSS file that includes the fonts?
> > 
> > ```
> > ...
> > /* Some cool fonts are licensed under OFL 1.1, see
> >  * LICENSES/exceptions/OFL-1.1 for more information. */
> > ...
> > ```
> 
> That's not in SPDX format :)

Yes, without it (CSS files of course should already have SPDX line); but I
highlight importing webfonts above, where due to binary nature of font files,
we have to resort to simple license notice above (pre-SPDX) whenever about
to use them.

> 
> Anyway, I think the meta-comment so far is "do we want to include fonts
> in the kernel source", right?  For that, I would argue "no, let's not
> deal with that mess for now".
> 

So far I'm only concerned about including OFL fonts. In the cover letter,
I also considered non-free, paid fonts (like Söhne), which IMO looks better
than IBM Plex. Of course, if someone submits a version of this series but
with Söhne instead (hey because many other sites do use that font), Greg will
instantly reject it, right?

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]