When creating a new repo, on the page titled "Create new Project", please add a drop down list to select a license to be used for the new project.

I thought about this but it implies either including all the Free licenses (and there are many: https://fedoraproject.org/wiki/Licensing ) or picking some. I know there are some that are way more popular but I fear that if we pick a set, there will always be someone asking for another one to be added.

Not suggesting a license discourages people from distributing code with a license.

I am not entirely sure about the 'discourages people'.

Related to this issue, it would also be very nice to have a new tab called "License" near "Overview" to quickly see the license of the project. It could work like this:

• if the project has a LICENSE/LICENSE.md/COPYING file, display the content of this file
• if not, display "The owner of this project hasn't assigned any license to this project"

What is the use case of this ?

I know there are many, but it's a finite set nonetheless. I would suggest at least to add the most popular ones, then for other licenses just ask for merge requests.

I am not entirely sure about the 'discourages people'.

Sorry my English is not the best :-) What I mean is that if there is a "Select license" field, people actually get to care about licensing. With no such field, it's almost like licensing is not important at all. I just think that we (people making free software) should encourage more this behavior of choosing a license for code that we share. Often on GitHub you find projects that the author clearly shared freely but didn't add any license file; the result is that every time I have to get in touch with the maintainer to ask under which license (and therefore conditions) I'm allowed to use his software. Besides, other development tools already such as autotools require users to add a license to their software.

What is the use case of this ?

Practical use case: User creates a new repo, and the new repo is initialized with a LICENSE file. Other practical advantage: the LICENSE is automatically added for me, I don't have to go search online for the full text of the license.

However it's not really a practical things for me, it's more about making developers/users aware of licensing. Other than this, Pagure will satisfy more of the GNU ethical repository criteria (C5, B2, B3) =)

+1

another important use case is for users browsing the site to easily find the license of a project without digging through the sources - a clear license categorization (perhaps shown beside the project name) would be very helpful in this way and could lend to the license being a criteria in a site-wide project search feature

i could also agree with a prominent if not ostentatious statement such "this project is not licensed for distribution - you are not allowed to use anything you see here" - this is an important issue that is too easily overlooked or entirely disregarded by users of popular git hosting sites

in the absence of such an alert - it could be easily argued that selecting and maintaining a free license could be optional only for private repos but should be mandatory for any public repo

Both GitLab and GitHub integrate with TLDRLegal and Choose an open source license to help people properly license their code based on intent.

@pingou We should definitely support showing what license a project is, it's just a matter of figuring out how to do the license interrogation.

I was looking into this the other day, and it seems there isn't much in the way of good Python modules for doing this along the lines of the licensee RubyGem...

ScanCode only works with Python 2, and it looks kind of complex, so that's a non-starter. LiD looks like it might be a better option (at least it has Python 3 support!), but it's not clear whether it's independently functional yet.

If I branch out past Python, there's askalono written in Rust. It has a CLI interface as well as a crate module, which could be theoretically wired up into Python through some FFI magic (cc: @ignatenkobrain), but using it as a library would convert our project into GPLv3+ because it is ASL 2.0. But, it is an option as well.

So, I guess the problem here is I don't know what we should select for supporting detection and identification of licenses in a project?

FYI, askalono-cli is now available in rawhide (thanks @eclipseo), so you can play with it if it is good for our purposes. We can start with CLI and then wire up using API.

I have my reservation about askalono, it's far from perfect, it doesn't detect multiple licenses in a single license file for example, or sometimes doesn't detect a basic MIT.
There was the Licensee rubygem I wanted to package too, but I failed to package its dependencies.

I have a very good experience with previously mentioned ScanCode tool.

And as for the Python 3 support, they are working on it as we speak: https://github.com/nexB/scancode-toolkit/issues/295.