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@xxxxxxxxxxxxxxx > > > Cc: Richard Fontana <rfontana@xxxxxxxxxx> > > > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > > Signed-off-by: Bagas Sanjaya <bagasdotme@xxxxxxxxx> > > > --- > > > 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
