Open
source development - an introduction to ownership and licensing
issues
By Rowan Wilson,
Published: 01 February 2005, Reviewed: 16 April 2012
Bài được đưa lên
Internet ngày: 16/04/2012
Lời
người dịch: Một bài viết hết sức cô đọng về các
vấn đề quyền sở hữu và cấp phép trong phần mềm,
đặc biệt là phần mềm tự do nguồn mở (PMTDNM) mà bất
kỳ ai có liên quan đều nên đọc để tuân thủ các điều
khoản và điều kiện của giấy phép và các vấn đề
liên quan khác. Bài viết nhắc nhở tất cả chúng ta rằng:
PMTDNM có bản quyền, tuân thủ luật bản quyền chứ
không phải những tuyên truyền ngược dạng FUD của những
người ác tâm, ác ý và/hoặc kém hiểu biết về nó.
Phần mềm, bản
quyền và việc cấp phép
Khi
bạn viết phần mềm, bạn đang tạo ra một dạng tài
sản. Mặc định, tài sản này sẽ được ai đó làm chủ
sở hữu. Nếu bạn là một nhân viên, có khả năng rằng
ông chủ của bạn sẽ sở hữu phần mềm mà bạn tạo
ra trong quá trình lao động làm thuê của bạn. Nếu bạn
đang làm việc cho bản thân bạn, hoặc làm việc trong
thời gian nhàn rỗi không cố liên quan tới công việc của
bạn, thì có khả năng là bạn sẽ sở hữu nó. Nếu bạn
là người tự làm [không làm thuê cho ai] và phát triển
phần mềm như một dịch vụ theo một thỏa thuận hợp
đồng, thì hợp đồng đó phải xác định ai là chủ sở
hữu trí tuệ của các kết quả đó. Nếu hợp đồng
không xác định ai sẽ làm chủ của tài sản, thì nhiều
khả năng là không phải nhà thầu mà đã viết nó sẽ sở
hữu nó. Nếu bạn đang làm việc như một phần của một
nhóm, khi có nhiều ông chủ, các nhà thầu và/hoặc các
cá nhân, hoặc một số bên có trụ sở bên ngoài nước
Anh, thì quyền sở hữu của tài sản kết quả có thể
là phức tạp. Có thể là tất cả những người đóng
góp cùng chung làm chủ tất cả các tài sản đó, hoặc
là tài sản đó được chia thành các phần mà được
những người hoặc tổ chức khác nhau làm chủ. Lý tưởng
mà nói, một thỏa thuận chi tiết hóa ai sẽ làm chủ
những gì nên được làm trước khi công việc được bắt
đầu.
Để an toàn, nguười
ta sẽ luôn phải chắc chắn rằng các thỏa thuận hoặc
hợp đồng chỉ định ai sẽ là chủ sở hữu trí tuệ
các kết quả từ sự cộng tác, nhóm hoặc công việc của
hợp đồng.
Phần mềm máy tính
được bảo vệ theo luật bản quyền. Luật bản quyền
trao cho người chủ các quyền nhất định của một tác
phẩm đối với tác phẩm đó, và làm cho nó bất hợp
pháp đối với những người khác để sử dụng tác phẩm
đó dù họ từng là người chủ của nó. Ban đầu bản
quyền tới là để đảm bảo rằng các tác giả thực
thụ đó được thưởng công xứng đáng cho tác phẩm của
họ. Các khái niệm của nó có nguồn gốc trong sự bảo
vệ các tác phẩm được viết, và nó có thể là hữu
dụng để nhớ rằng phần mềm máy tính và các tư liệu
có liên quan của nó được đối xử theo luật như những
mẩu của tác phẩm văn học.
Việc làm chủ bản
quyền trong một mẩu tác phẩm, hoặc văn học hoặc
chương trình [máy tính], có nghĩa là bạn quyết định ai
có thể sao chép nó, tùy biến nó và phân phối nó. Mặc
định, chỉ người chủ có thể làm những điều đó.
Bất kỳ ai mà sao chép, thay đổi hoặc phân phối cho ai
đó khác tác phẩm mà không có sự cho phép có thể có
những hành động pháp lý được thực hiện để chống
lại họ.
Bản quyền tới ngay
khi tác phẩm được cố định - nghĩa là ngay khi nó được
ghi nhận theo một số cách thức. Không cần phải đăng
ký tác phẩm của bạn để có được bản quyền; nó xảy
ra một cách tự động. Cũng không có yêu cầu để đánh
dấu tác phẩm của bạn như là được cấp bản quyền
với ký hiệu ©, dù bạn nên, khi mà điều này nhấn mạnh
điều cho là đúng theo pháp lý quyền là chủ của bạn
đối với nó.
Việc viết phần mềm
có thể tạo ra một mẩu của vật sở hữu. Ví dụ, mã
nguồn của chương trình là vật sở hữu, vì có thể là
tư liệu thiết kế chuẩn bị cho nó, tổ chức của nó
và giao diện người sử dụng của nó. Các hệ lụy của
thực tế này đáng ghi nhớ trong đầu.
Khai thác
Nếu một người chủ
bản quyền muốn kiếm tiền từ tác phẩm của họ, họ
có thể bán hoàn toàn các quyền cho nó (được biết như
là “chỉ định bản quyền”). Như với tài sản vật
lý, việc chỉ định bản quyền có liên quan tới việc
trao hoàn toàn quyền sở hữu của tác phẩm cho một người
mua hoặc người được chỉ định.
Tiếp cận khác đối
với việc khai thác một tác phẩm bản quyền là cấp
phép cho nó. Một giấy phép là một sự cho phép được
trao từ người chủ bản quyền cho tới một người khác
(được biết như là người được cấp phép). Người
chủ bản quyền đồng ý cho phép người được cấp phép
tiến hành các hành động mà có thể nếu không sẽ bị
luật cấm, như việc sao chép, tùy biến và/hoặc phân
phối tác phẩm đó. Người được cấp phép sẽ đồng ý
thực hiện các hành động đó trong khuôn khổ được
giấy phép thiết lập - có thể chỉ là việc tạo ra và
phân phối một số lượng các bản sao nhất định, hoặc
việc trả tiền phí bản quyền trong từng bản sao được
phân phối. Dù một giấy phép có thể được tạo ra mà
không có việc hình thành của một hợp đồng, hầu hết
các giấy phép được trao ở một dạng pháp lý trong đó
cả 2 bên thực hiện các nghĩa vụ nhất định trong sự
tôn trọng lẫn nhau và tác phẩm có bản quyền được
cấp phép; điều này được biết tới như là một “thỏa
thuận giấy phép”.
Các thỏa thuận giấy
phép là những tài liệu pháp lý kỹ thuật mà có nhiều
qui tắc pháp lý mô tả và hạn chế nội dung và cách
thức thể hiện. Vì thế đáng lưu ý rằng liệu có khi
nào đó một sự không đồng thuận về việc liệu có
hay không một sự vi phạm thỏa thuận đó, trong phân tích
cuối cùng luật sẽ xác định kết quả đầu ra đó. Một
giấy phép được phác thảo tồi có thể, khi được một
tòa án phân tích, được thấy có nghĩa như thứ gì đó
hoàn toàn khác với những gì cả người chủ bản quyền
và người được cấp phép mong đợi.
Cấp phép nguồn mở
là gì?
Nguồn mở mô tả một
nhóm các giấy phép mà tất cả đáp ứng được tập các
điều kiện nhất định. Các điều kiện được một
nhóm gọi là Sáng kiến Nguồn Mở duy trì, và cùng với
đó chúng được tham chiếu tới như là Định nghĩa Nguồn
Mở - OSD (Open Source Definition). Chúng ta sẽ rà soát lại
ngắn gọn chúng ở đây.
Một
giấy phép nguồn mở phải:
- trao cho giấy phép quyền để phân phối chương trình cho bản thân họ, bao gồm các quyền lấy tiền đối với nó
- trao sự truy cập tới mã nguồn của chương trình
- trao quyền để sửa đổi chương trình
- trao quyền để phân phối các phiên bản sửa đổi của chương trình
- cho phép sử dụng chương trình cho tất cả những người hoặc nhóm trong tất cả các lĩnh vực nghề nghiệp
- áp dụng cho bất kỳ ai mà nhận chương trình, mà không cần bất kỳ thỏa thuận bổ sung nào
- áp dụng cho chương trình mà nó cấp phép, bất kể chương trình đó có được như một phần của một nhóm chương trình, hoặc của bản thân nó
- cho phép phân phối với bất kỳ phần mềm nào khác
- cho phép phân phối ở bất kỳ dạng nào
Hiệu ứng mong muốn
của các điều kiện đó là để thúc đẩy sự phân phối
phần mềm một cách rộng rãi, và để khuyến khích mọi
người mà nhận phần mềm đóng góp vào cho chức năng
của nó bằng việc sửa đổi mã nguồn. Dù nó có thể
xem việc trao các quyền đó có thể dẫn tới một số
lượng lớn các phiên bản biến thể một chút của mẩu
phần mềm, trong thực tế các dự án PMTDNM thành công có
xu hướng hấp thụ những sửa đổi phân tán được
nhiều người đóng góp ngược vào một phiên bản duy
nhất được sửa đổi và được cải tiến.
Đáng lưu ý phần thứ
2 của điểm liệt kê đầu tiên ở trên. Đây là một sự
hiểu nhầm phổ biến rằng người ta không thể lấy tiền
cho việc phân phối phần mềm nguồn mở. Điều này không
phải thế. Trong thực tế, nó hiếm khi được thực hiện,
chủ yếu là vì mỗi khách hàng của bản đều có thể
biếu phần mềm trong sự cạnh tranh trực tiếp cho việc
bán hàng của riêng bạn.
Quyền sở hữu
phức tạp
Khi một mẩu PMNM được
phát triển, thường với nhiều người và nhóm khác nhau,
quyền sở hữu trở thành ngày càng phức tạp. Vấn đề
có liên quan tới sự cộng tác và quyền sở hữu được
xác định ở trên áp dụng ngang bằng cho những cộng tác
không có kế hoạch qua một giai đoạn thời gian. Có thể
tưởng tượng được cho từng người đóng góp để làm
chủ bản quyền đối với đóng góp của họ. Trong khi
trong thực tế hầu hết những người đóng góp sẽ có
thiện chí đồng ý cấp phép tư liệu của họ theo cùng
giấy phép như của tác phẩm gốc ban đầu, nghĩa là qui
trình thực hiện và cải tiến có thể tiếp tục, thì nó
có thể là phức tạp để xác định ai sẽ thực hiện
một sự khiếu nại pháp lý nếu ai đó quyết định sử
dụng chương trình đó theo một cách thức vi phạm giấy
phép của nó. Để tránh vấn đề này,
một số dự án nguồn mở yêu cầu những người đóng
góp chỉ định rõ ràng bản quyền trong những đóng góp
của họ cho một tổ chức điều hành dự án đó, vì thế
giữ cho quyền sở hữu được tập trung và làm cho sự
ép tuân thủ của giấy phép đó dễ dàng hơn. Một tiếp
cận lựa chọn là để những người đóng goáp cấp phép
những đóng góp của họ cho tổ chức điều hành dự án
theo một thỏa thuận giấy phép mà cho phép tổ chức đó
cấp phép lại sự đóng góp đó.
Hợp đồng và bản
quyền
Thường được thấy
rằng các giấy phép như những giấy phép trong định
nghĩa nguồn mở OSD là có vấn đề vì không không có
hành động công khai chấp nhận của những người được
cấp phép mà đưa chúng lên. Những thỏa thuận giấy phép
của người sử dụng đầu cuối được phân phối với
phần mềm sở hữu độc quyền (PMSHĐQ) thường đòi hỏi
một người sử dụng phải nháy vào một núm để chấp
nhận các điều kiện, và thực tế này dẫn tới nhiều
người tin tưởng rằng các giấy phép nguồn mở đòi hỏi
thứ gì đó ràng buộc tương tự. Điều này là không
đúng.
Các thỏa thuận giấy
phép sở hữu độc quyền của người sử dụng đầu
cuối là các hợp đồng để điều hành nhiều khía cạnh
của mối quan hệ giữa công ty và người sử dụng. Nếu
người sử dụng vi phạm, họ đã vi phạm hợp đồng của
họ, và công ty phần mềm có thể chọn sử dụng luật
hợp đồng để trừng phạt họ. Nhưng điều này có thể
là khó, đặc biệt khi luật hợp đồng khác nhau từ nước
này tới nước khác. Việc có được sự đồng ý công
khai từ những người sử dụng bằng việc làm cho họ
nháy núm 'Tôi chấp nhận' giúp làm cho qui trình tố tụng
là không cần thiết, khi một người sử dụng có trách
nhiệm tự họ làm quen với các điều khoản của bất kỳ
giấy phép nào hay hợp đồng nào có liên quan tới phần
mềm mà họ sử dụng - tuy nhiên, các hãng PMSHĐQ có xu
hướng bỏ ngoài tai lời quở trách và bắt nhấn núm
'Tôi chấp nhận'.
Dù
chúng không được xem là các hợp đồng, thì các giấy
phép nguồn mở được phác thảo phù hợp có ràng buộc
về pháp lý và hành động ép tuân thủ có thể được
thực hiện chống lại những người vi phạm chúng. Điều
này có thể theo luật hợp đồng hoặc bản quyền, phụ
thuộc vào cách mà giấy phép đó được lên khung. Không
ai được ép buộc phải chấp nhận rõ ràng giấy phép
đó, nhưng sự chấp nhận hoàn toàn các điều kiện giấy
phép đó là con đường duy nhất để sử dụng hợp phpas
theo luật bản quyền.
Vượt ra khỏi Định
nghĩa Nguồn Mở
Website Sáng kiến
Nguồn Mở hiện liệt kê hơn 50 giấy phép đáp ứng các
điều kiện được mô tả trong phần 3. Không là trong
phạm vi của tài liệu này để xem xét tất cả chúng.
Tuy nhiên, đáng chú ý, là hầu hết
giấy phép nguồn mở được sử dụng rộng rãi – GPL
(GNU General Public License) - áp đặt một điều kiện chủ
chốt hơn lên những người sao chép, tùy biến hoặc
phaanp hối phần mềm theo giấy phép này. Tất cả các
phần mềm được tạo ra bằng việc sửa đổi phần mềm
gốc ban đầu cũng phải được cấp phép theo GPL (nếu nó
được phân phối). Mục tiêu của điều kiện này là để
sản sinh ra một phần thân của PMNM sẽ phát triển khi
những người sử dụng đóng góp, và rằng không thể bị
co lại vì những người sử dụng bổ sung thêm nỗ lực
của riêng họ vào một mẩu phần mềm và sau đó cấp
phép lại kết quả đó theo những điều khoản hạn chế
hơn so với các điều khoản của GPL. Vì điều kiện này
có thể được xem như một ý định để lật đổ sử
dụng bản quyền sở hữu độc quyền, đôi khi nó còn
được biết tới như là copyleft.
Đáng
lưu ý rằng không có bổn phận để phát hành những thay
đổi mà bạn làm, hoặc theo GPL hoặc theo bất kỳ giấy
phép nguồn mở nào; bạn có thể giữ các phiên bản nội
bộ của phần mềm GPL mà bạn đã sửa đổi mà không
cần cấp phép cho chúng cho bất kỳ ai khác. Điều này áp
dụng ngang nhau cho các cá nhân và các thực thể pháp lý
như các công ty và các cơ quan.
Tính tương thích
của giấy phép
Thật quyến rũ để
tin tưởng rằng tất cả mã nguồn sẵn sàng theo một
giấy phép nguồn mở có thể được cập nhật và được
kết hợp mà không có hạn chế nào để tạo ra PMNM mới.
Không may điều này không phải như vậy. 2 giấy phép cùng
đáp ứng được các yêu cầu của Định nghĩa Nguồn Mở
một cách riêng rẽ có thể không có các điều khoản làm
cho chúng không tương thích với nhau. GNU GPL (tất cả các
phiên bản) đưa ra một ví dụ của điều này: nó bắt
buộc rằng mã nguồn kết hợp mã được cấp phép GPL
bản thân nó phải được cấp phép theo GPL như một tổng
thể nếu nó được phân phối. Nó cũng bắt buộc rằng
không có sự hạn chế bổ sung nào về các quyền nó trao
cho thể được áp đặt lên mã được cấp phép GPL. 2
điều kiện đó kết hợp để ngụ ý rằng mã được
cấp phép GPL chỉ có thể được trộn dễ dàng với các
mã được cấp phép GPL khác, hoặc với mã mà giấy phép
của nó áp đặt chỉ những điều kiện thể hiện trong
GPL. Rõ ràng không phải là nhiệm vụ dễ dàng để thiết
lập liệu một điều kiện trong một giấy phép có tương
đương chính xác về điều kiện được nêu khác nhau
trong giấy phép khác hay không. Quỹ Phần mềm Tự do
(FSF), người quản trị GPL, làm cho sẵn sàng một danh
sách các giấy phép mà họ xem là tương thích với GPL.
Vấn đề về tính
tương thích của giấy phép là một vấn đề phức tạp,
và việc xác định liệu 2 giấy phép có tương thích hay
không sẽ đòi hỏi sự giúp đỡ của một luật sư trong
tất cả hầu hết các trường hợp. Các lập trình viên
làm việc trong một mẩu phần mềm mà được phân phối
theo một giấy phép (bất kể nguồn mở hay gì khác) cần
phải nhận thức được về các khó khăn tiềm tàng trong
lĩnh vực này trước khi định trộn trong mã nguồn mở.
Thường thì cách đơn giản nhất để giải quyết những
xung đột về giấy phép là yêu cầu (những) người chủ
mã liệu họ có thiện chí phát hành mã của họ cho sự
bao gồm hay không. Tuy nhiên, tiếp cận này chỉ thực sự
thực tế ở những nơi mà số những người chủ là nhỏ.
Theo dõi sở hữu
trí tuệ
Các vấn đề về
tính tương thích của giấy phép và nhiều quyền sở hữu
phức tạp của sở hữu trí tuệ có ngụ ý rằng là mong
muốn, nếu không nói là cơ bản, đối với các lập
trình viên và các nhà quản lý của họ giữ cho các hồ
sơ được chi tiết. Các hệ thống kiểm
soát phiên bản đưa ra một số việc lưu giữ hồ sơ này
một cách tự động, ghi lại hồ sơ ai đã thực hiện
những thay đổi cho mã và họ đã làm gì. Để bổ
sung cho thông tin này, các nhà quản lý nên giữ các hồ
sơ tình trạng hợp đồng và cấp phép của những người
đóng góp để thiết lập ai là chủ công việc của họ.
Họ cũng nên yêu cầu và lưu giữ các
thỏa thuận rõ ràng (bản
dịch tiếng Việt) từ người chủ bản quyền mà
những đóng góp của họ có thể được cấp phép và
được phân phối theo giấy phép được lựa chọn cho dự
án như một tổng thể. Ở những nơi mã được mang vào
từ PMNM đang tồn tại, thì các chi tiết của giấy phép
phù hợp phải được ghi nhận (đã thiết lập trước
rằng giấy phép này là tương thích với chính sách cấp
phép của toàn bộ dự án).
Tóm tắt
Để
tóm tắt ngắn gọn các điểm được thực hiện trong tài
liệu này:
- Phần mềm là sở hữu trí tuệ.
- Phần mềm được bảo vệ theo luật bản quyền.
- Quyền sở hữu của phần mềm có thể được xác định bằng một sự xem xét pháp lý kỹ thuật của bất kỳ hợp đồng nào theo đó nó đã được sản xuất ra, và bất kỳ hoàn cảnh pháp lý nào khác phù hợp.
- Luật bản quyền nói rằng mặc định chỉ người chủ của phần mềm có thể sao chép, tùy biến hoặc phân phối nó.
- Người chủ của phần mềm có thể đồng ý cho phép người khác sao chép, tùy biến hoặc phân mã - thỏa thuận này được gọi là một giấy phép.
- Các giấy phép nguồn mở trao các quyền đó cho bất kỳ ai mà chọn để đưa chúng lên, với những điều kiện nhất định.
- Các giấy phép nguồn mở nhằm để tạo một cộng đồng những người đóng góp mà họ sẽ sửa lỗi và phát triển phần mềm đó.
- Việc kết hợp 2 mẩu mã phần mềm theo các giấy phép khác nhau có thể là phức tạp.
- Tất cả các dự án mà sản xuất ra phần mềm cần phải giữ các hồ sơ hoàn chỉnh, chi tiết về việc cấp phép và quyền sở hữu của những người đóng góp cho phần mềm đó.
When
you write software, you are creating a kind of property. By default,
this property will be owned by somebody. If you are an employee, it
is likely that your employer will own the software you create in the
course of your employment. If you are working for yourself, or
working in your free time on matters unrelated to your work, then it
is likely that you will own it. If you are self-employed and
developing software as a service under a contract agreement, then the
contract ought to define who owns the intellectual property that
results. If the contract does not define who will own the property,
it is more likely than not that the contractor who wrote it will own
it. If you are working as part of a group, where there are multiple
employers, contractors and/or individuals, or some parties are based
outside the UK, then the ownership of the resulting property can be
complex. It may be that all contributors jointly own all of the
property, or that the property is divided into sections that are
owned by different people or organisations. Ideally, an agreement
detailing who will own what should be made before the work is begun.
In
order to be safe, one should always make sure that agreements or
contracts specify who will own the intellectual property that results
from any collaboration, consortium or contract work.
Computer
software is protected by copyright law. Copyright law gives the owner
of a work certain rights over it, and makes it illegal for others to
use the work as though they were its owner. Copyright originally came
into being to ensure that literary authors were properly remunerated
for their work. Its concepts originate in the protection of written
works, and it can be helpful to remember that computer software and
its associated materials are treated by the law as species of
literary work.
Owning
the copyright in a piece of work, whether literary or programmatic,
means that you decide who can copy it, adapt it and distribute it. By
default, only the owner can do these things. Anyone who copies,
changes or distributes someone else’s work without permission can
have legal action taken against them.
Copyright
comes into being as soon as a work is fixed — meaning as soon as it
is recorded in some way. There is no need to register your work in
order to gain copyright; it happens automatically. There is also no
requirement to mark your work as copyrighted with a © symbol,
although you should, as this emphasises the legal presumption of your
ownership of it.
Writing
software may well result in more than one piece of property. For
example, program’s source code is property, as can be the
preparatory design material for it, its general organisation and its
user interface. The consequences of this fact are worth bearing in
mind.
If
a copyright owner wants to make money from their work, they can sell
the rights to it outright (known as “assignment of copyright”).
As with physical property, assigning the copyright involves handing
over complete ownership of the work to a buyer or assignee.
Another
approach to exploiting a copyright work is to license it. A licence
is a permission given by the copyright owner to another person (known
as the licensee). The copyright owner agrees to permit the licensee
to take actions that would otherwise be prohibited by law, such as
copying, adapting and/or distributing the work. The licensee will
agree to take these actions within the boundaries set by the licence
— perhaps only creating and distributing a certain number of
copies, or paying a royalty on each copy distributed. Although a
licence can be created without the forming of a contract, most
licences are granted in a legal form where both parties undertake
certain obligations in respect of each other and the licensed
copyright work; this is known as a “licence agreement”.
Licence
agreements are technical legal documents that have many legal rules
describing and confining their content and manner of expression. It
is therefore worth noting that should there ever be a disagreement
over whether or not there has been a breach of the agreement, in the
final analysis the law will determine the outcome. A poorly drafted
licence may, when construed by a court, be found to mean something
quite different from what both the copyright owner and the licensee
intended.
Open
source describes a group of licences that all meet a certain set of
conditions. The conditions are maintained by a group called the Open
Source Initiative, and together they are referred to as the Open
Source Definition (OSD). We will briefly review them here.
An
open source licence must:
- grant the licensee the right to distribute the program themselves, including the right to charge money for it
- grant access to the program’s source code
- grant the right to modify the program
- grant the right to distribute modified versions of the program
- allow use of the program by all persons or groups in all fields of endeavour
- apply to everyone who receives the program, without the need for any additional agreements
- apply to the program it licenses, whether the program is obtained as part of a group of programs, or on its own
- allow distribution with any other software
- allow distribution in any form
The
desired effect of these conditions is to promote wide distribution of
software, and to encourage people who receive the software to
contribute to its functionality by modifying the source code.
Although it may seem that granting these rights might lead to a large
number of slightly variant versions of a piece of software, in
practice successful open source software projects tend to absorb
disparate modifications made by many contributors back into a single
modified and improved version.
It
is worth noting the second part of the first bulleted point above. It
is a common misconception that one cannot charge money for
distributing open source software. This is not the case. In practice,
it is rarely done, mainly because each one of your customers could
give away the software in direct competition to your own sales.
As
a piece of open source software is developed, often by many different
people and groups, its ownership becomes more and more complex. The
issues relating to collaboration and ownership identified above apply
equally to unplanned collaborations over a period of time. It is
conceivable for every contributor to own the copyright to their
contribution. While in practice most contributors will willingly
agree to license their material under the same licence as the
original work, meaning that the process of uptake and improvement can
continue, still it can be complex to ascertain who should make a
legal complaint if someone decides to use the program in a way that
violates its licence. To avoid this issue, some open source projects
ask that contributors explicitly assign the copyright in their
contributions to a body that administers the project, thus keeping
ownership centralised and making enforcement of the licence easier.
An alternative approach is to have contributors license their
contributions to the project’s administrative body under a licence
agreement that permits the body to relicense the contribution.
It
is often observed that licences such as those within the OSD are
problematic because there is no overt act of acceptance by licensees
who take them up. End-user licence agreements that are distributed
with proprietary software often require a user to click a button to
accept the conditions, and this fact leads many to believe that open
source licences should require something similar to be binding. This
is incorrect.
Proprietary
end-user licence agreements are contracts to govern many aspects of
the relationship between company and user. If the user breaks the
agreement, they have breached their contract, and the software
company may choose to use the law of contract to punish them. But
this can be difficult, particularly as the law of contract varies
from country to country. Obtaining overt consent from users by making
them click the ‘I accept’ button helps make the process of
prosecuting breaches of the agreement under contract law easier. Some
would argue that the button is unnecessary, as a user has a
responsibility to acquaint themselves with any licence and contract
terms associated with software they use — however, proprietary
software firms tend to err on the side of caution and mandate the ‘I
accept’ button.
Although
they are not considered to be contracts, properly drafted open source
licences are legally binding and enforcement action can be taken
against those who breach them. This may be under contract or
copyright law, depending on how the licence is framed. No-one is
forced to explicitly accept the licence, but implicit acceptance of
the licence conditions is the only route to legitimate use under
copyright law.
The
Open Source Initiative website currently lists over 50 licences that
meet the conditions described in section 3. It is not within the
scope of this document to examine them all. It is notable, however,
that the most widely used open source licence — the GNU General
Public License (GPL) — imposes a major further condition upon those
who copy, adapt or distribute software under it. All software created
by modifying the original software must also be licensed under the
GPL (if it is distributed). The aim of this condition is to produce a
body of open source software that grows as users contribute, and that
cannot be shrunk by users adding their own effort to a piece of
software and then relicensing the result under terms that are more
restrictive than those of the GPL. Because this condition can be seen
as an attempt to subvert the proprietary use of copyright, it is
sometimes known as copyleft.
It
is worth noting that there is no compulsion to release changes that
you make, either under the GPL or any other open source licence; you
may keep internal versions of GPL software that you have modified
without necessarily licensing them to anyone else. This applies
equally to individuals and legal entities like companies and
institutions.
It
is tempting to believe that all the source code that is available
under an open source licence can be adapted and combined without
restriction in order to produce new open source software.
Unfortunately this is not the case. Two licences that each meet the
requirements of the Open Source Definition individually may
nevertheless contain terms that make them incompatible with each
other. The GNU GPL (all versions) provides an example of this: it
mandates that code that incorporates GPL-licensed code must itself be
licensed under the GPL as a whole if it is distributed. It also
mandates that no additional restrictions on the rights it grants can
be imposed on GPL-licensed code. These two conditions combine to mean
that GPL-licensed code can only be merged easily with other
GPL-licensed code, or with code whose licence imposes only conditions
present in the GPL. Clearly it is not an easy task to establish
whether a condition in one licence is the exact equivalent of a
differently worded condition in another licence. The Free Software
Foundation, which administers the GPL, makes available a list of
licences that they consider to be compatible with it.
The
issue of licence compatibility is a complex one, and determining
whether two licences are compatible will require the help of a lawyer
in all but the most simple of cases. Programmers working on a piece
of software that is to be distributed under a licence (whether open
source or otherwise) need to be aware of the potential difficulties
in this area before attempting to merge in open source code. Often
the simplest way of resolving licence conflicts is to ask the code’s
owner(s) if they would be willing to relicense their code for
inclusion. However, this approach is only really practical where the
number of owners is small.
The
issues of licence compatibility and of complex multiple ownership of
intellectual property mean that it is desirable, if not essential,
for programmers and their managers to keep detailed records. Version
control systems provide some of this record-keeping automatically,
recording who made changes to the code and what they did. To
complement this information, managers should keep records of the
contractual and licensing status of contributors in order to
establish who owns their work. They should also require and store
explicit
agreements from copyright owners that their contributions may be
licensed and distributed under the licence selected for the project
as a whole. Where code is brought in from existing open source
software, the details of the relevant licence must be recorded
(having first established that this licence is compatible with the
project’s overall licensing policy).
To
briefly summarise the points made in this document:
- Software is intellectual property.
- Software is protected under copyright law.
- The ownership of software can be determined by a technical legal examination of any contracts under which it was produced, and any other legally relevant circumstances.
- Copyright law says that by default only the owner of software may copy, adapt or distribute it.
- The owner of software can agree to let another person copy, adapt or distribute the code - this agreement is called a licence.
- Open source licences grant these rights to anyone who chooses to take them up, with certain conditions.
- Open source licences aim to create a community of contributors who will fix and develop the software.
- Combining two pieces of software code under different licences can be complex.
- All projects that produce software need to keep complete, detailed records of the licensing and ownership of contributions to that software.
Dịch: Lê Trung Nghĩa
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.