> In 1969 the US Department of Justice charged IBM with destroying businesses by bundling free software with IBM hardware. As a result of this suit, IBM unbundled its software; that is, software became independent products separate from hardware.
I wonder what 1969-era Justice would think of iphones
compares with gpl, but not with mit. i would think that gpl and mit are the two licences you would mostly want to consider these days - i don't think i've ever used any bsd software, but i might be wrong.
for example, some bsd licences have limitations on advertising, and other things. the mit licence is one para that basically says, maintain copyright notices and do what you want.
The common BSD-style licenses, 2-clause BSD and 3-clause BSD, are similar to the MIT license. The 2-clause BSD is effectively the same as the MIT license. The 3-clause BSD adds "don't use the names of the original software contributors to promote your derived work."
(The Go programming language and Chromium use BSD-style licenses.)
You're not using it, only services on top of it, so you're not entitled to it.
On the other hand, there's a reason Google forbids even spelling the letters AGPL, because then they might have to give you the source code. Copyleft doing exactly what it's supposed to do.
GPL talks only about "object code or executable form" as means of software distribution. When you ping a network server, it's not covered by the license. That's the whole point of AGPL: it covers network access as a mean of software distribution too.
That's the main omission in the article. They claim if you modify the source of a GPL program you need to publish your modifications. That's just not correct. If you distribute a binary form of the modified program you need to make the source available. Google don't distribute their internal kernel, so they are not required to make their modifications available.
They don't distribute it to contractors, I am pretty sure. If contractors work on it they are under NDA, with no rights to use the code for any other purpose, so considered inside Google. If they weren't you would find many copies on github.
Edit: I have no idea whether Google has contractors in such areas. I worked for a company of equal size many years ago and we had contractors everywhere. It was a massive bureaucracy to get access rights for what they needed to do their work, but in the end there was probably not much in the company that some contractor had not access to.
This is based largely on an essay from 18 to 20 years ago.[1]
The claim that GPL benefits large companies that want to maintain monopolistic market power is not supported by several developments in the years up till today. Intel’s stealth computer that runs inside of yours called the Intel Management Engine is running Minix, a non-GPL OS. Apple’s macOS/iOS/iPadOS is non-GPL. Sun’s Solaris was open sourced under CDDL, not GPL. Microsoft’s VS Code is not under GPL either.
> The claim that GPL benefits large companies that want to maintain monopolistic market power is not supported by several developments in the years up till today.
It's also blatantly the exact opposite of what companies have always done, back to the early days of BSD Unix, which is use software licensed under simple, permissive terms to base proprietary codebases off of. Them making that claim must be in bad faith, given how absolutely contrary it is to reality how it directly attacks a reason people don't use those kinds of licenses.
I could bring up how proprietary software companies go out of their way to insult the GPL by calling it "viral" but the breathtaking dishonesty of that argument alone makes my case for me.
> I could bring up how proprietary software companies go out of their way to insult the GPL by calling it "viral" but the breathtaking dishonesty of that argument alone makes my case for me.
I'm willing to say it -- the reason this narrative has so much purchase is that the FSF wants the GPL to be "viral" via its "interpretations" of its own license. If you don't want people to think you're part of the loony fringes, stop hanging out at the loony fringes.
As to whether the GPL actually is legally "viral", I have my doubts. I think the reason you actually don't see the FSF, SFLC, SFC in court is they think they've already lost at the fringes. The last several years of copyright law has been very, very hostile to any of the legal arguments they might make, say, re: dynamically linking modules. Credibility-wise they'd be wiped out. So, they keep soldiering on, pretending to man the battlements day after day.
> Free Software Foundation, Inc. v. Cisco Systems, Inc. was a lawsuit initiated by the Free Software Foundation (FSF) against Cisco Systems on December 11, 2008 in the United States District Court for the Southern District of New York.[1] The FSF claimed that various products sold by Cisco under the Linksys brand had violated the licensing terms of many programs on which FSF held copyright, including GCC, GNU Binutils, and the GNU C Library. Most of these programs were licensed under the GNU General Public License, and a few under the GNU Lesser General Public License.
[snip]
> On May 20, 2009 the parties announced a settlement that included Cisco appointing a director to ensure Linksys products comply with free-software licenses, and Cisco making an undisclosed financial contribution to the FSF.[9][10]
Of course you're right. No company would ever settle a suit it could win, after spending hundreds of thousands on attorneys fees, and going through discovery. /s
Note: I think Cisco was clearly in the wrong here. I think the GPL was enforceable in this instance. I just think don't the more loony claims (a dynamically linked module automatically creates a derivative work) at the fringes make much sense re: copyright law.
If you're telling the truth, back up your assertions. I've backed up mine.
> it could win after spending hundreds of thousands on attorneys fees.
You don't think Cisco has attorneys on retainer?
If the BSD zealots have to resort to dishonesty, people shouldn't trust them.
Also, I can't respond anymore, for some reason. I don't appreciate your trying to obfuscate what we were talking about (the enforceability of the GPL) or making it seem like settling isn't a victory.
> If you're telling the truth, back up your assertions. I've backed up mine.
You'll have to tell me what we are we arguing about? Dynamic linking? The viral-ity of a license? Whether the GPL is enforceable? You're kinda all over the map.
> You don't think Cisco has attorneys on retainer?
Sure, but a retainer doesn't cover all your legal bills. You may pay a modest retainer for the availability of a certain firm/attorney, but it never covers the bulk of litigation, which is extremely expensive.
> If the BSD zealots have to resort to dishonesty, people shouldn't trust them.
Absolutely not a BSD zealot. More of an MPL2 man for my personal projects. Usually happy to contribute to any OSI approved licensed project though!
> I could bring up how proprietary software companies go out of their way to insult the GPL by calling it "viral" but the breathtaking dishonesty of that argument alone makes my case for me.
Eh?
For a lot of my projects I don't care who uses it; I wrote it for my own reasons and if it's useful for anyone else, including corporations, that's fine with me. Other people can make different decisions on that, but this is mine. Integrating GPL, however, makes it a "GPL project" and makes it harder to use in some contexts because derivative software will have to be GPL as well, which why I'd rather not integrate GPL for these projects.
So it certainly "spreads" to other pieces of the software if integrated; i.e. it's "viral" (although I don't really like that term as it comes off as rather dismissive). All of this is kind of the very purpose of copyleft.
That is true. But it is weaker than GPL in that it permits mixing CDDL code with non-CDDL code.
The argument that the essay appears to be making is that large companies want to establish themselves as monopolies by requiring that competing forks publish their changes, incorporating the good changes, and outgunning them on overall development effort. My reading is that the CDDL would not force forks to publish the source code for changes that are made to non-CDDL source files.
The backstory of the CDDL is that Solaris used some code written by contractors over the decades, and Sun didn't have the rights to relicense them and didn't want to spend the effort rewriting all of it either. Since then, illumos has rewritten all those components.
It was a pragmatic and useful decision at the time that's become rather frustrating with ugly workarounds of dubious legality ("GPL condom"). I wish Sun had written in a GPL-compatibility clause similar to the copyleft EUPL.
They can't just relicense it without approval of all the authors/copyright holders, Oracle being chief among them. And we all know how Oracle treated OpenSolaris...
... if you want to foster and ensure the existence of proprietary software. Fair enough, I guess - but not something I would personally feel compelled to do.
Also note that the document never takes into account the needs of the eventual user of the appropriately licensed software, but only ever its (or other) developer(s).
Why would the eventual user care whether or not something is GPL or BSD? They're both free as in cookies and make no allowance or restriction on simple use of the software. The distinction is 100% about what a future developer can do or not do.
> Why would the eventual user care whether or not something is GPL or BSD?
As a user, I definitely prefer to use a copylefted program. This means that I am guaranteed to enjoy the four software freedoms; in particular, I can look at how the program works and I can change its behavior, or hire a programmer to change it.
A non-copylefted program, however, may be distributed by some middleman that deprives me of this freedom. Even if the original developer of the program shared it under a free-software licence, it can be re-packaged as a non-free wrapper. This is impossible with copyleft licenses. Thus, even if copyleft "imposes" some mild restrictions to developers, it is certainly very liberating to users! Notice that the only "restriction" imposed to developers is that they cannot re-package a copylefted program so that it becomes un-free.
>As a user, I definitely prefer to use a copylefted program.
Okay. Good for you. As a user who likes to combine software ideas, I don't want my work or inspiration to be tainted by a work that would try to restrict my work in the future.
You are free to enjoy what your freedoms and I am free to enjoy mine.
I don't develop OpenWRT, but I use it extensively. The GPL is one of the best tools we have for the software side of the right to repair, especially the GPLv3 (anti-tivoization provisions).
Just because you don't actively develop something doesn't mean that you won't find the economy and wider options and market forces it provides useful.
TiVo will never surpass the creativity of others. I whole-heartedly agree with anti-restriction clauses. Like "No lawsuits against users or other creators for "infringing patents" by using this software, if they are not, in another way, infringing. Otherwise, you lose your license."
Nothing about the GPLv3 license created that except that the authors wanted (or maybe didn't really want to) release under that license. And if they like to release under that license. Good for them! But I don't think they should require other software creators to release under the same license. And that's why I won't use GPL software other than LGPL.
Seems to me that every argument is missing a crucial link.
Not saying it's wrong, but it's fantastically poorly written.
E.g. why can users of GPL stuff not just fork, just like BSD?
Why can't someone take abandoned GPL and run with it?
"projects using licenses like the GPL… live under constant threat of having someone take over the project by producing a better version of the code and doing it faster than the original owners."
> E.g. why can users of GPL stuff not just fork, just like BSD?
A GPL-licensed project can be forked. But, if you release work that uses or is derived from the GPL-licensed project, among other things:
1. you must include or make easily available the source code for your derived work.
2. roughly speaking, the license of your derived work cannot be less free than the GPL license (i.e. cannot infringe on rights granted by the original GPL license).
Releasing work derived from a BSD-licensed project does not have these requirements.
"projects using licenses like the GPL… live under constant threat of having someone take over the project by producing a better version of the code and doing it faster than the original owners."
Yeah, I don't understand what the article is trying to say. Honestly the above seems like a good thing.
In other words, it's not that abandoned GPL can't be forked, it's that it's significantly less likely to be forked because the number of parties that could potentially fork it is significantly smaller.
Particularly for more niche projects, it depends not only on a party with the same use case and licensing needs as the original author stumbling across it, but also having the skill and will to take it over and judging that it's better to do that than to start from scratch. There's so many funnels there I wouldn't be surprised if for many projects only a single-digit number of people match that description.
I know the differences perfectly well. This is not a problem of me not knowing the difference. But what do the differences have to do with the point the author is trying to make?
* Use BSD/MIT for a utility. You want the utility to be universally available, and included into larger systems to make them more useful and compatible to each other. A compression library, a file format, a single-purpose program like sshd would benefit from a permissive license.
* Use GPL for a platform. If your stuff allows to build things based on it, if it is intended to serve as a backbone and a foundation, protect if from being grabbed by proprietary hands. Instead, make it safe for participants large and small (but especially large) to contribute to it openly without fear that somebody else would grab their contribution and turn it into a proprietary fork. Something like an OS kernel, or a desktop environment, or an application / database / etc server, or a compiler, may benefit from being released under GPL.
I don't have a strong opinion about programming languages: as long as the toolchain is open-source under whatever license, it usually thrives on its own merits, not due to licenses prodding its use one way or another. The language specification of course needs to be open for re-implementation, and the standard library should be licensed so that it could be included in closed-source projects.
Dual licensing (copyleft + paid commercial) is also a reasonable option.
Where would you say a UI framework (e.g. AppKit, Qt, etc) falls under this? Seems to straddling between utility and platform, and while I can see the benefit in keeping proprietary forks at bay one would probably want to enable the widest possible usage.
[...] if you want proprietary software, not just non-copyleft, to prosper. The reason Google, Facebook, Netflix, Twitter, even Amazon could gobble up so much of our data and communications and lives is thanks to licenses that didn't make it mandatory for those companies to share their source code. Non-copyleft is free work that can be turned into a commercial product.
"Freedom of the developer" doesn't exist in the vacuum. Your freedom to do what you want has impacts on the way other people will use the computer. If your freedom is more important than the collective well-being of sharing resources, products and knowledge, you are not a good person.
This article at no point talks about protection of the end user's freedoms, it's like an article defending factory farming which doesn't mention animal welfare or overuse of antibiotics and hormonal supplements.
> The above observations regarding moral rights imply that putting code under an ISC or two-clause BSD license essentially makes the code as free as it can possibly get.
Emphasis on: or two-clause BSD license.
That said, the ultimate recommendation on the page is ISC, but only because:
> The ISC copyright is functionally equivalent to a two-term BSD copyright with language removed that is made unnecessary by the Berne convention.
A negative for the ISC license: there has been controversy about "and/or" vs. "and" wording in the ISC license text. [1]
The OpenBSD project uses the "and" wording, whereas the license text on the OSI website uses the "and/or" wording.
Given all this, it seems to me that recommending the 2-clause BSD is the most straightforward option, because its only (and innocuous) issue is that it contains some no-longer-necessary language after the Berne convention agreements.
[1] From Wikipedia: When initially released, the license did not include the term "and/or", which was changed from "and" by ISC in 2007. Paul Vixie stated on the BIND mailing list that the ISC license started using the term "and/or" to avoid controversy similar to the events surrounding the University of Washington's refusal to allow distribution of the Pine email software.
ISC licence is essentially just identical to the 2-clause BSD (aka "FreeBSD license"), just phrased a bit different.
Choosing between BSD/ISC/MIT is essentially just choosing which phrasing you like best; the basic idea is the same. Almost all arguments in favour or against the 2-clause BSD license also apply to the ISC license, and vice versa.
What about redistribution of the product of macros/meta programming? Redistribution of the assembler output?
Thought experiment: I publish a library in which the .c file is released as public domain but the .h file (which has no function definitions, `static` or otherwise, and had no function-like macros) is released as BSD-2.
The header file will essentially disappear during compilation. You cannot make a .o out of such a header; there is no binary format of it.
Is the resulting binary covered by the BSD license?
I am highly in favor of {,A,L}GPL licenses, but my new library will be Apache2.
I would not release on MIT or BSD. Apache2 is not that different, but at least has a patent clause. With MIT/BSD you are in "let's just hope" territory.
Letting others change your license is saying you don't care about your work, but that's just my feeling.
Each project has its own target, and should chose the licenses accordingly, but I don't see reason for bsd/mit over apache.
My rule of the thumb is:
* apache for software that needs to be linked to proprietary
* LGPL for other library
* AGPL/GPL depending on your stance on network connectivity, and if you don't care about scaring companies that don't read licenses. (funny how EULA are ok for those companies though)
I would also like to see git hosting software (github, gitlab, gitea...) provide a checkbox to only accept contributions from people who agree on a CLA, and developers would only need a checkbox to agree to it.
Otherwise you are going to be stuck with GPL2 like linux, and you can't fix things that might make sense in your environment, both as being more restrictive, and being less restrictive. People can always fork if you do bad things anyway.
85 comments
[ 3.1 ms ] story [ 137 ms ] threadI wonder what 1969-era Justice would think of iphones
That's the "4-clause" BSD, which hasn't been very popular (since the 1980s? 90s?).
> the mit licence is one para that basically says, maintain copyright notices and do what you want.
The 2-clause BSD license is similar in length to the MITL (which is 3 paragraphs) and substantially similar in contents as well.
(The Go programming language and Chromium use BSD-style licenses.)
That i believe you...
Wow. TIL
On the other hand, there's a reason Google forbids even spelling the letters AGPL, because then they might have to give you the source code. Copyleft doing exactly what it's supposed to do.
So when i sit in a car (service) i don't use the Street (below the service)?
But you are right, and that's exactly why the GPL is NOT preventing Closed-source software per se.
Edit: I have no idea whether Google has contractors in such areas. I worked for a company of equal size many years ago and we had contractors everywhere. It was a massive bureaucracy to get access rights for what they needed to do their work, but in the end there was probably not much in the company that some contractor had not access to.
The claim that GPL benefits large companies that want to maintain monopolistic market power is not supported by several developments in the years up till today. Intel’s stealth computer that runs inside of yours called the Intel Management Engine is running Minix, a non-GPL OS. Apple’s macOS/iOS/iPadOS is non-GPL. Sun’s Solaris was open sourced under CDDL, not GPL. Microsoft’s VS Code is not under GPL either.
[1] https://web.archive.org/web/20080201042548/http://alumni.cse...
It's also blatantly the exact opposite of what companies have always done, back to the early days of BSD Unix, which is use software licensed under simple, permissive terms to base proprietary codebases off of. Them making that claim must be in bad faith, given how absolutely contrary it is to reality how it directly attacks a reason people don't use those kinds of licenses.
I could bring up how proprietary software companies go out of their way to insult the GPL by calling it "viral" but the breathtaking dishonesty of that argument alone makes my case for me.
I'm willing to say it -- the reason this narrative has so much purchase is that the FSF wants the GPL to be "viral" via its "interpretations" of its own license. If you don't want people to think you're part of the loony fringes, stop hanging out at the loony fringes.
As to whether the GPL actually is legally "viral", I have my doubts. I think the reason you actually don't see the FSF, SFLC, SFC in court is they think they've already lost at the fringes. The last several years of copyright law has been very, very hostile to any of the legal arguments they might make, say, re: dynamically linking modules. Credibility-wise they'd be wiped out. So, they keep soldiering on, pretending to man the battlements day after day.
https://en.wikipedia.org/wiki/Free_Software_Foundation,_Inc....
> Free Software Foundation, Inc. v. Cisco Systems, Inc. was a lawsuit initiated by the Free Software Foundation (FSF) against Cisco Systems on December 11, 2008 in the United States District Court for the Southern District of New York.[1] The FSF claimed that various products sold by Cisco under the Linksys brand had violated the licensing terms of many programs on which FSF held copyright, including GCC, GNU Binutils, and the GNU C Library. Most of these programs were licensed under the GNU General Public License, and a few under the GNU Lesser General Public License.
[snip]
> On May 20, 2009 the parties announced a settlement that included Cisco appointing a director to ensure Linksys products comply with free-software licenses, and Cisco making an undisclosed financial contribution to the FSF.[9][10]
Cisco wouldn't settle if it could win.
Even more:
https://opensource.stackexchange.com/questions/11452/have-th...
Yikes.
> Cisco wouldn't settle if it could win.
Of course you're right. No company would ever settle a suit it could win, after spending hundreds of thousands on attorneys fees, and going through discovery. /s
Note: I think Cisco was clearly in the wrong here. I think the GPL was enforceable in this instance. I just think don't the more loony claims (a dynamically linked module automatically creates a derivative work) at the fringes make much sense re: copyright law.
If you're telling the truth, back up your assertions. I've backed up mine.
> it could win after spending hundreds of thousands on attorneys fees.
You don't think Cisco has attorneys on retainer?
If the BSD zealots have to resort to dishonesty, people shouldn't trust them.
Also, I can't respond anymore, for some reason. I don't appreciate your trying to obfuscate what we were talking about (the enforceability of the GPL) or making it seem like settling isn't a victory.
You'll have to tell me what we are we arguing about? Dynamic linking? The viral-ity of a license? Whether the GPL is enforceable? You're kinda all over the map.
> You don't think Cisco has attorneys on retainer?
Sure, but a retainer doesn't cover all your legal bills. You may pay a modest retainer for the availability of a certain firm/attorney, but it never covers the bulk of litigation, which is extremely expensive.
> If the BSD zealots have to resort to dishonesty, people shouldn't trust them.
Absolutely not a BSD zealot. More of an MPL2 man for my personal projects. Usually happy to contribute to any OSI approved licensed project though!
Eh?
For a lot of my projects I don't care who uses it; I wrote it for my own reasons and if it's useful for anyone else, including corporations, that's fine with me. Other people can make different decisions on that, but this is mine. Integrating GPL, however, makes it a "GPL project" and makes it harder to use in some contexts because derivative software will have to be GPL as well, which why I'd rather not integrate GPL for these projects.
So it certainly "spreads" to other pieces of the software if integrated; i.e. it's "viral" (although I don't really like that term as it comes off as rather dismissive). All of this is kind of the very purpose of copyleft.
CDDL is a similarly copyleft license, though.
The argument that the essay appears to be making is that large companies want to establish themselves as monopolies by requiring that competing forks publish their changes, incorporating the good changes, and outgunning them on overall development effort. My reading is that the CDDL would not force forks to publish the source code for changes that are made to non-CDDL source files.
It was a pragmatic and useful decision at the time that's become rather frustrating with ugly workarounds of dubious legality ("GPL condom"). I wish Sun had written in a GPL-compatibility clause similar to the copyleft EUPL.
But apparently kept the same license?
>> Most of the existing code is licensed under the CDDL and we expect new code will generally be under this license as well.[0]
[0] https://github.com/illumos/illumos-gate
Also note that the document never takes into account the needs of the eventual user of the appropriately licensed software, but only ever its (or other) developer(s).
As a user, I definitely prefer to use a copylefted program. This means that I am guaranteed to enjoy the four software freedoms; in particular, I can look at how the program works and I can change its behavior, or hire a programmer to change it.
A non-copylefted program, however, may be distributed by some middleman that deprives me of this freedom. Even if the original developer of the program shared it under a free-software licence, it can be re-packaged as a non-free wrapper. This is impossible with copyleft licenses. Thus, even if copyleft "imposes" some mild restrictions to developers, it is certainly very liberating to users! Notice that the only "restriction" imposed to developers is that they cannot re-package a copylefted program so that it becomes un-free.
Okay. Good for you. As a user who likes to combine software ideas, I don't want my work or inspiration to be tainted by a work that would try to restrict my work in the future.
You are free to enjoy what your freedoms and I am free to enjoy mine.
Just because you don't actively develop something doesn't mean that you won't find the economy and wider options and market forces it provides useful.
> The distinction is 100% about what a future developer can do or not do.
I pointed out that this was incorrect.
> But I don't think they should require other software creators to release under the same license.
So you think end-user-hostile software is fine. I guess we disagree.
Not saying it's wrong, but it's fantastically poorly written.
E.g. why can users of GPL stuff not just fork, just like BSD?
Why can't someone take abandoned GPL and run with it?
"projects using licenses like the GPL… live under constant threat of having someone take over the project by producing a better version of the code and doing it faster than the original owners."
And BSD doesn't? Cough, open, net, FreeBSD.
A GPL-licensed project can be forked. But, if you release work that uses or is derived from the GPL-licensed project, among other things:
1. you must include or make easily available the source code for your derived work.
2. roughly speaking, the license of your derived work cannot be less free than the GPL license (i.e. cannot infringe on rights granted by the original GPL license).
Releasing work derived from a BSD-licensed project does not have these requirements.
References: https://en.wikipedia.org/wiki/GNU_General_Public_License#Ter...
(edit: and on second glance, sorry, it seems like these details aren't really that relevant to the point of your questions.)
"projects using licenses like the GPL… live under constant threat of having someone take over the project by producing a better version of the code and doing it faster than the original owners."
Yeah, I don't understand what the article is trying to say. Honestly the above seems like a good thing.
Particularly for more niche projects, it depends not only on a party with the same use case and licensing needs as the original author stumbling across it, but also having the skill and will to take it over and judging that it's better to do that than to start from scratch. There's so many funnels there I wouldn't be surprised if for many projects only a single-digit number of people match that description.
Because it doesn't make any sense to me.
And it doesn't make sense to me either.
https://www.boost.org/users/license.html
because it does not require the binaries to reproduce the license.
* Use BSD/MIT for a utility. You want the utility to be universally available, and included into larger systems to make them more useful and compatible to each other. A compression library, a file format, a single-purpose program like sshd would benefit from a permissive license.
* Use GPL for a platform. If your stuff allows to build things based on it, if it is intended to serve as a backbone and a foundation, protect if from being grabbed by proprietary hands. Instead, make it safe for participants large and small (but especially large) to contribute to it openly without fear that somebody else would grab their contribution and turn it into a proprietary fork. Something like an OS kernel, or a desktop environment, or an application / database / etc server, or a compiler, may benefit from being released under GPL.
I don't have a strong opinion about programming languages: as long as the toolchain is open-source under whatever license, it usually thrives on its own merits, not due to licenses prodding its use one way or another. The language specification of course needs to be open for re-implementation, and the standard library should be licensed so that it could be included in closed-source projects.
Dual licensing (copyleft + paid commercial) is also a reasonable option.
"Freedom of the developer" doesn't exist in the vacuum. Your freedom to do what you want has impacts on the way other people will use the computer. If your freedom is more important than the collective well-being of sharing resources, products and knowledge, you are not a good person.
https://www.openbsd.org/policy.html
> The above observations regarding moral rights imply that putting code under an ISC or two-clause BSD license essentially makes the code as free as it can possibly get.
Emphasis on: or two-clause BSD license.
That said, the ultimate recommendation on the page is ISC, but only because:
> The ISC copyright is functionally equivalent to a two-term BSD copyright with language removed that is made unnecessary by the Berne convention.
The OpenBSD project uses the "and" wording, whereas the license text on the OSI website uses the "and/or" wording.
Given all this, it seems to me that recommending the 2-clause BSD is the most straightforward option, because its only (and innocuous) issue is that it contains some no-longer-necessary language after the Berne convention agreements.
[1] From Wikipedia: When initially released, the license did not include the term "and/or", which was changed from "and" by ISC in 2007. Paul Vixie stated on the BIND mailing list that the ISC license started using the term "and/or" to avoid controversy similar to the events surrounding the University of Washington's refusal to allow distribution of the Pine email software.
ISC isn't perfect but it's a far better license than BSD.
Choosing between BSD/ISC/MIT is essentially just choosing which phrasing you like best; the basic idea is the same. Almost all arguments in favour or against the 2-clause BSD license also apply to the ISC license, and vice versa.
Under the BSD license, what requirements exist for redistributions that are neither source nor binary in the regular meaning of those terms?
Presumably there ought to be one, but... the license doesn't say.
What about redistribution of the product of macros/meta programming? Redistribution of the assembler output?
Thought experiment: I publish a library in which the .c file is released as public domain but the .h file (which has no function definitions, `static` or otherwise, and had no function-like macros) is released as BSD-2.
The header file will essentially disappear during compilation. You cannot make a .o out of such a header; there is no binary format of it.
Is the resulting binary covered by the BSD license?
I would not release on MIT or BSD. Apache2 is not that different, but at least has a patent clause. With MIT/BSD you are in "let's just hope" territory.
Letting others change your license is saying you don't care about your work, but that's just my feeling.
Each project has its own target, and should chose the licenses accordingly, but I don't see reason for bsd/mit over apache.
My rule of the thumb is:
* apache for software that needs to be linked to proprietary
* LGPL for other library
* AGPL/GPL depending on your stance on network connectivity, and if you don't care about scaring companies that don't read licenses. (funny how EULA are ok for those companies though)
I would also like to see git hosting software (github, gitlab, gitea...) provide a checkbox to only accept contributions from people who agree on a CLA, and developers would only need a checkbox to agree to it.
Otherwise you are going to be stuck with GPL2 like linux, and you can't fix things that might make sense in your environment, both as being more restrictive, and being less restrictive. People can always fork if you do bad things anyway.
Please consider at least adding an exception that allows this combination, like "Apache-2.0 WITH LLVM-Exception".