Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Matt Asay’s headline is best read as an argument about developer priorities, not a declaration that licensing disputes or obligations have ended. In his July 31, 2023, InfoWorld opinion essay, Asay argues that developers often favor access and low-friction tools over license purity. That practical preference can be real while formal distinctions between open-source and source-available software still matter.

What Asay means by “the war is over”

Asay’s central point is that developers want to build things with minimal friction. He wrote: “The goal of open source, of cloud, of open APIs, of great documentation, etc., is to enable developers to build with less friction and more opportunity.” That is his view as an InfoWorld contributing writer and emeritus Open Source Initiative board member—not a formal OSI position.

In this framing, developers may choose a useful project because it is easy to access, learn, and integrate, even if its license is not their preferred one. But that describes a trade-off in practice; it does not mean license terms have stopped governing what users may do. Asay’s essay also recognizes that people continue to contest terminology and licensing concerns.

“Open enough” is not the same as open source

“Open enough” is informal shorthand for software that feels accessible or useful to a developer. The Open Source Initiative (OSI) uses a more specific definition. Its Open Source Definition says source access alone is not sufficient: criteria include free redistribution, access to source code, permission to create derived works, and nondiscrimination against persons, groups, or fields of endeavor.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

That last criterion matters when a license limits use to particular fields—for example, barring commercial use or use in a named industry. A project can make code visible and still fail the OSI definition if its terms impose a field-of-use restriction. The OSI’s license list and definition provide a formal basis for distinguishing recognized open-source licenses from other terms.

How to assess a project’s openness

When evaluating a dependency or platform, separate practical accessibility from the permissions its license grants. Check the license text rather than relying on a repository label or a project’s marketing description.

Question What to check
Can you inspect and modify it? Is source code available in a form useful for making changes?
Can you redistribute it? Do the terms permit sharing the software, including in the ways relevant to your project?
Can you make and share adaptations? Do the terms allow modifications and derived works?
Are uses restricted? Do the terms discriminate by person, group, or field of endeavor, such as restricting commercial use?

These questions help identify the distinction at stake; they do not replace reading the complete license. Particular licenses can impose different conditions and obligations, and there is no universally best license established by these criteria alone. Organizations should review the actual terms of dependencies they use, especially when distributing software or building a commercial product.

What the 2023 argument does—and does not—prove

Asay points to developer behavior, permissive-licensing trends, and a survey conducted while he worked at AWS as support for his case. His essay does not provide the underlying trend analysis or enough survey details to independently establish a general, quantified finding about developer priorities. Those examples are best treated as evidence he invokes, rather than conclusive proof that developers broadly disregard license distinctions.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The OSI’s maintained definition and license resources establish that formal categories remain in use; they do not measure how much developers care about those categories in everyday choices. The strongest defensible conclusion is therefore narrower: convenience may weigh heavily in adoption decisions, but the available evidence does not show that licensing conflict is over.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

AI makes the distinction more than a question of visible code

The OSI’s Open Source AI Definition 1.0 extends the openness question to machine-learning systems. It frames openness around the freedoms to use a system for any purpose, study and inspect it, modify it, and share it. For meaningful modification, the preferred materials include data information, the complete code used to process, train, and run the system, and model parameters.

This AI definition is a contemporary framework, not the specific standard Asay’s 2023 essay used. It illustrates why “the source is available” may be too simple a test: a system can expose some components while leaving other materials needed for study or modification unavailable or subject to restrictive terms.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.