Making
your code available under an open source licence
By Ross Gardler,
Elizabeth Tatham, Amir Nettler, Published: 21 September 2009,
Reviewed: 12 March 2012
Bài được đưa lên
Internet ngày: 12/03/2012
Lời
người dịch: Bạn muốn làm cho mã nguồn của bạn sẵn
sàng theo một giấy phép nguồn mở, đặc biệt khi bạn
dựa vào một sản phẩm phần mềm nguồn mở khác của
thế giới mà vẫn tôn trọng các luật sở hữu trí tuệ
của thế giới hay không? Bài viết này phân tích các cách
thức để bạn đạt được điều đó. Còn đây là những
kết luận của nó: Các vấn đề
pháp lý quan trọng nhất phải được xem xét trước khi
làm cho mã sẵn sàng như nguồn mở có thể được tóm
tắt như sau: (1) Sự lựa chọn
giấy phép của bạn sẽ được chỉ định bằng cách mà
bạn mong muốn mã của bạn sẽ được sử dụng trong
tương lai; các giấy phép được OSI phê chuẩn được
khuyến cáo. (2) Các giấy phép được OSI phê chuẩn nằm
trong 3 chúng loại: copyleft, dễ dãi và một phần copyleft.
(3) Việc kiểm toán liên tục mã khi nó được đóng góp
là cơ bản, vì bạn cần phải có khả năng chứng minh đó
hoàn toàn là sở hữu trí tuệ của bạn. (4) Giấy phép
phải được hiển thị nổi bật trong tất cả các vị
trí phù hợp. (5) Mã phải được làm cho sẵn sàng để
tải về từ một điểm phân phối phù hợp như Google
Code hoặc Sourceforge.
Việc làm cho mã nguồn
của bạn sẵn sàng như nguồn mở có liên quan nhiều hơn
so với chỉ chỉ định trên trang web của dự án rằng mã
nguồn được cấp phép theo một giấy phép nguồn mở đặc
biệt. Bạn không chỉ cần cung cấp một
cách thức cho mọi người tải về và/hoặc đóng góp cho
dự án, mà bạn còn cần phải chọn giấy phép phù hợp
nhất và giải quyết các yêu cầu pháp lý khác. Một
trong những điều quan trọng nhất là bạn phải có khả
năng chứng minh rằng mã nguồn có thể được phát hành
một cách hợp pháp theo giấy phép đó; điều quan trọng
khác là mọi người mà tải nó về phải được nói
những trách nhiệm nào của họ đối với người sở hữu
dự án.
Tài liệu này đề
cập tới các vấn đề pháp lý chính mà các dự án đối
mặt khi mong muốn phát hành mã nguồn mở. Tuy nhiên, đối
với một dự án nguồn mở để thành công, điều cũng
quan trọng để xem xét một mô hình thực tế cho sự
bền vững (bản
dịch tiếng Việt) dài hạn, một phần chủ chốt của
điều đó là việc lôi cuốn một cộng
đồng (bản
dịch tiếng Việt) người sử dụng và các lập trình
viên. Các vấn đề đó nằm ngoài phạm vi tài liệu này.
Chọn một giấy
phép
Giấy phép xác định
các trách nhiệm được đặt ra lên các bên thứ 3 có
mong muốn sửa đổi và/hoặc sử dụng lại phần mềm
nguồn mở (PMNM) trng các sản phẩm của chính họ, vì thế
việc chọn đúng giấy phép là mấu chốt để đảm bảo
rằng người sở hữu dự án có khả năng duy trì bền
vững dự án theo bất kỳ cách gì họ chọn. Điều đầu
tiên chúng tôi khuyến cáo là hãy sử dụng chỉ các giấy
phép mà đã được Sáng kiến Nguồn Mở - OSI (Open
Source Initiative) phê chuẩn. Có nhiều lý do tốt lành
cho điều này, nhưng có lẽ thuyết phục nhất là việc
gắn với một giấy phép OSI làm cho nó có nhiều khả
năng để những người sử dụng và các lập trình viên
tiềm năng sẽ hiểu các điều khoản giấy phép của bạn
được rồi. Việc sử dụng một giấy phép mù mờ hoặc
tự bạn viết ra sẽ phủ định ưu thế này.
Có một dải rộng
lớn các giấy phép được OSI phê chuẩn để chọn. Giấy
phép nào là đúng cho một dự án được đưa ra còn phụ
thuộc vào các kế hoạch trong tương lai cho phần mềm đó.
Ở đây là một số câu hỏi chính nên được cân nhắc
khi chọn một giấy phép:
- Bạn có muốn cho phép những người khác tạo các công việc dẫn xuất mà không nhất thiết là nguồn mở không/
- Bạn có định tạo ra một doanh nghiệp dựa vào phân phối phần mềm đó không?
- Có là quan trọng cho bạn để lôi cuốn một cộng đồng phát triển tích cực là bên thứ 3 không?
- Liệu phần mềm của bạn có phụ thuộc vào bất kỳ phần mềm nào khác được cấp phép cho bạn hay không?
Đây chỉ là một
nhóm các câu hỏi bạn cần cân nhắc, và câu trả lời
cho từng câu hỏi sẽ dẫn tới các câu hỏi tiếp sau.
Tuy nhiên, quyết định cuối cùng thực sự phụ thuộc
vào câu trả lời cho câu hỏi đầu tiên: Bạn có muốn
cho phép những người khác tạo ra các công việc dẫn
xuất mà không nhất thiết phải là nguồn mở hay không?
Điều này không nói lên rằng các câu trả lời khác là
không quan trọng; chúng là, và thường các câu trả lời
cho chúng sẽ cho biết câu trả lời của bạn cho câu hỏi
đầu tiên. Điều này có nghĩa là bạn sẽ cần cân nhắc
tất cả các câu hỏi, và hơn thế nữa, cùng với nhau.
Các câu hỏi chính xác được trả lời sẽ phụ thuộc
vào hoàn cảnh cụ thể của bạn; chúng tôi vì thế
khuyến cáo rằng bạn liên
hệ với OSS Watch để có tư vấn về một giấy phép
sao cho bạn có thể khai thác đầy đủ các lựa chọn của
bạn.
Các dạng giấy
phép
Bất kể các ý định
của bạn là gì về sử dụng phần mềm của bạn trong
tương lai, có một giấy phép do OSI phê chuẩn để phù
hợp cho các mục đích của bạn. Các giấy phép do OSI phê
chuẩn, nói rộng ra, nằm trong 3 chủng loại chính:
copyleft, dễ dãi và một phần copyleft.
Một giấy phép
copyleft, như GNU GPL, bắt buộc bất kỳ ai sửa đổi
phần mềm và mong muốn phân phối phiên bản sửa đổi
của họ cần phải làm thế theo giấy phép copyleft theo
yêu cầu. Điều này có ý định để đảm bảo rằng mã
không bị lấy đi khỏi cộng đồng, và rằng tất cả
các cải tiến là sẵn sàng cho tất cả. Một giấy
phép dễ dãi, như giấy phép MIT, cho phép sử dụng lại
trong những điều khoản rộng rãi hơn nhiều, bao gồm sửa
đổi và phát hành ở các dạng không phải là mở. Điều
này có ý định tối đa hóa sử dụng một mẩu phần
mềm, thậm chí của các doanh nghiệp muốn dựa vào các
sản phẩm đóng trong mã đó. Một số giấy phép, như
Mozilla Public License (MPL), có ý định lấy ở dạng mỗi
tiếp cận trên một chút, bắt buộc giữ lại MPL trong
các tệp được sửa đổi từ dự án gốc ban đầu,
nhưng không trong các tệp mới được giới thiệu trong dự
án. Chúng được biết tới như là các giấy phép copyleft
yếu hoặc một phần. Website của OSS Watch có các
tài liệu mô tả các giấy phép nguồn mở chủ chốt
(bản dịch tiếng Việt).
Giấy phép mà bạn
chọn sẽ phụ thuộc vào các kế hoạch của bạn trong
tương lai đối với mã của bạn, như được chỉ ra bằng
các câu trả lời cho các câu hỏi ở trên, và cũng trong
quan điểm đạo đức của bạn đối với phần mềm tự
do. Những người đề xướng ra copyleft, như Quỹ Phần
mềm Tự do – FSF (Free Software Foundation), giữ nó như một
nguyên tắc đạo đức rằng một người sử dụng phải
có tự do để sử dụng, nghiên cứu, phân phối lại và
sửa đổi phần mềm mà họ sử dụng. Họ coi sự từ
chối các quyền tự do đó đối với những người sử
dụng của phần mềm của ai đó sẽ là chống lại xã
hội và vô đạo đức. Vì thế, các giấy phép copyleft
được viết để đảm bảo rằng được cấp phép
copyleft không thể dễ dàng được kết hợp vào trong phần
mềm mà không được cấp phép theo cách tự do tương tự.
Trong ngữ cảnh của
một doanh nghiệp - ví dụ, một doanh nghiệp mà bán các
dịch vụ dựa vào mã của chúng, như đang cài đặt và
tùy biên cho những người sử dụng - có khả năng sử
dụng hoặc một giấy phép copyleft hoặc dễ dãi. Tuy
nhiên, một giấy phép dễ dãi có thể làm gia tăng số
lượng các đối tác cộng tác bằng việc không loại trừ
những người mà có mong muốn phát hành các sản phẩm
dẫn xuất theo một giấy phép không mở. Những người đề
xướng cấp phép dễ dãi, trả lời cho những phản đối
về đạo đức của những người đề xướng copyleft, có
thể tranh luận rằng, trong khi việc cấp phép dễ dãi cho
phép sự kết hợp mã vào các tác phẩm sở hữu độc
quyền, thì những lợi ích của việc đệ trình những
thay đổi của mọi người ngược trở lại cho cộng đồng
làm cho điều này ít có khả năng hơn để xảy ra trong
thực tế.
Một tiếp cận lựa
chọn thay thế cho việc thương mại hóa mã của bạn là
việc
cấp phép đôi (bản
dịch tiếng Việt). Điều này liên quan tới việc phát
hành phần mềm của bạn theo một giấy phép copyleft mạnh
như GNU GPL, và cũng làm cho sẵn sàng một phiên bản theo
một giấy phép lựa chọn thay thế, vì thế cho phép người
sử dụng mà không muốn bị rằng buộc với GN GPL sẽ
trả tiền cho phiên bản không là copyleft. Thông thường,
họ có thể làm điều này vì họ muốn sản xuất ra một
sản phẩm dựa vào mã những không bị nhốt vì một giấy
phép copyleft. Liệu có hay không sự quản trị bổ sung có
liên quan trong mô hình này là đáng cho bạn sẽ phụ thuộc
vào việc bạn nghĩ thế nào khi chính những khách hàng sẽ
muốn trả tiền cho quyền để sản xuất các sản phẩm
dẫn xuất không phải copyleft. Bạn nên
nhớ là để đưa ra một giấy phép không phải là
copyleft bổ sung, bạn phải có thỏa thuận của tất cả
những người đóng góp hoặc sở hữu tất cả bản quyền
trong mã của riêng bạn.
Cũng quan trọng để
xem xét sự tương tác giữa giấy phép bạn chọn và giấy
phép của các sản phẩm mà bạn có thể muốn sử dụng
lại hoặc đóng góp như một phân công việc của bạn.
Việc kết hợp mã của 2 mẩu phần mềm theo các giấy
phép khác nhau có thể là phức tạp. Được nhắc nhở
còn tranh cãi về sử dụng lại phần mềm được cấp
phép BSD để làm tăng các khả năng kết nối mạng không
dây của nhân Linux, Trung tâm Luật Tự do cho Phần mềm –
SFLC (Software Freedom Law Center) đã đưa ra chỉ dẫn hữu
dụng này cho các lập trình viên làm việc với các dự
án được cấp phép GPL, những người muốn sử dụng
phần mềm có sẵn theo một giấy phép được gọi là dễ
dãi, như các giấy phép BSD hoặc MIT. Dù được các luật
sư Mỹ viết ra, nó vẫn phù hợp cho các lập trình viên
làm việc tại nước Anh.
Rõ ràng, việc chọn
giấy phép đúng là một quyết định phức tạp. OSS Watch
có thể giúp bằng việc cung cấp các tư vấn về giấy
phép tự do cho các cơ quan trung và cao hơn trong giáo dục
tại nước Anh; xin liên hệ
với chúng tôi để có thêm thông tin. Đối với thảo
luận chi tiết hơn về vì sao bạn cần cấp phép cho phần
mềm của bạn, hãy xem lưu ý ngắn gọn của chúng tôi
Phát triển
Nguồn Mở - Giới thiệu các vấn đề về Sở hữu và
Cấp phép (bản
dịch tiếng Việt).
Việc cấp phép cho
các điều khoản không phải phần mềm
Điều
quan trọng phải nhớ rằng các giấy phép tự do và nguồn
mở được thiết kế để được sử dụng trong mã phần
mềm. Nếu dự án của bạn bao gồm cả những khoản có
bản quyền không phải là phần mềm, như các hình ảnh,
âm thanh, tài liệu hoặc cơ sở dữ liệu, có các giấy
phép phù hợp hơn sẵn sàng được chỉnh sửa cho các
nhiệm vụ đó. Đối với các hình ảnh, âm thanh và tài
liệu, hãy xem xét sử dụng các giấy phép Creative Commons.
Đối với các cơ sở dữ liệu, mà có thể được bảo
vệ cả theo bản quyền và các quyền cơ sở dữ liệu
riêng rẽ, hãy thử một giấy
phép cơ sở dữ liệu mở.
Sở hữu trí tuệ
Một khi bạn đã chọn
giấy phép phù hợp được OSI phê chuẩn theo đó để
phát hành mã của bạn, thì bạn cần chắc chắn rằng
bạn có quyền làm thế một cách hợp pháp. Điều này
liên quan tới việc đảm bảo rằng bạn có thể chứng
minh rằng tất cả mã của bạn là hoàn toàn sở hữu trí
tuệ (IP) của bạn và rằng bạn có tất cả các quyền
cần thiết để cấp phép cho nó như bạn muốn, và việc
kiểm toán cho nó trên cơ sở hiện hành sao cho nó vẫn
theo cách đó.
Trong các dự án nhỏ,
nơi mà tất cả những người đóng góp và các lịch sử
thuê người làm việc của chúng là được rõ, điều này
thường rất đơn giản. Miễn là tất
cả những người đóng góp được thuê làm việc của
người nằm giữ bản quyền và các hợp đồng của họ
không cho phép họ giữ lại bản quyền trong công việc
của riêng họ, và miễn là tất cả những người đóng
góp có thiện chí khẳng định rằng công việc của họ
là của riêng họ và không bị sao chép từ dự án khác,
thì an toàn để nói rằng tất cả các quyền sở hữu
trí tuệ thuộc về người nắm giữ bản quyền.
Tuy
nhiên, mọi điều sẽ phức tạp hơn trong các dự án lớn
hơn mà có thể đã nhận được những đóng góp từ mọi
người không được thuê làm đối với người nắm giữ
bản quyền. Ví dụ, nếu bạn đã sử dụng một nhà thầu
cho một số công việc phát triển, bạn có thể không làm
chủ các bản quyền trong công việc của họ. Tương tự,
ai đó mà đã biếu mã, hoặc mã của người đó đã được
sao chép, có thể đã không có trao hoàn toàn sự rõ ràng
về bản quyền. Việc phát hành mã như nguồn mở khi bạn
không thể chứng minh rằng bạn sở hữu tất cả các bản
quyền trong mã đó không chỉ là không bình thường, mà
có thể còn gây ra hành động của tòa án chống lại
bạn.
Để có thêm thông
tin về vấn đề này, xem Bạn
có thể đóng góp mã cho một dự án nguồn mở hay không?
(bản
dịch tiếng Việt), nó thảo luận sự đóng góp mã
cho dự án của bên thứ 3, nhưng là phù hợp ngang bằng
cho các dự án đang tồn tại có mong muốn phát hành mã
theo một giấy phép nguồn mở.
Kiểm toán liên tục
Việc
kiểm toán sở hữu trí tuệ của bạn là một nhiệm vụ
liên tục. Các công cụ cho phép rà soát
lại mã và kiểm soát các hiệu đính
có thể được sử dụng, nó sẽ cho phép bạn kiểm toán
có hiệu quả mã khi nó được đóng góp và vì thế cả
loại bỏ phần không cần thiết của việc thực hiện
các kiểm toán theo chu kỳ. Kiểm toán liên tục tại thời
điểm đóng góp đảm bảo rằng bạn tối thiểu hóa được
những cơ hội làm hỏng một cách không có chủ ý các
phát hành mã của bạn, và dễ dàng hơn để thiết lập
một qui trình như vậy khi bắt đầu một dự án, trước
khi các bên thứ 3 trở nên có quan tâm trong mã của bạn.
Điều này được thảo luận xa hơn trong tài liệu của
chúng tôi về Thỏa
thuận Giấy phép của Người đóng góp (bản
dịch tiếng Việt).
Việc thiết lập qui
trình kiểm toán, và các công cụ hỗ trợ nó, cũng sớm
đảm bảo rằng có một sự theo dõi kiểm toán cho tất
cả những đóng góp, bao gồm những đóng góp từ đội
dự án. Trong trường hợp có bất kỳ dạng tranh cãi nào
về quyền sở hữu, thì sự theo dõi kiểm toán như vậy
là sống còn. Sử dụng kiểm soát phiên bản như một
công cụ theo dõi các quyền sở hữu trí tuệ (IPR) được
thảo luận trong lưu ý ngắn gọn của chúng tôi Kiểm
soát phiên bản là gì? Vì sao quan trọng cho sự chăm chỉ?
(bản
dịch tiếng Việt).
Áp dụng giấy phép
Một khi bạn đã chọn
giấy phép thì bạn muốn sử dụng và được khẳng định
rằng bạn có quyền hợp pháp để cấp phép cho tất cả
mã trong dự án của bạn, bạn phải áp dụng giấy phép
đó sao cho mọi người có thể thấy được nó. Không đủ
để chỉ đơn giản nói rằng mã của bạn là sẵn sàng
theo một giấy phép được chỉ định; bạn cũng cần đảm
bảo rằng nó được hiển thị nổi bật trong tất cả
những vị trí phù hợp. Ít nhất bạn phải:
- nói trên website của bạn giấy phép nào được áp dụng (ưu tiên trên trang chủ của bnj và trang tải về của bạn)
- đưa ra văn bản đầy đủ của giấy phép trên website của bạn
- đưa ra văn bản đầy đủ của giấy phép trong thư mục gốc root dự án nguồn của bạn (thường trong tệp gọi là LICENSE.TXT)
- đưa ra một lưu ý soạn sẵn ở đầu của từng tệp trong phân phối nguồn (văn bản soạn sẵn sử được sử dụng là khác nhau từ giấy phép này sang giấy phép kia. Bạn sẽ thường thấy thảo luận tiếp theo về cách áp dụng một giấy phép được ghi thành tài liệu cùng với giấy phép trong gốc home ban đầu của nó).
- đưa ra văn bản đầy đủ của giấy phép trong thư mục gốc root của những phát hành không phải nguồn của dự án (thường trong một tệp được gọi là LICENSE.TXT)
Có
các công cụ sẵn sàng mà có thể giúp với ứng dụng
một giấy phép cho các tệp nguồn của bạn. Để hỗ trợ
với điều này và những bài tập kiểm toán mã khác, xin
liên hệ với OSS
Watch.
Làm thỏa mãn các
yêu cầu của các phụ thuộc
Nếu mã của bạn bao
gồm các thư viện từ dự án khác thì điều quan trọng
là bạn tuân thủ với các yêu cầu của giấy phép đó.
Điều đầu tiên phải cân nhắc là liệu mã được đánh
đống có nằm dưới một giấy phép tương thích hay
không. Điều này là vấn đề phức tạp và nằm ngoài
phạm vi của tài liệu này. Nếu bạn cần trợ giúp xin
liên hệ với chúng tôi.
Tuy nhiên, ghi công và lưu ý về các giấy phép được
đánh đống là dễ dàng hơn để giải quyết và vì thế
là nằm trong phạm vi của tài liệu này.
Những giấy phép khác
nhau đòi hỏi những ghi công khác nhau, và một số không
đòi hỏi bất kỳ thứ gì cả. Tiếp cận tốt nhất là
đối xử với chúng tất cả như nhau khi trao sự ghi công
hơn so với yêu cầu hiếm khi là một vấn đề. Thực
tiễn chung nhất là phải đưa vào một tệp NOTICE.TXT ở
gốc root của thư mục đó, nó nêu các thông tin quan trọng
về giấy phép được sử dụng và các thư viện được
đánh đống. Ví dụ, đây là phần của tệp NOTICE.TXT của
dự án Apache Forrest:
Bản quyền của
Apache Forrest 2002-2009 Quỹ Phần mềm Apache. Sản phẩm này
bao gồm các phần mềm được phát triển tại Quỹ Phần
mềm Apache (http://www.apache.org/).
Cũng xem tệp LICENSE.TXT. Mục đích của tệp NOTICE.TXT là
để chứa các lưu ý được người sở hữu bản quyền
và giấy phép của họ yêu cầu. Một số sản phẩm đi
kèm có một yêu cầu ghi công, vì thế xem bên dưới. Các
sản phẩm đi kèm khác không đòi hỏi sự ghi công, nên
không được liệt kê. Sản phẩm này bao gồm phần mềm
được Nhóm OpenSymphony phát triển
http://www.opensymphony.com/.
Sản phẩm này bao gồm phần mềm được phát triển cho
dự án Krysalis http://www.krysalis.org/ [và cứ như thế].
Điều
quan trọng để lưu ý là một giấy phép, Giấy phép Ghi
công Công cộng Chung (Common Public Attribution License) có
những yêu cầu rất đặc thù với sự tôn trọng sự ghi
công. Điều này được mô tả trong tài liệu của chúng
tôi Common
Public Attribution License - Tổng quan (bản dịch tiếng
Việt).
Bổ sung thêm cho việc
cho vay mã đánh đống cũng cần thiết để đưa vào giấy
phép đầy đủ của bất kỳ mã nào mà được dự án
phân phối. Một lần nữa, không có cách cố định nào
để làm điều này, nhưng một thực tiễn chung là đưa
giấy phép vào cùng thư mục như thư viện được đưa
vào. Theo tiếp cận này thì tệp giấy phép sẽ được
đổi tên để chỉ ra rõ ràng thư viện nào được áp
dụng. Vì thế, ví dụ, nếu dự án đánh đống thư viện
‘jtidy-04aug2000r7-dev.jar’ thì nó nên đưa vào giấy phép
của thư viện đó trong một tệp gọi là
‘jtidy-04aug2000r7-dev.jar.license.txt’ và được lưu trữ
cùng với thư viện đó. Điều quan trọng để sử dụng
chính xác tên tệp y hệt sao cho nó có thể được tìm
thấy dễ dàng, và bạn nhắc các lập trình viên kiểm
tra giấy phép chính xác được sử dụng khi một thư viện
được cập nhật.
Làm cho mã sẵn
sàng
Làm cho mã của bạn
sẵn sàng như nguồn mở không kết thúc bằng việc áp
dụng một giấy phép cho mã nguồn đó. Bạn cũng phải
làm cho mã sẵn sàng cho mọi người để tải về từ một
điểm phân phối phù hợp, như website của bạn hoặc một
site đặt chỗ của dự án như Google Code hoặc SourceForge,
nhớ đưa bào nguồn cho bất kỳ thành phần nguồn mở
nào khác mà bạn đã sử dụng trong dự án của bạn.
Trong khi điều này là đủ từ một quan điểm pháp lý,
thì bạn sẽ cần đi xa hơn điều này và xây dựng một
cộng đồng những người đóng góp và những người sử
dụng xung quanh dự án của bạn; tiếp cận này được
biết như là phương
pháp phát triển mở (bản
dịch tiếng Việt) và điều này cũng là một lĩnh vực
theo đó OSS Watch có thể đưa
ra sự hỗ trợ.
Tổng kết
Các vấn đề pháp lý
quan trọng nhất phải được xem xét trước khi làm cho mã
sẵn sàng như nguồn mở có thể được tóm tắt như sau:
- Sự lựa chọn giấy phép của bạn sẽ được chỉ định bằng cách mà bạn mong muốn mã của bạn sẽ được sử dụng trong tương lai; các giấy phép được OSI phê chuẩn được khuyến cáo.
- Các giấy phép được OSI phê chuẩn nằm trong 3 chúng loại: copyleft, dễ dãi và một phần copyleft.
- Việc kiểm toán liên tục mã khi nó được đóng góp là cơ bản, vì bạn cần phải có khả năng chứng minh đó hoàn toàn là sở hữu trí tuệ của bạn.
- Giấy phép phải được hiển thị nổi bật trong tất cả các vị trí phù hợp.
- Mã phải được làm cho sẵn sàng để tải về từ một điểm phân phối phù hợp như Google Code hoặc Sourceforge.
Making
your code available as open source involves much more than just
indicating on the project web page that the code is licensed under a
particular open source licence. Not only do you need to provide a way
for people to download and/or contribute to the project, but you also
need to choose the most appropriate licence and address other legal
requirements. One of the most important of these is that you must be
able to prove that the code can legally be released under that
licence; another is that people who download it must be told what
their responsibilities are to the project owner.
This
document highlights the main legal issues faced by projects wishing
to release open source code. For an open source project to be
successful, however, it is also important to consider a realistic
model for long-term sustainability,
a major part of which is attracting a community
of users and developers. These issues are beyond the scope of this
document.
The
licence defines the responsibilities placed on third parties wishing
to modify and/or reuse open source software within their own
products, so choosing the right licence is key to ensuring that the
project owner is able to sustain the project in whichever way they
choose. The first thing we recommend is to use only licences that
have been approved by the Open
Source Initiative (OSI). There are many good reasons for this,
but perhaps the most convincing is that sticking with an OSI licence
makes it much more likely that potential users and contributors will
understand your licence terms already. Using an obscure licence or
writing your own will negate this advantage.
There
is a wide range of OSI-approved licences to choose from. Which one is
right for a given project depends on the future plans for the
software. Here are some key questions that should be considered when
choosing a licence:
- Do you want to allow others to create derivative works that are not necessarily open source?
- Do you intend to create a business based on the distribution of the software?
- Is it important for you to attract an active third-party development community?
- Does your software depend on any other software licensed to you?
This
is just a handful of the questions you need to consider, and the
answer to each will lead to further questions. However, the final
decision really depends on the answer to the first question: Do you
want to allow others to create derivative works that are not
necessarily open source? This is not to say that the other questions
are not important; they are, and often the answers to them will
inform your answer to the first question. This means that you will
need to consider all these questions, and more besides, together. The
precise questions to be answered will depend on your specific
circumstances; we therefore recommend that you contact
OSS Watch for a licence consultation so that you can fully
explore your options.
Whatever
your intentions regarding the future use of your software, there is
an OSI-approved licence to suit your purposes. OSI-approved licences,
broadly speaking, fall into three main categories: copyleft,
permissive and partial copyleft.
A
copyleft licence,
such as the GNU GPL, mandates that anyone who modifies the software
and wishes to distribute their modified version needs to do so under
the copyleft licence in question. This is intended to ensure that the
code is not taken away from the community, and that all improvements
are available to all. A permissive
licence, such as the
MIT licence, allows reuse on much broader terms, including
modification and release in non-open forms. This is intended to
maximise the use of a piece of software, even by businesses who wish
to base closed products on the code. Some licences, such as the
Mozilla Public License (MPL), attempt to take a little from each of
these approaches, mandating the preservation of the MPL on files
modified from the original project, but not on new files introduced
into the project. These are known as partial
or weak copyleft
licences. The OSS Watch website has documents
describing the major open source licences.
The
licence you choose will depend on your plans for the future of your
code, as indicated by your answers to the questions above, and also
on your ethical stance towards free software. Copyleft proponents,
such as the Free Software Foundation, hold it as an ethical principle
that a user ought to be free to use, study, re-distribute and modify
the software they use. They consider the denial of these freedoms to
the users of one’s software to be anti-social and unethical.
Therefore, copyleft licences are written to ensure that
copyleft-licensed cannot easily be incorporated into software that is
not licensed in a similarly liberal way.
In
the context of a business - for example, one which sells services
based on their code, such as doing installation and customisation for
users - it may be possible to use either a copyleft or a permissive
licence. However, a permissive licence might increase the number of
collaborative partners by not excluding those who would wish to
release derivative products under a non-open licence. Proponents of
permissive-licensing, responding to the ethical objections of
copyleft proponents, would argue that, while permissive licensing
does allow the incorporation of code into proprietary works, the
benefits of submitting one’s changes back to the community make
this less likely to happen in practice.
An
alternative approach to monetising your code is dual-licensing.
This involves releasing your software under a strong copyleft licence
such as the GNU GPL, and also making available a version under an
alternative licence, thus allowing users who do not wish to be bound
by the GNU GPL to pay for the non-copyleft version. Generally, they
would do this because they wish to produce a product based on the
code but not confined by a copyleft licence. Whether the additional
administration involved in this model is worth it for you will depend
on how likely you think it is that customers will want to pay for the
right to produce non-copyleft derivative products. You should
remember that in order to offer an additional non-copyleft licence,
you must have the agreement of all contributors or own all the
copyright in the code yourself.
It
is also important to consider the interaction between your chosen
licence and that of other products you might wish to reuse or
contribute to as part of your work. Combining two pieces of software
code under different licences can be complex. Prompted by controversy
over the reuse of BSD-licensed software to augment Linux’s wireless
networking capabilities, the Software Freedom Law Center produced
this useful
guide for developers working on GPL-licensed projects, who wish
to make use of software available under a so-called permissive
licence, such as the BSD or MIT licences. Although written by US
lawyers, it is just as relevant for developers working in the UK.
Clearly,
choosing the right licence is a complex decision. OSS Watch can help
by providing free licence consultations to higher and further
education institutions in the UK; please contact
us for more information. For a more detailed discussion of why
you need to license your software, see our briefing note Open
Source Development - An Introduction to Ownership and Licensing
Issues.
It
is important to remember that free and open source licences are
designed to be used on software code. If your project includes
non-software copyright items, such as images, sounds, documentation
or databases, there are more appropriate licences available that are
tailored to these tasks. For images, sounds and documentation,
consider using Creative Commons
licences. For databases, which can be protected both by copyright and
the separate database right, try an open
database
licence.
Once
you have chosen the most appropriate OSI-approved licence under which
to release your code, you need to make sure that you are legally
entitled to do so. This involves ensuring that you can prove that all
your code is exclusively your intellectual property (IP) and that you
have all the necessary rights to license it as you please, and
auditing it on an ongoing basis so that it remains that way.
In
small projects, where all contributors and their employment histories
are known, this is usually very simple. As long as all contributors
are in the employment of the copyright holder and their contracts do
not allow them to retain copyright on their own work, and as long as
all contributors are willing to confirm that their work is their own
and not copied from another project, it is safe to say that all the
intellectual property rights belong to the copyright holder.
However,
things get more complicated in larger projects that may have received
contributions from people not in the employment of the copyright
holder. For example, if you used a contractor for some development
work, you may not own the copyrights on their work. Similarly,
someone who donated code, or whose code has been copied, may not have
explicitly granted copyright clearance. Releasing code as open source
when you cannot prove that you own all copyrights on that code is not
only immoral, but could also result in court action against you.
For
more information on this issue, see Can
you contribute code to an open source project?, which discusses
contribution of code to a third-party project, but is equally
relevant to existing projects wishing to release code under an open
source licence.
Auditing
your intellectual property is an ongoing task. Tools to enable code
review and revision control can be put in place, which will allow
you to efficiently audit code as it is contributed and thus remove
the overhead of doing periodic audits. Ongoing audits at the point of
contribution ensure that you minimise the chances of inadvertently
contaminating your code releases, and it is easier to set up such a
process at the start of a project, before third parties become
interested in your code. This is discussed further in our document on
Contributor
Licence Agreements.
Setting
up the auditing process, and the tools to support it, early on also
ensures that there is an audit trail for all contributions, including
those from the project team. In the event of any kind of ownership
dispute, such an audit trail is vital. The use of version control as
an intellectual property rights (IPR) tracking tool is discussed in
our briefing note What
is version control? Why is it important for due diligence?.
Once
you have chosen the licence you wish to use and confirmed that you
are legally entitled to license all the code in your project, you
must apply the licence so that people can see it. It is not
sufficient to simply state that your code is available under a
specified licence; you also need to ensure that it is prominently
displayed in all appropriate locations. At a minimum you must:
- state on your website which licence is applied (preferably on your home page and your downloads page)
- provide the full text of the licence on your website
- provide the full text of the licence in the root directory of your source project (usually in a file called LICENSE.TXT)
- provide a boilerplate notice in the head of each file in the source distribution (The boilerplate text used varies from licence to licence. You will usually find further discussion on how to apply a licence documented alongside the licence in its original home.)
- provide the full text of the licence in the root directory of your non-source project distributions (usually in a file called LICENSE.TXT).
There
are tools available that can help with the application of a licence
to your source files. For assistance with this and other code audit
exercises, please contact OSS
Watch.
If
your code includes libraries from another project it is important
that you conform to the requirements of that licence. The first thing
to consider is whether the bundled code is under a compatible licence
or not. This is a complex issue and out of scope for this document.
If you need assistance please contact
us. However, attribution and notification of bundled licences is
easier to address and so is within scope of this document.
Different
licences require different attributions, and some don’t require any
at all. The best approach is to treat them all the same since giving
more attribution than is required is rarely a problem. The most
common practice is to include a NOTICE.txt file in the root of the
directory which states important information about the licence used
and bundled libraries. For example, here is a part of the NOTICE.txt
file of the Apache Forrest project:
Apache
Forrest Copyright 2002-2009 The Apache Software Foundation. This
product includes software developed at The Apache Software Foundation
(http://www.apache.org/). See also the file LICENSE.txt The purpose
of this NOTICE.txt file is to contain notices that are required by
the copyright owner and their license. Some of the accompanying
products have an attribution requirement, so see below. Other
accompanying products do not require attribution, so are not listed.
This product includes software developed by the OpenSymphony Group
http://www.opensymphony.com/ This product includes software developed
for project Krysalis http://www.krysalis.org/ [and so on…]
It
is important to note that one licence, the Common Public Attribution
License has very specific requirements with respect to attribution.
This is described in our document Common
Public Attribution License - An Overview.
In
addition to crediting bundled code it is also necessary to include
the full licence of any code that is distributed by the project.
Again, there is no fixed way of doing this, but a common practice is
to include the licence in the same directory as the included library.
In this approach the licence file will be renamed to clearly indicate
which library it applies to. So, for example, if the project bundles
the library ‘jtidy-04aug2000r7-dev.jar’ it should include the
library’s licence in a file called
‘jtidy-04aug2000r7-dev.jar.license.txt’ which is stored alongside
the library. It is important to use exactly the same filename so that
it can be found easily, and you remind developers to check the
correct licence is used when a library is updated.
Making
your code available as open source does not end with applying a
licence to the source code. You must also make the code available for
people to download from a suitable distribution point, such as your
website or a project-hosting site such as Google Code or SourceForge,
remembering to include source to any other open source components you
have used in your project. While this is sufficient from a legal
point of view, you will need to go beyond this and build a community
of contributors and users around your project; this approach is known
as the open
development method and this is also an area in which OSS Watch
can offer assistance.
The
most important legal issues to be considered before making code
available as open source can be summarised as follows:
- Your choice of licence will be dictated by how you wish your code to be used in future; OSI-approved licences are recommended.
- OSI-approved licences fall into three main categories: copyleft, permissive and partial copyleft.
- Ongoing auditing of code as it is contributed is essential, as you need to be able to prove that it is exclusively your intellectual property.
- The licence must be prominently displayed in all appropriate locations.
- The code must be made available for download from a suitable distribution point such as Google Code or Sourceforge.
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.