github / choosealicense.com Goto Github PK

Just want to throw this out in case it is of interest.

The Creative Commons website has a license builder which offers a neat form-based procedure for picking a variation of the CC license.

Something similar here would be great for discovery and matching needs perfectly. The homepage of ChooseALicense helps with this a tiny bit (top grid) but only pushes MIT, Apache and GPL licenses, which kind of sucks. Only suggesting 4 licenses is a real bias that seems a little misplaced.

It would be nice if you could provide a simple API to return the license data via JSON, or even just a standard URL structure that would allow us to obtain just the raw license. That is actually the reason why I created the following (before this project existed):

• https://github.com/datafolklabs/license

There is another project I maintain called BOSS which builds projects from templates, and supports pulling in the license content dynamically from the above repo. I'd like to change that to use 'ChooseALicense' however it doesn't appear there is any way to just get the raw license text.

It'd be nice if we could support translations for choosealicense.com. Several PRs have come in that translate the site, but they simply overwrite the English version 😱

We need a better approach.

The inelegant solution would be to have folders for each language that each pretty much contain the entire site translated to a language and then provide links on the main index to each.

A more elegant solution is to use Jekyll localization support (assuming there is such a thing) to do it. Or to build something ourselves.

Chrome works fine, only FF 25+ I tried has this problem.

Update

To clarify, @XhmikosR told me that the license text is actually copied just fine, but the button text is not updated to reflect that.

License, text, copied via clipboard differs (minor difference related to formating) from original, without good reason

here is original license:
curl http://www.gnu.org/licenses/gpl-3.0.txt|md5sum
d32239bcb673463ab874e80d47fae504 -

here is diff:

> 
4c5
<  Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>

---
>  Copyright (C) 2007 Free Software Foundation, Inc. {http://fsf.org/}
634,635c635,636
<     <one line to give the program's name and a brief idea of what it does.>
<     Copyright (C) <year>  <name of author>

---
>     {one line to give the program's name and a brief idea of what it does.}
>     Copyright (C) {year}  {name of author}
648c649
<     along with this program.  If not, see <http://www.gnu.org/licenses/>.

---
>     along with this program.  If not, see {http://www.gnu.org/licenses/}.
655c656
<     <program>  Copyright (C) <year>  <name of author>

---
>     [project]  Copyright (C) [year]  [fullname]
667c668
< <http://www.gnu.org/licenses/>.

---
> {http://www.gnu.org/licenses/}.
674c675,678
< <http://www.gnu.org/philosophy/why-not-lgpl.html>.

---
> {http://www.gnu.org/philosophy/why-not-lgpl.html}.
> 

Not sure where it would be appropriate on the site to add these, but I think it would be helpful to add links to the Wikipedia pages for the Bern Convention (which makes copyright automatic) and Work For Hire (the situation where code you write for your job is actually copyrighted to your employer, and not you).

Your most "simple and permissive" license is an Attribution license. Sometimes we literally just want to contribute our work to the public domain, and don't even care about it being attributed back to us. E.g.: http://unlicense.org/

Personally I'd like it if we could promote non-attribution license for those who don't care, because if you want to build up a custom project of 20 or 30 different open works, it's can be cumbersome to include attributions for all of them.

Please add LaTeX Project Public License (LPPL)

https://en.wikipedia.org/wiki/LaTeX_Project_Public_License

Wow great work. I bookmark the page. One license I miss is the beerware license described on wikipedia.

http://en.wikipedia.org/wiki/Beerware

You may use MIT stuff without distributing it.

Please consider adding the Unlicense to the list. A significant amount of people use this license and I personally prefer it since I find it even more "simple and permissive" than the MIT license. I'd be happy make a pull request for this if it is likely to be accepted.

The FreeBSD license has an extra bit at the end not included in the site's version:

The views and conclusions contained in the software and documentation are those of the authors and should not be interpreted as representing official policies, either expressed or implied, of the FreeBSD Project.

The Wikipedia article includes the disclaimer, but also brings out that some projects exclude it.

Should the disclaimer be included, or at least mentioned or the site?

Would love to see about baking in I18N support to choosealicense.com proper. See #67 and #62

We already have the bulk of the strings in a single file (_config.yml), so it should just be a matter of abstracting out some of our variables, as far as I can tell.

Would love to take this on starting in August if there's interest. Would be a great exercise to set a standard for Jekyll L10N, and can iterate on some of the lessons learned form https://github.com/CMSgov/healthcare.gov.

@parkr any interest?
@dhcole any insight / words of wisdom?

I would find it very helpful if we added a section describing some of the pros/cons of each license component. Or even just illustrative examples (e.g., this would likely require 20-40 extra hours of documentation work because it requires the developers to do x and y... OR ALSO this clause can discourage companies from adopting and building on your code because x). Some burdensome restrictions might seem fairly innocuous to an outsider not familiar with software development.

I think the wording "adds a restriction restricting" is ugly and adds more perceived complexity to GPL licenses. It is found in index.html at: "V3 is similar to V2, but adds a restriction restricting use in hardware that forbids software alterations.".

I believe that adding a FOSS exception to the GPL by default is a good idea, and should be added to the featured license.

This is a good example for such an exception. http://www.digirulesolutions.com/drupal/foss

See also these instructions by the FSF on the topic: http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

Is there any good reason to use a vanilla GPL v2 without making it compatible with at least the Apache License 2.0, one of the other features licenses?

PS:
While a FOSS exception like the one used by drupal does change the scope and effect of the copyleft of the GPL (thanks gerv), a minimal exception to the GPL v2 could at least ensure compatibility with the Apache License 2. As I understand, the "patent termination and indemnification provisions" in the Apache License 2 that, while present in the GPL v3, are not present in the GPL v2 and the only reasons the GPL v2 is not compatible with the Apache License 2, while the GPL v3 is compatible.
http://www.apache.org/licenses/GPL-compatibility.html
Could this not be remedied with a minimal exception to the GPL v2 stating that if part of the derived work covered is licensed under the Apache License 2, the patent and indemnification provisions are ok and not considered forbidden restrictions?
Other than the hassle of writing such a restriction and getting the legalese right, is there any reason not to do this? It would be really nice if two of the featured licenses on choosealicense.com were not incompatible with each other, wouldn't it?

The contrast of text to background when displaying a license text should be improved.

The text itself has a slightly darker grey as the background.

For the interested visitor and reader the license text should have either a darker text colour or bolder/thicker letters.

BTW: Thanks for that service! Especially the overview of the different licenses is really helpful.

Hi,
In order to avoid ambiguity and facilitate interactions with other projects, it would be nice to use the de facto standard for license names and IDs as defined by the SPDX project. see https://spdx.org/licenses/
Cheers,
Camille

I think it'd be great to add the Zlib license, the big thing with that license is the requirement for Modified verisons of the code to be marked as such

http://www.tldrlegal.com/license/zlib-libpng-license-(zlib)

It is pretty common for text editors, and IDE's to default line wrapping to 78 characters. It can be annoying to have to modify every license because it breaks to 'early', messing with the format.

It would be appreciated to require that the content of all licenses not exceed 78 characters. I'll be more than happy to submit a pull request if this is something that will be accepted.

Saw this Quora question:

If i fork someone's repo on github licensed under mit license and make some changes, can i release it under my name?

and, at least in my reading, none of the tooltips say specifically yay or nay. Or does this fall under "Sublicensing"?

/cc @hoolio

When choosing a licence you should know, that with the wrong license your software/project might be used to harm people or at least might help organisations that harm people.

An example:

I teach a JS class and have all my materials in a repo - both written materials, assignments, etc., and functional code that makes the slide deck itself work. I want to "properly" open source the whole thing.

What is the best way to handle these cases? Creative Commons discourages use of its licenses for software, but the language of something like the MIT license sound very code-specific. Do I need to include one license code, one for non-code? Where is that line drawn? Are there any licenses that can cover all of it? While I'm sure it's impossible to give a general, definitive answer, some guidance in the FAQ might be helpful.

/cc @hoolio

As tweeted:

"Please consult a legal expert before adopting a software license for your project" in the footer feels like a bit of a cop out.

A disclaimer is fine, but "demystifying" licenses only to say you must talk to a mystic is a little silly.

Perhaps the footer could instead say something more along the lines of the "About" page disclaimer (maybe linked to the disclaimer):

"If you have questions or issues, it’s always best to consult a professional."

The site only includes CC0, but would be great to include the others, or explain why (if?) they aren't appropriate for software projects.

There is currently no indication on the page that GPLv2 and GPLv3 are not compatible. This is especially problematic because the only two versions of the license linked are GPLv2 only and GPLv3 but not "GPLv2 or a later version".

The original goal for the /licenses list was to group licenses into license families and not list every single one. For example, rather than an entry for BSD 2-clause and BSD 3 clause, we'd just have BSD and in the description we'd offer links to both of them.

However, the list of licenses in the /licenses folder populates the dropdown list on github.com. The label shown in the list comes from the title: field in the license front matter.

So we need different titles for github.com than we show in the /licenses page.

So I propose we add two new fields:

family-title:
hide-from-licenses-list: (true|false)

The logic is simple. If family-title: is specified, we use that. Otherwise we fallback to title:.

If hide-from-licenses-list is true, we do not list that license on the licenses page. It defaults to false.

In general, I don't like "negative" properties, but this invokes the least amount of change as we only need to hide the redundant licenses. I'm open to doing the extra work and making the property be positive: show-in-licenses: if we think that's better.

Example changes:

title: BSD 2-clause License
family-title: BSD

title: BSD 3-clause License
hide-from-licenses: true

Thoughts?

The licenses we included are intended to be plain text. But since we render them on a website, we have issues with angle brackets. There are two cases we've seen for angle brackets.

1. To denote a template.

copyright <your name> <year> <month>

1. To denote a URL

for more info, visit <http://unlicense.org>

As of #53 we plan to manually replace angle brackets with square brackets. The problem we've encountered is that these licenses templates are the same one we use in .com when you pick a license and they are dropped as-is into a repository without the benefit of Jekyll processing.

So what I propose we consider, if possible:

1. License templates have the license in exactly the original plain text format.
2. When rendering to the web, replace angle brackets with < and >
3. Unless the contents start with "http:" or "https:" in which case we render it as a link. The copy and paste mechanism should still get the original text.

I have a feeling the inclusion of the angle brackets in the source might be a problem for Jekyll though, is that right @benbalter?

The licenses page lists "Patent grant" under GPLv2, LGPL*, and GPLv3.

However it doesn't list "Patent grant" under AGPL/Affero GPL. But looking at the licence text it looks like the AGPL does in fact include a patent grant like the other GPL licences.

It should have an API for people to hack with :)

For example, just having http://choosealicense.com/licenses/mit.json would be nice.

I would do it, but I don't know if you guys are happy with a Jekyll plugin or not?

👍

I was viewing the license list in my Web browser when I found a bug. To reproduce the bug, do the following:

1. Scroll down to the “LGPL” section.
2. Click on “LGPL v3”
3. Click on “LGPL v2.1”
4. Watch as the text below the buttons vanishes. See attached screenshot.

Nothing short of a page reload will make the text reappear. I’m using Safari 7.0 on OS X 10.9.0.

The description "Like a Choose Your Own Adventure site" isn't really accurate unless a wizard-like workflow is established to guide users through several choices, reaching the final result. A good example of such a wizard is the one from WikiMatrix.

Nothing complex or fancy is needed to implement this. A simple tree of hyperlinked pages would do, similar to John Cowan's FLOSS license selection wizard.

There's a warning about sublicensing being forbidden for GPLv3 & v2 (and Affero). While this is technically correct, I think a warning is inappropriate as the risk to the license user is minimal.

Clause 10 explains that, instead of you sublicensing the original work,
"Each time you convey a covered work, the recipient automatically receives
a license from the original licensors, to run, modify and propagate that work,
subject to this License."
Sublicensing is thus redundant, since every recipient has a license to the original work from the copyright holder, plus a license from you to your modifications.

I suggest just removing the warning.

To make it even more straitghforward, It would be cool to have button to make this site send a Pull Request to a specific public github repo adding the license as a file, and/or optionally as a new section on the README.md

The ISC license is a functionally equivalent and the prefered form of the 2-clause BSD license. [1][2]
There's no point recomending the 2-clause BSD license at this points, even projects initially written under the 2-clause BSD license are now suggesting new code use the ISC license.

Just examples for cases where we have them in different order.

Is there a reason for this? I like that these spell out the gist of the license and i think there is real value in the visual clarity that can be found in an ordered list that we are losing when we don't keep the same orde.

There's no point producing a patch for this without some agreement, hence an issue rather than a pull request :-)

The initial 3-way choice, while having the desirability of 1-click licensing choice, means that anyone concerned about patents will end up with Apache 2.0, whereas the GPLv3 also has patent language (and, the FSF would say, GPLv2 has an implied patent licence). In fact, the GPLv3's patent language is significantly stronger than that of the Apache licence, because redistribution means a licence is granted; you don't have to modify, and the patented code doesn't have to be part of your modification. So the patent protection for developers and users is a lot larger.

The best solution would be to say (as we do at Mozilla) that patent language is a necessary requirement for a modern open source licence, and in 2013 no-one should recommend a licence without it. That would simplify the choice down to Apache 2.0 or GPLv3+.

However, if that's a step too far for Github, could we instead have the following workflow?

1. A: "I want it simple and permissive" vs. B: "I want others to share their improvements"
2. A: "I'm not worried about patents" vs. B: "I want to try and avoid patent lawsuits"

A. A. would be MIT (or 2-clause BSD, or ISC, or whatever)
A. B. would be Apache 2.0
B. A. would be GPLv2+
B. B. would be GPLv3+

Gerv

Hope i'm not resurrecting a resolved issue (I looked and couldn't trace one):

If I'm not misreading the licenses, granting rights to their patents is part of what the contributors are required to do under some of the licenses and therefore belongs under the "Required" list and not the "Permitted" list. (Everybody else is then permitted to use and not to grant those patents)

Creating a repository with the BSD (3-Clause) License doesn't define values for all placeholders in the license.

Specifically, the {organization} placeholder is not replaced with any value, and this has to be done manually after creating the repository:

https://github.com/github/choosealicense.com/blob/gh-pages/licenses/bsd-3-clause.txt#L38

A better approach might be to replace {organization} with {fullname}.

cc @haacked @benbalter

When clickin the "Copy license text to clipboard", the license is not copied.
Running Firefox 22 on ArchLinux.

I'm constantly prompted to install a propietary plugin (#45), so that may be related.

The OSI maintains a list of approved OSS licenses here:

http://opensource.org/licenses/alphabetical

It would be good to see these added to the options, although perhaps with a smaller subset suggested by default.

(there's also the WTFPL but that may not be suitably "family friendly"?)

The GPL (V2 or V3) is a copyleft license that requires others who modify your code to disclose their changes if they redistribute it in source or binary form

I'm not sure this explains very clearly what the GPL does.

Basically the GPL makes sure the user of the 'product' will also receive the source and/or modifications. It does not mean the changes need to be made publicly available, only be made available to the user.

So I propose to change the text slightly:
The GPL (V2 or V3) is a copyleft license that requires others who modify your code to make the code and changes available to whomever they distribute it to

Or something along those lines.

Assuming you do:
ensure that installation of your Modified Version does not prevent the user
installing or running the Standard Version. In addition, the Modified Version
must bear a name that is different from the name of the Standard Version.

then the Artistic License 2.0 does not require Disclose Source

sources:
http://choosealicense.com/licenses/artistic/
http://osdir.com/ml/licenses.open-source.general/2007-03/msg00055.html

In it's infinite irony, this website seems to constantly prompt me to install flash. (ie: visit http://choosealicense.com/licenses/mit/, and a "plugin missing" bar will appear on firefox).

The way you present non-copyleft licenses is very, very incorrect.
I'm yet to see an open source project that wouldn't care about improvements. They all want contributions, but permissive ones choose not to try to force others to contribute (for various reasons).

I was pretty excited to learn that CC0 was among the legal texts available on choosealicense.com and that I could even choose it during repo creation. I love CC0 and advertise it to artists and developers alike: It's attached to the strong Creative Commons brand and equally applies to all types of creative works (unlike the limitation to software found in the Unlicense).

Of course that's just the opinion of one guy, but consider that the FSF explicitly recommends CC0 over Unlicense and that there's a wealth of CC0 media files already available.

So I hope you understand why I'm a bit disappointed about the resolution of #38. By no means do I want to put down the effort of the Unlicense people, their advocacy for the PD cause is excellent! But I believe the point of PD is simplicity, and to me that means the ability to use the same declaration for my software, its wiki, manual, screenshots, and many other things up to my holiday photographs and videos.

It's not impossible to read, but it's fairly unpleasant. I might suggest embedding a fixed-width font.

I've forked it and translated it to Chinese.

https://github.com/weakish/choosealicense.com/tree/gitcafe-pages

Well, not a very strict translation, e.g. I've mentioned AGPL in index.html in my translation.

The Chinese version of website:

http://choosealicense.gitcafe.com/

The site refers to "GPL" but there are various GPLs, not just the GNU GPL. GNU say to refer to it as "GNU GPL": http://www.gnu.org/licenses/gpl-faq.html#WhatDoesGPLStandFor

BTW, it may be worth spelling out GPL once as many mistakenly think the G stands for GNU whereas it's General. This is probably another reason they avoid what they think to be tautological: GNU GPL.

Hey guys,

awesome service you are running there. Just a couple of weeks ago I was pointed here: http://www.tldrlegal.com
which pretty much does the same as you. Maybe you want to cooperate somehow, don't know if you already aware of this other website but I hope this hint helps in any way.

Best of luck and thanks for your work
gossi