Dạng giấy phép nào tôi nên chọn?

What kind of licence should I choose?

By Rowan Wilson, Published: 23 May 2011, Reviewed: 14 May 2012

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

Bài được đưa lên Internet ngày: 14/05/2012

Lời người dịch: Chọn giấy phép cho phần mềm tự do nguồn mở của bạn là một việc không dễ, vì có rất nhiều loại giấy phép và chúng có những đặc trưng khác nhau, dù có 2 dòng chính là copyleft và dễ dãi (permissive). Dù thế nào, thì thông thường suy nghĩ chọn giấy phép cũng là làm sao đề phần mềm được nhiều người sử dụng dễ dàng nhất, điều thường là trái ngược với phần mềm sở hữu độc quyền khi luôn cấm đoán bạn thực hiện một hành động nào đó, như sao chép, tùy biến, phân phối và/hoặc phân phối lại. “Tài liệu này đã trình bày một số khác biệt giữa các giấy phép PMTDNM khác nhau, để giúp bạn xem xét dạng giấy phép nào bạn có thể muốn áp dụng cho mã của riêng bạn. Các ví dụ được cung cấp để bổ sung thêm dạng những cân nhắc có thể đặc trưng trong qui trình lựa chọn của riêng bạn. Tuy nhiên, bạn nên lưu ý, rằng không có một giấy phép nào có thể cho mọi sự kết hợp các tính năng, và vì thế có lẽ là cần thiết phải thỏa hiệp về một hoặc vài chủng loại các tính năng để thực sự chọn một giấy phép đang tồn tại sẵn trước rồi. Để đạt được điều này, có thể là hữu dụng để xếp hạng các tính năng mà bạn mong muốn theo trật tự về tầm quant trọng”.

Có nhiều giấy phép phần mềm tự do nguồn mở (PMTDNM), và trong khi chúng tất cả có ý định một cách rộng rãi tạo thuận lợi cho những điều y hệt nhau, thì chúng cũng có một số khác biệt. Một số khác biệt chính có thể được nhóm cùng vào các chủng loại, và tài liệu này hành động như một sự giới thiệu các chủng loại đó. Đọc xong tài liệu này, bạn sẽ có khả năng hiểu các quyết định nào bạn nên tiến hành để chọn một giấy phép cho mã của bạn.

Giữ dòng chính thống

Sáng kiến Nguồn Mở (OSI) - một tổ chức phi lợi nhuận được hình thành để giáo dục về nguồn mở - duy trì một danh sách các giấy phép mà họ thấy đang 'được sử dụng phổ biến và rộng rãi hoặc với các cộng đồng mạnh'. Mục tiêu của danh sách đó là để nhấn mạnh các giấy phép mà có khả năng trả lời cho các nhu cầu của nhiều người cấp phép mới đối với nguồn mở. Danh sách đó cũng giúp thực hiện nhiệm vụ lựa chọn giấy phép nguồn mở trở nên có khả năng quản lý được; danh sách đầy đủ của hơn 60 giấy phép có thể là làm thoái chí, và có nhiều giấy phép theo hầu hết cách cách thức tương tự về chức năng với một hoặc nhiều giấy phép được liệt kê 'được sử dụng phổ biến và rộng rãi'.

Việc sử dụng một giấy phép mà nhiều người khác sử dụng có một số ưu điểm. Nếu các điều khoản của giấy phép đó bị thách thức, sẽ có một lượng lớn những người cấp phép với một sự quan tâm trong việc đầu cấp vốn cho một câu trả lời đối với thách thức đó. Việc sử dụng một trong những giấy phép 'được sử dụng phổ biến và rộng rãi' cũng làm cho có khả năng hơn rằng các giấy phép của bạn sẽ là quen thuộc rồi với các điều khoản mà bạn đang chào. Dù như nhau, thì các nhà cấp phép không nên cảm thấy 'bị khóa trói' vào chỉ việc sử dụng một giấy phép 'được sử dụng phổ biến và rộng rãi'. Một số tính năng chúng tôi thảo luận bên dưới chỉ hiện diện trong kho rộng lớn hơn của tất cả các giấy phép được OSI phê chuẩn.

Dễ dãi và copyleft

Tất cả các giấy phép tự do nguồn mở cho phép những người khác làm những phiên bản được sửa đổi đối với mã của bạn, và làm các phiên bản được sửa đổi đó sẵn sàng cho những người khác. Giấy phép mà bạn chọn có thể làm cho các điều kiện về cách mà điều này sẽ xảy ra - đặc biệt những giấy phép có thể được sử dụng trong các phiên bản được sửa đổi. Những điều kiện đó có thể giúp giữ cho mã của bạn tự do, nhưng chúng cũng có thể đặt một số người không sử dụng được mã của bạn. Những điều kiện như vậy đôi khi được gọi là các điều kiện 'copyleft', một cách chơi chữ với từ bản quyền 'copyright'.

Các giấy phép nguồn mở không tìm cách kiểm soát cách mà mã được sửa dổi được cấp phép thường được tham chiếu tới như là các giấy phép 'dễ dãi'. Trong khi mã gốc ban đầu được bao trùm bằng một giấy phép dễ dãi nằm dưới giấy phép dễ dãi đó, thì bất kỳ sửa đổi nào đối với nó có thể được phân phối theo bất kỳ giấy phép nào mà người sửa đổi chọn, nguồn mở hay là không. Điều này có nghĩa là mã được cấp phép dễ dãi có thể tạo thành nền tảng của các sản phẩm nguồn đóng. Một số viện lý rằng điều này làm cho các giấy phép dễ dãi 'tự do' hơn so với các giấy phép copyleft, theo đó mọi người mà sửa đổi mã là tự do hơn để chọn những gì họ làm với nó. Những người khác viện lý rằng thiếu một yêu cầu rằng những sửa đổi sẽ là nguồn mở ngụ ý rằng các giấy phép dễ dãi là ít 'tự do' hơn. Khi những thảo luận về các lý tưởng tự do - và đặc biệt ý tưởng bắt buộc phải là tự do - về cơ bản là triết lý mà chúng nằm ngoài phạm vi của tài liệu này. Tuy nhiên, đáng lưu ý rằng có các quan điểm khác nhau trong thế giới tự do nguồn mở về cái gì là 'tự do' theo nghĩa của sự tự do thực sự ngụ ý.

Ví dụ: Như một phần của nghiên cứu của bà, Anne tạo ra một tiêu chuẩn cho việc ghi một dạng đặc biệt đối tượng dữ liệu phức tạp. Bà cũng viết mã để tạo và phân tích các tệp gắn với tiêu chuẩn đó. Anne hiểu sâu sắc rằng tiêu chuẩn đã trở nên được sử dụng một cách rộng rãi, khi những tiêu chuẩn của thiểu số là ít hữu dụng hơn nhiều. Vì thế bà quyết định rằng bà sẽ phát hành mã theo một giấy phép dễ dãi. Anne tin tưởng rằng bằng việc cho phép những người sáng tạo của cả các dự án nguồn đóng và nguồn mở sử dụng cùng y hệt mã để tạo ra và đọc các đối tượng dữ liệu, thì sự hiểu biết và tính hiệu quả của tiêu chuẩn đều sẽ được giúp cùng.

Copyleft mạnh và yếu

Bạn có nên chọn đưa vào các điều kiện cấp phép copyleft để sử dụng lại mã của bạn hay không, có một sự lựa chọn tiếp để được thực hiện. Các giấy phép copyleft được chia rộng rãi thành 2 loại 'sức mạnh': mạnh và yếu. Các điều kiện của copyleft mạnh chỉ thị rằng khi một mẩu phần mềm có chứa một số mã của bạn, thì phần mềm như một tổng thể phải được phân phối theo giấy phép của bạn, nếu nó được phân phối hoàn toàn. Hiệu ứng của điều này sẽ là việc mã nguồn đối với tất cả các bổ sung được làm tới mã đó cũng sẽ là sẵn sàng.

Copyleft yếu, mặt khác, ngụ ý rằng khi phần mềm có chứa một số mã của bạn, thì một số phần của phần mềm đó phải được phân phối theo giấy phép của bạn, nếu phần mềm đó được phân phối hoàn toàn. Các phần khác có thể được phân phối theo các giấy phép khác, thậm chí dù chúng tạo thành một phần của tác phẩm mà là - như một tổng thể - một phiên bản được sửa đổi của mã của bạn. Một hiệu ứng của điều này sẽ là việc mã nguồn đối với một số bổ sung được làm từ những người khác cho phần mềm của bạn có thể sẽ không sẵn sàng như nguồn mở. Hiệu ứng khác có thể là mọi người có thể thấy nó dễ dàng hơn để 'thương mại hóa' mã của bạn bằng việc bổ sung thêm các thành phần đóng và bán các giấy phép cho các phần đóng đó.

Để chọn một giấy phép copyleft yêu đặc thù, bạn cũng phải quyết định chính xác các phần nào của mã của bạn sẽ giữ lại giấy phép của bạn và các dạng bổ sung nào có thể mang một giấy phép của việc chọn phần chỉnh sửa.

Sự phân chia này có thể xảy ra cùng một lúc ở 3 mức độ:

• Mức module mà các giấy phép copyleft yếu chỉ thị rằng phần phụ ('module') của từng chức năng của mã trong phần mềm được cân nhắc một cách tách bạch. Ở những nơi mà một module có vài mã của bạn, nó phải mang giấy phép của bạn. Ở những nơi nó không mã của bạn, thì người chủ của mã đó sẽ chọn giấy phép của riêng họ cho module đó.
• Mức tệp mà các giấy hép copyleft yếu chỉ thị rằng từng bộ của mã và dữ liệu mà là khác biệt theo hệ thống tệp của máy tính được cân nhắc một cách tách biệt. Ở những nơi một tệp có chứa một số mã của bạn, nó phải mang giấy phép của bạn. Ở những nơi nó không có, thì chủ của mã đó sẽ chọn giấy phép của riêng họ.
• Mức giao diện thử viện mà các giấy phép copyleft yếu thường được sử dụng ở những nơi mà mã của bạn là một thư viện phần mềm (một bộ sưu tầm chức năng phần mềm có khả năng được các chương trình khác sử dụng thông qua một giao diện được đồng ý). Những sửa đổi của thư viện của bạn phải mang giấy phép của bạn, nếu chúng được phân phối. Các chương trình sử dụng thư viện của bạn, và có thể được phân phối cùng với nó, không cần sử dụng giấy phép của bạn.

Ví dụ: Barry viết một mẩu mã C xem xét các website qua một kết nối mạng và tạo ra các sơ đồ tệp hình ảnh của các liên kết giữa các trang của chúng. Barry muốn phát hành mã của anh theo một giấy phép copyleft vì anh muốn bắt buộc truy cập tới mã nguồn của tất cả những sửa đổi chương trình của anh mà được phát hành. Tuy nhiên, Barry cũng muốn một sự khác biệt lớn của các dự án có khả năng sử dụng chương trình của anh - một phần vì anh tin tưởng điều này sẽ khuyến khích những sửa đổi hữu ích và những tối ưu hóa tác phẩm của anh mà anh muốn thấy. Barry quyết định đóng gói chương trình của anh như một thư viện và sử dụng giấy phép copyleft yếu GNU LGPLv2.1 mức giao diện thư viện lên nó, vì dường như với anh thì điều này thể hiện một sự cân bằng tốt giữa việc khuyến khích sử dụng lại của cả các dự án nguồn đóng và nguồn mở, trong khi vẫn chỉ thị phát hành được mã nguồn của những sửa đổi tới các phần mà anh có quan tâm - mã của riêng anh và chức năng mà nó cụ thể hóa.

Quyền tài phán

'Quyền tài phán' tham chiếu tới một vị trí hoặc lãnh thổ đặc thù và hệ thống luật của nó. Ở những nơi một giấy phép chỉ định một quyền tài phán, thì người cấp phép và (những) người được cấp phép đồng ý rằng các điều khoản trong giấy phép sẽ được hiểu theo tham chiếu tới luật của quyền tài phán đó và rằng hành động pháp lý đưa ra - ví dụ - từ sự vi phạm các điều khoản giấy phép sẽ diễn ra trong quyền tài phán đó.

Trong khi quyền tài phán là một vấn đề quan trọng, thì có thể đáng lưu ý rằng theo truyền thống thì những người chủ của PMTDNM không có xu hướng tìm kiếm những thiệt hại về tiền từ những người vi phạm các điều khoản cấp phép của họ, mà thay vào đó tìm kiếm để ép người vi phạm hoặc tuân thủ các điều khoản hoặc chấm dứt sử dụng mã của họ theo yêu cầu. Đối với các mục đích đó thường không cần thiết để dùng tới việc thực sự mang một vi phạm ra tòa, đặc biệt nếu họ có một hồ sơ công khai và uy tín để bảo vệ. Đơn giản thường yêu cầu sự tuân thủ có thể là có hiệu lực, và nếu không được, thì việc đưa ra công khai sự vi phạm có thể giúp đạt được sự tuân thủ. Không phải tất cả các giấy phép PMTDNM chỉ định một quyền tài phán. Trên thực tế hầu hết là im lặn về chủ đề này. Trong các trường hợp đó thì bất kỳ quyền tài phán nào cũng có thể được lựa chọn khi và nếu cần thiết, dù hoàn toàn có khả năng là người mà bạn đang cố mang ra tòa sẽ hoặc là phớt lờ bạn hoặc tranh cãi về sự lựa chọn vị trí của bạn nếu nó không phù hợp với họ. Cuối cùng một số giấy phép PMTDNM nói rằng quyền tài phán hoặc tùy vào người cấp phép hoặc tự động theo của người cấp phép (ở những nơi mà họ sinh sống hoặc về nguyên tắc đang làm việc).

Ví dụ: Đại học Crabapple hiểu sâu sắc để viết một chính sách về phát hành nguồn mở, như một sự cúng vốn cực kỳ lớn chỉ định điều này như một điều kiện tiên quyết. Các luật sư trong Crabapple quyết định rằng một mẩu chính của chính sách này phải là việc xức dầu của một giấy phép đặc biệt như lựa chọn được các cơ quan ưu tiên khi việc cấp phép cho phần mềm như nguồn mở. Trong cuộc gặp đầu tiên để thảo luận giấy phép nào sẽ chọn, được chỉ ra rằng chính sách đảm bảo của cơ quan không bao trùm hành động pháp lý ở nước ngoài. vì thế nó đã quyết định rằng một tính năng cơ bản của giấy phép được xức dầu phải là giấy phép nó ép tuân thủ một quyền tài phán địa phương cho bất kỳ hành động pháp lý nào gây ra từ sự phân phối phần mềm mà nó bao trùm.

Các bằng sáng chế

Liệu bạn hoặc cơ quan bạn có sở hữu bất kỳ bằng sáng chế nào không? Nếu bạn có, và bạn phát hành một số mã thể hiện chúng theo một giấy phép PMTDNM, thì bạn rất có khả năng sẽ trao các quyền sử dụng bằng sáng chế phù hợp đó (trong kết nối với mã đó) cho bất kỳ ai chọn sử dụng nó - thậm chí nếu giấy phép đó không nói rõ ràng như thế. Trong nhiều quyền tài phán, ví dụ tại Anh và Mỹ, việc cấp phép cho ai đó để tiến hành một hành động nhất định (như việc sao chép hoặc tùy biến mã của bạn) cũng có thể ngụ ý cấp phép cho họ để lấy tất cả các bước cần thiết khác để thực hiện hành động đó. Các bước ngụ ý được cấp phép đó có thể hầu hết nhất định bao gồm sử dụng bằng sáng chế phần mềm được thể hiện của bạn. Nên được lưu ý rằng mọi người mà tùy biên mã của bạn không thể mở rộng chức năng của nó để nắm lấy các bằng sáng chế phần mềm khác của bạn - bạn trao các quyền chỉ cho các bằng sáng chế được thể hiện trong mã mà bạn đã phát hành, chức không phải bất kỳ dạng mã tới sau nào có thể lấy. Một số giấy phép PMTDNM không nói gì về chủ đề trao bằng sáng chế - dù như được lưu ý điều này có thể không ngụ ý rằng họ không trao các quyền của bằng sáng chế. Một số giấy phép PMTDNM trao rõ ràng các quyền của bằng sáng chế cần thiết để sử dụng, tùy biến và phân phối phần mềm đó.

Giấy phép PMTDNM của bạn cũng có thể bao gồm những gì đôi khi được gọi là một mệnh đề 'trả đũa về bằng sáng chế'. Những phần đó của một giấy phép về cơ bản nói rằng bất kỳ ai mà mang hành động pháp lý nói rằng phần mềm được cấp phép bao gồm một trong những bằng sáng chế phần mềm của họ sẽ mất giấy phép bạn đã được trao để sao chép, sử dụng, tùy biên và phân phối mã. Một mệnh đề như vậy có ý định can ngăn mọi người khỏi việc mang dạng hành động pháp lý này vào.

Ví dụ: Giáo sư Dopaska đã tạo ra một quy trình do phần mềm thể hiện cho việc dự đoán bạo động dân sự mà đại học của ông tin tưởng có thể được trao bằng sáng chế. Giáo sư hiểu sâu sắc sẽ phát hành sự thể hiện bằng phần mềm qui trình này theo giấy phép dễ dãi Apache License, v2, khi mà ông mong muốn thấy qui trình đó được sử dụng khắp mọi nơi để cải thiện uy tín hàn lâm của ông. Nhân viên chuyển giao tri thức tại cơ quan của Giáo sư Dopaska không hiểu về ý tưởng này, khi họ muốn có được bằng sáng chế và xây dựng một công ty được xoay ra từ nó, và tin tưởng rằng phát hành nguồn mở sẽ làm xói mòn doanh thu cấp phép của sự đầu cơ này.

Sự ghi công được cải thiện

Tất cả các giấy phép PMTDNM chỉ định rằng bất kỳ ai mà phân phối hoặc tùy biến phần mềm phải ghi công các tác giả gốc ban đầu của phần mềm ở đâu đó trong phát hành của họ. Một số giấy phép PMTDNM đi xa hơn thế, và chỉ định rằng sự ghi công phải được thực hiện ở dạng đặc biệt và xuất hiện trong các sự việc đặc biệt, ví dụ trong giao diện người sử dụng của phần mềm mỗi lẫn nó được chạy. Dạng qui định này đôi khi được gọi là 'sự ghi công được cải thiện' hoặc 'badgeware'.

Ví dụ: Edward tạo ra một công cụ cho việc ảo hóa tần suất xuất hiện các từ trong tài liệu theo một cách thức lôi cuốn. Edward phỏng đoán rằng công cụ đó có thể sẽ được sử dụng rộng rãi, nhưng không đủ cơ bản cho hầu hết nghiệp vụ cốt lõi của người sử dụng để hỗ trợ một mô hình cấp phép có trả tiền. Sự thật là, những gì Edward thực sự muốn đạt được là sự công khai cho tư vấn quảng cáo mà ông quản lý và vì nó mã đã được viết. Edward quyết định phát hành công cụ của ông theo giấy phép Common Public Attribution License v1 vì giấy phép này bắt buộc hiển thị một URL, một hình đồ họa và một mệnh đề chi công mỗi lần phần mềm được chạy. Edward đưa ra URL, logo và dòng quảng cáo trên site từ vấn của ông cùng với phần mềm sao cho những người sử dụng sẽ giúp quảng cáo doanh nghiệp của ông khi họ sử dụng và sử dụng lại mã của ông.

Khe hở về tính riêng tư

Nếu ai đó sử dụng mã của bạn để tạo một dịch vụ trực tuyến hoặc một giải pháp nội bộ, có thể tùy biến và cải thiện nó, thì hầu hết các giấy phép PMTDNM không chỉ định rằng nguồn đối với phiên bản được tùy biến hoặc cải thiện phải được phát hành. Hầu hết các giấy phép PMTDNM làm nó thành một điều kiện phân phối rằng mã nguồn sẽ được phân phối lại. Nói chung việc không làm cho các dịch vụ sẵn sàng qua một mạng, cả việc không sử dụng mã, việc không triển khai mã trong một cơ quan duy nhất được xác định như là sự phân phối bên trong các giấy phép đó.

Mọt số người trong cộng đồng PMTDNM cảm thấy rằng hiện tượng này, đôi khi được gọi là 'khe hở của nhà cung cấp dịch vụ ứng dụng – ASP' hoặc 'khe hở về tính riêng tư' cần phải được chỉnh sửa. Lý lẽ của họ là tính công bằng chỉ thị rằng tất cả những người hưởng lợi từ mã phải đóng góp tác phẩm của họ ngược về cho thế giới, thậm chí nếu họ không, nói nghiêm túc, phân phối mã. Để giải quyết vấn đề này, một số giấy phép PMTDNM thực hiện phát hành mã nguồn với điều kiện không chỉ cho phát tán mà còn cho triển khai nội bộ và/hoặc tiến hành các dịch vụ có sẵn qua mạng bằng việc sử dụng phần mềm. Các dạng điều kiện đó vì thế đặc biệt phù hợp cho mã mà có khả năng sẽ được sử dụng trong nội bộ hoặc như một cơ sở cho một dịch vụ mạng.

Ví dụ: Fareeda muốn xây dựng một doanh nghiệ cung cấp một các dễ dàng cho những người sử dụng để xây dựng các video âm nhạc trình bày các slide phức tạp từ các ảnh của họ trên các site mạng xã hội. Bà thấy một mẩu phần mềm nguồn mở theo giấy phép GNU Affero GPL v3, nó đưa ra một cách thuận tiện để điều hành yêu cầu mà site của bà phải giao tiếp với nhiều site bên ngoài khác. Nhìn vào giấy phép đó, Fareeda phát hiện rằng các điều khoản của nó bắt buộc rằng - nếu bà sửa đổi mã mà nó bao trùm và sử dụng nó như là cơ sở của một dịch vụ được cung cấp qua một mạng như bà có ý định - thì bà cũng phải làm cho mã nguồn đối với những sửa đổi của bà sẵn sàng cho những người sử dụng dịch vụ. Fareeda bây giờ phải quyết định liệu mô hình kinh doanh của bà sẽ có bị ảnh hưởng, được trợ giúp hay bị xói mòn vì trách nhiệm pháp lý tiềm tàng này hay không.

Không quảng cáo

Một số giấy phép PMTDNM rõ ràng cấm sử dụng các tên tác giả để quảng cáo một sản phẩm hoặc dịch vụ dựa vào mã của các tác giả đó.

Ví dụ: Như một phần của một dự án nhà nước cấp vốn, Đại học Gerhentz tạo mã tự động tùy biến các giao diện người sử dụng theo các kích cỡ hiển thị tùy ý. Đại học hiểu rõ rằng việc cấp vốn nhà nước dẫn tới lợi ích tối đã của nhà nước trong cả các phần mềm nguồn đóng và mở, và vì thế muốn phát hành mã theo một giấy phép nguồn mở dễ dãi. Tuy nhiên Gerhentz không muốn được xem là đang chứng thực cho các sản phẩm có chứa mã của họ, vì họ cảm thấy rằng điều này có thể tiềm tàng làm hại cho uy tín của đại học. Vì thế được quyết định rằng giấy phép BSD License sẽ đưa ra cả khả năng sử dụng lại rộng rãi và khóa trong sử dụng quảng cáo mà họ tìm kiếm.

Kết luận

Tài liệu này đã trình bày một số khác biệt giữa các giấy phép PMTDNM khác nhau, để giúp bạn xem xét dạng giấy phép nào bạn có thể muốn áp dụng cho mã của riêng bạn. Các ví dụ được cung cấp để bổ sung thêm dạng những cân nhắc có thể đặc trưng trong qui trình lựa chọn của riêng bạn. Tuy nhiên, bạn nên lưu ý, rằng không có một giấy phép nào có thể cho mọi sự kết hợp các tính năng, và vì thế có lẽ là cần thiết phải thỏa hiệp về một hoặc vài chủng loại các tính năng để thực sự chọn một giấy phép đang tồn tại sẵn trước rồi. Để đạt được điều này, có thể là hữu dụng để xếp hạng các tính năng mà bạn mong muốn theo trật tự về tầm quant trọng. OSS Watch có thể giúp bạn chọn một giấy phép phù hợp nhất cho các đặc tính mong muốn nhất của bạn - hãy liên hệ.

There are many free and open source software licences, and while they all broadly attempt to facilitate the same things, they also have some differences. Some of the major differences can be grouped together into categories, and this document acts as an introduction to these categories. Having read this document, you should be able to understand which decisions you should take in order to select a licence for your code.

Staying mainstream

The Open Source Initiative - a non-profit organisation formed to educate about open source - maintains a list of licences that they see as being ‘popular and widely used or with strong communities’. The purpose of the list is to highlight those licences which are likely to answer the needs of many licensors new to open source. The list also helps to make the task of open source licence selection seem manageable; the full list of more than 60 licences can be daunting, and contains many licences which are in most ways similar in function to one or more of the ‘popular and widely used’ listed licences.

Using a licence that many others use has some advantages. If the terms of the licence are challenged, there will be a larger pool of licensors with an interest in funding a response to the challenge. Using one of the ‘popular and widely used’ licences also makes it more likely that your licensees will already be familiar with the terms you are offering. Equally though, licensors should not feel ‘locked in’ to only using a ‘popular and widely used’ licence. Some of the features we discuss below are only present in the wider pool of all OSI-approved licences.

Permissive and copyleft

All free and open source licences allow others to make modified versions of your code, and to make these modified versions available to others. The licence you choose can make conditions about how this happens - specifically what licences can be used on these modified versions. These conditions can help keep your code free, but they can also put some people off reusing your code. Such conditions are sometimes called ‘copyleft’ conditions, in a play on the word ‘copyright’.

Open source licences that do not seek to control how modified code is licensed are often referred to as ‘permissive’ licences. While the original code covered by a permissive licence stays under that permissive licence, any modifications to it can be released under any licence that the modifier chooses, open source or not. This means that permissively licensed code can form the basis of closed source products. Some argue that this makes permissive licences more ‘free’ than copyleft licences, in that people who modify the code are freer to choose what they do with it. Others argue that the lack of a requirement that modifications be open source means that permissive licences are less ‘free’. As discussions of ideas of freedom - and particularly the idea of compulsion to be free - are essentially philosophical they fall outside the scope of this document. It is worth noting, however, that there are differing views within the free and open source world about what ‘free’ in the sense of freedom really means.

Example: As part of her astrophysics research Anne creates a standard for recording a specific kind of complex data object. She also writes code to create and parse files that adhere to the standard. Anne is keen that the standard becomes widely used, as minority standards are far less useful. Therefore she decides that she will release the code under a permissive licence. Anne believes that by allowing creators of both closed and open source projects to use the same code to create and read the data objects, uptake and efficacy of the standard will both be helped along.

Strong and weak copyleft

Should you choose to include copyleft licensing conditions on reuse of your code, there is a further choice to be made. Copyleft licences are broadly divided into two ‘strengths’: strong and weak. Strong copyleft conditions dictate that when a piece of software contains some of your code, the software as a whole must be distributed under your licence, if it is distributed at all. The effect of this will be that the source code to all additions made to the code will be available.

Weak copyleft, on the other hand, means that when software contains some of your code, some parts of the software must be distributed under your licence, if the software is distributed at all. Other parts may be distributed under other licences, even though they form part of a work which is - as a whole - a modified version of your code. One effect of this will be that the source code to some additions made by others to your software may not be available as open source. Another effect may be that people may find it easier to ‘productise’ your code by adding closed components and selling licences to these closed parts.

To choose a specific weak copyleft licence, you must also decide precisely which parts of your code will retain your licence and what kinds of additions can bear a licence of the modifier’s choosing. This division can happen at one of three levels:

• Module level weak copyleft licences dictate that each functional sub-section (‘module’) of code within the software is considered separately. Where a module contains some of your code, it must bear your licence. Where it does not, the owner of that code gets to choose their own licence for that module.
• File level weak copyleft licences dictate that each collection of code and data that is distinct according to the computer’s file system is considered separately. Where a file contains some of your code, it must bear your licence. Where it does not, the owner of that code gets to choose their own licence.
• Library interface level weak copyleft licences are generally used where your code is a software library (a collection of software functionality which is usable by other programs via an agreed interface). Modifications of your library must bear your licence, if they are distributed. Programs that use your library, and are perhaps distributed alongside it, need not use your licence.

Example: Barry writes a piece of C code that examines websites over a network connection and generates image file diagrams of the links between their pages. Barry wants to release his code under a copyleft licence because he wants to mandate access to the source code of all modifications of his program that are released. However, Barry also wants a wide variety of projects to be able to use his program - partly because he believes this will encourage the useful modifications and optimisations of his work that he wants to see. Barry decides to package his program as a library and use the library interface level weak copyleft licence the GNU LGPLv2.1 on it, as it seems to him that this represents a good balance between encouraging reuse by both closed and open source projects while mandating the release of source of modifications to the parts he is interested in - his own code and the functionality it embodies.

Jurisdiction

A ‘jurisdiction’ refers to a specific location or territory and its system of law. Where a licence specifies a jurisdiction, the licensor and the licensee(s) agree that the terms in the licence are to be understood in reference to that jurisdiction’s law and that legal action resulting - for example - from breach of the licence’s terms will take place in that jurisdiction.

While jurisdiction is an important issue, it may be worth noting that traditionally free and open source software owners do not tend to seek monetary damages from those who infringe their licensing terms, but seek instead to compel the infringer to either abide by the terms or terminate their use of the code in question. For these purposes it is often unnecessary to resort to actually taking an infringer to court, particularly if they have a public profile and reputation to protect. Often simply requesting compliance can be effective, and if that fails, publicising the infringement can help achieve compliance. Not all free and open source software licences specify a jurisdiction. In fact most are silent on the subject. In these cases any jurisdiction can be selected when and if necessary, although it is quite possible that the person you are trying to take to court will either ignore you or dispute your choice of location if it does not suit them. Finally some free and open source software licences state that the jurisdiction is either up to the licensor or automatically that of the licensor (where they reside or principally do business).

Example: Crabapple University is keen to write a policy on open source release, as an extremely large endowment specifies this as a pre-condition. Lawyers within Crabapple decide that a key piece of this policy must be the anointing of a specific licence as the institution’s preferred option when licensing out software as open source. At the first meeting to discuss which licence to choose, it is pointed out that the institutional insurance policy does not cover legal action abroad. It is therefore decided that an essential feature of the anointed licence must be that it enforces a local jurisdiction for any legal action resulting from the release of software it covers.

Patents

Do you or your institution own any software patents? If you do, and you release some code that embodies them under a free or open source software licence, then you are very likely to be granting rights to use the relevant patent (in connection with that code) to anyone who chooses to use it - even if the licence does not explicitly say so. In many jurisdictions, for example the UK and the US, licensing someone to take a particular action (like copying or adapting your code) can also impliedly license them to take all other steps necessary to take that action. These impliedly licensed steps would almost certainly include use of your embodied software patent. It should be noted that people who adapt your code cannot expand its functionality to capture other software patents of yours - you grant rights only to the patents embodied in the code you released, not any subsequent form the code may take. Some free and open source software licences say nothing on the subject of patent grants - although as noted this may not mean that they grant no patent rights. Some free and open source software licences explicitly grant patent rights necessary to use, adapt and distribute the software.

Your free or open source software licence can also include what is sometimes called a ‘patent retaliation’ clause. These sections of a licence essentially say that anyone who brings legal action alleging that the licensed software embodies one of their software patents will lose the licence you have granted to copy, use, adapt and distribute the code. Such a clause is intended to dissuade people from bringing this kind of legal action.

Example: Professor Dopaska has created a software-embodied process for predicting civil unrest that his university believes is patentable. The professor is keen to release the software embodiment of this process under the permissive Apache License, v2, as he wishes to see the process used ubiquitously to enhance his academic reputation. Knowledge transfer staff at Professor Dopaska’s institution are not keen on this idea, as they wish to obtain the patent and build a spin-out company around it, and believe that the open source release will undermine the licensing income of this venture.

Enhanced attribution

All free or open source software licences specify that anyone who distributes or adapts the software must give credit to the original authors of the software somewhere in their distribution. Some free or open source software licences go further than this, and specify that the credit must take a particular form and appear in specific instances, for example on the software’s user interface every time it is run. This kind of stipulation is sometimes called ‘enhanced attribution’ or ‘badgeware’.

Example: Edward creates a tool for visualising the frequency of occurences of words in documents in an attractive way. Edward surmises that the tool will probably be used widely, but is not essential enough to most users’ core business to support a paid licensing model. In truth, what Edward really wants to achieve is publicity for the promotional consultancy he runs and for which the code was written. Edward decides to release his tool under the Common Public Attribution License v1 as this mandates the display of a URL, a graphic and an attribution phrase every time the software is run. Edward provides his consultancy site’s URL, logo and strapline along with the software so that users will help promote his business when they use and reuse his code.

The privacy loophole

If someone uses your code to create an online service or an in-house solution, perhaps adapting and improving it, most free and open source software licences do not specify that the source to the adapted or improved version must be released. Most free and open source software licences make it a condition of distribution that source code be released. In general neither making services available over a network, nor using the code, nor deploying the code within a single institution is defined as distribution within these licences.

Some within the free and open source software community feel that this phenomenon, sometimes called the ‘ASP (application service provider) loophole’ or ‘privacy loophole’ needs to be fixed. Their argument is that fairness dictates that all those who benefit from the code must contribute their work back to the world, even if they are not, strictly speaking, distributing the code.To address this issue, some free or open source software licences make release of the source code a condition not only for distribution but also for internal deployment and/or making services available over a network using the software. These kinds of conditions are therefore particularly suited to code which is likely to be used in-house or as a basis for a networked service.

Example: Fareeda wants to build a business providing an easy way for users to build complex slide show music videos from their photographs on social networking sites. She finds a piece of open source software under the GNU Affero GPL v3 which provides a convenient way to handle the requirement that her site must interface with many external sites. Looking into the licence, Fareeda discovers that its terms mandate that - if she modifies the code it covers and uses it as the basis of a service provided over a network as she intends - she must also make the source code to her modifications available to service users. Fareeda must now decide if her business model will be unaffected, aided or undermined by this potential responsibility.

No promotion

Some free and open source software licences explicitly forbid the use of the authors’ names to promote a product or service based upon the authors’ code.

Example: As part of a publicly-funded project Gerhentz University creates code which automatically adapts user interfaces to arbitrary display sizes. The institution is keen that the public funding leads to the maximum public benefit both in open and closed source software, and so wishes to release the code under a permissive open source licence. However Gerhentz does not wish to be seen to be endorsing products that contain their code, as they feel that this may potentially damage the institution’s reputation. Therefore it is decided that the BSD License will provide both the wide reusability and block on promotional use that they seek.

Conclusion

This document has presented some of the key differences between the various free and open source licences, in order to help you consider what kind of licence you might want to apply to your own code. Examples are provided to flesh out the kind of considerations that might feature in your own selection process. You should note, however, that there is not a licence for every possible combination of features, and so it may well be necessary to compromise on one or more category of features in order to actually choose a pre-existent licence. To achieve this it can be helpful to rate the features you desire in order of importance. OSS Watch can help you choose a licence which best fits your most desired characteristics - just get in touch.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com