Opened 5 weeks ago
Last modified 5 weeks ago
#35829 new Cleanup/optimization
Update/Fix Font Awesome icons
Reported by: | stefan6419846 | Owned by: | |
---|---|---|---|
Component: | contrib.admin | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Jacob Kaplan-Moss | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | yes |
Description (last modified by )
While looking through the source code, I stumbled upon the https://github.com/django/django/tree/main/django/contrib/admin/static/admin/img directory.
From reading the provided information, these files were originally created by the Font Awesome project, although being converted to standalone SVG files by some third-party. As far as I can see, they have received some modifications for Django to set some other color for example.
There possibly are multiple license-related aspects which show up here (Disclaimer: IANAL):
- Splitting the big SVG file as done by Font-Awesome-SVG-PNG might be considered derivative work with a new name per OFL-1.1 and at least is covered by the weak copyleft effect of the OFL-1.1. The MIT LICENSE file provided in the directory is clearly wrong here.
- Changing the color of individual files or re-arranging them can more likely be considered derivative work, usually requiring using a different name under the terms of the OFL-1.1 and applying the OFL-1.1 to these files.
Given these observations, I would propose to update this directory accordingly:
- Update Font Awesome to the latest version. Desktop releases for version 6.6.0 already provide individual SVG files which actually have a license comment inside as well.
- Update the README and LICENSE file accordingly to indeed include the correct license text, id est the OFL-1.1 one. The README ideally documents which changes were done to which original version.
Change History (7)
comment:1 by , 5 weeks ago
Summary: | Update Font Awesome icons → Update/Fix Font Awesome icons |
---|
comment:2 by , 5 weeks ago
Description: | modified (diff) |
---|
comment:3 by , 5 weeks ago
follow-up: 5 comment:4 by , 5 weeks ago
Type: | Bug → Cleanup/optimization |
---|---|
UI/UX: | set |
Hello stefan6419846, thank you for your ticket. I'm also not a layer, and I don't have clarity on what we really need to do here. Some replies inline:
Replying to stefan6419846:
From reading the provided information, these files were originally created by the Font Awesome project, although being converted to standalone SVG files by some third-party. As far as I can see, they have received some modifications for Django to set some other color for example.
I agree with this conclusion as far as I can see. Though note that the standalone SVG files do seem to be licensed under MIT as per https://github.com/Rush/Font-Awesome-SVG-PNG/?
- Splitting the big SVG file as done by Font-Awesome-SVG-PNG might be considered derivative work with a new name per OFL-1.1 and at least is covered by the weak copyleft effect of the OFL-1.1. The MIT LICENSE file provided in the directory is clearly wrong here.
Wouldn't this be an issue that https://github.com/Rush/Font-Awesome-SVG-PNG has to deal with?
- Changing the color of individual files or re-arranging them can more likely be considered derivative work, usually requiring using a different name under the terms of the OFL-1.1 and applying the OFL-1.1 to these files.
I'm not seeing name matching between what we have in Django and what I have downloaded from Font Awesome. Could you please provide a few specific examples?
- Update Font Awesome to the latest version. Desktop releases for version 6.6.0 already provide individual SVG files which actually have a license comment inside as well.
- Update the README and LICENSE file accordingly to indeed include the correct license text, id est the OFL-1.1 one. The README ideally documents which changes were done to which original version.
I don't object with this proposal, it feels like a good refresh though it would need more work than that. We'd need the proper coloring and resizing to be applied, and potentially a re-take of all the admin screenshots used in the docs.
If we eventually accept this ticket, would you be able to help with this? Thanks!
comment:5 by , 5 weeks ago
I agree with this conclusion as far as I can see. Though note that the standalone SVG files do seem to be licensed under MIT as per https://github.com/Rush/Font-Awesome-SVG-PNG/?
Wouldn't this be an issue that https://github.com/Rush/Font-Awesome-SVG-PNG has to deal with?
Yes, this repository is marked as MIT, although mentioning in the README that the Font Awesome font is subject to OFL-1.1. Unfortunately, just relying on this information is not sufficient. In theory, every user of the package (or every part of the supply chain, depending on how you want to name it) is required to review this and look for possible inconsistencies. With the usual warranty disclaimers of FOSS packages it ultimately is the task of the final distributor to verify the correctness of the provided data - especially if Django is part of commercial applications where contracts specify warranty-related clauses. (Please note that this might differ depending on the jurisdiction/country. AFAIK this is what holds true for Germany.)
For now, it is not completely clear for me which version of Font Awesome Django currently uses. According to the history at https://github.com/django/django/commits/main/django/contrib/admin/static/admin/img/README.txt and the upstream history, this might be version 4.3.0, which would match the README statement about OFL-1.1: https://github.com/Rush/Font-Awesome-SVG-PNG/blob/31dd85aef85aed8cfbe8c8d4423ca9a262a23620/package.json#L24
https://github.com/Rush/Font-Awesome-SVG-PNG/issues/79 already is an upstream issue about this. Depending on the Font Awesome version, different terms are relevant, which I have documented there a bit more.
- Changing the color of individual files or re-arranging them can more likely be considered derivative work, usually requiring using a different name under the terms of the OFL-1.1 and applying the OFL-1.1 to these files.
I'm not seeing name matching between what we have in Django and what I have downloaded from Font Awesome. Could you please provide a few specific examples?
This is about using the reserved font name "Font Awesome", which according to the OFL-1.1 cannot be used for derivatives of the original font. This initially arises from Font-Awesome-SVG-PNG as well, but still holds true for Django as well. To be honest, applying the name clause (3) to standalone SVG icons does not necessarily make sense and only occurs for the problematic Font Awesome version 4.
I don't object with this proposal, it feels like a good refresh though it would need more work than that. We'd need the proper coloring and resizing to be applied, and potentially a re-take of all the admin screenshots used in the docs.
At least coloring and resizing should ideally be easy enough due to SVG files basically being XML with plain drawing operations. As for how different the icons are between the different versions, this is something which would have to be evaluated - the initial problem with this is finding the matching Font Awesome names for the symbols used by Django, as this is not documented and Django renamed the files to better match the corresponding use cases. (For example, eye.svg has been renamed to icon-viewlink.svg in Django.)
If we eventually accept this ticket, would you be able to help with this? Thanks!
Yes, I should be able to help with this.
comment:6 by , 5 weeks ago
Cc: | added |
---|---|
Triage Stage: | Unreviewed → Accepted |
Thank you for the extra details! I think those make sense, and specifically they help me understand the overall issue a bit more.
I'll be accepting on the basis to, at least, document and clarify this usage more clearly. Original font-awesome kit was added in #20597.
comment:7 by , 5 weeks ago
Natalia asked me to take a look with my DSF Board hat on. I'm very much not a lawyer but I do know some things about licensing. I tend to agree with stefan6419846 that this probably is a license violation, and that upgrading and updating the README/LICENSE seems like a proper remedy. I don't think it's a super huge risk, but it is _a_ risk and we should take care of it.
(Another option would be to switch to a different icon set that has a more compatible license, e.g. https://github.com/feathericons/feather is MIT, but honestly that seems like a lot more work for little extra benefit.)
Additional note: At least for recent versions of the Font Awesome the SVG files itself are available under the terms of CC-BY-4.0, possibly simplifying things quite a lot.