Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove google fonts from themes #1161

Closed
DevOfManyThings opened this issue Mar 15, 2023 · 10 comments · Fixed by #1192
Closed

Remove google fonts from themes #1161

DevOfManyThings opened this issue Mar 15, 2023 · 10 comments · Fixed by #1192
Assignees
Labels
enhancement New feature or request feature request Request a feature or introduce and update to the project. ready to test Ready to be tested for quality assurance.

Comments

@DevOfManyThings
Copy link

Current Behavior

I'm not an expert on this, so this is my knowledge from some basic googling, but it looks like directly using google fonts is a breach in GDPR, meaning anyone who uses the pre-built themes and even the official Skeleton docs themselves are potentially at risk.

https://meetanshi.com/blog/google-fonts-gdpr-compliant/
https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/

There's two separate issues here:

The official skeleton docs
The workaround is pretty simple here because we can simply download the fonts and host them from the skeleton repo directly (assuming the fonts licenses permit that, afaik that's fine but worth double checking).

Users of Skeleton themes on their own sites
Those who use the skeleton themes, ideally you wouldn't want them to also be downloading the font files from skeletons hosting, that just puts additional cost/load on skeletonlabs + could bring in the original issue with google fonts, if skeleton decide to start tracking IPs etc (with appropriate GDPR consent) that's fine, but people building with Skeleton might not have acquired it for their website visitors so it could just repeat the original issue.

Solution
I think the best approach is to have two sets of themes, one set which is used by the docs which uses the fonts and references the font files hosted on the same infra as the rest of the skeleton docs (instead of google fonts).

The other set of theme files are what users of Skeleton import, these don't download custom fonts but there could be some commentary at the top of the theme file, or something added to the theme docs explaining how to use custom fonts?

I know you don't want Skeleton to be responsible for GDPR or legal issues, but I think the default setup looks like it could cause problems which we want to avoid where possible! If anyone is more knowledgeable on this subject knows I'm wrong here please chime in! I'd be very happy to be incorrect here.

Steps To Reproduce

N/A, this just didn't make sense as a feature request/docs update.

Anything else?

No response

@DevOfManyThings DevOfManyThings added the bug Something isn't working label Mar 15, 2023
@endigo9740
Copy link
Contributor

endigo9740 commented Mar 15, 2023

Per the Documentation

This is going to sound rather blunt, but stick with me here for a second. Frankly speaking I don't give a crap about GDPR in relation to the Skeleton documentation site. The reasons for this is as follows:

  1. No one owns Skeleton. It's a MIT licensed open source project. Skeleton itself is not a company. It does not harvest data, it does not earn money or profits, and it's not an entity that can be sued. So Skeleton itself will never be subject to anything resembling GDPR.
  2. Skeleton Labs, the organization that lives alongside, supports, and contributes to Skeleton, is a US-based company. Our LLC is filed in the State of Texas in the US. So I feel we would be outside European jurisdiction
  3. The Skeleton documentation site is hosted with Vercel, which again is a US-based company.
  4. While Vercel may use edge servers globally, I have zero clue on the impact of GDPR in this respect

Unless someone well versed (and preferably a Lawyer) can step in provide reference to Skeleton Labs being in a position of vulnerability, then I really am not concerned with this. That said, I will bring it up to my business partner to see what our lawyers recommend for Skeleton Labs. If anything of note is discovered, we'll move on it asap.

Per our End Users

All that said, I certainly don't want our users to be negatively impacted by GDPR. So this an angle that is much more applicable to the project. Aside from a GDPR focus, I have been keen to decouple fonts from themes for performance reasons for a while.

If a user decides not to opt into using the included fonts, the fonts are still being fetched remotely, which has a performance impact. We've already signaled our interest in moving to locally embedded fonts, which comes with a number of improvements:
#1149

This would not only more GDPR friendly, but also provide optimal performance for end users. So I'll plan to reference this ticket in that thread.

@endigo9740 endigo9740 added enhancement New feature or request feature request Request a feature or introduce and update to the project. and removed bug Something isn't working labels Mar 15, 2023
@DevOfManyThings
Copy link
Author

Skeleton Docs
GDPR is incredibly broad in scope, and is applicable if you're serving content to EU citizens regardless of where the hosting company is based: https://gdpr.eu/compliance-checklist-us-companies/#:~:text=The%20GDPR%20applies%20to%20companies,and%20even%2C%20perhaps%2C%20visitors.

There's obviously arguments that could be made of whether anything would realistically ever happen for this particular issue, but that's up to you/your partners/lawyers to decide on.

End Users
I think that fix is perfect for this scenario, performance improvement + GDPR friendly 👍

@endigo9740
Copy link
Contributor

Yeah the core team and I were discussing this internally a bit. Essentially the plan will be to decouple the fonts and recommend users embed them locally, rather than a external reference. This should bring them into compliance. We're going to make this a priority, so expect movement on this before the next release in a couple weeks.

@endigo9740
Copy link
Contributor

@endigo9740 endigo9740 self-assigned this Mar 17, 2023
@ttmc
Copy link

ttmc commented Mar 17, 2023

"No one owns Skeleton. It's a MIT licensed open source project."

This is a misunderstanding of intellectual property law. The copyright in a particular fragment of code is owned by whoever wrote it, or their employer. The fact that that a fragment of code is licensed under an MIT license doesn't mean that nobody owns it anymore; it just means that the owner has agreed to let others do certain things with that code so long as they abide by the terms of the license.

If you actually wanted to abandon ownership, you'd have to deed the code to the public domain. Very few software developers do that because it would leave them vulnerable to being sued by a user of the code. (The last section of the MIT license, the part in ALL CAPS, it the part that guards against this. All open source licenses have something similar.)

https://mit-license.org/

@endigo9740
Copy link
Contributor

endigo9740 commented Mar 17, 2023

@ttmc Thanks for the clarification. We did actually discuss this internally between the core team and this was brought to my attention. Hey I'm not a lawyer and I will never pretend to be one, so seriously thanks for expanding.

Just so it's stated clearly here, we WILL be addressing the original issue at hand, which is making themes GDPR friend. This will be accomplished by the following:

  1. Decouple and remove Google Fonts from each theme
  2. We'll still make recommendations if you use X theme consider using font X and Y, with maybe a quick link to the resources
  3. We'll also advise folks to embed the fonts locally, rather than a keeping them as an external reference.
  4. We'll provide instruction for now to use locally embedded fonts

I believe by doing this things should then be compliant. There's also some major performance benefits to doing this, so honestly there's very little reason not to make this to default recommendation. Though it does require a couple extra loops to jump through on setup.

@endigo9740
Copy link
Contributor

@endigo9740 endigo9740 added the ready to test Ready to be tested for quality assurance. label Mar 24, 2023
@endigo9740
Copy link
Contributor

These updates are now ready to test, please provide feedback either here or in the PR thread.

@endigo9740 endigo9740 unpinned this issue Mar 27, 2023
@dandanthedev
Copy link

quick so to this: https://fonts.coollabs.io/

@endigo9740
Copy link
Contributor

Very interesting @daanschenkel - I've never heard of this! I'm going to make a new ticket to review this in the near future. If it looks like a good fit we'll consider it for Skeleton. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feature request Request a feature or introduce and update to the project. ready to test Ready to be tested for quality assurance.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants