Added ./licensecheck.pl to the project, and updated .travis.yml to run that after other CI tests. The 56 other changes are simply license additions.

Bump.

Bump again. If you add me as a maintainer on GitHub and PyPI I can merge it in and release version 1.0 myself. I'm already a GitHub and/or PyPI maintainer for:

• django-admin-row-actions
• django-multiselectfield
• django-smart-selects
• django-world-languages
• humanhash3
• markdown-icons
• django-cities
• django-osm-field

Why is this necessary? Many projects clutter their files with licensing information, many don't. The only argument in favor for it I found is that it makes it "more obvious" that there's no warranty in case somebody "separates the file" from the project. Is that a worry that has ever been confirmed as being a real issue?

The reason I'm picky here is that there is a non-zero cost from putting this in. It poisons history, it must be maintained forward when new files are created, it wastes disk space and screen real estate when opening the file. Is it a big deal? No. But is it necessary? I also doubt it.

Since @gsnedders was the author of #130 he may be in a better position to answer to why this is important than me.

According to @kenrussell in #125:

In order for Chromium to be pulled in to various Linux source distributions there's a requirement that all of the third party files pass the Linux licensecheck utility.

I have asked him in that PR to be more specific about exactly which Linux distributions carry that requirement.

@ambv Here's some point-by-point rebuttals:

It poisons history

Can you explain what you mean by this more? It seems like you're saying this is a lot of files that people would have to rebase onto, but that's the case for any PR that makes changes to a lot of files, and because the changes to all files (ignoring adding licensecheck.pl and the travis test) are at the top, the number of merge conflicts that can't be automatically resolved should theoretically be minimal.

it must be maintained forward when new files are created

That's a legitimate complaint. I have added the license check to the travis.yml as you can see in this line, so once this is merged in tests with new files should fail until they explicitly carry a license. Note that this travis test rather intentionally doesn't check which license a file has, just that it has a recognized license.

it wastes disk space

It's 2016, is this really an issue anymore? It adds a few KB at most. Loading this webpage probably caused your computer to swap more memory to disk than the entirety of this size change. If it is legitimately that big of an issue for you or any other contributor I would be happy to ship you a few extra low-capacity (<100 GB) hard drives I have lying around free of charge (maybe not international).

it wastes...screen real estate

Yes...until you scroll past it. Which I'll admit is certainly an annoyance, but as you note, hardly a big deal.

Also, I'm happy to have this not merged in - that's totally fine. Just, in that case though, please close #125 as WONTFIX, remove it from milestone 1 and mark the milestone as complete. The milestone is actually what the bleach project is waiting on and I'm waiting on them. 😄

@blag uh, that shouldn't be the only thing on that milestone… oh, there's also https://github.com/html5lib/html5lib-python/milestone/8 with another useless number, which appears to be what I expected to put out as a de-facto 1.0rc (whether or not it gets labelled as such depends on whether we want pip users to get updated to it, etc.).

I'm taking this out of the 1.0 milestone. I'm not wild about including the pl file in the repository for the reasons listed. I'm happy for this to land in 1.0, but I don't think it should block.

That's understandable.

The only reason I added a Perl file to this Python project is because it's a standard tool copied from other projects. If there was an acceptable Python version I would have used that.