Like the MIT License and the BSD License family, the ISC License is a short, permissive license. Created by the Internet Software Consortium (now the Internet Systems Consortium), the ISC License is basically a “stripped down” version of the MIT and simplified BSD licenses, with all extraneous language removed.
The ISC License has an interesting and somewhat controversial history, which is one reason why it’s not used as often as other permissive licenses. In fact, its creator, the ISC, no longer uses it for their open source software, selecting the Mozilla Public License 2.0 instead.
So, why is this license less popular than the rest of its permissive license cohort, and why might some projects still choose it? We’ll get into the details below.
ISC License: Requirements
Functionally, the ISC License is identical to the MIT License. The difference lies in the license language, which is as brief as possible, following the rules of the Berne Convention. Basically, this convention set the “ground rules” for the protection of authored works.
The ISC License has very few requirements — only two, in fact — and they’re the same as those of the MIT License. When copying or modifying the licensed code, users must include:
- The original copyright notice
- A copy of the license itself
As with the BSD and MIT licenses, the copyright notice is “baked into” the ISC text. At the beginning of the terms, you’ll see the following line: “Copyright (c) 4-digit year, Company or Person's Name.” The author of the software fills out this information before putting the license in the code repository, and in doing so covers both requirements.
Using the Licensed Code
As a permissive license, the ISC allows for just about any application of the code. Users are free to:
- Use the code commercially. A company or individual can create a proprietary work that includes a copy or modification of the ISC-licensed code, then charge money for that software.
- Modify the code. A developer may make changes to or rework the original software.
- Distribute the code. An individual can share the code, including any updates or alterations, with others, either privately, publicly, or both.
The license clearly states that it does not provide a warranty on the software. Also, contributors (“authors”) disclaim liability for any damages that may arise from the use or sale of the ISC’d code.
ISC License vs. Other Permissive Licenses
While the ISC License is very similar to other common permissive licenses, there are a few key differences. In this section, we’ll compare the ISC with the MIT, BSD, and Apache 2.0 licenses.
ISC License vs. the MIT License
For all intents and purposes, these two licenses are the same. The ISC License simply removes language that would be considered extraneous according to the Berne Convention. The MIT License is much more explicit in its wording, stating outright that users have the right to sublicense, modify, copy, and/or distribute the code.
ISC License vs. the BSD Licenses
The ISC License is considered equivalent to the Simplified (2-Clause) BSD License but with more concise language. It’s not as permissive as the BSD 0-Clause License (which is essentially a public-domain-equivalent license), nor as strong as the BSD 3-Clause License, which includes a non-endorsement clause.
ISC License vs. the Apache License 2.0
The Apache License 2.0 has an additional requirement beyond those of the MIT, Simplified BSD, and ISC licenses. If a user makes any significant changes to the code, they must include a list of those modifications when distributing the software. They do not need to disclose the source code, however, which is why the Apache License 2.0 is still considered permissive.
History and Controversy of the ISC License
Since the ISC License is basically the same as the MIT and Simplified BSD licenses, why isn’t it used as frequently? After all, it’s even more concise. You’d think that would make it the most popular of the permissive license options.
The answer lies in the wording of the original license. When it was released, the ISC License read: “Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted ...” The use of “and” turned out to be a problem, with some (particularly the University of Washington) interpreting it as a prohibition against distributing the software. To address this issue, the “and” was later changed to “and/or.”
Because of this ambiguity, the highly influential GNU suggests that developers select a different license for their open source software. They do state that there’s no reason to avoid software already under this license, but future projects should avoid it. This recommendation has no doubt hurt the ISC License’s usage rates. And, as a result, the license isn’t as recognized or trusted as other permissive options like MIT and Apache 2.0.
The Future of the ISC License
The ISC License may not recover from its unfortunate history. However, with the overall popularity of permissive licenses growing by the year, it may yet turn a corner. After all, it’s short, concise, and as OSS licenses go, easy to read. It’s also an example of why wording makes such a big difference when it comes to legal concerns — something all OSS users should keep in mind.