요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
이 문서가 설명하려는 것
1.Intro.rst:50-103원문 작성 당시 Linux 커널은 800만 줄이 넘고 release마다 1,000명 이상의 contributor가 참여하는 가장 크고 활발한 free-software project 가운데 하나였다. 1991년의 작은 출발에서 휴대용 music player, desktop PC, 대형 supercomputer와 그 사이의 수많은 system에서 동작하는 견고하고 효율적이며 확장 가능한 운영체제 구성요소로 성장했다.
Linux가 성장하면서 개발에 참여하려는 개인과 회사도 늘었다. hardware vendor는 자사 제품이 Linux에서 잘 지원되기를 원하고, embedded system vendor는 통합 제품의 한 구성요소인 Linux가 목적에 잘 맞기를 원한다. distribution과 software vendor는 커널 기능·성능·신뢰성에 직접 이해관계가 있으며, end user도 자신의 요구에 맞게 Linux를 바꾸려 한다.
필요한 기술을 가진 누구나 Linux를 개선하고 개발 방향에 영향을 줄 수 있다는 점은 Linux의 핵심 장점이다. 일반적인 약 3개월의 개발 cycle에 100개가 넘는 회사 소속 또는 독립 개발자 1,000명 이상이 참여할 수 있다는 점에서 커널은 다른 free-software project보다도 개방적이다.
커널 community와 일하는 일이 특별히 어렵지는 않지만, 처음 참여하는 사람은 자주 곤란을 겪는다. 매일 수천 줄이 바뀌는 환경에서 고품질 결과물을 유지하기 위해 community가 고유한 작업 방식을 발전시켰기 때문이다. 그래서 커널 개발 절차는 proprietary software 개발 방식과 크게 다르다.
처음에는 이 절차가 낯설고 위압적으로 보일 수 있지만 그 뒤에는 오랜 경험과 이유가 있다. community의 방식을 이해하지 못하거나 의도적으로 우회하려 하면 불필요한 마찰이 생긴다. 배우려는 사람에게는 도움을 주지만 설명을 듣지 않거나 절차를 무시하는 사람에게 쓸 시간은 많지 않다.
이 문서의 목적은 그런 시행착오를 줄이는 데 있다. 분량은 많지만 미리 읽는 데 들인 시간은 실제 patch를 제출할 때 빠르게 회수된다. 커널은 계속 더 나은 코드를 만드는 개발자를 필요로 하며, 이 문서는 개인 개발자와 그를 고용한 조직이 community에 참여하도록 돕는다.
작성과 지원
1.Intro.rst:105-115Jonathan Corbet이 이 문서를 작성했으며 Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, Jochen Voß의 의견으로 개선되었다.
Linux Foundation이 이 작업을 지원했으며, 원문은 작업의 가치를 알아보고 성사시킨 Amanda McPherson에게 특별히 감사를 표한다.
코드를 mainline에 넣어야 하는 이유
1.Intro.rst:117-228여기서 mainline은 Linus Torvalds가 관리하며 Linux distribution이 기반으로 사용하는 커널을 뜻한다. 짧게 보면 코드를 community에 제출하는 일이 피할 수 있는 비용처럼 보이고, 별도 보관하면서 사용자만 직접 지원하는 편이 쉬워 보일 수 있다. 하지만 out-of-tree로 유지하는 방식은 장기 비용을 숨긴 false economy다.
사용자에게 자동으로 전달된다
mainline에 merge된 코드는 해당 기능을 enable한 모든 distribution을 통해 Linux 사용자에게 제공된다. distribution과 kernel version마다 driver disk나 별도 download를 만들고 지원할 필요가 줄어든다. mainline 포함만으로 배포와 지원 문제의 상당 부분이 해결된다.
내부 API 변경의 유지비용을 community와 함께 부담한다
커널은 user space에 대한 interface를 안정적으로 유지하려 노력하지만 내부 API는 계속 바뀐다. 이는 언제든 근본적인 개선을 허용해 코드 품질을 높이기 위한 의도적인 설계다. 반대로 out-of-tree 코드는 새 커널마다 API 변화에 맞춰 계속 수정해야 한다.
mainline 안의 코드는 API를 바꾼 개발자가 그 변경으로 깨지는 in-tree code도 함께 고쳐야 한다는 규칙의 보호를 받는다. 따라서 mainline에 포함된 코드의 장기 유지비용이 훨씬 낮다.
다른 개발자의 개선과 review를 받는다
커널 안의 코드는 사용자와 다른 개발자가 개선할 수 있다. merge 전후의 review는 원 개발자의 숙련도와 관계없이 더 나은 구현 방법, 심각한 bug, security 문제를 찾아낸다. 폐쇄된 환경에서 만든 코드는 외부 시각의 review 효과가 특히 크다. 원문은 이를 요약해 out-of-tree code의 품질이 더 낮다고 지적한다.
개발 방향에 직접 영향을 준다
외부에서 요구사항을 말하는 사용자도 의견을 전달할 수 있지만, 실제 개발에 참여하는 사람은 더 강한 발언권과 자신의 필요에 맞는 변경을 구현할 능력을 가진다.
경쟁 구현이 먼저 합쳐질 위험을 줄인다
기능을 별도 유지하는 동안 제3자가 비슷한 기능을 다른 방식으로 구현해 mainline에 제출할 수 있다. 그 구현이 먼저 자리 잡으면 기존 out-of-tree 코드를 merge하기 매우 어려워질 수 있다. 그러면 비표준 기능을 영구히 별도 유지하거나 코드를 버리고 사용자를 in-tree 구현으로 migration해야 한다.
기여 자체가 ecosystem을 유지한다
코드 기여는 kernel에 새 기능을 더할 뿐 아니라 다른 개발자가 재사용할 capability와 구현 예를 제공한다. Linux용 코드를 개발했다면 platform이 계속 성공하는 데 이해관계가 있으며, upstream 기여는 그 성공을 돕는 가장 직접적인 방법 가운데 하나다.
Binary-only module의 추가 문제
1.Intro.rst:183-218앞의 논리는 proprietary binary-only 형태로 배포하는 코드를 포함해 모든 out-of-tree kernel code에 적용된다. binary-only 배포에는 다음 문제가 더해진다.
- 법적 상태가 불명확하다. 여러 kernel copyright holder는 대다수 binary-only module이 커널의 derivative work이므로 GPL 위반이라고 본다. 원문은 법률 자문이 아니며 최종 판단은 법원이 한다고 명시한다.
- kernel 문제를 debug하기 매우 어려워져 많은 kernel developer가 조사를 시도하지 않는다. 사용자는 community support를 받기 어려워진다.
- 지원하려는 distribution과 kernel version마다 module build를 제공해야 한다. 하나의 module에 수십 개 build가 필요할 수 있고, 사용자는 kernel을 올릴 때 module도 별도로 갱신해야 한다.
- source가 공개되지 않으므로 community review 자체가 불가능하다. 공개 코드에 대한 review의 장점이 binary-only code에는 더 강하게 적용된다.
Embedded product도 예외가 아니다
1.Intro.rst:219-228embedded vendor는 frozen kernel version을 넣은 완결된 제품을 출하하므로 release 뒤 추가 개발이 없다고 생각하기 쉽다. 하지만 이 주장은 넓은 code review의 가치와 사용자가 제품 기능을 확장할 가능성을 놓친다.
embedded product에도 상업적 수명이 있고 결국 다음 version을 출시해야 한다. 코드가 mainline에 있고 꾸준히 유지된 vendor가 새 제품을 더 빠르게 시장에 내놓을 수 있다.
Licensing
1.Intro.rst:230-269Linux 커널에는 여러 license의 코드가 들어가지만 모든 코드는 전체 커널 배포 license인 GNU GPL version 2와 호환되어야 한다. 원문은 실무적으로 기여 코드가 GPLv2 또는 3-clause BSD license로 제공된다고 설명한다. 호환되지 않는 license의 기여는 받아들여지지 않는다.
커널 기여에는 copyright assignment를 요구하지 않는다. mainline에 merge된 코드는 원래 소유권을 유지하며, 그 결과 커널에는 수천 명의 권리자가 있다.
이 소유 구조 때문에 커널 전체 license를 바꾸기는 사실상 불가능하다. 모든 copyright holder의 동의를 얻거나 반대하는 권리자의 코드를 제거할 현실적인 방법이 거의 없으므로, 가까운 미래에 GPL version 3으로 migration할 가능성은 없다.
기여 코드는 적법한 free software여야 한다. 신원을 알 수 없거나 익명인 contributor의 코드는 받지 않는다. 모든 contributor는 sign-off를 통해 해당 코드가 GPL 조건으로 커널과 함께 배포될 수 있음을 진술해야 한다.
소유자가 free software로 license하지 않은 코드나, 적절한 보호 절차 없이 reverse engineering한 결과처럼 copyright 문제를 일으킬 위험이 있는 코드는 기여할 수 없다.
개발 mailing list에서는 copyright 질문에 여러 답변이 달릴 수 있지만 답변자는 보통 변호사가 아니다. Linux source와 관련된 법적 판단이 필요하다면 해당 분야를 이해하는 변호사와 상담해야 하며, 기술 mailing list의 답변에 의존하는 것은 위험하다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. _development_process_intro:
Introduction
============
Executive summary
-----------------
The rest of this section covers the scope of the kernel development process
and the kinds of frustrations that developers and their employers can
encounter there. There are a great many reasons why kernel code should be
merged into the official ("mainline") kernel, including automatic
availability to users, community support in many forms, and the ability to
influence the direction of kernel development. Code contributed to the
Linux kernel must be made available under a GPL-compatible license.
:ref:`development_process` introduces the development process, the kernel
release cycle, and the mechanics of the merge window. The various phases in
the patch development, review, and merging cycle are covered. There is some
discussion of tools and mailing lists. Developers wanting to get started
with kernel development are encouraged to track down and fix bugs as an
initial exercise.
:ref:`development_early_stage` covers early-stage project planning, with an
emphasis on involving the development community as soon as possible.
:ref:`development_coding` is about the coding process; several pitfalls which
have been encountered by other developers are discussed. Some requirements for
patches are covered, and there is an introduction to some of the tools
which can help to ensure that kernel patches are correct.
:ref:`development_posting` talks about the process of posting patches for
review. To be taken seriously by the development community, patches must be
properly formatted and described, and they must be sent to the right place.
Following the advice in this section should help to ensure the best
possible reception for your work.
:ref:`development_followthrough` covers what happens after posting patches; the
job is far from done at that point. Working with reviewers is a crucial part
of the development process; this section offers a number of tips on how to
avoid problems at this important stage. Developers are cautioned against
assuming that the job is done when a patch is merged into the mainline.
:ref:`development_advancedtopics` introduces a couple of "advanced" topics:
managing patches with git and reviewing patches posted by others.
:ref:`development_conclusion` concludes the document with pointers to sources
for more information on kernel development.
What this document is about
---------------------------
The Linux kernel, at over 8 million lines of code and well over 1000
contributors to each release, is one of the largest and most active free
software projects in existence. Since its humble beginning in 1991, this
kernel has evolved into a best-of-breed operating system component which
runs on pocket-sized digital music players, desktop PCs, the largest
supercomputers in existence, and all types of systems in between. It is a
robust, efficient, and scalable solution for almost any situation.
With the growth of Linux has come an increase in the number of developers
(and companies) wishing to participate in its development. Hardware
vendors want to ensure that Linux supports their products well, making
those products attractive to Linux users. Embedded systems vendors, who
use Linux as a component in an integrated product, want Linux to be as
capable and well-suited to the task at hand as possible. Distributors and
other software vendors who base their products on Linux have a clear
interest in the capabilities, performance, and reliability of the Linux
kernel. And end users, too, will often wish to change Linux to make it
better suit their needs.
One of the most compelling features of Linux is that it is accessible to
these developers; anybody with the requisite skills can improve Linux and
influence the direction of its development. Proprietary products cannot
offer this kind of openness, which is a characteristic of the free software
process. But, if anything, the kernel is even more open than most other
free software projects. A typical three-month kernel development cycle can
involve over 1000 developers working for more than 100 different companies
(or for no company at all).
Working with the kernel development community is not especially hard. But,
that notwithstanding, many potential contributors have experienced
difficulties when trying to do kernel work. The kernel community has
evolved its own distinct ways of operating which allow it to function
smoothly (and produce a high-quality product) in an environment where
thousands of lines of code are being changed every day. So it is not
surprising that Linux kernel development process differs greatly from
proprietary development methods.
The kernel's development process may come across as strange and
intimidating to new developers, but there are good reasons and solid
experience behind it. A developer who does not understand the kernel
community's ways (or, worse, who tries to flout or circumvent them) will
have a frustrating experience in store. The development community, while
being helpful to those who are trying to learn, has little time for those
who will not listen or who do not care about the development process.
It is hoped that those who read this document will be able to avoid that
frustrating experience. There is a lot of material here, but the effort
involved in reading it will be repaid in short order. The development
community is always in need of developers who will help to make the kernel
better; the following text should help you - or those who work for you -
join our community.
Credits
-------
This document was written by Jonathan Corbet, [email protected]. It has been
improved by comments from Johannes Berg, James Berry, Alex Chiang, Roland
Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh,
Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, and
Jochen Voß.
This work was supported by the Linux Foundation; thanks especially to
Amanda McPherson, who saw the value of this effort and made it all happen.
The importance of getting code into the mainline
------------------------------------------------
Some companies and developers occasionally wonder why they should bother
learning how to work with the kernel community and get their code into the
mainline kernel (the "mainline" being the kernel maintained by Linus
Torvalds and used as a base by Linux distributors). In the short term,
contributing code can look like an avoidable expense; it seems easier to
just keep the code separate and support users directly. The truth of the
matter is that keeping code separate ("out of tree") is a false economy.
As a way of illustrating the costs of out-of-tree code, here are a few
relevant aspects of the kernel development process; most of these will be
discussed in greater detail later in this document. Consider:
- Code which has been merged into the mainline kernel is available to all
Linux users. It will automatically be present on all distributions which
enable it. There is no need for driver disks, downloads, or the hassles
of supporting multiple versions of multiple distributions; it all just
works, for the developer and for the user. Incorporation into the
mainline solves a large number of distribution and support problems.
- While kernel developers strive to maintain a stable interface to user
space, the internal kernel API is in constant flux. The lack of a stable
internal interface is a deliberate design decision; it allows fundamental
improvements to be made at any time and results in higher-quality code.
But one result of that policy is that any out-of-tree code requires
constant upkeep if it is to work with new kernels. Maintaining
out-of-tree code requires significant amounts of work just to keep that
code working.
Code which is in the mainline, instead, does not require this work as the
result of a simple rule requiring any developer who makes an API change
to also fix any code that breaks as the result of that change. So code
which has been merged into the mainline has significantly lower
maintenance costs.
- Beyond that, code which is in the kernel will often be improved by other
developers. Surprising results can come from empowering your user
community and customers to improve your product.
- Kernel code is subjected to review, both before and after merging into
the mainline. No matter how strong the original developer's skills are,
this review process invariably finds ways in which the code can be
improved. Often review finds severe bugs and security problems. This is
especially true for code which has been developed in a closed
environment; such code benefits strongly from review by outside
developers. Out-of-tree code is lower-quality code.
- Participation in the development process is your way to influence the
direction of kernel development. Users who complain from the sidelines
are heard, but active developers have a stronger voice - and the ability
to implement changes which make the kernel work better for their needs.
- When code is maintained separately, the possibility that a third party
will contribute a different implementation of a similar feature always
exists. Should that happen, getting your code merged will become much
harder - to the point of impossibility. Then you will be faced with the
unpleasant alternatives of either (1) maintaining a nonstandard feature
out of tree indefinitely, or (2) abandoning your code and migrating your
users over to the in-tree version.
- Contribution of code is the fundamental action which makes the whole
process work. By contributing your code you can add new functionality to
the kernel and provide capabilities and examples which are of use to
other kernel developers. If you have developed code for Linux (or are
thinking about doing so), you clearly have an interest in the continued
success of this platform; contributing code is one of the best ways to
help ensure that success.
All of the reasoning above applies to any out-of-tree kernel code,
including code which is distributed in proprietary, binary-only form.
There are, however, additional factors which should be taken into account
before considering any sort of binary-only kernel code distribution. These
include:
- The legal issues around the distribution of proprietary kernel modules
are cloudy at best; quite a few kernel copyright holders believe that
most binary-only modules are derived products of the kernel and that, as
a result, their distribution is a violation of the GNU General Public
license (about which more will be said below). Your author is not a
lawyer, and nothing in this document can possibly be considered to be
legal advice. The true legal status of closed-source modules can only be
determined by the courts. But the uncertainty which haunts those modules
is there regardless.
- Binary modules greatly increase the difficulty of debugging kernel
problems, to the point that most kernel developers will not even try. So
the distribution of binary-only modules will make it harder for your
users to get support from the community.
- Support is also harder for distributors of binary-only modules, who must
provide a version of the module for every distribution and every kernel
version they wish to support. Dozens of builds of a single module can
be required to provide reasonably comprehensive coverage, and your users
will have to upgrade your module separately every time they upgrade their
kernel.
- Everything that was said above about code review applies doubly to
closed-source code. Since this code is not available at all, it cannot
have been reviewed by the community and will, beyond doubt, have serious
problems.
Makers of embedded systems, in particular, may be tempted to disregard much
of what has been said in this section in the belief that they are shipping
a self-contained product which uses a frozen kernel version and requires no
more development after its release. This argument misses the value of
widespread code review and the value of allowing your users to add
capabilities to your product. But these products, too, have a limited
commercial life, after which a new version must be released. At that
point, vendors whose code is in the mainline and well maintained will be
much better positioned to get the new product ready for market quickly.
Licensing
---------
Code is contributed to the Linux kernel under a number of licenses, but all
code must be compatible with version 2 of the GNU General Public License
(GPLv2), which is the license covering the kernel distribution as a whole.
In practice, that means that all code contributions are covered either by
GPLv2 (with, optionally, language allowing distribution under later
versions of the GPL) or the three-clause BSD license. Any contributions
which are not covered by a compatible license will not be accepted into the
kernel.
Copyright assignments are not required (or requested) for code contributed
to the kernel. All code merged into the mainline kernel retains its
original ownership; as a result, the kernel now has thousands of owners.
One implication of this ownership structure is that any attempt to change
the licensing of the kernel is doomed to almost certain failure. There are
few practical scenarios where the agreement of all copyright holders could
be obtained (or their code removed from the kernel). So, in particular,
there is no prospect of a migration to version 3 of the GPL in the
foreseeable future.
It is imperative that all code contributed to the kernel be legitimately
free software. For that reason, code from contributors without a known
identity or anonymous contributors will not be accepted. All contributors are
required to "sign off" on their code, stating that the code can be distributed
with the kernel under the GPL. Code which has not been licensed as free
software by its owner, or which risks creating copyright-related problems for
the kernel (such as code which derives from reverse-engineering efforts lacking
proper safeguards) cannot be contributed.
Questions about copyright-related issues are common on Linux development
mailing lists. Such questions will normally receive no shortage of
answers, but one should bear in mind that the people answering those
questions are not lawyers and cannot provide legal advice. If you have
legal questions relating to Linux source code, there is no substitute for
talking with a lawyer who understands this field. Relying on answers
obtained on technical mailing lists is a risky affair.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
이 개발 절차 문서가 다루는 내용
1-48이 장은 kernel 개발 절차의 범위와 개발자 및 고용주가 겪을 수 있는 어려움을 설명한다. Kernel code를 공식 mainline에 merge해야 할 이유는 많다. 모든 user에게 자동으로 제공되고, 여러 형태의 community 지원을 받을 수 있으며, kernel 개발 방향에도 영향을 줄 수 있다. Linux kernel에 기여하는 code는 GPL-compatible license로 제공해야 한다.
| 절 | 내용 |
|---|---|
| development_process | 개발 절차, kernel release cycle, merge window의 동작, patch 개발·review·merge 단계, 도구와 mailing list를 소개한다. 입문자는 첫 연습으로 bug를 찾아 수정하는 것이 좋다. |
| development_early_stage | 가능한 한 일찍 개발 community를 참여시키는 데 중점을 두고 project 초기 계획을 설명한다. |
| development_coding | coding 과정, 다른 개발자가 겪은 함정, patch 요구 사항, kernel patch의 정확성을 검사하는 도구를 설명한다. |
| development_posting | review를 위해 patch를 게시하는 과정을 설명한다. 적절한 형식과 설명을 갖추고 올바른 대상에게 보내야 진지하게 검토받을 수 있다. |
| development_followthrough | patch 게시 뒤 reviewer와 협업하는 방법을 설명한다. Mainline에 merge되었다고 일이 모두 끝났다고 가정해서는 안 된다. |
| development_advancedtopics | git으로 patch를 관리하는 방법과 다른 사람이 게시한 patch를 review하는 방법을 소개한다. |
| development_conclusion | kernel 개발에 관한 추가 정보 source를 안내하며 문서를 마무리한다. |
Linux kernel project와 개발 community
50-103이 문서가 작성될 당시 Linux kernel은 8백만 줄이 넘는 code와 release마다 1,000명이 훨씬 넘는 contributor가 참여하는, 가장 크고 활발한 free software project 중 하나였다. 1991년의 소박한 시작에서 발전하여 손바닥 크기의 digital music player, desktop PC, 최대 규모의 supercomputer와 그 사이의 거의 모든 system에서 동작하는 뛰어난 operating system component가 되었다. 거의 모든 상황에 적용할 수 있는 견고하고 효율적이며 scalable한 해결책이다.
Linux의 성장과 함께 개발에 참여하려는 개발자와 회사도 늘었다. Hardware vendor는 자신의 제품을 Linux가 잘 지원하여 user에게 매력적으로 보이기를 원한다. Linux를 통합 제품의 구성 요소로 쓰는 embedded system vendor는 해당 작업에 Linux가 최대한 적합하기를 원한다. Linux 기반 제품을 만드는 distributor와 software vendor는 kernel의 기능, 성능, 신뢰성에 직접적인 이해관계가 있다. End user 역시 자신의 요구에 맞게 Linux를 바꾸려 할 수 있다.
필요한 능력을 가진 누구나 Linux를 개선하고 개발 방향에 영향을 줄 수 있다는 접근성은 Linux의 가장 강력한 특징 중 하나다. Proprietary product는 free software 개발 절차의 이런 개방성을 제공할 수 없다. Kernel은 다른 free software project보다도 더 열려 있으며, 일반적인 3개월 개발 cycle에는 100개가 넘는 회사에 속하거나 어떤 회사에도 속하지 않은 1,000명 이상의 개발자가 참여할 수 있다.
Kernel 개발 community와 일하는 것 자체가 특별히 어렵지는 않지만 많은 잠재 contributor가 kernel 작업을 시도하다가 어려움을 겪었다. Community는 매일 수천 줄이 바뀌는 환경에서도 원활히 동작하고 높은 품질을 내기 위한 독자적인 방식을 발전시켰다. 따라서 Linux kernel 개발 절차가 proprietary 개발 방법과 크게 다른 것은 자연스럽다.
새 개발자에게 이 절차는 낯설고 위압적으로 보일 수 있지만, 그 뒤에는 충분한 이유와 축적된 경험이 있다. Community의 방식을 이해하지 못하거나 의도적으로 무시하고 우회하려는 개발자는 큰 좌절을 겪는다. Community는 배우려는 사람을 돕지만, 다른 사람의 말을 듣지 않거나 개발 절차를 중요하게 여기지 않는 사람에게 쓸 시간은 거의 없다.
이 문서를 읽으면 그런 좌절을 피할 수 있기를 기대한다. 내용은 많지만 읽는 데 들인 노력은 곧 보상받는다. 개발 community에는 kernel을 더 좋게 만들 개발자가 늘 필요하며, 이 문서는 독자나 독자의 동료가 community에 합류하도록 돕기 위한 것이다.
저자와 기여자
105-115이 문서는 Jonathan Corbet <[email protected]>가 작성했다. Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, Jochen Voß의 의견으로 개선되었다.
Linux Foundation이 이 작업을 지원했다. 특히 이 작업의 가치를 알아보고 실현되도록 도운 Amanda McPherson에게 감사를 전한다.
Code를 mainline에 넣어야 하는 이유
117-185일부 회사와 개발자는 kernel community의 작업 방식을 배우고 code를 mainline kernel에 넣어야 할 이유를 묻는다. 여기서 mainline은 Linus Torvalds가 관리하고 Linux distributor가 기반으로 사용하는 kernel을 뜻한다. 단기적으로는 code 기여가 피할 수 있는 비용처럼 보이고 별도로 유지하면서 user를 직접 지원하는 편이 쉬워 보일 수 있다. 그러나 out-of-tree code를 따로 유지하는 것은 실제로는 잘못된 절약이다.
- Mainline에 merge된 code는 모든 Linux user에게 제공되며 이를 enable한 distribution에는 자동으로 포함된다. Driver disk, 별도 download, 여러 distribution과 version 조합의 지원 부담이 사라져 배포와 지원 문제를 크게 줄인다.
- Kernel은 userspace와의 interface를 안정적으로 유지하려 하지만 내부 kernel API는 계속 바뀐다. 이는 근본적인 개선을 언제든 가능하게 하여 code 품질을 높이려는 의도적인 설계다. Out-of-tree code는 새 kernel에서 동작하도록 끊임없이 고쳐야 하지만, mainline code는 API를 바꾼 개발자가 그 변경으로 깨지는 code도 함께 수정해야 한다는 규칙의 보호를 받아 유지 비용이 훨씬 낮다.
- Kernel 안에 들어간 code는 다른 개발자가 개선하는 경우가 많다. User community와 customer가 제품을 개선할 권한을 갖게 하면 예상하지 못한 좋은 결과가 나올 수 있다.
- Kernel code는 mainline merge 전후에 review를 받는다. 원 개발자의 능력과 관계없이 review는 개선점을 찾으며 심각한 bug와 security 문제를 발견하는 경우도 많다. 폐쇄적인 환경에서 만든 code는 외부 개발자의 review로 특히 큰 도움을 받는다. Out-of-tree code의 품질은 더 낮다.
- 개발 절차에 참여하면 kernel 개발 방향에 영향을 줄 수 있다. 바깥에서 불만을 제기하는 user의 목소리도 들리지만, active developer는 더 강한 발언권과 자신의 요구에 맞게 kernel을 개선할 능력을 갖는다.
- Code를 별도로 유지하는 동안 제3자가 비슷한 기능의 다른 구현을 기여할 수 있다. 그렇게 되면 기존 code를 merge하기가 극도로 어려워질 수 있다. 결국 비표준 기능을 영구히 out-of-tree로 유지하거나 기존 code를 버리고 user를 in-tree 구현으로 옮겨야 한다.
- Code 기여는 이 전체 절차를 움직이는 근본 행동이다. 새 기능과 다른 kernel 개발자에게 유용한 capability 및 example을 제공한다. Linux용 code를 개발했다면 platform의 지속적인 성공에 이해관계가 있으며, 기여는 그 성공을 보장하는 가장 좋은 방법 중 하나다.
Binary-only module이 추가로 만드는 문제
187-228앞의 이유는 proprietary binary-only 형태로 배포하는 code를 포함한 모든 out-of-tree kernel code에 적용된다. Binary-only 배포에는 그 밖에도 고려할 요소가 있다.
- Proprietary kernel module 배포의 법적 지위는 매우 불명확하다. 많은 kernel copyright holder는 대부분의 binary-only module이 kernel의 derivative work이므로 배포가 GNU GPL을 위반한다고 본다. 이 문서의 저자는 변호사가 아니며 이 내용은 법률 자문이 아니다. Closed-source module의 실제 법적 지위는 법원만 판단할 수 있지만 불확실성 자체는 존재한다.
- Binary module은 kernel 문제 debugging을 극도로 어렵게 만들어 대부분의 kernel 개발자가 시도조차 하지 않는다. 따라서 user가 community의 지원을 받기도 어려워진다.
- 배포자는 지원하려는 모든 distribution과 kernel version마다 module build를 제공해야 한다. 충분한 범위를 지원하려면 module 하나에도 수십 개 build가 필요할 수 있고, user는 kernel을 upgrade할 때마다 module도 별도로 upgrade해야 한다.
- Code review에 관한 앞의 설명은 closed-source code에 더욱 강하게 적용된다. Code를 전혀 볼 수 없으므로 community review를 받을 수 없고 심각한 문제가 있을 가능성이 높다.
Embedded system 제작자는 고정된 kernel version을 쓰는 독립 제품을 출하하고 release 뒤 추가 개발이 필요 없다고 생각하여 이 조언을 무시하고 싶을 수 있다. 그러나 이는 광범위한 code review의 가치와 user가 제품에 기능을 추가할 수 있게 하는 가치를 놓친다. 이런 제품에도 상업적 수명이 있고 결국 새 version을 내야 한다. Code가 mainline에 있고 잘 유지되는 vendor가 다음 제품을 더 빨리 시장에 내놓을 수 있다.
License, copyright ownership, sign-off
230-268Linux kernel에는 여러 license 아래의 code가 기여되지만 모든 code는 kernel 배포 전체를 포괄하는 GNU General Public License version 2(GPLv2)와 호환되어야 한다. 실제로 기여 code는 GPLv2, 선택적으로 후속 GPL version 배포를 허용하는 문구가 붙은 GPLv2, 또는 three-clause BSD license로 제공된다. 호환 license가 없는 기여는 kernel에 받아들이지 않는다.
Kernel 기여 code에 copyright assignment를 요구하거나 요청하지 않는다. Mainline에 merge된 모든 code의 소유권은 원래 소유자에게 남으므로 현재 kernel에는 수천 명의 소유자가 있다.
이 소유 구조 때문에 kernel license를 바꾸려는 시도는 거의 확실히 실패한다. 모든 copyright holder의 동의를 얻거나 동의하지 않은 사람의 code를 제거할 수 있는 현실적인 상황은 거의 없다. 따라서 예측 가능한 미래에 GPL version 3으로 전환할 가능성은 없다.
Kernel에 기여하는 모든 code는 합법적인 free software여야 한다. 신원을 알 수 없거나 익명인 contributor의 code는 받아들이지 않는다. 모든 contributor는 자신의 code가 GPL에 따라 kernel과 함께 배포될 수 있음을 밝히는 sign-off를 해야 한다. 소유자가 free software로 license하지 않은 code나 적절한 보호 절차 없이 reverse engineering한 code처럼 copyright 문제를 일으킬 위험이 있는 code는 기여할 수 없다.
Linux 개발 mailing list에는 copyright 관련 질문이 자주 올라오고 많은 답변이 달리지만, 답변자는 대개 변호사가 아니며 법률 자문을 제공할 수 없다. Linux source code와 관련된 법적 질문이 있다면 이 분야를 이해하는 변호사와 상담해야 한다. 기술 mailing list의 답변에 의존하는 것은 위험하다.
요약
1.Intro.rst:6-48이 장은 커널 개발 절차가 다루는 범위와 개발자 및 고용주가 겪을 수 있는 어려움을 소개한다. 코드를 공식 mainline 커널에 합쳐야 하는 이유로는 사용자에게 자동으로 배포되는 점, 다양한 형태의 community 지원, 커널 개발 방향에 영향을 줄 수 있는 점이 있다. Linux 커널에 기여하는 코드는 GPL과 호환되는 license로 제공해야 한다.
처음 커널 개발을 시작한다면 실제 bug를 찾아 고치는 일을 첫 연습으로 권한다. 작은 수정이라도 재현, 원인 분석, patch 작성, review와 follow-up이라는 전체 흐름을 경험할 수 있기 때문이다.