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

Fonts don't have a suitable license for distribution #59

Closed
pwaller opened this issue Oct 15, 2018 · 20 comments · Fixed by #61
Closed

Fonts don't have a suitable license for distribution #59

pwaller opened this issue Oct 15, 2018 · 20 comments · Fixed by #61

Comments

@pwaller
Copy link
Owner

pwaller commented Oct 15, 2018

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:

  1. Identify fonts which need removing.
    • (or equivalently, which can be kept, so that the code is self standing)
  2. Remove them from the github repository.
    • Decode if they need removing from the history of the repository.
  3. Remove them from source distributions on PyPi.
    • Decide if they need removing from older versions (if they should be removed from the repository
  4. Provide a mechanism for the user to obtain/use additional fonts from sources where the license is valid.
@peterbrittain
Copy link
Collaborator

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.

@pwaller
Copy link
Owner Author

pwaller commented Oct 15, 2018

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.

@peterbrittain
Copy link
Collaborator

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 git rm is good enough.

If we then simply delete older releases (from https://github.com/pwaller/pyfiglet/releases and PYPI), we're no longer redistributing the offending files.

@peterbrittain
Copy link
Collaborator

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)?

@pwaller
Copy link
Owner Author

pwaller commented Nov 14, 2018

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.

@MinchinWeb
Copy link
Contributor

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?

@peterbrittain
Copy link
Collaborator

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.

@peterbrittain
Copy link
Collaborator

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?

@pwaller
Copy link
Owner Author

pwaller commented Nov 27, 2018

Hmm. Not sure I have a great answer. I personally install things using pip install --user, not doing the installation as root. I consider it pretty unfortunate if a package requires root to install - not everyone has root access.

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?

@peterbrittain
Copy link
Collaborator

Yeah - I was originally thinking that, but then when you look at all pkg_resources, it really doesn't allow you to start messing around with the installed files.

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.

@pwaller
Copy link
Owner Author

pwaller commented Nov 27, 2018

/usr/share would usually be the responsibility of the distribution to manage. If you're going to put random files down you should probably put them in /usr/local/share/... or alike to avoid colliding with the distro package manager.

We could potentially 'look in a few places' for the files.

@peterbrittain
Copy link
Collaborator

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.

@pwaller
Copy link
Owner Author

pwaller commented Nov 27, 2018

I still want to maintain the requirement 'it should be possible without root', if possible.

@peterbrittain
Copy link
Collaborator

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?

@pwaller
Copy link
Owner Author

pwaller commented Nov 27, 2018

Sounds good to me.

@MinchinWeb
Copy link
Contributor

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...

@peterbrittain
Copy link
Collaborator

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.

@MinchinWeb
Copy link
Contributor

What folder do you plan on using on Windows? there is no /usr sub-tree there...

@peterbrittain
Copy link
Collaborator

%APPDATA%\pyfiglet - which will typically resolve to something like C:\Users\Name\AppData\Roaming\pyfiglet according to my testing.

@pwaller
Copy link
Owner Author

pwaller commented Dec 6, 2018

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...).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants