-
Notifications
You must be signed in to change notification settings - Fork 139
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
Fonts don't have a suitable license for distribution #59
Comments
On point 1... Assuming that @MinchinWeb's analysis in #46 is right, the various fonts released in figlet 2.x should be fine as long as they are the same as the ones distributed these days under the BSD license. I think the rest have to go unless Markus (of JavE fame) gives us a new license for those files. Looking at #20, I see that one of the fonts (banner) is safely distributed by figlet (https://github.com/cmatsuoka/figlet/blob/master/fonts/banner.flf) and so we are covered by the BSD license for that file. The other looks like it is another unlicensed file and so sadly unusable. |
Thanks for your input. Would you be willing to help get the repository into the right state? I could use all of the help I can get. |
Yeah - I can help out a bit more... My main concern here is the question of how to handle git history. Although there is a supported way to delete files permanently (https://help.github.com/articles/removing-sensitive-data-from-a-repository/), it is quite clear that this is (a) REALLY SCARY and (b) only affects your repo, so other contributors (i.e. the 41 existing forks) then have to rebase to continue. I bet this is just going to blow up in our faces, so I suggest we take the safer option of not re-writing the history until such a time as the owner of any of these fonts asks us to do so. I'm willing to bet that this will never happen and so a simple If we then simply delete older releases (from https://github.com/pwaller/pyfiglet/releases and PYPI), we're no longer redistributing the offending files. |
So... Shall I just delete these font files as proposed? And if that's OK, how do we handle the last bit? Just create another script that will unzip a tarfile and copy the ciles into the fonts folder (and update the readme)? |
That sounds good to me. Thanks very much if you can take that on, my resources for going deep into this are limited at the moment. |
I'm a little sad to see them go. I think the long term plan would be to have some way of pointing to font folders or files; very few programs ship with all their fonts internally. Alternately, could the JavE download be bundled up (as is) with a metadata file as a separate PyPI download, and this point to that as a font source? |
Agreed that it's a shame to do this, but the issue stands that we don't have a clear right to redistribute them. If you can contact Markus (of JavE fame), confirm that he owns the rights to those fonts and gives us a suitable license to redistribute, we're sorted! Otherwise, the best we can legally do is provide a way to load other fonts and tell people how to download the necessary files. Creating a separate package and putting it on PyPI ourselves is just making the same mistake with this new package. |
OK - so I started looking at doing this. The deleting of files is easy! :-) However, the ability to upload new files is a bit problematic. It requires the ability to write new files somewhere... Unsurprisingly, pkg_resources doesn't allow you to do that, so I'm thinking of simply creating a standard location to look for extra files - e.g. %APPDATA%\pyfiglet on Windows and /usr/share/pyfiglet for the rest. Any objections? |
Hmm. Not sure I have a great answer. I personally install things using Would it be possible to try and locate where pyfiglet is (whether it is an egg or not) and put the files alongside those in a way that pkg_resources will find them? |
Yeah - I was originally thinking that, but then when you look at all It looks like I could find a filename for an existing resource (see http://peak.telecommunity.com/DevCenter/PkgResources#resource-extraction), but this raises concerns about the use of zipped egg files, which would need a separate solution. It's also not obvious to me what to do about uninstalling the fonts if we write directly into the package directories. Net was that I thought it would be safer to do something similar to figlet (on my distro at least) and put the files in /usr/share. |
We could potentially 'look in a few places' for the files. |
Good point. We should definitely put it in /usr/local/share. I don't think we should worry about multiple locations as we are the ones providing a way to add extra fonts and so can just look at where we feel is the right place to add them. |
I still want to maintain the requirement 'it should be possible without root', if possible. |
OK - so maybe try uploading to the package first (which only works for virtualenv installations that avoid using zipped egg files) and fail back to /usr/local/share if that's not possible? |
Sounds good to me. |
Take a look at appdirs. It's a package that's designed to help you figure out what folders to use on the various OS's. You'll probably got crazy with corner cases otherwise... |
I had a quick look at the appdirs stuff and related docs from Apple on file structure and it wasn't obvious to me that we needed a different directory for macOS (as it still supports the /usr sub-tree), so I've avoided pulling in the extra dependency for now. |
What folder do you plan on using on Windows? there is no |
%APPDATA%\pyfiglet - which will typically resolve to something like C:\Users\Name\AppData\Roaming\pyfiglet according to my testing. |
Released in v0.8.0 (and v0.8.post0 due to a minor mistake of mine and PyPI's not allowing you to reupload archives with the same number...). |
Please see comments raised by @peterbrittain in #58 (comment)
#58
In essence, I think we need to revert #46, or come to an understanding that distributing these is legitimate.
Paging @peterbrittain, @stefanor @asakasinsky (#20) @MinchinWeb (#46).
I could use some help figuring out what needs to be done here, I also don't have much free time for actioning this. Here is a quick first pass proposal:
The text was updated successfully, but these errors were encountered: