2003: Linux Met a Legal Shadow
· 42 min read · Views --

2003: Linux Met a Legal Shadow

Author: Alex Xiang

Essays

In 2003, Linux was still rising, but there was a new shadow in the air.

The previous year, Linux was learning how to do business. Red Hat launched its enterprise-oriented Advanced Server, UnitedLinux tried to unite several distribution companies, and OpenOffice.org, Mozilla, GNOME, and KDE kept the dream of desktop Linux alive.

By 2003, another question became more concrete: what did it really mean to use, modify, and distribute all this open-source software every day?

This was not a philosophical question.

It landed on licenses, product boundaries, customer contracts, whether a company could close part of its code, and whether an engineer could casually put code found online into a project.

One timeline detail needs correction.

Richard Stallman was not received in China by the company I worked for in 2003. More accurately, he was invited to China by TurboLinux in 1999, and TurboLinux was the predecessor of the company I later joined. This detail matters. It shows that the intersection of the free software movement and China’s Linux boom happened earlier than my entry into the Linux company, and it was not something I personally witnessed that year.

So this essay is not about “I met Stallman.” It is about what really changed in IT history in 2003: SCO v. IBM put Linux into large-scale legal controversy for the first time; Red Hat Enterprise Linux 3 and the Fedora Project made the split between enterprise and community editions clearer; and free software, open source, commercialization, and compliance became entangled.

Free Software Is Not Simply Free-of-Charge Software

Many people first hear “free software” and naturally understand it as software that costs no money.

But the “free” Stallman repeatedly emphasized was not about price. It was about freedom.

The freedom to use software, the freedom to study how it works, the freedom to modify it, and the freedom to distribute original and modified versions. This sounds basic today, but it produced many arguments at the time.

Because many people in China first approached Linux through “no cost.”

Operating-system licenses were expensive. Development tools were expensive. Server software was expensive. Suddenly Linux and a large group of open-source tools were available: installable, usable, and readable. Of course that was attractive. But “free of charge” was only the entrance. If you stopped there, it was easy to misunderstand open source.

What free software really changed for programmers was the relationship between software and users.

You did not have to wait only for a vendor to fix a bug. You did not have to guess what was happening inside the system. In theory, you could read the source, change it, recompile it, and send changes back to the community. Even if you never submitted a patch, knowing that this path existed changed how you looked at software.

That was one of Linux’s greatest trainings for that generation of programmers.

It made people realize: software is not a black box, systems are not mystical objects, and authority is not impossible to challenge.

GPL Turned an Ideal Into Rules

If free software stayed only as a slogan, it would be hard to protect itself.

The importance of the GPL is that it turned an idea into legal and engineering rules.

You can use, study, modify, and distribute GPL software, but if you distribute a modified version, you usually need to comply with corresponding source-code requirements. For many commercial companies, this was exactly the controversial part of GPL.

Engineers like freedom. Bosses may not.

Sales teams like saying “we built our own system based on Linux.” Customers like hearing “source code is controllable.” But product owners soon ask: which code can remain closed? Which modifications must be opened? Does dynamic linking count? What about kernel modules? Can we sell one component separately? Who owns customer customization code?

These questions are not solved by the phrase “we love open source.”

Inside a Linux company, licenses were not decorative text in a README. They affected product design, delivery methods, and business models. You had to know what you used, what you changed, what you distributed, and what you promised.

This is also something many programmers overlook early on.

When writing code, it is easy to think that making it run matters most. After working on products, you learn that running code is only the first step. Where it came from, whether it can be legally distributed, how it will be maintained, and who is responsible when problems happen all matter as much.

Free software, community, commercialization, and legal boundaries

Free software is not simply “free to use.” It involves source code, licenses, community, commercial support, and legal boundaries. The image is a period-inspired illustration.

Open Source and Free Software Were Not the Same

Around 2003, Chinese technical communities also discussed the difference between open source and free software.

Today many people mix the terms. It was the same then.

But their starting points are not identical. Free software emphasizes user freedom and moral position. Open source emphasizes development method, engineering efficiency, and commercial friendliness. The former asks whether users have freedom; the latter asks whether source openness produces better software and collaboration.

This is not just wordplay.

For companies, “open source” is easier to explain externally. It sounds neutral, practical, and suitable for business cooperation. For some idealists, “free software” is the foundation, reminding everyone not to reduce source openness into merely a development strategy.

At the time, I was not capable of thinking deeply about these issues.

I mostly listened, watched, and joined scattered discussions. Truly understanding the difference came many years later. After experiencing commercial projects, customer delivery, closed products, open-source dependencies, security compliance, and legal review, you realize that these abstract-sounding words eventually become real constraints.

In software, words matter.

Behind words are interests, rights, and boundaries.

SCO v. IBM Put a Shadow Over Linux

Another major event in 2003 was SCO suing IBM.

The lawsuit dragged on for many years and became one of the most famous legal events in Linux history. From today’s point of view, Linux has become the base of servers, cloud computing, phones, containers, and AI infrastructure, and the SCO story feels like an episode from an older era.

But in 2003, its psychological impact was real.

Could Linux be used safely? Would enterprise customers worry about legal risk? Could open-source code be pulled into copyright disputes? Sales teams, customers, and media would repeat these questions.

For Linux companies, this was not distant news.

If a customer asked, “Will this system have legal problems?”, engineers could not simply answer, “We believe in open source.” You had to explain licenses, code sources, how the distribution managed upstream components, and where risk boundaries were. Even if many questions could not be finally answered by frontline engineers, they changed how everyone understood open source.

This made me realize early that open source is not a world only programmers participate in.

It has code and law, community and business, ideals and risk control.

RHEL, Fedora, and a Split Path

Also in 2003, Red Hat’s direction became clearer.

Red Hat Enterprise Linux 3 was released, and the Fedora Project appeared around the same time. In simple terms, Red Hat separated the stable enterprise distribution from the community innovation distribution. Enterprise customers needed stability, support cycles, and commercial services. The community needed faster iteration, more open experimentation, and freer participation.

This split later became highly influential.

It showed that Linux commercialization was not simply selling a disc. It required separating users, rhythms, and responsibility boundaries.

Enterprise editions must be slow, stable, and supportable. Community editions can be faster, newer, and more experimental. The two are related, but they cannot be confused.

Many domestic Linux companies faced similar questions then, only with completely different resources, ecosystem, and market conditions.

We wanted to build desktops, servers, government and enterprise projects, and community influence. Every path was right; every path required investment. The problem was that one company could hardly do everything well at once.

That is the cruelty of infrastructure software companies.

All directions matter. Money and people are not enough.

The 1999 Prehistory

Stallman’s 1999 visit to China at TurboLinux’s invitation belongs before this historical line.

At that time, China’s Linux boom had just begun. TurboLinux, Red Flag, BluePoint, Xteam, and other names were entering technical media and community view. TurboLinux targeted the Asian market, valued localization, and had early contact with Chinese universities, enterprises, and communities. It later became the predecessor of the company I joined, so this line is not abstract information for me. It is part of company history.

This prehistory explains why open-source discussions in 2003 did not appear out of nowhere.

The ideas of free software, the GNU/Linux naming debate, GPL constraints, and enterprise-distribution commercialization had already been discussed in domestic Linux circles. But in 2003, SCO v. IBM suddenly made these issues no longer only ideals and community arguments. They became realities that enterprise customers would ask about, legal departments would examine, and sales and engineers could not avoid.

People like Stallman are rare. He was not introducing a product or telling a funding story. He talked about freedom, user rights, licenses, and why software should not be completely locked inside black boxes.

Inside a commercial company, this can sound out of place.

Companies need revenue, customers need delivery, products need release dates, and engineers need to fix bugs. The free software movement sounds too idealistic, too hard-edged, and sometimes a little inhuman.

But looking back many years later, I think that hard edge has value.

Industry naturally slides toward convenience, monopoly, and closure. Commercial companies call it efficiency. Platforms call it experience. Users accept many restrictions because they are convenient. Someone needs to stand in a harder position and remind people repeatedly: software is not only a commodity. It also determines the relationship between people and machines, people and knowledge, and people and platforms.

I may not agree with every claim of the free software movement.

But I respect that persistence.

The Real Impact on Programmers

After 2003, the word “open source” no longer only excited me.

It began to carry responsibility.

When using open-source code, respect the license. When modifying open-source software, know what you changed. When delivering systems to customers, explain component sources. When building company products, know what can be opened and what cannot be casually promised.

This is important training for a programmer.

It turns you gradually from someone who writes code into someone responsible for the software lifecycle.

Later, whether in large internet companies or startups, open-source dependencies became more and more common. Today, an ordinary web project may indirectly depend on hundreds or thousands of open-source packages. The AI era is even more so: models, inference frameworks, vector databases, frontend components, Python packages, and container images all depend on open source.

Without being hit by these questions early in a Linux company, it is easy to treat open source as a free warehouse.

But open source is not a free warehouse.

It is a collaboration method and a responsibility relationship.

The Next Year, Scripting Languages Became Everyday Tools

This 2003 line is about free software and open-source ideas.

In 2004, I want to write about something closer to daily development: Perl, PHP, Java, and my early use of Python. In those years, building systems, websites, internal tools, and automation meant using many languages. That mixture helped people understand earlier that “languages are only tools.”

The next essay is about scripting languages and early Python.

2003 IT Timeline

  • SCO sued IBM. The lawsuit around UNIX, Linux, and intellectual property erupted in 2003, casting a legal shadow over enterprise Linux adoption and making open-source compliance more visible.
  • Red Hat Enterprise Linux 3 was released. The RHEL enterprise path became clearer, and Linux commercialization moved more explicitly toward subscriptions, stable support, and enterprise services.
  • Fedora Project appeared. Red Hat separated community and enterprise distributions. Fedora later became an important role for community innovation and RHEL upstream development.
  • WordPress 1.0 era began. WordPress appeared in 2003. It later became one of the most important open-source CMS and blogging systems, deeply influencing personal publishing and website building.
  • Skype was released. In 2003, Skype brought P2P communication and internet voice calling to more ordinary users.
  • iTunes Music Store launched. Apple launched the iTunes Music Store in 2003, pushing digital music distribution into a new commercial order.

References

More in this column

View all posts in "Thirty Years in IT and Me"