Skip to content

Adds ISC License #50

Merged
merged 26 commits into from Jun 14, 2014
@juanfra684

No description provided.

@Haacked
GitHub member
Haacked commented Jul 17, 2013

From what you mentioned earlier, this should really replace the BSD licenses, right?

@Haacked
GitHub member
Haacked commented Jul 17, 2013

According to #44 this should replace the BSD 2-clause. I'd love to see some references on why that's the case as I'm honestly not familiar with the deprecation of BSD in favor of ISC.

@bendiken

One argument seen often is that since three versions of the BSD license exist, there's not a little potential for confusion. Particularly as for compatibility with other licenses, especially the GPL.

Also, the OpenBSD project switched to ISC, and now state:

The ISC copyright is functionally equivalent to a two-term BSD copyright with language removed that is made unnecessary by the Berne convention. This is the preferred license for new code incorporated into OpenBSD.

@juanfra684

I'm against the removal of BSD 2-clause from the site but I think ISC is a better recommendation for new code. A simpler license is always a good thing.

@sl4mmy sl4mmy referenced this pull request Jul 19, 2013
Closed

Add ISC license. #58

juanfra684 and others added some commits Jul 17, 2013
@juanfra684 juanfra684 Adds ISC License 8bb2727
@sl4mmy sl4mmy Fix template parameter markers in ISC license.
License template parameters are surrounded by square brackets, not
angle brackets.  Drop extension from source: as it's unnecessary.
Add more details to description:.  Add note: and filename:.  Add
private-use and sort permissions.
dc2fc64
@sl4mmy
sl4mmy commented Jul 19, 2013

This is great, thanks @juanfra684 for leading the charge!

@sl4mmy
sl4mmy commented Jul 19, 2013

@Haacked I think adding the ISC license and removing the 2-clause BSD license are two separate issues. Can this pull request be merged in so the two licenses are both live on the site while the interested parties continue the removal discussion?

For what it's worth, I don't think the 2-clause BSD license should be removed at all. Although the ISC license is functionally equivalent and simpler, there is a lot of history behind the BSD license and it's a lot more famous. I prefer adding a note to the BSD license YAML front matter pointing users to the ISC license instead.

@hobarrera

The removal of the two-clause BSD license is because they're both functionaly identical, and the two-clause version has text that, "[...]was made unnecessary by the Berne[...]" (Quoted from OpenBSD/policy)
Thus the keeping the two-claus BSD license means keeping identical licenses. Since it's the one with redundant text there's no point in keeping it.

@sl4mmy
sl4mmy commented Jul 26, 2013

I understand why some think the 2-clause BSD license should be removed, but it's not strictly necessary for adding the ISC license. The world won't end because there are two functionally equivalent licenses available for people to choose from. :)

Let's first get this pull request merged. Afterwards, we can open a separate issue or pull request to continue the discussion about removing the 2-clause BSD license.

@hobarrera

@sl4mmy It's not "necessary", but since the site's goal it to make choosing a license easier, keeping redundant licenses doesn't really help.

@Haacked
GitHub member
Haacked commented Jul 26, 2013

@sl4mmy: I think the relevant question is whether there's any reason at all for anyone to choose BSD anymore now that there's ISC?

The problem of course is that BSD has all the name recognition and BSD doesn't. So I'm inclined to want to have it be "ISC (formerly BSD)" or something like that.

I think it makes sense to add ISC, but before I do, I want to better understand what we plan to do for BSD.

@sl4mmy
sl4mmy commented Jul 26, 2013

@hobarrera Please open a separate issue for removing the 2-clause BSD license and continue the discussion there. I don't want this to hold up adding the ISC license.

@Haacked I think the only reason people would choose the 2-clause BSD license over the ISC license is because they never heard of the ISC license. Also, I don't think "ISC (fromerly BSD)" is accurate, perhaps "ISC (2-clause BSD)" is better?

@hobarrera

@sl4mmy I did (#44), and I was pointed here to continue discussion.

@Haacked
GitHub member
Haacked commented Jul 27, 2013

I think the only reason people would choose the 2-clause BSD license over the ISC license is because they never heard of the ISC license.

That's exactly the thing I'd love to prevent.

Also, I don't think "ISC (fromerly BSD)" is accurate, perhaps "ISC (2-clause BSD)" is better?

That sounds good to me. We can explain the "discrepancy" in the description of the ISC license.

@devinus
devinus commented Aug 22, 2013

👍

@benbalter
GitHub member

👎 to removing BSD. The site's about helping authors choose a license, but also about answering the question "what does this license do?". Many developers are familiar with the BSD, have used BSD licensed projects, etc., and to be completely silent on the issue would be confusing.

As for "recommending" ISC over BSD... we don't do that with any other license now. We have three "featured" licenses on the front page, but that's it. Don't know that we want to be in the business of picking favorites. That said, putting a note or adding something to the description of BSD with a link towards ISC saying "everyone agrees this is the new BSD" or whatever, makes more sense to me.

Do we have any numbers on BSD vs. ISC usage? Is there anything somewhat-official saying BSD has been deprecated in favor of ISC?

@devinus
devinus commented Aug 23, 2013

@benbalter The ISC license is functionally equivalent to the BSD license. The BSD license only has verbiage rendered unnecessary by the Berne Convention. Read more about it here: http://en.wikipedia.org/wiki/ISC_license

@hobarrera

@benbalter I've included the closest thing to an official source above (OpenBSD's license recomendation).

No one owns or controls the BSD license, so no one will provide "official" guidelines. However, if two codes are functionally IDENTICAL, and one contains redundant text, I belive it's quite obvious that the non-redundant version is prefered (the exact same thing happens code).

We don't recommmend any license over another right now, because there is no other set of identical licenses right now.

@Haacked
GitHub member
Haacked commented Aug 23, 2013

@benbalter My ideal solution is to implement #29 and make ISC the "featured" one in the "BSD family".

Don't know that we want to be in the business of picking favorites.

True, but we do want to guide people to make the best choices. And based on all the evidence I've seen, it doesn't make any sense to choose BSD over ISC. ISC truly seems like the successor of BSD. It doesn't seem like we're picking a favorite when they're of the same lineage.

@ghost
ghost commented Aug 24, 2013

Well, while essentially equivalent, BSD 2-clause requires keeping acknowledgment in materials accompanying the distribution, such as documentation. Theoretically, someone can think they abide by ISC by no visible acknowledgment for a binary distribution, and BSD 2-clause by documenting what software they used. (to clarify, I mean keeping what exists)
I can see why an explicit requirement can matter for authors.

FWIW, I think @Haacked's solution for BSD family is the best, to simplify the list and link to variants.

@hobarrera

@engelnyst I belive the Berne Convention covers that.

@Haacked
GitHub member
Haacked commented Oct 29, 2013

Update: I started work on the license groupings here: #111

Once we get that in, we can work on getting this in.

@ghost
ghost commented Nov 6, 2013

@hobarrera Thank you. I assume you are thinking at moral rights to authorship or related. You might be right. However, I think this is not at all a legal question, more a matter of interpretation and community understanding, and the question relevant here is whether the authors feel they want/don't want an explicit condition to include copyright and license terms with a binary distribution.

In this sense, ISC license does not replace BSD 2-clause.

If, on the other hand, we look at the text of the licenses with an interpretive intent to remove "redundant licenses", then I don't see why we can't reasonably say that all permissive licenses say the same thing "do what you want, attribute me" and remove MIT too. (Sorry, I lost a long comment expanding on these points.)

@raineorshine

Anything I can do to help move this along? I think ISC should get added as soon as possible so that this site can continue to serve as a useful resource for people (like me) who are looking for an explanation of the most common licenses and how they differ.

@michaeldexter

This issue has nothing to do with license politics, theory, emotion or preference. BSD contributors are becoming more and more active with GitHub and the there is the simple fact that they have slightly-different licenses and sometimes use them both as needed. I went to enter some ISC code and could not choose the ISC license and had to wonder if my paste of it was properly formatted to GitHub standards and conventions. In short, I all wanted to do was to check the "ISC" checkbox and could not.

@benbalter
GitHub member

Now that we have grouped licenses, I'm 👍 to revisiting this discussion. It's clear that removing BSD isn't an option, but adding ISC, and possibly making it the featured license within the BSD group may be the way to go. Thoughts?

To summarize, practically speaking, ISC is a simplified version of BSD2 and MIT. The difference being largely language, age, and adoption.

@sl4mmy
@benbalter
GitHub member

@juanfra684 are you able to update the pull request, if you're still interested, if not, perhaps someone would be willing to open a new one?

@michaeldexter

License groups sound great solution and hopefully will encourage greater awareness of the issues at hand. Either way, there is the practical matter that some developers must select a very specific "BSD" license such as ISC for given projects regardless of any given opinion.

@juanfra684

@benbalter I've merged the last changes in the branch. What other changes are needed?

@Lagg
Lagg commented Jun 1, 2014

Can this be merged please. There are plenty of people who would love to discover the ISC license and I'm in love with it myself but sadly found it back before github existed in some ISC (appropriately enough) code. You have a pretty good opportunity to assist in discovery here GitHub guys. Don't squander it by letting this pull request rot. (@benbalter)

I was even about to open a pull request myself, good thing I searched.

P.S. Here is a guilt trip commit. If it is not sufficiently guilt trippy enough more guilt trip commits can be arranged.

@benbalter
GitHub member

Sounds like the consensus is to add ISC to the BSD family as the "featured" license? (thus making it the default/prefered BSD-style license, but preserving the "WTF does the BSD license mean" use case).

With an updated PR and passing tests, I'd be glad to merge pending any objection?

@devinus
devinus commented Jun 2, 2014

I used to believe ISC license was a better BSD license, until I read some dissenting opinions. The FSF recommends not to use ISC when you want a BSD license because of clarity, and recommends the 2-clause BSD over it.

http://programmers.stackexchange.com/questions/157476/isc-license-advice

@raineorshine
@michaeldexter

Speaking from a BSD perspective, I suggest this be as apolitical as possible because a project choice of a specific permissive license may have nothing to do with a personal choice. One developer may (and ideally will) contribute to three different BSD OS's with three OS-specific "BSD" licenses.

@sl4mmy
sl4mmy commented Jun 2, 2014

@devinus Are you objecting to including ISC at all? Or are you objecting to marking it as the "preferred" license for the BSD family?

@devinus
devinus commented Jun 2, 2014

@metaraine Agreed.

@sl4mmy The preferred. It's got enough controversy to not be a great "default" license, and I would like to see users have to make that decision for themselves.

@juanfra684

@devinus the problem with the ISC license was due to the word "and". It was changed to the actual "and/or". IIRC, the culprit was the University of Washington and its interpretation of the license of Pine.

@devinus
devinus commented Jun 2, 2014

@juanfra684 The FSF's interpretation is actually after the license was changed to "and/or"

@michaeldexter

May I humbly suggest that the only possible "default" BSD license was the original one with the advertising clause which has been depreciated for good reason? This may simply want to be a "Permissive" category that includes BSD N-clause, ISC, MIT and other variations. All established licenses should selectable by the user if the goal is to encourage participation on GitHub.

@Lagg
Lagg commented Jun 8, 2014

I really don't understand why people are coming out of the woodwork to stall this again. And frankly, what FSF recommends as far as permissive licenses go doesn't matter. They're biased towards copyleft so it creates a bit of a conflict. This is pretty much why ISC isn't as widely known as it could be. People coming out of the wood work claiming that it shouldn't be recommended because it's simple. It's the most ridiculous thing I've ever heard. More ridiculous than dismissing it in favor of its functionally identical BSD equivalent. Which at least has merit if you tilt your head and look at it from a certain angle.

Thank you for the response though @benbalter and @juanfra684 . I still hope to see this in.

@michaeldexter

What is the status of getting the ISC license added as a choice on GitHub, inside or outside of a BSD/Permissive category?

@benbalter
GitHub member

Copyleft or complexity isn't at issue here. Please don't derail the discussion.

The general consensus is that BSD is here to stay as it's a popular license for existing projects and users may want to know what rights they have been granted. As for adding ISC, either grouped with BSD or on its own, from the project goals:

Not comprehensive. Seems like an odd goal, but there are a bajillion licenses out there. We're going to have to filter that down to a small list of those that matter.

Fewer than 500 projects on GitHub (out of 13.5M) are currently licensed under the ISC license. Some search results for common places to look:

Compare that to MIT which has more than 250,000 results, or even BSD, which has more than 10,000.

I don't doubt that the ISC is a great license, and perhaps superior to BSD. That's not at issue here. What's at issue is whether it is widely enough used such that the value of adding it outweighs its diluting effect. Is there a list of major projects using the license?

@raineorshine
@sl4mmy
sl4mmy commented Jun 12, 2014

@benbalter I doubt such a list exists, but ISC is the preferred license of the OpenBSD project for the past several years so some of the big name projects using it are OpenBSD, OpenSSH, and tmux.

Did you search for copyright notices & license statements in actual source files?

Also, your search obviously misses any project whose LICENSE file doesn't include an explicit statement like "This project is released under the terms of the ISC license," so you're not counting any projects which simply copied the ISC license text verbatim. I found a further 43 projects by searching for "Permission to use, copy, modify, and distribute this software" (the original wording) and another 54 with the revised wording (i.e. "and/or distribute").

Not Earth-shattering... However, if you drop the path:LICENSE constraint then there are over 300,000 results.

One aspect of the ISC license is that its terms are so liberal it's compatible with virtually every other license, so ISC-licensed code can easily be incorporated into non-ISC-licensed projects. Perhaps this gets to a philosophical question about choosealicense.com that you & GitHub need to address regarding "licensing projects" vs "licensing code." There might not be a lot of ISC-licensed projects, but there is a lot of ISC-licensed code; is that enough to clear the bar for inclusion?

@michaeldexter

@benbalter With regard to the number of known uses of the ISC license on GitHub, note there is a potential chicken and egg problem: *BSD users are often turned off by strongly biased environments, which fortunately this is not but could be assumed to be given the broader community history.
@sl4mmy Thank you for pointing out the "universal donor" nature of the ISC license in contrast to "universal recipient" ones.

@hobarrera

@benbalter The fact that it's used more doesn't make it a better choice. The OpenBSD proyect has literally thousands of files with the BSD license, yet they recomend the ISC because the BSD one is needlessly redundant (and legally, the same).
Recomending a license with reduntand, needless text for which these is an equivalent succesor makes no sense.

Also, using GitHub as a reference isn't really a good idea. Github (or rather, this proyect) BSD and does not ISC right now, so it's natural that there are more proyects licensed over a the former.

Valid points to recomend ISC:

  • It's shorter
  • It's equivalent to BSD
  • It's generally recomended by large BSD-like proyects (eg: OpenBSD, OpenSSH).

Valid points in favour of BSD license:

  • There are more copies floating around (duh! it's older)
@benbalter
GitHub member

Again, no one is denying the merits of the ISC license (I'm personally a big fan of short, permissive licenses).

MIT, BSD, and ISC appear to be functionally equivalent (with ISC being much less widely used). Adding ISC adds "yet another" nearly identical permissive license to the drop down.

  1. How does adding ISC outweigh the cognitive burden it imposes on uninitiated users (other than "it's better" or "it's shorter" — we can't remove BSD).

  2. How can we objectively counsel a user to choose between MIT, BSD, and ISC, without making qualitative judgements or without falling back to a holy war?

@sl4mmy
@raineorshine
@benbalter
GitHub member

Jeez... What cognitive burden?

@sl4mmy please keep the conversation respectful.

Specifically, the cognitive burden, not within the license itself, but A) the fact that it adds yet another license to the license dropdown (a paradox of choice, question number 1 above), and B) that we provide no means to differentiate it from functionally equivalent licenses (question number 2 above). The site's target audience is not opinionated power users, but those already confused by the number of licensing options available.

@juanfra684

Guys, please don't start an endless discussion about licenses. One year to import just one text file is a lot of time.

@benbalter there is some remaining issue preventing the import of the license?. The pull request passes the travis tests.

@sl4mmy
sl4mmy commented Jun 13, 2014

@juanfra684 Sorry, I'm not trying to start an endless discussion, I'm trying to end one. :)

@benbalter I apologize if you thought I was being disrespectful, I'm just frustrated that this pull request has been open for 11 months while the discussion here keeps going around and around without seeming to make any progress. :(

Are you wondering out loud or are you responding to the actual content of the commits in this pull request? For example, does the "description:" not do a good enough job of explaining the ISC license, how it's different, etc.? Admittedly it's pretty terse. If we reword and improve the description then this pull request would be more palatable?

@hobarrera

@benbalter You are wrong. MIT is different. BSD and ISC are exactly the same. The removed texts is made redundant due to the Berne Convention.

When choosing two code implementations, would you choose on that has a great deal of redudant code that's three times as long?

Eg:
if somevalue:
return true
else if not somevalue:
return false

Or
return somevalue

I'm guessing anyone would pick the second version. So why would you pick a longer legal code when both are the exact same?


Yes, there's probably more code with the BSD clause right now, but even those who initially backed up the BSD license (eg: *BSD proyects) will tell you to use ISC now.


This isn't a popularity contest. It's trying to help users who know little/nothing make an informed choise. Showing them deprecated alternatives before non-depracted one hurts our goal!

I've also clearly stated the goals of the license, and have not seen anyone disprove those arguments.


Yes, users are probably confused by the amount of licenses available, and more makes it harder to pick one. This is a clear +1 to deleting the simplified BSD license.


As a final choice, can we not add a tag saying "This license replaces the simplified BSD license, which is equivalent, but contains redudant texts?" This would CLEARLY help remove confusion from users:

  • Even if they'd see it elsewhere, they'd understand about the BSD-license and why not to choose it.
  • It still reflects the recomendation of the informed community which uses this license.
@Lagg
Lagg commented Jun 14, 2014

Yeah. I'm trying to keep out of this besides minor comments of encouragement (because I'm sick of this kind of thing, I became disillusioned with GNU because of that nonsense) and far be it for me to tell a github employee how to do their own merge mastering for a github site but that is rather silly. For all intents and purposes ISC deprecates BSD. BSD projects themselves even note this and one of them literally is replacing it. It's what a license looks like when it's refactored. It's not very reasonable for you to tell people not to use its main feature (being a cleaner and even simpler BSD) as a point of argument and then proceed to use something like BSD having a more readily recognizable name or being "more known" as an argument against replacing it.

Granted, even though I don't like the dishonesty involved I do understand marketing and brand. Which is why the aforementioned solution of noting that ISC is a cleaned BSD should be more than sufficient.

As an aside, ISC doing this aligns perfectly with the problem that choosealicense.com was created to help. People becoming fatigued with the license hell and just wanting to push their code out somewhere and KIS(S) without having to both read a gigantic essay length license /or including said essay in every source file and thus pushing it without any license thinking it was automatically PD.

With the increasing (and overdue, in my opinion) focus on elegance and simplicity with readability being considered just as important as documentation. Having a code cleanup pass in license form fits together like so many lego blocks. It even aligns with github's goal itself to make version control simple and fun. So you should really consider that stuff when pondering this instead of diluting it down to oversimplified and frankly unfair requirements of "Tell me how this functionally identical license is superior but you're not allowed to use its explicit primary feature that makes it superior as part of that justification"

@benbalter benbalter merged commit 52adce2 into github:gh-pages Jun 14, 2014

1 check passed

Details continuous-integration/travis-ci The Travis CI build passed
@benbalter
GitHub member

Thanks everyone for weighing in and for the enlightening discussion. Modified the pull request to make ISC the default license within the BSD group as originally proposed since that seemed to be the consensus, and adjusted the description to explain what a permissive license is.

The license should make its way into the drop down on GitHub.com shortly, and please feel free to open a pull request with any changes to the description, meta-data, etc.

@juanfra684 thanks for the pull request! Glad we were able to get this merged.

@Lagg
Lagg commented Jun 14, 2014

@benbalter Yay, thanks. Very pleasing and reassuring to see stuff like this actually make progress instead of stalling and sputtering out.

@sl4mmy
@hobarrera

Thanks, @benbalter!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.