search

rstudio / bslib

Tools for theming Shiny and R Markdown via Bootstrap 3, 4, or 5.
https://rstudio.github.io/bslib/
Other
466 stars 57 forks source link

Sources for inst/fonts/*.woff -- potential License problems? #412

Closed nileshpatra closed 2 years ago

nileshpatra commented 2 years ago

The issue tracker is not for questions. If you have a question, please feel free to ask bslib help questions on RStudio Community under the bslib tag, at https://community.rstudio.com/tag/bslib. Please tag your post with a bslib tag to increase visibility.

Apologies for not doing this, I am a bit short on time and wanted to get this sorted out quickly, this is also not general help.

Actually, we were trying to package bslib for debian (as this is also a pre-dependency of rmarkdown) and I noticed that there are several font .woff files in inst/fonts -- unfortunately pre-compiled binaries like this will is not allowed for 'our' processes, and hence if you could please point me to the sources as to where you got these from, that'd be great.

Additionally, is it possible to re-generate these, somehow?

Let me know.

nileshpatra commented 2 years ago

I see that you are using tools/main.R to update it, but I also noticed that you are fetching google fonts (Sans Pro, et. al.) but these appear to be proprietary in nature. Since the license of the project is MIT, would that not violate it?

wch commented 2 years ago

I believe the SIL OFL license allows redistribution in a project that is licensed with the MIT license. However, it looks like we should add a LICENSE file to inst/fonts/.

https://opensource.stackexchange.com/questions/5739/can-i-use-the-mit-license-if-i-use-font-awesome-sil-ofl

cpsievert commented 2 years ago

could please point me to the sources as to where you got these from, that'd be great.

The relevant bit is https://github.com/rstudio/bslib/blob/888fbe064491692deb56fd90dc23455052e31073/tools/download_bootswatch_fonts.R#L30

nileshpatra commented 2 years ago

Thank you very much for the responses. However, I think it'll be bit of a problem to distribute these google fonts in debian (since they need "free" distribution) -- I can do something to keep these out. Do you think bslib would be usable enough w/o the google fonts in there?

cpsievert commented 2 years ago

Without the font files, fonts for at least a handful of bootswatch themes won't look right.

If we also included the ttf files as a fallback, would that solve the problem?

nileshpatra commented 2 years ago

On Wed, 23 Feb, 2022, 2:39 am Carson Sievert, @.***> wrote:

Without the font files, fonts for at least a handful of bootswatch themes won't look right.

That doesn't sound too good :(

If we also included the ttf files as a fallback, would that solve the problem?

Yep, that'd be nice, but only if the license is in open domain and is free software one (I'm not sure if that might be the case)

wch commented 2 years ago

@nileshpatra According to this, I think the SIL Open Font License is DSFG-compatible: https://wiki.debian.org/DFSGLicenses#The_SIL_Open_Font_License

And I believe that the fonts we have in bslib are distributed under the SIL Open Font License (though it would be good to check).

nileshpatra commented 2 years ago

On Wed, 23 Feb, 2022, 4:47 am Winston Chang, @.***> wrote:

@nileshpatra https://github.com/nileshpatra According to this, I think the SIL Open Font License is DSFG-compatible: https://wiki.debian.org/DFSGLicenses#The_SIL_Open_Font_License

And I believe that the fonts we have in bslib are distributed under the SIL Open Font License (though it would be good to check).

It would be great if you could please check, and add a corresponding license file in the "inst/fonts" dir, that'd really help. Thanks again for replying so quickly

nileshpatra commented 2 years ago

@nileshpatra According to this, I think the SIL Open Font License is DSFG-compatible: https://wiki.debian.org/DFSGLicenses#The_SIL_Open_Font_License

And I believe that the fonts we have in bslib are distributed under the SIL Open Font License (though it would be good to check).

Yes, but I think the only problem is in the debian land, these could be considered binaries w/o sources and can cause problems that way. I just sent an email to the list asking for more clarifications on this.

tillea commented 2 years ago

Regarding easiest way to be safe on a Debian system would be to use existing packaged fonts. When looking at the Debian package pool for larger font packages with a big variety of fonts I can find the following

I'm not sure what requirements the fonts used in bslib need to be fulfilled but from my naive point of view it has advantages to use fonts that are widely used. From a Debian point of view we would be able so simply depend from these packages and symlink the according files which would be extremely convenient.

Kind regards, Andreas.

tillea commented 2 years ago 
* [IBM Plex - extensive font family developed by IBM](https://tracker.debian.org/pkg/fonts-ibm-plex)
* [Fonts included inside the MathJax package](https://tracker.debian.org/pkg/mathjax)

In Debian we desperately need to package bslib since lots of dependencies depend from this but we have no chance with the current code featuring fonts without source. Do you see any chance to replace these as suggested in the near future? Kind regards, Andreas.

tillea commented 2 years ago

Without the font files, fonts for at least a handful of bootswatch themes won't look right.

If we also included the ttf files as a fallback, would that solve the problem?

I think those ttf files would enable us stepping forward as well. The other problem are the copies of different versions of bootstrap.js

Kind regards, Andreas.

cpsievert commented 2 years ago

The other problem are the copies of different versions of bootstrap.js

Having access to multiple version of Bootstrap is a major feature of {bslib}...why is that an issue?

tillea commented 2 years ago

Am Mon, Apr 04, 2022 at 12:06:41PM -0700 schrieb Carson Sievert:

The other problem are the copies of different versions of bootstrap.js

Having access to multiple version of Bootstrap is a major feature of {bslib}...why is that an issue?

Debian tries hard to avoid code copies of libraries to enable maintaining security issues. Thus we are extra picky about unmaintained versions of libraries like old versions of Bootstrap.

Would you mind explaining for what purpose these old versions of Bootstrap are used. This is a honest question since I need to admit that I do not even have the slightest idea about the purpose of bslib - I just learned about bslib since its a dependency of other R packages.

Kind regards, Andreas.

cpsievert commented 2 years ago

The main reason is backwards compatibility: Bootstrap 4+ breaks lots of existing (and new) Shiny apps and R Markdown documents (for lots of different reasons that are outside of our control). With bslib::bs_theme(version = 3), users can utilize theming options that bslib provides without having to upgrade Bootstrap.

cpsievert commented 2 years ago

Is this still an issue (feel free to reopen if it is)? Looks like have found a workaround https://ftp-master.debian.org//new/r-cran-bslib_0.3.1+dfsg-1.html

tillea commented 2 years ago

Am Fri, Apr 29, 2022 at 11:34:49AM -0700 schrieb Carson Sievert:

Is this still an issue? Looks like you may have found a way around it? https://ftp-master.debian.org//new/r-cran-bslib_0.3.1+dfsg-1.html To be honest - I don't know. It depends in what direction r-cran-bslib will leave the new queue. If it will be accepted the issue is done - if not it would be better if you would have left that issue open.

github-actions[bot] commented 1 year ago

This issue has been automatically locked. If you believe you have found a related problem, please open a new issue (with a reproducible example or feature request) and link to this issue.