Fonts don't have a suitable license for distribution

[pwaller]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

/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]

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]

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

[peterbrittain]

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?