Red Hat 계정으로 회원 프로필, 기본 설정 및 고객 상태에 따라 다음의 서비스에 액세스할 수 있습니다.
아직 등록하지 않으셨습니까? 등록해야 하는 이유:
- 한 곳에서 기술 자료 문서를 탐색하고, 지원 사례와 서브스크립션을 관리하고, 업데이트를 다운로드 할 수 있습니다.
- 조직 내의 사용자를 보고, 계정 정보, 기본 설정 및 권한을 편집할 수 있습니다.
- Red Hat 자격증을 관리하고 시험 내역을 조회하며 자격증 관련 로고 및 문서를 다운로드할 수 있습니다.
Red Hat 계정으로 회원 프로필, 기본 설정 및 자신의 고객 상태에 따른 기타 서비스에 액세스할 수 있습니다.
보안을 위해, 공용 컴퓨터 사용 중에 Red Hat 서비스 이용이 끝난 경우 로그아웃하는 것을 잊지 마십시오.로그아웃
Thirty years ago you might catch the video for R.E.M.'s "Losing My Religion" on MTV, decide you want to buy a copy and pick up your house phone to call a friend to take you to the nearest record store and hope they had it in stock. Today you can just dial up the video on your phone and text your friend about it. That's in large part because of two other things that happened in 1991: The release of the Linux kernel and the second version of the GNU General Public License (GPLv2).
It's, perhaps, a little more complicated than that, but the fact is that a huge swath of technologies we depend on are directly tied to those events. Let's take a step back and talk about those events and what they've enabled.
What is the GPL?
At its most basic, the GPL (like other licenses) is a license that specifies what you can do with a work. Usually this work is a piece of software, like the Linux kernel, but may be something else like documentation.
What's special about the GPL, and other free and open source (FOSS) licenses, is that it uses copyright to maximize the rights given to users, rather than the typical approach of using copyright to restrict what people can do with software or other works.
If you've read an End User License Agreement (EULA), it will typically be full of things you cannot do or specify what you can do in a very limited fashion. For example, it may state that you cannot distribute the software, or that you can only run the software on one machine, or even one type of machine.
The GPL, on the other hand, is aimed at giving specific rights to the recipients of a work to protect what GNU founder Richard Stallman referred to as "the four freedoms."
The GPL's four freedoms
Free software conveys four "freedoms" to users: The freedom to run, copy, study/improve and distribute a work.
In short, this means that if you are given a GPL'ed program you can run it without restriction. You can copy it for a friend, you can tinker with it and improve it, and you can distribute those changes.
You get a copy of Fedora Workstation and you want to run it? Go for it. It's explicitly allowed by the GPL (and other free and open source licenses included with a copy of Fedora).
Want to make a copy for a friend? Go for it. Want to dig in and see how it works? That's also allowed.
Fix a bug in a program and want to share that fix? You can do that, too. However, there's a slight catch in that distributing GPL'ed software comes with some added responsibilities.
Protecting user rights with the GPL
The GPL isn't the only license that conveys these types of freedoms to users. It's one of many free and open source (FOSS) licenses. Note the distinction between "free" and "open source." (See the FAQ for more on this.) What makes the GPL interesting is that it is what's sometimes known as a reciprocal license.
Basically, the GPL insists that the same rights that you received under the GPL be passed on to those you distribute the work to. You cannot receive software under the GPLv2, like the Linux kernel, make changes and then slap a different license on the work that restricts others' ability to do the same thing. The GPL is a creative way to use copyright to encourage use, study, modification and distribution of software rather than trying to restrict it — which is typically what copyright is used to do.
The GPLv2 isn't the only FOSS license in town. It's not even the only version of the GPL in town, but that's a story for another time. The Open Source Initiative lists a bunch of licenses that fit the Open Source Definition.
Permissive vs. copyleft licenses
FOSS licenses are often discussed as being permissive or copyleft. As we've discussed already, copyleft licenses require that you reciprocate by making your changes available when you distribute software under the GPL or other reciprocal licenses. The code was shared with you under the GPL and you are required to share your changes and improvements to that code if you distribute it.
Note that the requirement is triggered when GPL'ed software is distributed, not merely when changes are made. So if you download software and fiddle with it for your own use or learning, but do not distribute it, you are not required to distribute those changes or otherwise make them available to anyone.
Permissive licenses, on the other hand, allow distribution without sharing changes. For example, the MIT license even allows distribution under a proprietary license but does require the inclusion of the original copyright notice.
The Linux kernel is at the heart
All that license stuff is interesting, but what does it have to do with the Linux kernel's success?
Let's back up just slightly to discuss what the kernel is, and isn't. The Linux kernel is the core of the operating system. At a very high level, the kernel manages the hardware, processes, memory, files and so forth. Alone, it's not something most people care about or really interact with, but it's vitally important to the overall operating system.
Many other things go into what we call a Linux distribution, like the GNU utilities and compilers that were already available from the GNU project and helped in building Linux in the first place. And, of course, you have applications to complete the picture and make a computer worth using in the first place. This includes everything from web servers and databases to user desktops.
But the kernel is at the heart of all that, and the reason that Linux has been arguably the most successful operating system of all time is due to the fact that its license allowed copying, improvement, distribution and required sharing of changes. (Note that the license does not require collaboration, but the reciprocal nature of Linux strongly encourages it.)
The first version of the Linux kernel was released under a custom license that restricted commercial activity, but that didn't last long. Linus Torvalds released Linux 0.99 using the GPLv2 in 1992. Why? In Torvalds' own words, "it quickly became evident that my original copyright was so restrictive that it prohibited some entirely valid uses... And while I was nervous about the GPL at first, I also wanted to show my appreciation to the GCC C compiler that Linux depended on, which was obviously GPL'd."
By removing restrictions to commercial use and so forth, Torvalds opened the door to companies improving and distributing Linux. Allowing commercial interests meant that resellers could try to make a buck by packaging Linux and selling it with books, in boxed sets, with magazines, and any number of other methods.
It's important at this point to remember that software distribution in the early 1990s was a lot different than today. Most people received software on a floppy disk (or disks) or CD-ROM. Some people could download software via FTP, but that could be difficult for many users.
First encounters of the Linux kind
Richard Jones, now a senior principal software engineer with Red Hat's R&D Platform team, says he had been using Minix prior to discovering Linux via Slackware Linux. Getting Slackware over the net was a bit of an ordeal, says Jones.
"It came on.... something like 30 3.5-inch (floppy) disks if you wanted a full-featured distribution. It took a day just to download and copy to floppies, but at the time (1992/1993) I was working for a government research place that had access to this amazing new thing called the internet."
Role of the GNU General Public License
The GPLv2's reciprocity meant that vendors distributing Linux couldn't (legally) withhold their changes to the kernel. That encouraged (some might inaccurately say forced) the sharing of changes and work upstream rather than forking the kernel for specific distributions.
Around the same time that Linux was first released, an effort was underway to port another *nix to x86 PCs, under the name 386BSD. That was forked to FreeBSD and NetBSD in 1993. OpenBSD followed in 1995.
While Linux projects and vendors focused on a single Linux kernel, BSD development went in several directions. Admittedly, this is a drastic oversimplification of all the factors that played into Linux's success and the evolution of many, less successful, BSD-based operating systems. The GPL was a factor in Linux's success but not the only one.
For example, Jones points to one of the technical differences between Linux and BSDs that mattered early on. "Simply put Linux had shared libraries," says Jones. "BSD did not, and when you only have a 40 MB hard disk having only one copy of each library really mattered."
UNIX-like but without the price
Price mattered too. While the BSDs were free (as in beer), proprietary UNIX operating systems were decidedly not. Jones mentions that he paid $150 to get a boxed copy of Minix and had to wait weeks to get the software.
Stephen Smoogen, a long-time Linux user and Red Hat employee, says he had been using UNIX when he got started with Linux but the price was pretty steep. "I had been using UNIX for about four years, and the cost of a workstation was around $16,000 USD."
Not exactly affordable for home use, but Smoogen didn't want to go the MS-DOS and Windows route. "I had tried DOS and Windows but found the power of shell scripts, pipes and GCC tools to be too much to go back to it."
Happily, he didn't have to, and the hardware Linux ran on was much more affordable. "Linux on my i386 allowed me to have all the tools and commands I was using on the UNIX box for about $1,600."
Red Hat enters the picture
The first Linux kernel code was released in 1991, but Red Hat wasn't founded until a little later. A few years later, give or take and depending on how you'd define "founded."
Marc Ewing created his own Linux distribution and put out the famed Halloween Red Hat Linux release in October 1994. Meanwhile Bob Young was selling Linux and UNIX software via a company called ACC Corporation around the same time.
In 1995 the two came together as Red Hat Software, with Young as CEO. Red Hat Linux (not yet Red Hat Enterprise Linux) was sold as a boxed product through online vendors and brick-and-mortar stores. Users could also get their hands on Red Hat Linux (and other distributions) on cheap CDs (vendors like Linux Mall sold Linux CDs, including Red Hat Linux, for $0.99 plus shipping) or just through copies shared by their friends.
Without the ability to copy and distribute Linux freely, it's unlikely that the operating system would have caught on the way it did. Without the reciprocal nature of the GPL, it's unlikely the kernel would have become a commons for so many commercial and community interests to draw on.
Here we are, 30 years after the creation of a hobby kernel by a college student and the publication of a revolutionary software license. Separately, the license and the kernel might have just been footnotes alongside Minix or the long-awaited GNU Hurd operating system kernel.
But together they struck a spark that lit a fire that is still burning today.
From hobby to interplanetary adventures
The Linux kernel is now ubiquitous. It's in Android phones, and it's running many of the services you use to place calls, send texts, stream music, watch videos, play games and much more.
Linux runs the TOP500 Supercomputers and powers public clouds. It runs render farms for movie studios and powers Chromebooks for kids doing virtual learning. It powers Raspberry Pi single board computers for hobbyists and powers everything from the Content Delivery Networks (CDNs) for streaming services to the set top boxes and smart TVs.
Not bad for an operating system that was originally developed as a hobby by a college kid. Just imagine what the next 30 years might bring.
About the author
Joe Brockmeier is the editorial director of the Red Hat Blog. He also acts as Vice President of Marketing & Publicity for the Apache Software Foundation.
Brockmeier joined Red Hat in 2013 as part of the Open Source and Standards (OSAS) group, now the Open Source Program Office (OSPO). Prior to Red Hat, Brockmeier worked for Citrix on the Apache OpenStack project, and was the first OpenSUSE community manager for Novell between 2008-2010.