Linux 커널 개발 절차 입문

문서 전체 개요

이 장은 kernel 개발 절차의 범위와 개발자 및 고용주가 겪을 수 있는 어려움을 설명한다. Kernel code를 공식 mainline에 merge해야 할 이유는 많다. 모든 user에게 자동으로 제공되고, 여러 형태의 community 지원을 받을 수 있으며, kernel 개발 방향에도 영향을 줄 수 있다. Linux kernel에 기여하는 code는 GPL-compatible license로 제공해야 한다.

이탈리아어판은 개발 절차 전체를 일곱 단계로 안내합니다. 초기 기획부터 coding, patch 게시, reviewer와의 후속 작업, git과 review의 고급 주제, 추가 자료까지 이어지며, 처음 참여하는 개발자는 실제 bug를 찾아 고치는 작업으로 절차를 익히도록 권합니다.

커널 code를 공식 mainline에 넣으면 사용자에게 즉시 배포되고 community의 유지보수와 review를 받을 수 있으며 개발 방향에도 영향을 줄 수 있습니다. 모든 기여는 GPLv2와 호환되는 license로 제공되어야 합니다.

.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/1.Intro.rst <development_process_intro>`
:Translator: Alessia Mantegazza <[email protected]>

.. _it_development_intro:

Introduzione
============

Riepilogo generale
------------------

Il resto di questa sezione riguarda il processo di sviluppo del kernel e
quella sorta di frustrazione che gli sviluppatori e i loro datori di lavoro
potrebbero dover affrontare.  Ci sono molte ragioni per le quali del codice
per il kernel debba essere incorporato nel kernel ufficiale, fra le quali:
disponibilità immediata agli utilizzatori, supporto della comunità in
differenti modalità, e la capacità di influenzare la direzione dello sviluppo
del kernel.
Il codice che contribuisce al kernel Linux deve essere reso disponibile sotto
una licenza GPL-compatibile.

La sezione :ref:`it_development_process` introduce il processo di sviluppo,
il ciclo di rilascio del kernel, ed i meccanismi della finestra
d'incorporazione.  Il capitolo copre le varie fasi di una modifica: sviluppo,
revisione e ciclo d'incorporazione. Ci sono alcuni dibattiti su strumenti e
liste di discussione. Gli sviluppatori che sono in attesa di poter sviluppare
qualcosa per il kernel sono invitati ad individuare e sistemare bachi come
esercizio iniziale.

La sezione :ref:`it_development_early_stage` copre i primi stadi della
pianificazione di un progetto di sviluppo, con particolare enfasi sul
coinvolgimento della comunità, il prima possibile.

La sezione :ref:`it_development_coding` riguarda il processo di scrittura
del codice. Qui, sono esposte le diverse insidie che sono state già affrontate
da altri sviluppatori.  Il capitolo copre anche alcuni dei requisiti per le
modifiche, ed esiste un'introduzione ad alcuni strumenti che possono aiutarvi
nell'assicurarvi che le modifiche per il kernel siano corrette.

La sezione :ref:`it_development_posting` parla del processo di pubblicazione
delle modifiche per la revisione. Per essere prese in considerazione dalla
comunità di sviluppo, le modifiche devono essere propriamente formattate ed
esposte, e devono essere inviate nel posto giusto. Seguire i consigli presenti
in questa sezione dovrebbe essere d'aiuto nell'assicurare la migliore
accoglienza possibile del vostro lavoro.

La sezione :ref:`it_development_followthrough` copre ciò che accade dopo
la pubblicazione delle modifiche; a questo punto il lavoro è lontano
dall'essere concluso.  Lavorare con i revisori è una parte cruciale del
processo di sviluppo; questa sezione offre una serie di consigli su come
evitare problemi in questa importante fase.  Gli sviluppatori sono diffidenti
nell'affermare che il lavoro è concluso quando una modifica è incorporata nei
sorgenti principali.

La sezione :ref:`it_development_advancedtopics` introduce un paio di argomenti
"avanzati": gestire le modifiche con git e controllare le modifiche pubblicate
da altri.

La sezione :ref:`it_development_conclusion` chiude il documento con dei
riferimenti ad altre fonti che forniscono ulteriori informazioni sullo sviluppo
del kernel.

문서의 대상과 개발 community

이 문서가 작성될 당시 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에 합류하도록 돕기 위한 것이다.

Linux kernel은 다양한 장치와 system에서 동작하는 대규모 공동 개발 project이며 hardware vendor, embedded vendor, distribution, software vendor와 최종 사용자 모두가 기능·성능·신뢰성에 직접 이해관계를 갖습니다.

개발 방식은 proprietary project와 다르지만 무작위적인 것은 아닙니다. 빠른 변화 속에서도 품질을 유지하기 위해 축적된 규칙이므로, 새 contributor는 이를 우회하기보다 mailing list와 reviewer의 feedback을 듣고 기존 절차를 이해해야 합니다.

Di cosa parla questo documento
------------------------------

Il kernel Linux, ha oltre 8 milioni di linee di codice e ben oltre 1000
contributori ad ogni rilascio; è uno dei più vasti e più attivi software
liberi progettati mai esistiti.  Sin dal sul modesto inizio nel 1991,
questo kernel si è evoluto nel miglior componente per sistemi operativi
che fanno funzionare piccoli riproduttori musicali, PC, grandi super computer
e tutte le altre tipologie di sistemi fra questi estremi.  È una soluzione
robusta, efficiente ed adattabile a praticamente qualsiasi situazione.

Con la crescita di Linux è arrivato anche un aumento di sviluppatori
(ed aziende) desiderosi di partecipare a questo sviluppo. I produttori di
hardware vogliono assicurarsi che il loro prodotti siano supportati da Linux,
rendendo questi prodotti attrattivi agli utenti Linux.  I produttori di
sistemi integrati, che usano Linux come componente di un prodotto integrato,
vogliono che Linux sia capace ed adeguato agli obiettivi ed il più possibile
alla mano. Fornitori ed altri produttori di software che basano i propri
prodotti su Linux hanno un chiaro interesse verso capacità, prestazioni ed
affidabilità del kernel Linux.  E gli utenti finali, anche, spesso vorrebbero
cambiare Linux per renderlo più aderente alle proprie necessità.

Una delle caratteristiche più coinvolgenti di Linux è quella dell'accessibilità
per gli sviluppatori; chiunque con le capacità richieste può migliorare
Linux ed influenzarne la direzione di sviluppo.  Prodotti non open-source non
possono offrire questo tipo di apertura, che è una caratteristica del software
libero.  Ma, anzi, il kernel è persino più aperto rispetto a molti altri
progetti di software libero.  Un classico ciclo di sviluppo trimestrale può
coinvolgere 1000 sviluppatori che lavorano per più di 100 differenti aziende
(o per nessuna azienda).

Lavorare con la comunità di sviluppo del kernel non è particolarmente
difficile.  Ma, ciononostante, diversi potenziali contributori hanno trovato
delle difficoltà quando hanno cercato di lavorare sul kernel.  La comunità del
kernel utilizza un proprio modo di operare che gli permette di funzionare
agevolmente (e genera un prodotto di alta qualità) in un ambiente dove migliaia
di stringhe di codice sono modificate ogni giorni. Quindi non deve sorprendere
che il processo di sviluppo del kernel differisca notevolmente dai metodi di
sviluppo privati.

Il processo di sviluppo del Kernel può, dall'altro lato, risultare
intimidatorio e strano ai nuovi sviluppatori, ma ha dietro di se buone ragioni
e solide esperienze.  Uno sviluppatore che non comprende i modi della comunità
del kernel (o, peggio, che cerchi di aggirarli o violarli) avrà un'esperienza
deludente nel proprio bagaglio.  La comunità di sviluppo, sebbene sia utile
a coloro che cercano di imparare, ha poco tempo da dedicare a coloro che non
ascoltano o coloro che non sono interessati al processo di sviluppo.

Si spera che coloro che leggono questo documento saranno in grado di evitare
queste esperienze spiacevoli.  C'è  molto materiale qui, ma lo sforzo della
lettura sarà ripagato in breve tempo.  La comunità di sviluppo ha sempre
bisogno di sviluppatori che vogliano aiutare a rendere il kernel migliore;
il testo seguente potrebbe esservi d'aiuto - o essere d'aiuto ai vostri
collaboratori- per entrare a far parte della nostra comunità.

저자와 기여자

이 문서는 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에게 감사를 전한다.

Jonathan Corbet이 문서를 작성했고 여러 kernel 개발자가 검토 의견을 제공했습니다. Linux Foundation은 이 작업을 지원했으며 문서는 개인 경험이 아니라 community가 반복해서 겪은 개발 절차를 정리한 공동 지식입니다.

Crediti
-------

Questo documento è stato scritto da Jonathan Corbet, [email protected].
È stato migliorato da 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 e Jochen Voß.

Questo lavoro è stato supportato dalla Linux Foundation; un ringraziamento
speciale ad Amanda McPherson, che ha visto il valore di questo lavoro e lo ha
reso possibile.

mainline 반영과 binary-only module

일부 회사와 개발자는 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의 지속적인 성공에 이해관계가 있으며, 기여는 그 성공을 보장하는 가장 좋은 방법 중 하나다.

앞의 이유는 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가 다음 제품을 더 빨리 시장에 내놓을 수 있다.

out-of-tree code는 당장 merge 비용을 피하는 것처럼 보여도 kernel 내부 API 변화, distribution별 build, 사용자 지원과 품질 검증 비용을 계속 떠안습니다. mainline code는 API를 바꾸는 개발자가 함께 고치고 다른 개발자의 review와 개선을 받으므로 장기 유지비가 낮아집니다.

binary-only module은 법적 불확실성뿐 아니라 debugging과 community 지원을 어렵게 하고 kernel·distribution 조합마다 별도 build를 요구합니다. 고정 kernel을 쓰는 embedded 제품도 다음 세대 제품과 기능 확장을 고려하면 upstream 유지보수의 이점을 무시하기 어렵습니다.

L'importanza d'avere il codice nei sorgenti principali
------------------------------------------------------

Alcune aziende e sviluppatori ogni tanto si domandano perché dovrebbero
preoccuparsi di apprendere come lavorare con la comunità del kernel e di
inserire il loro codice nel ramo di sviluppo principale (per ramo principale
s'intende quello mantenuto da Linus Torvalds e usato come base dai
distributori Linux). Nel breve termine, contribuire al codice può sembrare
un costo inutile; può sembra più facile tenere separato il proprio codice e
supportare direttamente i suoi utilizzatori. La verità è che il tenere il
codice separato ("fuori dai sorgenti", *"out-of-tree"*) è un falso risparmio.

Per dimostrare i costi di un codice "fuori dai sorgenti", eccovi
alcuni aspetti rilevanti del processo di sviluppo kernel; la maggior parte
di essi saranno approfonditi dettagliatamente più avanti in questo documento.
Considerate:

- Il codice che è stato inserito nel ramo principale del kernel è disponibile
  a tutti gli utilizzatori Linux. Sarà automaticamente presente in tutte le
  distribuzioni che lo consentono. Non c'è bisogno di: driver per dischi,
  scaricare file, o della scocciatura del dover supportare diverse versioni di
  diverse distribuzioni; funziona già tutto, per gli sviluppatori e per gli
  utilizzatori. L'inserimento nel ramo principale risolve un gran numero di
  problemi di distribuzione e di supporto.

- Nonostante gli sviluppatori kernel si sforzino di tenere stabile
  l'interfaccia dello spazio utente, quella interna al kernel è in continuo
  cambiamento. La mancanza di un'interfaccia interna è deliberatamente una
  decisione di progettazione; ciò permette che i miglioramenti fondamentali
  vengano fatti in un qualsiasi momento e che risultino fatti con un codice di
  alta qualità. Ma una delle conseguenze di questa politica è che qualsiasi
  codice "fuori dai sorgenti" richiede costante manutenzione per renderlo
  funzionante coi kernel più recenti. Tenere un codice "fuori dai sorgenti"
  richiede una mole di lavoro significativa solo per farlo funzionare.

  Invece, il codice che si trova nel ramo principale non necessita di questo
  tipo di lavoro poiché ad ogni sviluppatore che faccia una modifica alle
  interfacce viene richiesto di sistemare anche il codice che utilizza
  quell'interfaccia. Quindi, il codice che è stato inserito nel ramo principale
  ha dei costi di mantenimento significativamente più bassi.

- Oltre a ciò, spesso il codice che è all'interno del kernel sarà migliorato da
  altri sviluppatori. Dare pieni poteri alla vostra comunità di utenti e ai
  clienti può portare a sorprendenti risultati che migliorano i vostri
  prodotti.

- Il codice kernel è soggetto a revisioni, sia prima che dopo l'inserimento
  nel ramo principale.  Non importa quanto forti fossero le abilità dello
  sviluppatore originale, il processo di revisione troverà il modo di migliore
  il codice.  Spesso la revisione trova bachi importanti e problemi di
  sicurezza.  Questo è particolarmente vero per il codice che è stato
  sviluppato in un ambiente chiuso; tale codice ottiene un forte beneficio
  dalle revisioni provenienti da sviluppatori esteri. Il codice
  "fuori dai sorgenti", invece, è un codice di bassa qualità.

- La partecipazione al processo di sviluppo costituisce la vostra via per
  influenzare la direzione di sviluppo del kernel. Gli utilizzatori che
  "reclamano da bordo campo" sono ascoltati, ma gli sviluppatori attivi
  hanno una voce più forte - e la capacità di implementare modifiche che
  renderanno il kernel più funzionale alle loro necessità.

- Quando il codice è gestito separatamente, esiste sempre la possibilità che
  terze parti contribuiscano con una differente implementazione che fornisce
  le stesse funzionalità.  Se dovesse accadere, l'inserimento del codice
  diventerà molto più difficile - fino all'impossibilità.  Poi, dovrete far
  fronte a delle alternative poco piacevoli, come: (1) mantenere un elemento
  non standard "fuori dai sorgenti" per un tempo indefinito, o (2) abbandonare
  il codice e far migrare i vostri utenti alla versione "nei sorgenti".

- Contribuire al codice è l'azione fondamentale che fa funzionare tutto il
  processo. Contribuendo attraverso il vostro codice potete aggiungere nuove
  funzioni al kernel e fornire competenze ed esempi che saranno utili ad
  altri sviluppatori.  Se avete sviluppato del codice Linux (o state pensando
  di farlo), avete chiaramente interesse nel far proseguire il successo di
  questa piattaforma. Contribuire al codice è une delle migliori vie per
  aiutarne il successo.

Il ragionamento sopra citato si applica ad ogni codice "fuori dai sorgenti"
dal kernel, incluso il codice proprietario distribuito solamente in formato
binario.  Ci sono, comunque, dei fattori aggiuntivi che dovrebbero essere
tenuti in conto prima di prendere in considerazione qualsiasi tipo di
distribuzione binaria di codice kernel. Questo include che:

- Le questioni legali legate alla distribuzione di moduli kernel proprietari
  sono molto nebbiose; parecchi detentori di copyright sul kernel credono che
  molti moduli binari siano prodotti derivati del kernel e che, come risultato,
  la loro diffusione sia una violazione della licenza generale di GNU (della
  quale si parlerà più avanti).  L'autore qui non è un avvocato, e
  niente in questo documento può essere considerato come un consiglio legale.
  Il vero stato legale dei moduli proprietari può essere determinato
  esclusivamente da un giudice. Ma l'incertezza che perseguita quei moduli
  è lì comunque.

- I moduli binari aumentano di molto la difficoltà di fare debugging del
  kernel, al punto che la maggior parte degli sviluppatori del kernel non
  vorranno nemmeno tentare.  Quindi la diffusione di moduli esclusivamente
  binari renderà difficile ai vostri utilizzatori trovare un supporto dalla
  comunità.

- Il supporto è anche difficile per i distributori di moduli binari che devono
  fornire una versione del modulo per ogni distribuzione e per ogni versione
  del kernel che vogliono supportate.  Per fornire una copertura ragionevole e
  comprensiva, può essere richiesto di produrre dozzine di singoli moduli.
  E inoltre i vostri utilizzatori dovranno aggiornare il vostro modulo
  separatamente ogni volta che aggiornano il loro kernel.

- Tutto ciò che è stato detto prima riguardo alla revisione del codice si
  applica doppiamente al codice proprietario.  Dato che questo codice non è
  del tutto disponibile, non può essere revisionato dalla comunità e avrà,
  senza dubbio, seri problemi.

I produttori di sistemi integrati, in particolare, potrebbero esser tentati
dall'evitare molto di ciò che è stato detto in questa sezione, credendo che
stiano distribuendo un prodotto finito che utilizza una versione del kernel
immutabile e che non richiede un ulteriore sviluppo dopo il rilascio.  Questa
idea non comprende il valore di una vasta revisione del codice e il valore
del permettere ai propri utenti di aggiungere funzionalità al vostro prodotto.
Ma anche questi prodotti, hanno una vita commerciale limitata, dopo la quale
deve essere rilasciata una nuova versione.  A quel punto, i produttori il cui
codice è nel ramo principale di sviluppo avranno un codice ben mantenuto e
saranno in una posizione migliore per ottenere velocemente un nuovo prodotto
pronto per essere distribuito.

license, copyright와 sign-off

Linux 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의 답변에 의존하는 것은 위험하다.

기여 code는 GPLv2 전체 배포와 호환되어야 하며 일반적으로 GPLv2 또는 three-clause BSD 조건을 사용합니다. copyright assignment는 요구하지 않고 원 소유자가 권리를 유지하므로 kernel에는 수천 명의 copyright holder가 존재합니다.

익명 기여나 적법한 자유 software임을 확인할 수 없는 code는 받아들이지 않습니다. contributor의 sign-off는 GPL 조건으로 배포할 권리가 있음을 확인하며, reverse engineering이나 license 문제처럼 법적 판단이 필요한 사안은 기술 mailing list가 아니라 전문 변호사에게 확인해야 합니다.

Licenza
-------

IL codice Linux utilizza diverse licenze, ma il codice completo deve essere
compatibile con la seconda versione della licenza GNU General Public License
(GPLv2), che è la licenza che copre la distribuzione del kernel.
Nella pratica, ciò significa che tutti i contributi al codice sono coperti
anche'essi dalla GPLv2 (con, opzionalmente, una dicitura che permette la
possibilità di distribuirlo con licenze più recenti di GPL) o dalla licenza
three-clause BSD.  Qualsiasi contributo che non è coperto da una licenza
compatibile non verrà accettata nel kernel.

Per il codice sottomesso al kernel non è necessario (o richiesto) la
concessione del Copyright.  Tutto il codice inserito nel ramo principale del
kernel conserva la sua proprietà originale; ne risulta che ora il kernel abbia
migliaia di proprietari.

Una conseguenza di questa organizzazione della proprietà è che qualsiasi
tentativo di modifica della licenza del kernel è destinata ad un quasi sicuro
fallimento.  Esistono alcuni scenari pratici nei quali il consenso di tutti
i detentori di copyright può essere ottenuto (o il loro codice verrà rimosso
dal kernel).  Quindi, in sostanza, non esiste la possibilità che si giunga ad
una versione 3 della licenza GPL nel prossimo futuro.

È imperativo che tutto il codice che contribuisce al kernel sia legittimamente
software libero.  Per questa ragione, un codice proveniente da un contributore
anonimo (o sotto pseudonimo) non verrà accettato.  È richiesto a tutti i
contributori di firmare il proprio codice, attestando così che quest'ultimo
può essere distribuito insieme al kernel sotto la licenza GPL.  Il codice che
non è stato licenziato come software libero dal proprio creatore, o che
potrebbe creare problemi di copyright per il kernel (come il codice derivante
da processi di ingegneria inversa senza le opportune tutele), non può essere
diffuso.

Domande relative a questioni legate al copyright sono frequenti nelle liste
di discussione dedicate allo sviluppo di Linux.  Tali quesiti, normalmente,
non riceveranno alcuna risposta, ma una cosa deve essere tenuta presente:
le persone che risponderanno a quelle domande non sono avvocati e non possono
fornire supporti legali.  Se avete questioni legali relative ai sorgenti
del codice Linux, non esiste alternativa che quella di parlare con un
avvocato esperto nel settore.  Fare affidamento sulle risposte ottenute da
una lista di discussione tecnica è rischioso.