Làm cho mã nguồn sẵn sàng theo một giấy phép nguồn mở

By Ross Gardler, Elizabeth Tatham, Amir Nettler, Published: 21 September 2009, Reviewed: 12 March 2012

Theo: http://www.oss-watch.ac.uk/resources/opensourceyourcode

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 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 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.

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. Đ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.

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?, 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.

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ỉ?.

Á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ổ 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ở 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.

Choosing a licence

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 f-rom. 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 cre-ate derivative works that are not necessarily open source?

• Do you intend to cre-ate 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 cre-ate 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.

Types of licence

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 f-rom 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 f-rom each of these approaches, mandating the preservation of the MPL on files modified f-rom 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 al-ternative 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 al-ternative 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.

Licensing non-software items

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.

Intellectual property

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, whe-re 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 f-rom 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 f-rom 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.

Continued auditing

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 f-rom 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?.

Applying the licence

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 f-rom 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.

Satisfying the requirements of dependencies

If your code includes libraries f-rom 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 up-dated.

Making the code available

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 f-rom 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 f-rom 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.

Summary

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 f-rom a suitable distribution point such as Google Code or Sourceforge.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com