Booting ARM Linux

 

In order to boot ARM Linux, you require a boot loader, which is a small

program that runs before the main kernel. The boot loader is expected to

initialise various devices, and eventually call the Linux kernel,

passing information to the kernel.

Essentially, the boot loader should provide (as a minimum) the following:

1. Setup and initialise the RAM. <#1>
2. Initialise one serial port. <#2>
3. Detect the machine type. <#3>
4. Setup the kernel tagged list. <#4>
5. Call the kernel image. <#5>

 

_1. Setup and initialise RAM_

 

Existing boot loaders: MANDATORY

New boot loaders: MANDATORY

 

The boot loader is expected to find and initialise all RAM that the

kernel will use for volatile data storage in the system. It performs

this in a machine dependent manner. (It may use internal algorithms to

automatically locate and size all RAM, or it may use knowledge of the

RAM in the machine, or any other method the boot loader designer sees fit.)

 

_2. Initialise one serial port_

 

Existing boot loaders: OPTIONAL, RECOMMENDED

New boot loaders: OPTIONAL, RECOMMENDED

 

The boot loader should initialise and enable one serial port on the

target. This allows the kernel serial driver to automatically detect

which serial port it should use for the kernel console (generally used

for debugging purposes, or communication with the target.)

As an alternative, the boot loader can pass the relevant 'console='

option to the kernel via the tagged lists specifing the port, and serial

format options as described in

linux/Documentation/kernel-parameters.txt.

 

_3. Detect the machine type_

 

Existing boot loaders: OPTIONAL

New boot loaders: MANDATORY

 

The boot loader should detect the machine type its running on by some

method. Whether this is a hard coded value or some algorithm that looks

at the connected hardware is beyond th

Booting ARM Linux

 

In order to boot ARM Linux, you require a boot loader, which is a small

program that runs before the main kernel. The boot loader is expected to

initialise various devices, and eventually call the Linux kernel,

passing information to the kernel.

Essentially, the boot loader should provide (as a minimum) the following:

1. Setup and initialise the RAM. <#1>
2. Initialise one serial port. <#2>
3. Detect the machine type. <#3>
4. Setup the kernel tagged list. <#4>
5. Call the kernel image. <#5>

 

_1. Setup and initialise RAM_

Booting ARM Linux

 

In order to boot ARM Linux, you require a boot loader, which is a small

program that runs before the main kernel. The boot loader is expected to

initialise various devices, and eventually call the Linux kernel,

passing information to the kernel.

Essentially, the boot loader should provide (as a minimum) the following:

1. Setup and initialise the RAM. <#1>
2. Initialise one serial port. <#2>
3. Detect the machine type. <#3>
4. Setup the kernel tagged list. <#4>
5. Call the kernel image. <#5>

 

_1. Setup and initialise RAM_

 

Existing boot loaders: MANDATORY

New boot loaders: MANDATORY

 

The boot loader is expected to find and initialise all RAM that the

kernel will use for volatile data storage in the system. It performs

this in a machine dependent manner. (It may use internal algorithms to

automatically locate and size all RAM, or it may use knowledge of the

RAM in the machine, or any other method the boot loader designer sees fit.)

 

_2. Initialise one serial port_

 

Existing boot loaders: OPTIONAL, RECOMMENDED

New boot loaders: OPTIONAL, RECOMMENDED

 

The boot loader should initialise and enable one serial port on the

target. This allows the kernel serial driver to automatically detect

which serial port it should use for the kernel console (generally used

for debugging purposes, or communication with the target.)

As an alternative, the boot loader can pass the relevant 'console='

option to the kernel via the tagged lists specifing the port, and serial

format options as described in

linux/Documentation/kernel-parameters.txt.

 

_3. Detect the machine type_

 

Existing boot loaders: OPTIONAL

New boot loaders: MANDATORY

 

The boot loader should detect the machine type its running on by some

method. Whether this is a hard coded value or some algorithm that looks

at the connected hardware is beyond the scope of this document. The boot

loader must ultimately be able to provide a MACH_TYPE_xxx value to the

kernel. (see linux/arch/arm/tools/mach-types).

 

_4. Setup the kernel tagged list_

 

Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED

New boot loaders: MANDATORY

 

The boot loader must create and initialise the kernel tagged list. A

valid tagged list starts with ATAG_CORE and ends with ATAG_NONE. The

ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag has the

size field set to '2' (0x00000002). The ATAG_NONE must set the size

field to zero.

 

Any number of tags can be placed in the list. It is undefined whether a

repeated tag appends to the information carried by the previous tag, or

whether it replaces the information in its entirety; some tags behave as

the former, others the latter.

The boot loader must pass at a minimum the size and location of the

system memory, and root filesystem location. Therefore, the minimum

tagged list should look:

 

+-----------+

base -> | ATAG_CORE | |

+-----------+ |

| ATAG_MEM | | increasing address

+-----------+ |

| ATAG_NONE | |

+-----------+ v

 

The tagged list should be stored in system RAM.

The tagged list must be placed in a region of memory where neither the

kernel decompressor nor initrd 'bootp' program will overwrite it. The

recommended placement is in the first 16KiB of RAM.

 

_5. Calling the kernel image_

 

Existing boot loaders: MANDATORY

New boot loaders: MANDATORY

 

There are two options for calling the kernel zImage. If the zImage is

stored in flash, and is linked correctly to be run from flash, then it

is legal for the boot loader to call the zImage in flash directly.

The zImage may also be placed in system RAM (at any location) and called

there. Note that the kernel uses 16K of RAM below the image to store

page tables. The recommended placement is 32KiB into RAM.

In either case, the following conditions must be met:

• CPU register settings
•   r0 = 0.
•   r1 = machine type number discovered in (3) above.
•   r2 = physical address of tagged list in system RAM.

• CPU mode
•   All forms of interrupts must be disabled (IRQs and FIQs.)
•   The CPU must be in SVC mode. (A special exception exists for Angel.)
• Caches, MMUs
•   The MMU must be off.
•   Instruction cache may be on or off.
•   Data cache must be off.
• The boot loader is expected to call the kernel image by jumping

 

directly to the first instruction of the kernel image.

 

Last modified: May 18, 2002

2003 Russell King All rights reserved.

 

 

Existing boot loaders: MANDATORY

New boot loaders: MANDATORY

 

The boot loader is expected to find and initialise all RAM that the

kernel will use for volatile data storage in the system. It performs

this in a machine dependent manner. (It may use internal algorithms to

automatically locate and size all RAM, or it may use knowledge of the

RAM in the machine, or any other method the boot loader designer sees fit.)

 

_2. Initialise one serial port_

 

Existing boot loaders: OPTIONAL, RECOMMENDED

New boot loaders: OPTIONAL, RECOMMENDED

 

The boot loader should initialise and enable one serial port on the

target. This allows the kernel serial driver to automatically detect

which serial port it should use for the kernel console (generally used

for debugging purposes, or communication with the target.)

As an alternative, the boot loader can pass the relevant 'console='

option to the kernel via the tagged lists specifing the port, and serial

format options as described in

linux/Documentation/kernel-parameters.txt.

 

_3. Detect the machine type_

 

Existing boot loaders: OPTIONAL

New boot loaders: MANDATORY

 

The boot loader should detect the machine type its running on by some

method. Whether this is a hard coded value or some algorithm that looks

at the connected hardware is beyond the scope of this document. The boot

loader must ultimately be able to provide a MACH_TYPE_xxx value to the

kernel. (see linux/arch/arm/tools/mach-types).

 

_4. Setup the kernel tagged list_

 

Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED

New boot loaders: MANDATORY

 

The boot loader must create and initialise the kernel tagged list. A

valid tagged list starts with ATAG_CORE and ends with ATAG_NONE. The

ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag has the

size field set to '2' (0x00000002). The ATAG_NONE must set the size

field to zero.

 

Any number of tags can be placed in the list. It is undefined whether a

repeated tag appends to the information carried by the previous tag, or

whether it replaces the information in its entirety; some tags behave as

the former, others the latter.

The boot loader must pass at a minimum the size and location of the

system memory, and root filesystem location. Therefore, the minimum

tagged list should look:

 

+-----------+

base -> | ATAG_CORE | |

+-----------+ |

| ATAG_MEM | | increasing address

+-----------+ |

| ATAG_NONE | |

+-----------+ v

 

The tagged list should be stored in system RAM.

The tagged list must be placed in a region of memory where neither the

kernel decompressor nor initrd 'bootp' program will overwrite it. The

recommended placement is in the first 16KiB of RAM.

 

_5. Calling the kernel image_

 

Existing boot loaders: MANDATORY

New boot loaders: MANDATORY

 

There are two options for calling the kernel zImage. If the zImage is

stored in flash, and is linked correctly to be run from flash, then it

is legal for the boot loader to call the zImage in flash directly.

The zImage may also be placed in system RAM (at any location) and called

there. Note that the kernel uses 16K of RAM below the image to store

page tables. The recommended placement is 32KiB into RAM.

In either case, the following conditions must be met:

• CPU register settings
•   r0 = 0.
•   r1 = machine type number discovered in (3) above.
•   r2 = physical address of tagged list in system RAM.

• CPU mode
•   All forms of interrupts must be disabled (IRQs and FIQs.)
•   The CPU must be in SVC mode. (A special exception exists for An

  드디어 시작이다...

  생각나는 대로 조금 씩.. 적어보자..

  2007/03/23

  i859 test board 수령

  현 상황 - 아무 것도 확인 안됨.. JTAG도 붙지 않음..

  gel.)
• Caches, MMUs
•   The MMU must be off.
•   Instruction cache may be on or off.
•   Data cache must be off.
• The boot loader is expected to call the kernel image by jumping

 

directly to the first instruction of the kernel image.

 

Last modified: May 18, 2002

2003 Russell King All rights reserved.

 

e scope of this document. The boot

loader must ultimately be able to provide a MACH_TYPE_xxx value to the

kernel. (see linux/arch/arm/tools/mach-types).

 

_4. Setup the kernel tagged list_

 

Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED

New boot loaders: MANDATORY

 

The boot loader must create and initialise the kernel tagged list. A

valid tagged list starts with ATAG_CORE and ends with ATAG_NONE. The

ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag has the

size field set to '2' (0x00000002). The ATAG_NONE must set the size

field to zero.

 

Any number of tags can be placed in the list. It is undefined whether a

repeated tag appends to the information carried by the previous tag, or

whether it replaces the information in its entirety; some tags behave as

the former, others the latter.

The boot loader must pass at a minimum the size and location of the

system memory, and root filesystem location. Therefore, the minimum

tagged list should look:

 

+-----------+

base -> | ATAG_CORE | |

+-----------+ |

| ATAG_MEM | | increasing address

+-----------+ |

| ATAG_NONE | |

+-----------+ v

 

The tagged list should be stored in system RAM.

The tagged list must be placed in a region of memory where neither the

kernel decompressor nor initrd 'bootp' program will overwrite it. The

recommended placement is in the first 16KiB of RAM.

 

_5. Calling the kernel image_

 

Existing boot loaders: MANDATORY

New boot loaders: MANDATORY

 

There are two options for calling the kernel zImage. If the zImage is

stored in flash, and is linked correctly to be run from flash, then it

is legal for the boot loader to call the zImage in flash directly.

The zImage may also be placed in system RAM (at any location) and called

there. Note that the kernel uses 16K of RAM below the image to store

page tables. The recommended placement is 32KiB into RAM.

In either case, the following conditions must be met:

• CPU register settings
•   r0 = 0.
•   r1 = machine type number discovered in (3) above.
•   r2 = physical address of tagged list in system RAM.

• CPU mode
•   All forms of interrupts must be disabled (IRQs and FIQs.)
•   The CPU must be in SVC mode. (A special exception exists for An

  드디어 시작이다...

  생각나는 대로 조금 씩.. 적어보자..

  2007/03/23

  i859 test board 수령

  현 상황 - 아무 것도 확인 안됨.. JTAG도 붙지 않음..

  gel.)
• Caches, MMUs
•   The MMU must be off.
•   Instruction cache may be on or off.
•   Data cache must be off.

  Booting ARM Linux

   

  In order to boot ARM Linux, you require a boot loader, which is a small

  program that runs before the main kernel. The boot loader is expected to

  initialise various devices, and eventually call the Linux kernel,

  passing information to the kernel.

  Essentially, the boot loader should provide (as a minimum) the following:

• Setup and initialise the RAM. <#1>
• Initialise one serial port. <#2>
• Detect the machine type. <#3>
• Setup the kernel tagged list. <#4>
• Call the kernel image. <#5>

 

_1. Setup and initialise RAM_

 

Existing boot loaders: MANDATORY

New boot loaders: MANDATORY

 

The boot loader is expected to find and initialise all RAM that the

kernel will use for volatile data storage in the system. It performs

this in a machine dependent manner. (It may use internal algorithms to

automatically locate and size all RAM, or it may use knowledge of the

RAM in the machine, or any other method the boot loader designer sees fit.)

 

_2. Initialise one serial port_

 

Existing boot loaders: OPTIONAL, RECOMMENDED

New boot loaders: OPTIONAL, RECOMMENDED

 

The boot loader should initialise and enable one serial port on the

target. This allows the kernel serial driver to automatically detect

which serial port it should use for the kernel console (generally used

for debugging purposes, or communication with the target.)

As an alternative, the boot loader can pass the relevant 'console='

option to the kernel via the tagged lists specifing the port, and serial

format options as described in

linux/Documentation/kernel-parameters.txt.

 

_3. Detect the machine type_

 

Existing boot loaders: OPTIONAL

New boot loaders: MANDATORY

 

The boot loader should detect the machine type its running on by some

method. Whether this is a hard coded value or some algorithm that looks

at the connected hardware is beyond the scope of this document. The boot

loader must ultimately be able to provide a MACH_TYPE_xxx value to the

kernel. (see linux/arch/arm/tools/mach-types).

 

_4. Setup the kernel tagged list_

 

Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED

New boot loaders: MANDATORY

 

The boot loader must create and initialise the kernel tagged list. A

valid tagged list starts with ATAG_CORE and ends with ATAG_NONE. The

ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag has the

size field set to '2' (0x00000002). The ATAG_NONE must set the size

field to zero.

 

Any number of tags can be placed in the list. It is undefined whether a

repeated tag appends to the information carried by the previous tag, or

whether it replaces the information in its entirety; some tags behave as

the former, others the latter.

The boot loader must pass at a minimum the size and location of the

system memory, and root filesystem location. Therefore, the minimum

tagged list should look:

 

+-----------+

base -> | ATAG_CORE | |

+-----------+ |

| ATAG_MEM | | increasing address

+-----------+ |

| ATAG_NONE | |

+-----------+ v

 

The tagged list should be stored in system RAM.

The tagged list must be placed in a region of memory where neither the

kernel decompressor nor initrd 'bootp' program will overwrite it. The

recommended placement is in the first 16KiB of RAM.

 

_5. Calling the kernel image_

 

Existing boot loaders: MANDATORY

New boot loaders: MANDATORY

 

There are two options for calling the kernel zImage. If the zImage is

stored in flash, and is linked correctly to be run from flash, then it

is legal for the boot loader to call the zImage in flash directly.

The zImage may also be placed in system RAM (at any location) and called

there. Note that the kernel uses 16K of RAM below the image to store

page tables. The recommended placement is 32KiB into RAM.

In either case, the following conditions must be met:

• CPU register settings
•   r0 = 0.
•   r1 = machine type number discovered in (3) above.
•   r2 = physical address of tagged list in system RAM.

• CPU mode
•   All forms of interrupts must be disabled (IRQs and FIQs.)
•   The CPU must be in SVC mode. (A special exception exists for An

  드디어 시작이다...

  생각나는 대로 조금 씩.. 적어보자..

  2007/03/23

  i859 test board 수령

  현 상황 - 아무 것도 확인 안됨.. JTAG도 붙지 않음..

  gel.)
• Caches, MMUs
•   The MMU must be off.
•   Instruction cache may be on or off.
•   Data cache must be off.
• The boot loader is expected to call the kernel image by jumping

 

directly to the first instruction of the kernel image.

 

Last modified: May 18, 2002

2003 Russell King All rights reserved.

 

• The boot loader is expected to call the kernel image by jumping

 

directly to the first instruction of the kernel image.

 

Last modified: May 18, 2002

2003 Russell King All rights reserved.

 

이 글은 스프링노트에서 작성되었습니다.

성당과 시장’에서 본 오픈소스 개발 모델의 적용

“재미있는 문제를 풀어보고 싶다면 자신에게 재미있는 문제를 찾아 나서는 것부터 시작하라(To solve an interesting problem, start by finding a problem that is interesting to you).” - 성당과 시장, 에릭 레이몬드

우리나라에 리눅스라는 새로운 운영체제가 널리 알려지기 시작한 것은 대략 1999년을 기점으로 생각할 수 있다. 이른바 리눅스 1세대라 불리는 사람들이 노력한 결과 수차례의 공동체 세미나 등 여러 매체를 통한 홍보를 통해 일반 대중들에게 널리 알려질 수 있었으며, 또한 네트워크에 대한 급속한 사용량 증가에 따라 그를 감당할 수 있는 네트워크 서버가 필요하게 되었고, 저비용으로 그러한 시스템을 구축할 수 있는 새로운 운영체제가 필요한 시기였기 때문에 리눅스라는 운영체제가 급속도로 퍼질 수 있었다.
하지만 리눅스가 사람들에게 폭발적인 힘을 가지고서 널리 퍼질 수 있었던 가장 큰 이유는 리눅스의 개발 방법인 오픈소스 개발 모델 때문이 아닐까? 늘어나는 네트워크 사용량과 많은 이유로 발생하는 보안 문제 등의 여러 문제의 해결 방안에 대한 요구가 기존의 운영체제 소프트웨어 업체는 감당하기 힘들 만큼 늘어나게 되었고, 이를 기존의 소프트웨어 개발 방법으로는 엄청난 부하가 걸리게 된다. 이러한 문제들은 리눅스는 오픈소스 개발 모델을 통해 해결해 왔다. 우리가 가장 쉽게 접할 수 있는 오픈소스 개발 모델은 GNU 프로젝트와 리눅스이다.

GNU 프로젝트와 오픈소스 모델의 가치
GNU 프로젝트는 1983년에 리차드 스톨만에 의해 시작되었다. 그는 MIT 대학에서 직업적인 연구 활동을 시작했던 1971년에 자유 소프트웨어만을 사용하는 연구 그룹에서 일하고 있었으며, 그 시절에는 상업적인 컴퓨터 회사들조차도 자유 소프트웨어를 배포하던 때였으므로 프로그래머들은 아무런 제약 없이 서로 협력하며 개발을 진행해 왔다. 하지만 1980년대에 이르러 거의 모든 소프트웨어들은 소유와 독점에 관한 법률에 의해서 제한되었으며, 소유권자들은 소프트웨어의 자유로운 이용을 통한 사용자들의 상호 협력을 그들의 권리를 내세워서 금지시켰다. 바로 이것이 GNU 프로젝트가 시작된 이유이다. GNU 프로젝트가 진행되어 가면서 GCC(GNU C Complier)와 Emacs 등의 소프트웨어들이 개발되었고, 1991년 리누스 토발즈에 의해 리눅스 커널이 공개되면서 완전한 자유 소프트웨어로 구성된 운영체제인 GNU/리눅스와 GNU/Hurd, GNU/Dawrin 등이 현재 계속 개발되어가고 있다.
여기서 오픈소스 개발에 관심을 가진 사람이라면 한번쯤은 접하게 되는 것이 ‘성당과 시장’이라는 에릭 레이몬드의 글이다. 그는 두 가지 형태의 소프트웨어 개발 모델을 제시하였다. 그의 표현을 빌리자면 ‘찬란한 고독 속에서 일하는 몇 명의 도사 프로그래머나 작은 그룹의 뛰어난 프로그래머들에 의해 조심스럽게 만들어지고 때가 되어야 발표할 수 있는 엄숙한 성당 건축 방식’과 ‘일찍, 그리고 자주 발표하여 다른 사람에게 위임할 수 있는 것은 모두 위임하고, 뒤범벅된 부분까지 공개하는 그런 스타일은 서로 다른 의견과 접근 방식이 난무하는 매우 소란스러운 시장 같은 분위기’이다. 이런 시장 바닥에서 조리 있고 안정적인 시스템이 탄생했고(리눅스의 탄생) 성당 건축가들이 상상하기도 힘든 속도로 계속 성장하고 강해지는 것을 보고 의식적으로 자기가 가진 의구심을 시험해 볼 수 있는 기회라고 생각하여 fetchmail(이메일 클라이언트의 일종)을 ‘시장’ 개발 모델을 이용하여 개발했다.
이 개발이 진행되는 동안 에릭 레이몬드는 이른바 리누스의 법칙(“충분히 많은 베타 테스터와 공동 개발자가 있으면 거의 모든 문제들은 빨리 파악될 것이고 쉽게 고치는 사람이 있게 마련이다”)을 이용하여 fetchmail을 완성할 수 있었으며, 이 ‘시장’개발 모델이 충분히 효율적이라는 것을 검증할 수 있었고, 그 결과 fetchmail은 매우 큰 성공을 이룬 프로젝트가 되었다.
‘성당과 시장’이라는 글이 발표된 뒤 7개월이 지나 넷스케이프는 자사의 웹 브라우저인 네비게이터 소스를 공개하기로 발표한다. 상업 소프트웨어 즉, 성당 건축가들이 시장 스타일을 받아들이기로 한 것이다. 이는 소프트웨어 개발 모델에 있어 ‘성당’ 모델 보다는 ‘시장’ 모델이 좀더 효율적이라고 판단되어 내린 결정일 것이다.
한 사람이 어떤 프로젝트를 온전히 해내는 건 불가능하다. 하다못해 버그 패치라도 다른 누군가의 손을 한번 더 거치면 더 좋은 코드가 나올 수 있다는 것이 자유 소프트웨어의 전제이다. 외국에서는 이런 역할 분담이 매우 잘 정착된 것처럼 보여진다. 어딘가 빈 자리가 보이면 자신의 역량이 허용하는 만큼을 추가한다. 굳이 멋진 프로그램으로 만들어 낼 필요는 없다. 단지 자신이 생각했을 때 아쉬웠던 기능을 적당한 형식으로 추가하기만 하면 된다. 그렇게만 해 두면, 그 이상의 것은 나중에 또 누군가가 수정하고 최적화할 것이기 때문이다. 이것이 바로 자유 소프트웨어 개발 모델의 특징이자 장점이기 때문이다. 현재 우리나라 사람들에게 필요한 것이 바로 이런 것이 아닌지 모르겠다. 사람들의 나쁜 습성 중 하나가 감사에는 인색하고, 자신보다 나은 사람이 있으면 칭찬하고 격려하기 보다는 어떻게든 흠집을 내서 깎아내린다는 것이다. 자신의 의견을 밝히는 데는 누구보다 열성적인 사람들이 직접 그 문제를 해결하기 위해 얼마나 노력을 하는지 한번 지켜 볼 문제이다.

필요에 따른 비전과 계획
이러한 ‘시장’ 모델의 소프트웨어 개발방식에 있어 가장 중요한 것은 그 소프트웨어들이 나아갈 방향을 제시하는 것이라 생각이 든다. 에릭 레이몬드는 “소프트웨어에 있어서 모든 좋은 성과들은 개발자 자신의 가려운 곳을 긁는 것으로부터 시작된다”라고 주장했다 이것은 매우 타당한 말이다. 하지만 그것만으로는 부족하다. 프로젝트가 있으면 그 프로젝트를 현명하게 이끌어 나갈 수 있는 무언가가 필요하기 때문이다.
현재 개발되어 있는 대부분의 GNU 소프트웨어의 핵심적인 부분들은 대부분 완전한 자유 운영체제를 만들기 위한 목적으로 개발된 것이다. GNU 소프트웨어는 가려울 때마다 가려운 곳을 긁듯이 그때그때 만들어진 것이 아니라 비전과 계획에 의해 만들어 진 것이다. 예를 들어, GNU C 라이브러리를 개발한 이유는 유닉스 형태의 운영 환경에서 C 라이브러리가 필요했기 때문이고, BASH를 개발한 이유 또한 유닉스 환경이 셸을 요구했기 때문이다.
GNU tar나 리차드 스톨만이 직접 개발한 GNU C 컴파일러와 GNU Emacs 그리고 GDB와 GNU Make도 같은 이유에서 개발된 것들이었다. 물론, 이 모든 것이 어떤 필요에 의해 그 문제를 해결해 나가는 과정상에 있는 것들이지만, 이를 적절하게 조율하고 순서를 정하는 것 역시 매우 중요한 일이다. 프로젝트의 방향을 제시하는 사람은 독창적인 설계를 제시하는 사람이기 보다는 좋은 설계를 알아볼 수 있으며 그 프로젝트를 구성하는 사람들과 의사소통이 잘 되는 사람이라야 할 것이다.

오픈소스 모델이 사회 곳곳에 퍼지기를
개인적인 욕심이 있다면 이러한 과정을 사회적 의미로 분석하여 검증된 사안을 사회 곳곳으로 퍼져나가도록 돕는 학자들의 손길이 좀더 정교하고 깊숙하게 파고들었으면 하는 바람이다. 「컴퓨터 프로그래밍의 심리학」이라는 글에서는 ‘자아를 내세우지 않는 프로그램(egoless programming)’이 극적으로 빠른 개선을 가져왔다고 진단하고 있다. 리눅스의 발전과정이나 fetchmail의 오픈 프로젝트 과정에서 우리가 배울 수 있는 것은 숙련된 기술자들이 가지고 있는 능력을 어떻게 잘 엮어내느냐 하는 것만 있는 것은 아닌 것 같다.
여기에서 밝히는 ‘시장’ 개발 모델은 여러 사람들이 이루어 나가는 단체, 이른바 노동조합, 시민단체, 기업, 심지어는 이 나라를 운영해 나가는 정치 집단 등에게 던지는 메시지가 담겨 있다고 생각한다. 하나의 목적을 위하여 공동으로 노력을 해 나가는 데 있어 가까이서 ‘감 놔라 배 놔라’ 훈수를 두는 숙련된 사람들을 끌어들이는 능력과 공동의 이해를 위해 서로 협력하게 하는 능력을 어떻게 발휘할 것인가 하는 것이다.

love is undefinable...

무언가에 매진해야 한다....

많은 일들이 진행 중이다..

새 프로젝트... 새로운 책임..

많은 것이 부담 스럽다..

글을 쓰겠다는 것.. 어려서 부터 가장 하고 싶은 일이었으나,

참으로 쉽지 않은 일이다.

나라는 사람이 가지고 있는 천성적인 게으름으로 보건데,

특히나, 아무런 구속 없이 스스로를 다그친 다는 것이 정말 쉬운 일이 아니다.

그러나, 이제 무언가 다시 시작해 보려 한다.

내 나이, 이제 32, 아직 늦지 않은 거겠지?

한번 변해 보고 싶다...

지금 내가 있는 곳, 앞으로 내가 가야할 길....

#증거 사진 1.

Domke F-2

내가 지금 하고 있는 일은 모 회사의 의뢰를 받아 하드웨어/커널 인터페이스를 설계하고, 그 구현을 검증하는 일이다.
무언가 프레임웍을 설계하고, 이를 검증한다는 것은 상당한 내공을 필요로 하는 일임에도 불구하고, 지금의 내가 할 수 있는 일인지 주저주저 하면서 여지까지 진행하여 왔는데, 지금의 시험 절차서를 작성하고 있는데 정말 앞이 캄캄하다. 과연 내가 끝을 볼 수 있을까?
ㅁ

 

자유 소프트웨어와 GNU 그리고, GPL(GNU Public License)

필요로 하는 자가 있거든 쓰게 하라. 이는 자비가 아니라 의무이니라.

-- 움베르토 에코, ``장비의 이름'' 중에서, 1980년

근래 들어 "Free Software"라는 말을 자주 듣게 됩니다. 그러나 많은 사람들이 “Free Sofware"라는 단어의 의미에 대해서 제대로 알고 있지는 않습니다. Free software에 대해 처음 알게 된 많은 사람들은 "free software"라는 용어의 "free"가 예상했던 의미와 굉장히 다르다는 것을 알게 되면 무척 당황스러울 것이라 생각합니다.

"Free Software"에서 사용된 ”free"라는 단어의 의미는 무엇에 구속되거나 얽매이지 않는다는 관점에서의 자유를 말합니다. 자유에 해당하는 영어 단어인 "free"는 2가지 뜻을 함께 갖고 있습니다. 첫 번째는 구속되지 않는다는 의미이고, 두 번째는 돈을 지불하지 않아도 된다는 무료(無料, gratis)라는 의미입니다. 영어에서는 이러한 중의적인 의미의 차이 때문에 많은 오해가 발생하기도 하지만 다행히 한국어에서는 자유 소프트웨어의 참된 의미만을 나타내 줄 수 있는 "자유(自由)"라는 단어가 독립적으로 존재하기 때문에 용어상의 문제로 인한 혼동은 없다고 할 수 있습니다. 따라서 GNU/FSF에서 사용하는 자유 소프트웨어를 지칭할 때는 용어상의 혼동이 존재할 수 있는 "프리 소프트웨어"가 아닌 보다 명확한 의미를 가진 "자유 소프트웨어"로 번역하는 것이 바람직합니다. 자유 소프트웨어는 무엇에 구속되거나 얽매이지 않아도 되는 소프트웨어라는 뜻입니다.

여기에서 자유 소프트웨어의 역사 및, FSF(Free Software Foundation)와 GNU에 대해서 알아보고 난 후, 이야기를 진행하도록 하겠습니다. 자유 소프트웨어의 개념은 1980년대 중반 리차드 스톨만(Richard M. Stallman) 및 그가 세운 자유 소프트웨어 재단(Free Software Foundation)과 함께 생겨났습니다. 리차드 스톨만이 MIT에서 직업적인 연구활동을 시작했던 1971년에 그는 자유 소프트웨어만을 사용하는 연구 그룹에서 일하게 되었는데, 그 시절은 상업적인 컴퓨터 회사들 조차도 자유 소프트웨어를 배포하던 때였으므로 프로그래머들은 아무런 제약 없이 서로 협력할 수 있었습니다. 그러나 1980년대에 이르러 거의 모든 소프트웨어들은 소유와 독점에 관한 법률에 의해서 제한되었으며, 소유권자들은 소프트웨어의 자유로운 이용을 통한 사용자들의 상호 협력을 그들의 권리를 내세워서 금지시켰습니다. 그래서 스톨만은 소프트웨어가 컴퓨터 하드웨어로부터 떨어져 나오면서 상업적인 제품으로 팔리기 시작한 것은 지극히 잘못된 일이라고 주장했습니다. 그는 모든 소프트웨어는 무제한 공유되고 무료로 배포돼야 한다는 주장과 함께, MIT를 떠나 FSF를 설립하고, 상업용 소프트웨어와의 전쟁을 선포합니다. 바로 이것이 GNU 프로젝트가 시작된 이유였습니다.

GNU 프로젝트는 초기의 컴퓨터 공동체 안에 충만해 있던 호의적인 상호 협력의 정신을 재건하기 위한 구체적인 실현 방법으로 1983년에 시작되었으며, 이는 독점 소프트웨어의 소유자들이 만든 장벽들을 제거함으로써 상호 협력의 풍토를 다시 부활시키는 것을 그 목적으로 합니다.

모든 컴퓨터 사용자들은 운영체제가 필요합니다. 만약 자유롭게 사용할 수 있는 운영체제가 없다면 컴퓨터를 사용하고자 하는 모든 사람들은 독점적인 상용 운영체제를 이용할 수밖에 없을 것입니다. 따라서, 자유 소프트웨어에 대한 첫번째 과제는 자유 운영체제를 만드는 것이었습니다.

운영체제는 단순히 커널만을 의미하는 것이 아닙니다. 운영체제에는 컴파일러와 문서 편집기, 스프레드 쉬트, 메일 소프트웨어와 같은 다양한 종류의 소프트웨어들이 통합되어 있어야 합니다. 따라서, 완성된 운영체제를 만든다는 것은 무척이나 방대한 작업이며 많은 세월이 필요한 일입니다.

이러한 운영체제를 유닉스와 호환되도록 결정했던 이유는 유닉스의 설계 방식에 대한 전반적인 우수성과 이식성이 이미 충분히 증명되었기 때문이고, 호환성을 통해서 많은 유닉스 사용자들이 보다 쉽게 GNU 환경으로 적응할 수 있도록 하기 위해서 입니다.

자유 운영체제에 대한 GNU 프로젝트의 첫 번째 계획은 1990년대에 와서 실현되었습니다. 커널을 제외한 주요 부분들을 새롭게 작성하고 취합하던 과정에서 GNU/FSF는 리누스 토발즈(Linus Tovalds)에 의해서 리눅스가 개발되고 있다는 사실을 알게 되었고, 리눅스는 곧 GNU와 합류하게 되었습니다. 자유 소프트웨어인 리눅스 커널과의 결합으로 GNU 시스템은 독립된 운영체제로서의 완성된 모습을 갖출 수 있었고 슬랙웨어와 데비안, 레드햇과 같은 GNU 시스템에 기반한 많은 운영체제들이 이제는 수십만에 달하는 사용자를 갖게 되었습니다.

그럼 다시 자유 소프트웨어의 이야기로 돌아가 보도록 하겠습니다. 우리가 소프트웨어를 사용하는데 있어서 돈을 내지 않아도 된다는 것은 전혀 자유로운 것이 아닙니다. 우리가 가지고 있는 소프트웨어를 다른 사람에게 배포하거나 새로운 기능을 추가하고자 할 때, 이를 금지당할 수도 있습니다. 무료로 배포되는 대부분의 소프트웨어들을 보면, 관련 제품을 판촉하거나, 사업상의 전략으로 경쟁자를 시장에서 몰아내거나, 영업을 방해하기 위한 한 수단으로 사용되는 경우가 많습니다. 앞서 스톨만의 경우와 같이, 이렇게 배포된 소프트웨어가 영구적으로 무료 소프트웨어로 남아 있을 것이라고는 그 누구도 장담하지 못합니다.

진정한 자유 소프트웨어라면, 항상 자유로워야 합니다. 일반적으로 배포된 자유 소프트웨어는 비(非) 자유 소프트웨어로 변경될 수도 있습니다. 그렇게 되면, 기존의 자유 소프트웨어상태일 때, 개선되었던 많은 부분과 많은 가능성 들이 사라질 수도 있습니다. 자유 소프트웨어가 진정한 자유 소프트웨어로 자유롭게 남아 있기 위해서는 소프트웨어는 저작권(copyright)과 라이센스가 반드시 명시되어야 합니다.

좀 더 간단하게 이야기 하면, 소프트웨어는 자유로울 수도 있고, 그렇지 않을 수도 있습니다. 하지만, 실제로는 이렇게 쉽게 구분지을 수가 없습니다. 많은 사람들이 “이 소프트웨어는 자유 소프트웨어이다”라고 이야기 할 때, 이것이 어떤 의미를 가지는 있는지는 그 소프트웨어가 가지고 있는 라이센스를 읽어보면 좀 더 자세히 알 수 있습니다.

GNU/FSF에서는 어떤 프로그램이 "자유 소프트웨어"인가 아닌가를 판단할 수 있는 기준으로 다음과 같은 4가지 조건을 규정하고 있는데, 이 조건들을 모두 충족시키는 소프트웨어를 자유 소프트웨어라고 할 수 있습니다.

      자유 0: 프로그램을 어떠한 목적을 위해서라도 실행할 수 있는 자유

      자유 1: 프로그램의 작동 원리를 연구하고, 이를 자신의 필요에 맞게 변경시킬 수있는 자유

      자유 2: 이웃을 돕기 위해서 프로그램을 복제하고 배포할 수 있는 자유

      자유 3: 프로그램을 향상시키고 이를 공동체 전체의 이익을 위해서 다시 환원시킬 수 있는 자유

위의 4가지 조건들은 자유 소프트웨어를 명확하게 규정하기 위한 것이며, 이러한 기준을 만족하는 소프트웨어를 보호하기 위한 법률적 장치가 GNU GPL이라고 불리는 사용권 허가 방식입니다. 흔히 말하는 카피레프트라는 단어는 특정한 소프트웨어를 자유 소프트웨어로 만드는 방식들을 통칭하는 일반적인 명칭이며 카피레프트가 성립하기 위해서는 ＂자유2"에 해당하는 프로그램에 대한 배포가 일어날 경우에 원시 코드의 개작 여부에 상관없이 배포 기준을 그대로 유지시켜야 합니다. 예를 들면, 자신이 얻은 원시 코드를 개작해서 새로운 기능을 추가하거나 보다 확장된 프로그램을 만들었다 하더라도 최초의 원시 코드에 설정된 사용권 허가 방식을 변경하거나 새로운 제한 사항을 추가하지 않고 원래의 내용을 그대로 유지시켜야 합니다. 따라서 카피레프트로 설정된 프로그램을 기반으로 만들어진 프로그램들은 모두 카피레프트가 될 수밖에 없는 순환적인 구조를 갖게 됩니다. 자유 소프트웨어의 범위와 체계가 현재와 같이 커질 수 있었던 가장 근본적인 외적 이유는 카피레프트가 이러한 순환적이고 팽창적인 구조를 갖고 있기 때문입니다.

GNU GPL은 이러한 카피레프트를 실제로 구현한 방법 중 하나이며, 만약 새로운 사용권 허가 문서를 만들 경우에 카피레프트에 맞게 설계된다면 이는 GNU GPL과 같이 카피레프트를 담보할 수 있는 실제적인 법률 장치 중의 하나가 되는 것입니다. 따라서 반드시 GNU GPL을 사용하지 않더라도 자유 소프트웨어에 대한 4가지 조건들을 만족시키면서 소프트웨어를 사용하거나 배포할 수 있도록 허용한다면 그것은 GNU/FSF가 견지하고 있는 "자유 소프트웨어" 외적인 형식면에서 호환된다고 말할 수 있으며, 이러한 GPL 호환 사용권 허가 방식들은 GPL과 충돌하지 않기 때문에 함께 혼용될 수 있습니다. 여기에 해당하는 것으로는 LGPL, X11 라이센스, Zlib 라이센스, Python 라이센스, Expat 라이센스 등이 있는데 여러가지 사용권 허가 방식들과 이들 간의 호환 여부에 대한 간략한 설명은 http://www.gnu.org/philosophy/license-list.html 페이지를 통해 참고할 수 있습니다. 이 글은 GNU/FSF가 카피레프트의 방법으로 공식적으로 사용하고 있는 GPL에 집중하고 있기 때문에 GPL 호환 및 비호환 사용권 허가 방법들에 대한 설명은 생략합니다.

자유 소프트웨어를 가름하는 4가지 기준에 따라 다양한 종류의 소프트웨어들을 다음과 같은 다이어그램으로 분류해 볼 수 있습니다.

그림 1) 자유 소프트웨어가 되기 위한 4가지 조건에 의한 소프트웨어의 분류

GPL 소프트웨어 - GPL'ed software

GPL을 사용권 허가 방법으로 사용하고 있는 소프트웨어를 지칭합니다. GNU/FSF가 배포하고 있는 거의 대부분의 소프트웨어들은 GPL 소프트웨어입니다.

카피레프트 소프트웨어 - Copylefted software

GNU/FSF가 정의하고 있는 자유 소프트웨어 대한 4가지 조건을 충족시키는 소프트웨어 중에서 카피레프트 방식의 배포가 이루어지는 소프트웨어를 지칭합니다. 즉 원시 코드의 개작 여부에 관계없이 원래의 배포 기준을 그대로 유지시켜야하는 소프트웨어를 말합니다. GPL은 카피레프트를 구현하는 방식이기 때문에 GPL 소프트웨어는 카피레프트 소프트웨어의 부분 집합이 됩니다.

공용 소프트웨어 - Public domain software

저작권자가 저작권을 명시적으로 포기했거나 저작권자를 알 수 없는 공개된 소프트웨어를 지칭합니다. 카피레프트는 저작권을 인정하는 방식이기 때문에 공용 소프트웨어가 카피레프트에 포함되지는 않지만, 저작권이 없음으로 인해서 사용상의 어떠한 제한도 존재하지 않기 때문에 자유 소프트웨어처럼 사용될 수 있습니다. 이 말은 공용 소프트웨어가 독점 소프트웨어로 사용될 수도 있다는 것을 함축합니다. [그림 1]에서는 보다 명확한 분류를 위해 공용 소프트웨어를 자유 소프트웨어의 부분 집합으로만 표시했지만, 경우에 따라서 독점 소프트웨어의 부분 집합으로 표시될 수도 있습니다. GNU/FSF에서는 사용자에게 유리한 방향으로 정의하는 기준을 적용해서 공용 소프트웨어를 `카피레프트 이외의 자유 소프트웨어'로 분류하고 있습니다. [그림 1]에서 자유 소프트웨어를 구성하는 부분 집합 중 카피레프트 소프트웨어의 여집합이 `카피레프트 이외의 자유 소프트웨어'입니다.

XFree86 형태의 소프트웨어 - XFree86 style software

공용 소프트웨어와 마찬가지로 `카피레프트 이외의 자유 소프트웨어' 중 하나입니다. 대표적인 그래픽 유저 인터페이스인 X 윈도우 시스템에 적용되는 사용권 허가 방식이 여기에 해당하는데, 이 방식에서는 개작과 재배포가 허용되지만, 카피레프트에는 허용되지 않는 추가적인 제약의 설정이 가능합니다. 이 말은 이러한 형태의 소프트웨어를 이용해서 독점 소프트웨어를 만드는 것이 가능하다는 뜻입니다.

오픈 소스 소프트웨어 - Open Source software

오픈 소스에 대한 정의를 충족시키는 소프트웨어를 지칭합니다. 오픈 소스에 대한 정의는 http://korea.gnu.org/people/chsong/copyleft/osd-korean.html 문서를 통해 참고할 수 있습니다. 예외가 존재하기는 하지만, 명칭상의 차이를 제외하면 일반적으로 오픈 소스 소프트웨어는 자유 소프트웨어와 동일하다고 볼 수 있습니다.3

셰어웨어 - Shareware

일정한 기간 동안 무료로 사용할 수 있게 하는 등의 부분적인 제한을 설정해서 배포되지만, 계속해서 사용하기 위해서는 비용을 지불해야 하는 소프트웨어를 지칭합니다. 셰어웨어는 상업적인 목적을 위한 마케팅 방법의 하나로 대부분 원시 코드가 제공되지 않거나 배포상의 제약이 설정되므로 독점 소프트웨어에 속합니다.

프리웨어 - Freeware

셰어웨어와 유사한 형태의 소프트웨어로, 일반적으로 배포는 허용하지만 개작은 허용하지 않는 경향을 갖고 있습니다. 프리웨어라는 표현에 특히 주의해야 하는 것은 자유 소프트웨어가 아님에도 불구하고 유사한 어감의 단어를 사용함으로써 사용자들을 혼동시키고 있기 때문입니다. GNU/FSF에서는 프리웨어라는 표현을 사용하지 않고 있으며, 프리웨어는 결코 자유 소프트웨어가 아닙니다.

비공개 소프트웨어 - Closed software

(오픈 소스 소프트웨어에 대한 상대적인 표현으로) 원시 코드가 공개되지 않는 소프트웨어를 지칭합니다. 원시 코드가 공개되지 않는 것은 `자유1'과 `자유 3'을 성립시킬 수 없기 때문에 비공개 소프트웨어는 독점 소프트웨어에 속합니다.

독점 소프트웨어 - Proprietary software

원시 코드가 공개되지 않거나 프로그램에 대한 복제 및 배포가 금지되는 등의 자유 소프트웨어에 대한 4가지 조건이 충족되지 않는 소프트웨어를 지칭합니다. [그림 1]에 의하면 무료로 다운 받을 수 있는 소프트웨어의 영역에 독점 소프트웨어의 일부가 포함되어 있기도 한데, 무료로 다운 받을 수 있다고 하더라도 사용과 복제 및 배포 상의 제약이 있다면 이는 자유 소프트웨어가 될 수 없기 때문에 독점 소프트웨어에 포함됩니다. Acrobat Reader나 Real Player와 같은 프로그램이 이러한 형식을 갖는 대표적인 예라고 할 수 있습니다. 이와 반대로 무료로 다운 받을 수 있는 소프트웨어의 영역에 자유 소프트웨어의 일부가 제외되어 있는 이유는 자유 소프트웨어라고 해서 무조건 무료로 제공되어야 한다는 조건이 자유 소프트웨어에 대한 4가지 조건에는 포함되어 있지 않기 때문입니다. 따라서 A라는 기업이 GPL로 사용권 허가를 설정한 프로그램을 새롭게 창작한 뒤에 이를 유료로 판매하면서 제품을 구입하는 사람에게만 원시 코드를 제공하는 방식으로 사업을 영위한다고 해도 이는 GPL 위반이 되지 않습니다. GNU GPL은 카피레프트를 실제로 구현한 것이기 때문에 카피레프트 방식을 충족시키기만 하면 구체적인 배포 형태에 대한 제한은 두지 않습니다.

상용 소프트웨어 - Commercial software

[그림 1]에는 언급되어 있지 않지만, 소프트웨어의 종류를 구분할 때 빼놓을 수 없는 중요한 형태의 하나가 바로 상용 소프트웨어입니다. 상용 소프트웨어는 판매 수익을 통해 돈을 벌기 위한 목적으로 만들어진 소프트웨어를 말합니다. 자유 소프트웨어에서 사용된 "자유"는 무료를 의미하는 금전적인 측면의 자유가 아니라 구속되지 않는다는 관점에서의 자유라고 이미 언급한 바 있습니다. 따라서 자유 소프트웨어를 유료로 판매하는 것은 전혀 문제가 되지 않기 때문에 경우에 따라서 자유 소프트웨어가 상용 소프트웨어가 될 수도 있습니다. 또한 독점 소프트웨어라고 해서 모두 상용 소프트웨어가 되는 것도 아닙니다. A라는 기업에 의해서 만들어진 인터넷 유해 정보 차단 프로그램이 인터넷을 통해서 무료로 배포되고 있다고 가정해 봅시다. A가 프로그램의 원시 코드를 공개하지 않고 제3자에 의한 개작과 배포를 허용하지 않는다고 해도 프로그램을 개발한 목적 자체가 공익을 위한 것이었고 또한 프로그램을 전액 무료로 배포하고 있다면 이 프로그램을 상용 소프트웨어로 볼 수 없습니다. 그러나 이 프로그램이 자유 소프트웨어의 조건들을 충족시키지는 못하기 때문에 자유 소프트웨어로 간주될 수도 없습니다. 이 프로그램을 굳이 [그림 1]의 기준에 따라 분류해 본다면 `비상용 독점 소프트웨어'가 된다고 할 수 있습니다. 따라서 상용 소프트웨어는 자유 소프트웨어와 독점 소프트웨어를 가늠하는 구분이 아니라 단지 돈을 받고 판매하는가 아닌가에 근거한 구분 방식입니다. 자유 소프트웨어와 독점 소프트웨어는 경우에 따라서 모두 상용 소프트웨어와 비상용 소프트웨어가 될 수 있습니다.

위의 분류 형태를 가만히 살펴보면, 그 기준이 저작권이 누구에게 있는가에 초점을 맞추고 있는 것이 아니라 프로그램의 원시 코드가 제공되는 지와 개작과 배포를 허용하는지의 여부에 있다는 것을 알 수 있습니다. 이는 소프트웨어의 분류가 다른 사람들의 사용을 염두에 둔 기준을 바탕으로 한 것이기 때문입니다.

일반적으로 라이센스(License)라는 말로 불리는 "사용권 허가" 또는 "사용 허가"는 정해진 범위 안에서의 사용을 허가해 주는 저작권자로부터의 일방적인 승인입니다. 이러한 상황에서는 사용자가 저작권자의 승인 내용에 포함된 조건에 동의할 경우에만 사용 계약이 성립됩니다. GNU GPL(GNU General Public License)은 마지막에 포함된 라이센스라는 단어가 말해주듯이 저작권 설정 문서가 아닌 사용권 허가 문서입니다. 새로운 저작물을 창작하게 되면 명시적인 저작권 설정 절차를 거치지 않는다고 하더라도 창작과 함께 저작권이 자동적으로 인정됩니다.   컴퓨터 프로그램 또한 저작권법에 의해서 이러한 권리가 자동으로 인정되는데, 미국과는 달리 한국에서는 "컴퓨터 프로그램 보호법"이라는 별개의 특별법이 적용됩니다. 그러나 실제적으로는 컴퓨터 프로그램의 특수성을 감안해서 법률의 이름만을 따로 만들 뒤에 세부적인 조항을 저작권법의 범위 안에서 컴퓨터 프로그램에 맞게 적용하도록 입법한 것이기 때문에 저작권법의 틀에서 벗어나지 않습니다.

따라서, GNU GPL은 프로그램을 창작한 저작자로부터 불특정 다수의 사람들에게 해당 프로그램을 GNU/FSF가 정의하고 있는 자유 소프트웨어의 범위 안에서 마음껏 사용할 수 있도록 합법적으로 허용해 주는 사용권 허가 문서라고 할 수 있습니다.

마지막으로, 자유 소프트웨어는 어느 한계까지 발전할 수 있을까요? 특허 제도와 같은 법률적 강제 장치가 자유 소프트웨어를 전면적으로 금지시키지 않는 한 그 가능성은 무한하다고 생각하고 있습니다. GNU/FSF의 궁극적인 목표는 컴퓨터 사용자들이 희망하는 어떠한 형태의 작업도 완벽하게 실현시킬 수 있는 자유 소프트웨어를 제공하는 것이며, 그것은 곧 소프트웨어에 있어서 독점이라는 해악을 영원히 사라지게 만들기 위한 것입니다.

무얼해야 할지, 무엇을 했는지.. 언젠가 부터 내 생활이 정리 되지 않고 있다는 것을 느꼈다..
그래서 어찌 해야할까 고민을 하다가.. 예전처럼 플래너를 다시 써 보기로 했다.

그런데, 지금 집에 있는 플래너의 바인더가 상태가 말이 아닌지라, 이 참에 새로운 바인더를 구매해서 사용해 보기로 했는데, 어떤 사이즈로 가야할지 고민하다가 결국에는 CEO 링 바인더로 결정을 했다..

앞으로 회사에 출근하면 업무시작전에 항상 하루를 계획하고 집에가기 전에 그 계획을 확인할 수 있도록 해야겠다..

70년의 역사를 자랑하는 보드게임의 살아있는 전설 모노폴리!
영화 E.T의 첫 장면에서 아이들이 하고 있던 게임...
힐러리 여사의 자서전에서 "어린 시절 나는 아버지로부터 보드게임을 통해 경제를 배웠다."라는 부분에 인용되었던 게임..
1935년에 개발되어 70여년 동안 2억 세트 이상이 팔린 게임...

우연히 오승영씨에게 보드 게임을 하나 달라고 조르다가...
어떤 게임을 원하느냐는 말에.. 아무 생각 없이... "모노폴리"를.. 외쳤고.. 어쩌다 내 손에 들어오게 되었다...

오승영씨로 부터 "정말 탁월한 선택이야!" 라는 이야기를 듣고 무슨 이야기인지 이해를 못 했는데, 게임을 실제로 받아 보고 나서, 입이 떡~ 벌어지고야 말았다. 부담스러운 원목 케이스 부터 시작해서, 디테일이 살아있는 말들, 그리고, 지폐들, 주화 및 기타 게임 진행에 필요한 모든 것들이 상당히 럭슈어리 하게 구성이 되어 있었다. 이전에 내가 유일하게 가지고 있었던, 카르카손과는 전혀 "레벨이 틀린" 구성이었다. 실제로 게임을 해 보기가 아까울 정도로...

그런데.. 누구랑 하지? -_-;
 

more..