The Mac in the coffee shop is a certified UNIX system. The Linux fleet serving most of the internet is not. That is not a joke about the year of the Linux desktop — it is a statement about trademark law, and it is the fastest route into a question engineers keep asking in the wrong register. Is Linux UNIX? Legally, no: all-caps “UNIX” is a certification mark owned by The Open Group, and no mainstream distribution has ever signed the agreement that permits its use. Technically, the question barely parses, because certification measures conformance to a published interface, not ancestry, not architecture, and not quality.
That gap — between owning the code and owning the right to make a claim about it — is the single most consequential thing that happened to Unix, and the reason the interface outlived every company that ever owned an implementation of it. This piece works through the actual mechanism: what the mark certifies, who currently holds it, why two Linux distributions have held it and yours does not, and what a platform team can steal from a standards body that has no source tree, no product revenue, and a fifty-year winning streak.
Three Claims That Sound Identical and Are Not
Most arguments about this subject are two people using one word for three different assertions. Separate them once and the rest of the topic stops being contentious.
“Certified UNIX” is a legal status. It means a specific vendor ran The Open Group’s conformance test suites against a named Product Standard — the versioned brands run UNIX 95, UNIX 98, UNIX 03, and UNIX V7 — for a specific product on specific hardware, then signed the Open Brand Trademark Licence Agreement. The Open Group states the consequence plainly on its UNIX certification page: only systems fully compliant and certified against the Single UNIX Specification may use the UNIX trademark. Certification is per-product, per-version, and subject to re-certification; it lapses.
“POSIX-conformant” is a claim about implementing a document — IEEE Std 1003.1, which since the Austin Group’s formation in 1998–99 has been the same text as The Open Group Base Specifications and ISO/IEC 9945. Anyone can implement it. Anyone can also claim to have implemented it, because outside the certification programme nobody polices the claim.
“Unix-like” is a descriptive adjective that nobody owns and nobody can enforce: hierarchical filesystem, processes with fork/exec, file descriptors, a shell that is an ordinary program, a broadly POSIX-shaped syscall surface. It is a statement about family resemblance, and it is the only one of the three claims that is free.
| Certified UNIX | POSIX-conformant | Unix-like | |
|---|---|---|---|
| What it asserts | A named product version passed a named Product Standard’s test suites | The system implements IEEE Std 1003.1 / SUS | It behaves like Unix |
| Who decides | The Open Group | The implementer’s own assertion | Nobody |
| How it’s verified | Conformance suites + signed trademark licence + re-certification | Optionally, by the same programme; otherwise not at all | Not verified |
| What it costs | Engineering to pass, plus the trademark licence, on every release you want covered | Free to read; free to claim | Free |
| Examples (register read 13 August 2026) | macOS 26.0 Tahoe, IBM AIX 7 and z/OS 3.1, HPE HP-UX 11i v3 | Most serious Unix-likes claim substantial conformance | Linux distributions, the BSDs, illumos |
The useful reframing: copyright governs copying, and the certification mark governs claiming. They are separate instruments with separate owners, and the whole modern shape of the Unix world falls out of the fact that those two owners are not the same entity.
Who Actually Holds UNIX Certification Right Now
The Open Group publishes the Register of UNIX Certified Products, and it is the only acceptable source for any “is X certified UNIX?” claim. Read live on 13 August 2026, the register listed four holders.
| Holder | Products listed | Notes |
|---|---|---|
| Apple Inc. | macOS 26.0 Tahoe (Apple silicon and Intel Macs); macOS 15.0 Sequoia | An unbroken line back to Mac OS X 10.5 Leopard, registered 18 May 2007 under UNIX 03 |
| IBM Corporation | z/OS 3.1 and z/OS V2R1 (with Security Server and the C/C++ compiler); AIX 7 at 7.2 TL5+, AIX 7 at 7.1 TL5+/7.2 TL2+, AIX 6.1, AIX 5L 5.3 | The mainframe operating system is certified UNIX. So is AIX, back to a 2006-dated 5L release |
| Hewlett Packard Enterprise | HP-UX 11i v3, release B.11.31 or later | The last of the big proprietary Unixes still actively carrying the mark |
| The SCO Group, Inc. | UnixWare 7.1.3 and later; SCO OpenServer Release 5 and Release 6 | The company filed for bankruptcy in September 2007 and its litigation finally ended in 2021. The name is still on the register |
Two things about that table are worth more than the trivia value.
The first is Apple. macOS is certified UNIX and has been since Leopard in 2007 — the most widely deployed certified UNIX in history is a consumer laptop operating system, and it is certified for the least romantic reason imaginable: Apple ran the suites and signed the agreement. It is not certified because Darwin inherited BSD code. Ancestry is irrelevant to the mark. XNU is a hybrid kernel combining Mach and BSD components — do not let anyone call it a microkernel without heavy qualification — but its genealogy earns Apple exactly nothing at The Open Group. Conformance is a measured property of a shipping product, not a property of a family tree. The proof is in Apple’s own portfolio: iOS shares enormous amounts of that lineage and does not appear on the register.
The second is Oracle. Solaris was certified — its Solaris 11 FCS registration page, UNIX 03, dated 8 November 2011, is still live, and Oracle publicised a Solaris 11.4 certification to UNIX V7 in 2018. But Oracle did not appear in the register listing retrieved on 13 August 2026. State exactly that and date it, rather than repeating “Solaris is certified UNIX” from memory. Certifications lapse quietly, and a live registration page is not the same artifact as a current listing.
The Claim You Should Stop Making: “Linux Can’t Be Certified”
This is the part that turns a pedantic correction into an interesting one. The confident version of the claim — that Linux is architecturally or legally barred from UNIX certification — is false, and the register itself is the disproof.
Two Linux distributions have held UNIX 03.
| Distribution | Base | Registered | Status |
|---|---|---|---|
| Inspur K-UX 3.0 (on Inspur TS K1) | Red Hat Enterprise Linux–derived | 3 February 2016 | Valid until 3 February 2019 — expired |
| Huawei EulerOS 2.0 (on KunLun mission-critical servers) | CentOS-derived | 8 September 2016 | Registration page live and shows no end date; Huawei did not appear in the main register listing retrieved 13 August 2026 |
A Linux kernel with a glibc userland passed the Single UNIX Specification conformance suites, twice, at two different vendors, on purpose. Huawei announced it as a product milestone at the time. Whatever else is true, “Linux cannot be certified UNIX” is not.
So why isn’t Red Hat Enterprise Linux on that register? Why not Ubuntu, SUSE, Debian, or Amazon Linux? Because certification is a procurement question, not a capability question. Both certified Linux distributions were built to sell into a specific institutional market — big-iron, mission-critical server deployments in an environment where a purchase order or a government tender could plausibly list “UNIX certified” as a requirement. That is the entire economic logic of the mark.
For a distribution whose customers are cloud providers, developers, and platform teams, the arithmetic is straightforward and unfavourable. Passing the suites is real engineering work; the trademark licence is the commercial instrument you sign afterwards; and both obligations recur, because the mark attaches to a product version, not to a project. Enterprise Linux ships new minor releases constantly. Certifying a moving target, forever, to satisfy a claim no customer has ever demanded in a contract, is spending money to buy nothing.
That generalises past Unix, and it is the most immediately useful sentence in this article. For any conformance programme — SOC 2, FIPS 140-3, PCI DSS, CNCF’s Certified Kubernetes, UNIX — the question is never “can we pass?” The question is “who requires it in a purchase order?” If the answer is nobody, passing is a vanity project with a recurring maintenance cost. If the answer is your largest customer segment, it is a feature with a deadline.
POSIX and the SUS Are One Document — and It’s Free to Read
The specification side of this story is much less mysterious than the trademark side, and considerably more useful day to day.
The standardisation effort had two independent starts in 1984: the /usr/group Standard in the United States, which fed directly into IEEE work begun that year, and X/Open in Europe, formed by vendors to define a comprehensive open systems environment. The IEEE track produced IEEE Std 1003.1-1988 — POSIX.1 — synthesised from Seventh Edition Unix, System III, System V, 4.2BSD, and 4.3BSD. Per The Open Group’s POSIX.1 backgrounder, the draft was headed for the brand name “IEEE-IX” until Richard Stallman suggested “POSIX” instead.
The two tracks merged in practice. The Austin Group, formed in 1998–99, developed POSIX and the Single UNIX Specification as a single text, and since 2001 the same document has shipped simultaneously as IEEE Std 1003.1, The Open Group Base Specifications, and ISO/IEC 9945. The current edition is POSIX.1-2024 — IEEE Std 1003.1-2024, Base Specifications Issue 8 — published 14 June 2024.
Read it. It is free. The complete text of POSIX.1-2024 is published openly at pubs.opengroup.org, no membership, no paywall, no registration — the IEEE listing for the same standard is the version you pay for. It is the single most useful link in this entire subject area, and it is startling how many engineers who write portable C, shell, and build tooling for a living have never opened the document that defines what “portable” means. When you want to know whether a behaviour is guaranteed or is a Linux extension you will regret depending on, the rationale sections there answer it definitively in a way that Stack Overflow does not.
Note what the free specification implies about the business model. The Open Group gives away the standard and charges for the mark. The document is the commons; the claim is the product.
The Payoff: “Separating the Trademark From Any Code Stream”
Here is the mechanism sentence for this whole subject, and it comes from The Open Group’s own History of UNIX:
“X/Open introduces the Single UNIX Specification (formerly Spec 1170), separating the trademark from any code stream.”
That phrase is doing a lot of work. Novell — which had acquired Unix System Laboratories from AT&T in 1993 — transferred rights to the UNIX trademark and the Single UNIX Specification to X/Open, announced in October 1993 and completed the following year. From that moment “UNIX” stopped denoting a lineage of source code descending from a particular Bell Labs tape and started denoting conformance to a published interface. Any implementation could earn it. No implementation was born with it.
The second half of the trick is how the specification’s content was chosen. Spec 1170 got its number from a survey conducted under the Common Open Software Environment initiative: the group counted the system and library calls that a large sample of real Unix applications actually made, and found 1,170 of them. That list went to X/Open for fast-track standardisation.
Read that again as an engineering method rather than a historical footnote. The interface everyone eventually had to implement was derived by profiling real callers, not designed in a committee room and not proposed by the vendor with the most to gain. It was implementable by everyone precisely because it described what programs were already doing. Committee-designed APIs accrete the union of every member’s wish list; usage-derived APIs converge on the intersection of what anyone actually needs. The first is negotiated, the second is measured.
Together those two moves are a reusable strategy, and it is the most transferable thing in this article:
- Separate the mark from the code stream. Own the right to make a claim, not the implementation. An owner with no implementation has no incentive to bias the specification toward one vendor.
- Derive the specification from measured usage. Instrument the callers before you write the document.
- Ship the conformance suite, not just the prose. A standard that cannot be tested is a suggestion.
- Licence the mark rather than the source. That is the enforcement mechanism, and it is the one that survives when the implementations don’t.
The modern rhymes are everywhere once you know the shape. Certified Kubernetes is a conformance suite plus a mark, run by a foundation with no proprietary distribution to protect. The OCI image and runtime specifications did the same thing to container formats. The Java TCK is the classic commercial version. And the instructive counter-example is the S3 API — the most widely reimplemented storage interface in the industry, a de facto standard nobody owns, which means nobody can define it, nobody can test conformance to it, and every “S3-compatible” claim is a vendor’s word about an unwritten target.
The Control Group: The LSB Died and the Trademark Didn’t
If the trademark-plus-test-suite formula sounds like an obvious win, the Linux world ran the control experiment and lost it.
The Linux Standard Base was the community’s own conformance standard — a specification of binary interfaces, libraries, and filesystem layout intended to let an ISV ship one binary that ran across distributions. It had genuine industry backing under the Linux Foundation. It had a specification. It had test suites.
It has been dead for a decade. LSB 5.0, released 3 June 2015, was the last version. Debian dropped LSB support that same year, and Ubuntu followed. On 7 February 2023, a former project maintainer wrote to the lsb-discuss mailing list that the LSB project was essentially abandoned — insufficient interest, insufficient resources.
| Single UNIX Specification | Linux Standard Base | |
|---|---|---|
| Custodian | The Open Group — an institution whose only assets are the mark and the suites | Linux Foundation workgroup, staffed by vendor volunteers |
| Enforcement instrument | A certification mark: you may not make the claim without passing | None. Nothing stopped a distribution from ignoring it |
| Incentive to comply | Sell into markets that require the mark | Goodwill toward third-party ISVs |
| Current status (13 August 2026) | Live; POSIX.1-2024 published June 2024; register still issuing certifications | Last release June 2015; declared essentially abandoned February 2023 |
The comparison is not about which document was better written. It is about what happens when nobody has standing to enforce a standard. The LSB asked distributions to comply out of shared interest; distributions concluded that the packaging and container ecosystem had solved the ISV problem well enough, and simply stopped. The specification with a trademark owner and a test suite outlived the specification without one — and note the irony in the scoreboard: the survivor is the one backed by a legal instrument, in a community that generally prefers to solve problems with code. Governance is an engineering deliverable, and the LSB is the case study in what a project costs itself by treating it as paperwork.
The Naming Argument, Described and Not Adjudicated
One adjacent dispute deserves a paragraph precisely because it is not the same question, and gets tangled with it constantly.
Linux is a kernel. Linus Torvalds announced it in August 1991 against a Minix backdrop and relicensed it to GPLv2 effective 1 February 1992. A running system is a kernel plus a userland, and on a typical distribution a very large share of that userland — the C library, the compiler toolchain, coreutils — comes from the GNU project, which had been building a Unix-compatible system since 1983 and lacked a production kernel. The Free Software Foundation therefore asks that the combined system be called GNU/Linux, arguing that the naming shapes public understanding of where the system came from. Most of the industry, most distributions, and the kernel project itself use “Linux” for the whole system; Debian is the most prominent holdout, shipping officially as Debian GNU/Linux. Both positions are sincerely held, both are documented, and this article takes neither.
What is worth extracting is the structural observation: the GNU/Linux argument is about attribution, and the UNIX trademark question is about certification. One is a dispute over credit with no adjudicating body; the other is a legal status with a register, a test suite, and an owner who can sue. They feel similar because both are arguments about names. They resolve completely differently, and for exactly that reason.
What an Architect Should Take From This
The durable lesson is not “actually, macOS is the real UNIX.” It is a claim about where power sits in a technology ecosystem.
Every company in this story that owned the implementation is gone or absorbed — AT&T’s Unix business, USL, Novell’s stewardship, Santa Cruz Operation, Caldera, the SCO Group, Sun, DEC, SGI. Every one of them believed the code was the asset. The institution still standing owns no operating system, ships no kernel, and has no product revenue from an implementation. It owns a specification anyone can read for free, a set of conformance tests, and a trademark.
So when you build a platform, an internal API, a plugin contract, or an ecosystem you want to outlive your team’s headcount, the question is not only “what should this interface do?” It is “what makes this interface survive us?” The answer that has now worked for thirty years: publish the specification openly, derive it from what callers actually do rather than from what you would like them to do, make conformance testable by a third party, and hold something enforceable — a mark, a certification, a badge — that lets you define what does and does not count as the thing.
That is why the Mac is UNIX and the Linux box is not, and why neither fact tells you anything at all about which one is the better system.
❓ Frequently Asked Questions
Is Linux UNIX, in one sentence?
No — no mainstream Linux distribution is certified UNIX, because “UNIX” is a certification mark owned by The Open Group and using it requires passing the Single UNIX Specification conformance suites and signing the Open Brand Trademark Licence Agreement. Linux is Unix-like and broadly POSIX-shaped, which is a description of behaviour rather than a legal status.
Why is macOS certified UNIX when Linux isn’t?
Because Apple ran the conformance test suites and signed the trademark agreement, and has kept doing so since Mac OS X 10.5 Leopard was registered on 18 May 2007. It is not certified because Darwin inherited BSD code — ancestry is irrelevant to the mark. The register read on 13 August 2026 lists macOS 26.0 Tahoe for both Apple silicon and Intel Macs.
Can a Linux distribution be certified UNIX at all?
Yes, and two have been. Inspur K-UX 3.0, derived from Red Hat Enterprise Linux, was registered on 3 February 2016 and was valid until 3 February 2019. Huawei EulerOS 2.0, derived from CentOS, was registered on 8 September 2016 for its KunLun servers. Mainstream distributions do not certify because the mark buys them nothing their customers will pay for — economics and choice, not capability.
Is Solaris still certified UNIX?
Its registration pages remain live — Solaris 11 FCS under UNIX 03 dated 8 November 2011, and Oracle publicised a Solaris 11.4 certification to UNIX V7 in 2018 — but Oracle did not appear in the register listing retrieved on 13 August 2026. Because certifications lapse and the register is the only authority, check it on the day you need the answer rather than repeating a remembered status.
What’s the difference between POSIX and the Single UNIX Specification?
Since the Austin Group formed in 1998–99 they are the same text, published under three names: IEEE Std 1003.1, The Open Group Base Specifications, and ISO/IEC 9945. The current edition is POSIX.1-2024, Base Specifications Issue 8, published 14 June 2024. The difference that remains is enforcement: POSIX conformance is something an implementer asserts, while UNIX certification is something The Open Group tests and licenses.
Where can I read the POSIX specification without paying for it?
The full text of POSIX.1-2024 is published openly at pubs.opengroup.org — no membership, no paywall. The paid version is the IEEE-branded copy of the identical document. If you write portable C, shell scripts, or build tooling, the rationale sections there are the authoritative answer to “is this behaviour guaranteed or is it a Linux extension?”
What does “Spec 1170” refer to?
It is the origin of the Single UNIX Specification. The Common Open Software Environment initiative surveyed a large sample of real Unix applications and counted the system and library calls they actually made — 1,170 of them — then sent that list to X/Open for fast-track standardisation. The specification was derived by measuring callers rather than by negotiating a wish list, which is why it was implementable by everyone.
📚 Further Reading
- What Is Chromium? The Open-Source Engine Behind Chrome — the same split, one browser generation later: the freely copyable code base on one side, and the brand, the trademark, and the proprietary bits on the other.
- What Is a Container? The Idea That Powers Modern Software (and AI) — the ecosystem where the OCI specifications and Certified Kubernetes are currently re-running the Open Group playbook described here.
- What is MCP? The Protocol That Lets AI Connect to Your Apps — a young specification facing the same question this article ends on: what makes an interface survive its sponsor?
- Architecture Fitness Functions for Bounded Contexts — conformance suites as executable governance, applied inside a single codebase instead of across an industry.
- The Best Books on Distributed Systems (Beginner to Expert) — for the broader reading on interface stability and compatibility guarantees that this piece’s transferable lesson sits inside.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Start with the free one. The document this entire article is about — POSIX.1-2024, IEEE Std 1003.1-2024, The Open Group Base Specifications Issue 8 — is published in full, openly, at pubs.opengroup.org. No membership, no paywall. The IEEE-branded copy of the identical text is the one that costs money. If you write portable C, shell, or build tooling, that link is worth more than every book below combined.
UNIX: A History and a Memoir
Brian Kernighan · Book
The best single history of Unix, written by someone who was in the room. Kernighan is unusually careful about the difference between what he witnessed and what he was told, which makes it a rare popular history you can actually cite. Where this article stops — at the trademark — the book fills in the fifty years of engineering culture that produced something worth putting a mark on.
The Linux Programming Interface
Michael Kerrisk · Book
The most directly useful follow-up to the “certified versus POSIX-conformant versus Unix-like” distinction in this piece, because Kerrisk marks the boundary explicitly and constantly: for each interface he covers, whether it is specified by POSIX/SUS or is a Linux-specific extension. That is exactly the knowledge that turns “portable” from a hope into a decision. Written by the long-time maintainer of the Linux man-pages project.
Advanced Programming in the UNIX Environment (3rd ed.)
W. Richard Stevens & Stephen A. Rago · Book
The systems-programming reference that treats the specification as the subject rather than any one implementation — it works against POSIX and the SUS, noting where Linux, macOS, Solaris, and the BSDs diverge. If you want to feel what “the interface outlived the implementations” means in practice, this is the book that makes the point on every other page. (Be careful ordering: the 2nd edition is a different ASIN and a significantly older text.)
A Quarter Century of UNIX
Peter H. Salus · Book
The standard history of the period this article’s second half depends on — the standards efforts, X/Open, the vendor wars, and the run-up to the trademark transfer. It is out of print at the publisher and only available used, but Salus authorised The Unix Heritage Society to distribute a scan — look for it at tuhs.org before paying used-market prices. Worth reading critically: some of the most-quoted “Unix philosophy” lines in circulation are Salus’s own 1994 condensations rather than anything the original authors wrote.
For primary sources rather than books, two links do most of the work. The Open Group’s Register of UNIX Certified Products is the only authority on any “is X certified UNIX?” question, and it changes — check it on the day you need the answer. And The Unix Heritage Society hosts the actual V1–V7 and 32V sources, free under the BSD-style Ancient UNIX licence granted on 24 January 2002, which means the code at the root of this whole story is now something you can simply read.