Phát triển nguồn mở - giới thiệu các vấn đề về quyền sở hữu và cấp phép

Open source development - an introduction to ownership and licensing issues

By Rowan Wilson, Published: 01 February 2005, Reviewed: 16 April 2012

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

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

Lời người dịch: Một bài viết hết sức cô đọng về các vấn đề quyền sở hữu và cấp phép trong phần mềm, đặc biệt là phần mềm tự do nguồn mở (PMTDNM) mà bất kỳ ai có liên quan đều nên đọc để tuân thủ các điều khoản và điều kiện của giấy phép và các vấn đề liên quan khác. Bài viết nhắc nhở tất cả chúng ta rằng: PMTDNM có bản quyền, tuân thủ luật bản quyền chứ không phải những tuyên truyền ngược dạng FUD của những người ác tâm, ác ý và/hoặc kém hiểu biết về nó.

Phần mềm, bản quyền và việc cấp phép

Khi bạn viết phần mềm, bạn đang tạo ra một dạng tài sản. Mặc định, tài sản này sẽ được ai đó làm chủ sở hữu. Nếu bạn là một nhân viên, có khả năng rằng ông chủ của bạn sẽ sở hữu phần mềm mà bạn tạo ra trong quá trình lao động làm thuê của bạn. Nếu bạn đang làm việc cho bản thân bạn, hoặc làm việc trong thời gian nhàn rỗi không cố liên quan tới công việc của bạn, thì có khả năng là bạn sẽ sở hữu nó. Nếu bạn là người tự làm [không làm thuê cho ai] và phát triển phần mềm như một dịch vụ theo một thỏa thuận hợp đồng, thì hợp đồng đó phải xác định ai là chủ sở hữu trí tuệ của các kết quả đó. Nếu hợp đồng không xác định ai sẽ làm chủ của tài sản, thì nhiều khả năng là không phải nhà thầu mà đã viết nó sẽ sở hữu nó. Nếu bạn đang làm việc như một phần của một nhóm, khi có nhiều ông chủ, các nhà thầu và/hoặc các cá nhân, hoặc một số bên có trụ sở bên ngoài nước Anh, thì quyền sở hữu của tài sản kết quả có thể là phức tạp. Có thể là tất cả những người đóng góp cùng chung làm chủ tất cả các tài sản đó, hoặc là tài sản đó được chia thành các phần mà được những người hoặc tổ chức khác nhau làm chủ. Lý tưởng mà nói, một thỏa thuận chi tiết hóa ai sẽ làm chủ những gì nên được làm trước khi công việc được bắt đầu.

Để an toàn, nguười ta sẽ luôn phải chắc chắn rằng các thỏa thuận hoặc hợp đồng chỉ định ai sẽ là chủ sở hữu trí tuệ các kết quả từ sự cộng tác, nhóm hoặc công việc của hợp đồng.

Phần mềm máy tính được bảo vệ theo luật bản quyền. Luật bản quyền trao cho người chủ các quyền nhất định của một tác phẩm đối với tác phẩm đó, và làm cho nó bất hợp pháp đối với những người khác để sử dụng tác phẩm đó dù họ từng là người chủ của nó. Ban đầu bản quyền tới là để đảm bảo rằng các tác giả thực thụ đó được thưởng công xứng đáng cho tác phẩm của họ. Các khái niệm của nó có nguồn gốc trong sự bảo vệ các tác phẩm được viết, và nó có thể là hữu dụng để nhớ rằng phần mềm máy tính và các tư liệu có liên quan của nó được đối xử theo luật như những mẩu của tác phẩm văn học.

Việc làm chủ bản quyền trong một mẩu tác phẩm, hoặc văn học hoặc chương trình [máy tính], có nghĩa là bạn quyết định ai có thể sao chép nó, tùy biến nó và phân phối nó. Mặc định, chỉ người chủ có thể làm những điều đó. Bất kỳ ai mà sao chép, thay đổi hoặc phân phối cho ai đó khác tác phẩm mà không có sự cho phép có thể có những hành động pháp lý được thực hiện để chống lại họ.

Bản quyền tới ngay khi tác phẩm được cố định - nghĩa là ngay khi nó được ghi nhận theo một số cách thức. Không cần phải đăng ký tác phẩm của bạn để có được bản quyền; nó xảy ra một cách tự động. Cũng không có yêu cầu để đánh dấu tác phẩm của bạn như là được cấp bản quyền với ký hiệu ©, dù bạn nên, khi mà điều này nhấn mạnh điều cho là đúng theo pháp lý quyền là chủ của bạn đối với nó.

Việc viết phần mềm có thể tạo ra một mẩu của vật sở hữu. Ví dụ, mã nguồn của chương trình là vật sở hữu, vì có thể là tư liệu thiết kế chuẩn bị cho nó, tổ chức của nó và giao diện người sử dụng của nó. Các hệ lụy của thực tế này đáng ghi nhớ trong đầu.

Khai thác

Nếu một người chủ bản quyền muốn kiếm tiền từ tác phẩm của họ, họ có thể bán hoàn toàn các quyền cho nó (được biết như là “chỉ định bản quyền”). Như với tài sản vật lý, việc chỉ định bản quyền có liên quan tới việc trao hoàn toàn quyền sở hữu của tác phẩm cho một người mua hoặc người được chỉ định.

Tiếp cận khác đối với việc khai thác một tác phẩm bản quyền là cấp phép cho nó. Một giấy phép là một sự cho phép được trao từ người chủ bản quyền cho tới một người khác (được biết như là người được cấp phép). Người chủ bản quyền đồng ý cho phép người được cấp phép tiến hành các hành động mà có thể nếu không sẽ bị luật cấm, như việc sao chép, tùy biến và/hoặc phân phối tác phẩm đó. Người được cấp phép sẽ đồng ý thực hiện các hành động đó trong khuôn khổ được giấy phép thiết lập - có thể chỉ là việc tạo ra và phân phối một số lượng các bản sao nhất định, hoặc việc trả tiền phí bản quyền trong từng bản sao được phân phối. Dù một giấy phép có thể được tạo ra mà không có việc hình thành của một hợp đồng, hầu hết các giấy phép được trao ở một dạng pháp lý trong đó cả 2 bên thực hiện các nghĩa vụ nhất định trong sự tôn trọng lẫn nhau và tác phẩm có bản quyền được cấp phép; điều này được biết tới như là một “thỏa thuận giấy phép”.

Các thỏa thuận giấy phép là những tài liệu pháp lý kỹ thuật mà có nhiều qui tắc pháp lý mô tả và hạn chế nội dung và cách thức thể hiện. Vì thế đáng lưu ý rằng liệu có khi nào đó một sự không đồng thuận về việc liệu có hay không một sự vi phạm thỏa thuận đó, trong phân tích cuối cùng luật sẽ xác định kết quả đầu ra đó. Một giấy phép được phác thảo tồi có thể, khi được một tòa án phân tích, được thấy có nghĩa như thứ gì đó hoàn toàn khác với những gì cả người chủ bản quyền và người được cấp phép mong đợi.

Cấp phép nguồn mở là gì?

Nguồn mở mô tả một nhóm các giấy phép mà tất cả đáp ứng được tập các điều kiện nhất định. Các điều kiện được một nhóm gọi là Sáng kiến Nguồn Mở duy trì, và cùng với đó chúng được tham chiếu tới như là Định nghĩa Nguồn Mở - OSD (Open Source Definition). Chúng ta sẽ rà soát lại ngắn gọn chúng ở đây.

Một giấy phép nguồn mở phải:

• trao cho giấy phép quyền để phân phối chương trình cho bản thân họ, bao gồm các quyền lấy tiền đối với nó

• trao sự truy cập tới mã nguồn của chương trình

• trao quyền để sửa đổi chương trình

• trao quyền để phân phối các phiên bản sửa đổi của chương trình

• cho phép sử dụng chương trình cho tất cả những người hoặc nhóm trong tất cả các lĩnh vực nghề nghiệp

• áp dụng cho bất kỳ ai mà nhận chương trình, mà không cần bất kỳ thỏa thuận bổ sung nào

• áp dụng cho chương trình mà nó cấp phép, bất kể chương trình đó có được như một phần của một nhóm chương trình, hoặc của bản thân nó

• cho phép phân phối với bất kỳ phần mềm nào khác

• cho phép phân phối ở bất kỳ dạng nào

Hiệu ứng mong muốn của các điều kiện đó là để thúc đẩy sự phân phối phần mềm một cách rộng rãi, và để khuyến khích mọi người mà nhận phần mềm đóng góp vào cho chức năng của nó bằng việc sửa đổi mã nguồn. Dù nó có thể xem việc trao các quyền đó có thể dẫn tới một số lượng lớn các phiên bản biến thể một chút của mẩu phần mềm, trong thực tế các dự án PMTDNM thành công có xu hướng hấp thụ những sửa đổi phân tán được nhiều người đóng góp ngược vào một phiên bản duy nhất được sửa đổi và được cải tiến.

Đáng lưu ý phần thứ 2 của điểm liệt kê đầu tiên ở trên. Đây là một sự hiểu nhầm phổ biến rằng người ta không thể lấy tiền cho việc phân phối phần mềm nguồn mở. Điều này không phải thế. Trong thực tế, nó hiếm khi được thực hiện, chủ yếu là vì mỗi khách hàng của bản đều có thể biếu phần mềm trong sự cạnh tranh trực tiếp cho việc bán hàng của riêng bạn.

Quyền sở hữu phức tạp

Khi một mẩu PMNM được phát triển, thường với nhiều người và nhóm khác nhau, quyền sở hữu trở thành ngày càng phức tạp. Vấn đề có liên quan tới sự cộng tác và quyền sở hữu được xác định ở trên áp dụng ngang bằng cho những cộng tác không có kế hoạch qua một giai đoạn thời gian. Có thể tưởng tượng được cho từng người đóng góp để làm chủ bản quyền đối với đóng góp của họ. Trong khi trong thực tế hầu hết những người đóng góp sẽ có thiện chí đồng ý cấp phép tư liệu của họ theo cùng giấy phép như của tác phẩm gốc ban đầu, nghĩa là qui trình thực hiện và cải tiến có thể tiếp tục, thì nó có thể là phức tạp để xác định ai sẽ thực hiện một sự khiếu nại pháp lý nếu ai đó quyết định sử dụng chương trình đó theo một cách thức vi phạm giấy phép của nó. Để tránh vấn đề này, một số dự án nguồn mở yêu cầu những người đóng góp chỉ định rõ ràng bản quyền trong những đóng góp của họ cho một tổ chức điều hành dự án đó, vì thế giữ cho quyền sở hữu được tập trung và làm cho sự ép tuân thủ của giấy phép đó dễ dàng hơn. Một tiếp cận lựa chọn là để những người đóng goáp cấp phép những đóng góp của họ cho tổ chức điều hành dự án theo một thỏa thuận giấy phép mà cho phép tổ chức đó cấp phép lại sự đóng góp đó.

Hợp đồng và bản quyền

Thường được thấy rằng các giấy phép như những giấy phép trong định nghĩa nguồn mở OSD là có vấn đề vì không không có hành động công khai chấp nhận của những người được cấp phép mà đưa chúng lên. Những thỏa thuận giấy phép của người sử dụng đầu cuối được phân phối với phần mềm sở hữu độc quyền (PMSHĐQ) thường đòi hỏi một người sử dụng phải nháy vào một núm để chấp nhận các điều kiện, và thực tế này dẫn tới nhiều người tin tưởng rằng các giấy phép nguồn mở đòi hỏi thứ gì đó ràng buộc tương tự. Điều này là không đúng.

Các thỏa thuận giấy phép sở hữu độc quyền của người sử dụng đầu cuối là các hợp đồng để điều hành nhiều khía cạnh của mối quan hệ giữa công ty và người sử dụng. Nếu người sử dụng vi phạm, họ đã vi phạm hợp đồng của họ, và công ty phần mềm có thể chọn sử dụng luật hợp đồng để trừng phạt họ. Nhưng điều này có thể là khó, đặc biệt khi luật hợp đồng khác nhau từ nước này tới nước khác. Việc có được sự đồng ý công khai từ những người sử dụng bằng việc làm cho họ nháy núm 'Tôi chấp nhận' giúp làm cho qui trình tố tụng là không cần thiết, khi một người sử dụng có trách nhiệm tự họ làm quen với các điều khoản của bất kỳ giấy phép nào hay hợp đồng nào có liên quan tới phần mềm mà họ sử dụng - tuy nhiên, các hãng PMSHĐQ có xu hướng bỏ ngoài tai lời quở trách và bắt nhấn núm 'Tôi chấp nhận'.

Dù chúng không được xem là các hợp đồng, thì các giấy phép nguồn mở được phác thảo phù hợp có ràng buộc về pháp lý và hành động ép tuân thủ có thể được thực hiện chống lại những người vi phạm chúng. Điều này có thể theo luật hợp đồng hoặc bản quyền, phụ thuộc vào cách mà giấy phép đó được lên khung. Không ai được ép buộc phải chấp nhận rõ ràng giấy phép đó, nhưng sự chấp nhận hoàn toàn các điều kiện giấy phép đó là con đường duy nhất để sử dụng hợp phpas theo luật bản quyền.

Vượt ra khỏi Định nghĩa Nguồn Mở

Website Sáng kiến Nguồn Mở hiện liệt kê hơn 50 giấy phép đáp ứng các điều kiện được mô tả trong phần 3. Không là trong phạm vi của tài liệu này để xem xét tất cả chúng. Tuy nhiên, đáng chú ý, là hầu hết giấy phép nguồn mở được sử dụng rộng rãi – GPL (GNU General Public License) - áp đặt một điều kiện chủ chốt hơn lên những người sao chép, tùy biến hoặc phaanp hối phần mềm theo giấy phép này. Tất cả các phần mềm được tạo ra bằng việc sửa đổi phần mềm gốc ban đầu cũng phải được cấp phép theo GPL (nếu nó được phân phối). Mục tiêu của điều kiện này là để sản sinh ra một phần thân của PMNM sẽ phát triển khi những người sử dụng đóng góp, và rằng không thể bị co lại vì những người sử dụng bổ sung thêm nỗ lực của riêng họ vào một mẩu phần mềm và sau đó cấp phép lại kết quả đó theo những điều khoản hạn chế hơn so với các điều khoản của GPL. Vì điều kiện này có thể được xem như một ý định để lật đổ sử dụng bản quyền sở hữu độc quyền, đôi khi nó còn được biết tới như là copyleft.

Đáng lưu ý rằng không có bổn phận để phát hành những thay đổi mà bạn làm, hoặc theo GPL hoặc theo bất kỳ giấy phép nguồn mở nào; bạn có thể giữ các phiên bản nội bộ của phần mềm GPL mà bạn đã sửa đổi mà không cần cấp phép cho chúng cho bất kỳ ai khác. Điều này áp dụng ngang nhau cho các cá nhân và các thực thể pháp lý như các công ty và các cơ quan.

Tính tương thích của giấy phép

Thật quyến rũ để tin tưởng rằng tất cả mã nguồn sẵn sàng theo một giấy phép nguồn mở có thể được cập nhật và được kết hợp mà không có hạn chế nào để tạo ra PMNM mới. Không may điều này không phải như vậy. 2 giấy phép cùng đáp ứng được các yêu cầu của Định nghĩa Nguồn Mở một cách riêng rẽ có thể không có các điều khoản làm cho chúng không tương thích với nhau. GNU GPL (tất cả các phiên bản) đưa ra một ví dụ của điều này: nó bắt buộc rằng mã nguồn kết hợp mã được cấp phép GPL bản thân nó phải được cấp phép theo GPL như một tổng thể nếu nó được phân phối. Nó cũng bắt buộc rằng không có sự hạn chế bổ sung nào về các quyền nó trao cho thể được áp đặt lên mã được cấp phép GPL. 2 điều kiện đó kết hợp để ngụ ý rằng mã được cấp phép GPL chỉ có thể được trộn dễ dàng với các mã được cấp phép GPL khác, hoặc với mã mà giấy phép của nó áp đặt chỉ những điều kiện thể hiện trong GPL. Rõ ràng không phải là nhiệm vụ dễ dàng để thiết lập liệu một điều kiện trong một giấy phép có tương đương chính xác về điều kiện được nêu khác nhau trong giấy phép khác hay không. Quỹ Phần mềm Tự do (FSF), người quản trị GPL, làm cho sẵn sàng một danh sách các giấy phép mà họ xem là tương thích với GPL.

Vấn đề về tính tương thích của giấy phép là một vấn đề phức tạp, và việc xác định liệu 2 giấy phép có tương thích hay không sẽ đòi hỏi sự giúp đỡ của một luật sư trong tất cả hầu hết các trường hợp. Các lập trình viên làm việc trong một mẩu phần mềm mà được phân phối theo một giấy phép (bất kể nguồn mở hay gì khác) cần phải nhận thức được về các khó khăn tiềm tàng trong lĩnh vực này trước khi định trộn trong mã nguồn mở. Thường thì cách đơn giản nhất để giải quyết những xung đột về giấy phép là yêu cầu (những) người chủ mã liệu họ có thiện chí phát hành mã của họ cho sự bao gồm hay không. Tuy nhiên, tiếp cận này chỉ thực sự thực tế ở những nơi mà số những người chủ là nhỏ.

Theo dõi sở hữu trí tuệ

Các vấn đề về tính tương thích của giấy phép và nhiều quyền sở hữu phức tạp của sở hữu trí tuệ có ngụ ý rằng là mong muốn, nếu không nói là cơ bản, đối với các lập trình viên và các nhà quản lý của họ giữ cho các hồ sơ được chi tiết. Các hệ thống kiểm soát phiên bản đưa ra một số việc lưu giữ hồ sơ này một cách tự động, ghi lại hồ sơ ai đã thực hiện những thay đổi cho mã và họ đã làm gì. Để bổ sung cho thông tin này, các nhà quản lý nên giữ các hồ sơ tình trạng hợp đồng và cấp phép của những người đóng góp để thiết lập ai là chủ công việc của họ. Họ cũng nên yêu cầu và lưu giữ các thỏa thuận rõ ràng từ người chủ bản quyền mà những đóng góp của họ có thể được cấp phép và được phân phối theo giấy phép được lựa chọn cho dự án như một tổng thể. Ở những nơi mã được mang vào từ PMNM đang tồn tại, thì các chi tiết của giấy phép phù hợp phải được ghi nhận (đã thiết lập trước rằng giấy phép này là tương thích với chính sách cấp phép của toàn bộ dự án).

Tóm tắt

Để tóm tắt ngắn gọn các điểm được thực hiện trong tài liệu này:

• Phần mềm là sở hữu trí tuệ.

• Phần mềm được bảo vệ theo luật bản quyền.

• Quyền sở hữu của phần mềm có thể được xác định bằng một sự xem xét pháp lý kỹ thuật của bất kỳ hợp đồng nào theo đó nó đã được sản xuất ra, và bất kỳ hoàn cảnh pháp lý nào khác phù hợp.

• Luật bản quyền nói rằng mặc định chỉ người chủ của phần mềm có thể sao chép, tùy biến hoặc phân phối nó.

• Người chủ của phần mềm có thể đồng ý cho phép người khác sao chép, tùy biến hoặc phân mã - thỏa thuận này được gọi là một giấy phép.

• Các giấy phép nguồn mở trao các quyền đó cho bất kỳ ai mà chọn để đưa chúng lên, với những điều kiện nhất định.

• Các giấy phép nguồn mở nhằm để tạo một cộng đồng những người đóng góp mà họ sẽ sửa lỗi và phát triển phần mềm đó.

• Việc kết hợp 2 mẩu mã phần mềm theo các giấy phép khác nhau có thể là phức tạp.

• Tất cả các dự án mà sản xuất ra phần mềm cần phải giữ các hồ sơ hoàn chỉnh, chi tiết về việc cấp phép và quyền sở hữu của những người đóng góp cho phần mềm đó.

Software, copyright and licensing

When you write software, you are creating a kind of property. By default, this property will be owned by somebody. If you are an employee, it is likely that your employer will own the software you cre-ate in the course of your employment. If you are working for yourself, or working in your free time on matters unrelated to your work, then it is likely that you will own it. If you are self-employed and developing software as a service under a contract agreement, then the contract ought to define who owns the intellectual property that results. If the contract does not define who will own the property, it is more likely than not that the contractor who wrote it will own it. If you are working as part of a group, whe-re there are multiple employers, contractors and/or individuals, or some parties are based outside the UK, then the ownership of the resulting property can be complex. It may be that all contributors jointly own all of the property, or that the property is divided into sections that are owned by different people or organisations. Ideally, an agreement detailing who will own what should be made before the work is begun.

In order to be safe, one should always make sure that agreements or contracts specify who will own the intellectual property that results f-rom any collaboration, consortium or contract work.

Computer software is protected by copyright law. Copyright law gives the owner of a work certain rights over it, and makes it illegal for others to use the work as though they were its owner. Copyright originally came into being to ensure that literary authors were properly remunerated for their work. Its concepts originate in the protection of written works, and it can be helpful to remember that computer software and its associated materials are treated by the law as species of literary work.

Owning the copyright in a piece of work, whether literary or programmatic, means that you decide who can copy it, adapt it and distribute it. By default, only the owner can do these things. Anyone who copies, changes or distributes someone else’s work without permission can have legal action taken against them.

Copyright comes into being as soon as a work is fixed — meaning as soon as it is recorded in some way. There is no need to register your work in order to gain copyright; it happens automatically. There is also no requirement to mark your work as copyrighted with a © symbol, although you should, as this emphasises the legal presumption of your ownership of it.

Writing software may well result in more than one piece of property. For example, program’s source code is property, as can be the preparatory design material for it, its general organisation and its user interface. The consequences of this fact are worth bearing in mind.

Exploitation

If a copyright owner wants to make money f-rom their work, they can sell the rights to it outright (known as “assignment of copyright”). As with physical property, assigning the copyright involves handing over complete ownership of the work to a buyer or assignee.

Another approach to exploiting a copyright work is to license it. A licence is a permission given by the copyright owner to another person (known as the licensee). The copyright owner agrees to permit the licensee to take actions that would otherwise be prohibited by law, such as copying, adapting and/or distributing the work. The licensee will agree to take these actions within the boundaries set by the licence — perhaps only creating and distributing a certain number of copies, or paying a royalty on each copy distributed. Although a licence can be cre-ated without the forming of a contract, most licences are granted in a legal form whe-re both parties undertake certain obligations in respect of each other and the licensed copyright work; this is known as a “licence agreement”.

Licence agreements are technical legal documents that have many legal rules describing and confining their content and manner of expression. It is therefore worth noting that should there ever be a disagreement over whether or not there has been a breach of the agreement, in the final analysis the law will determine the outcome. A poorly drafted licence may, when construed by a court, be found to mean something quite different f-rom what both the copyright owner and the licensee intended.

What is open source licensing?

Open source describes a group of licences that all meet a certain set of conditions. The conditions are maintained by a group called the Open Source Initiative, and together they are referred to as the Open Source Definition (OSD). We will briefly review them here.

An open source licence must:

• grant the licensee the right to distribute the program themselves, including the right to c-harge money for it

• grant access to the program’s source code

• grant the right to modify the program

• grant the right to distribute modified versions of the program

• allow use of the program by all persons or groups in all fields of endeavour

• apply to everyone who receives the program, without the need for any additional agreements

• apply to the program it licenses, whether the program is obtained as part of a group of programs, or on its own

• allow distribution with any other software

• allow distribution in any form

The desired effect of these conditions is to promote wide distribution of software, and to encourage people who receive the software to contribute to its functionality by modifying the source code. Although it may seem that granting these rights might lead to a large number of slightly variant versions of a piece of software, in practice successful open source software projects tend to absorb disparate modifications made by many contributors back into a single modified and improved version.

It is worth noting the second part of the first bulleted point above. It is a common misconception that one cannot c-harge money for distributing open source software. This is not the case. In practice, it is rarely done, mainly because each one of your customers could give away the software in direct competition to your own sales.

Complex ownership

As a piece of open source software is developed, often by many different people and groups, its ownership becomes more and more complex. The issues relating to collaboration and ownership identified above apply equally to unplanned collaborations over a period of time. It is conceivable for every contributor to own the copyright to their contribution. While in practice most contributors will willingly agree to license their material under the same licence as the original work, meaning that the process of uptake and improvement can continue, still it can be complex to ascertain who should make a legal complaint if someone decides to use the program in a way that violates its licence. To avoid this issue, some open source projects ask that contributors explicitly assign the copyright in their contributions to a body that administers the project, thus keeping ownership centralised and making enforcement of the licence easier. An al-ternative approach is to have contributors license their contributions to the project’s administrative body under a licence agreement that permits the body to relicense the contribution.

Contract and copyright

It is often observed that licences such as those within the OSD are problematic because there is no overt act of acceptance by licensees who take them up. End-user licence agreements that are distributed with proprietary software often require a user to click a button to accept the conditions, and this fact leads many to believe that open source licences should require something similar to be binding. This is incorrect.

Proprietary end-user licence agreements are contracts to govern many aspects of the relationship between company and user. If the user breaks the agreement, they have breached their contract, and the software company may choose to use the law of contract to punish them. But this can be difficult, particularly as the law of contract varies f-rom country to country. Obtaining overt consent f-rom users by making them click the ‘I accept’ button helps make the process of prosecuting breaches of the agreement under contract law easier. Some would argue that the button is unnecessary, as a user has a responsibility to acquaint themselves with any licence and contract terms associated with software they use — however, proprietary software firms tend to err on the side of caution and mandate the ‘I accept’ button.

Although they are not considered to be contracts, properly drafted open source licences are legally binding and enforcement action can be taken against those who breach them. This may be under contract or copyright law, depending on how the licence is framed. No-one is forced to explicitly accept the licence, but implicit acceptance of the licence conditions is the only route to legitimate use under copyright law.

Beyond the Open Source Definition

The Open Source Initiative website currently lists over 50 licences that meet the conditions described in section 3. It is not within the scope of this document to examine them all. It is notable, however, that the most widely used open source licence — the GNU General Public License (GPL) — imposes a major further condition upon those who copy, adapt or distribute software under it. All software cre-ated by modifying the original software must also be licensed under the GPL (if it is distributed). The aim of this condition is to produce a body of open source software that grows as users contribute, and that cannot be shrunk by users adding their own effort to a piece of software and then relicensing the result under terms that are more restrictive than those of the GPL. Because this condition can be seen as an attempt to subvert the proprietary use of copyright, it is sometimes known as copyleft.

It is worth noting that there is no compulsion to release changes that you make, either under the GPL or any other open source licence; you may keep internal versions of GPL software that you have modified without necessarily licensing them to anyone else. This applies equally to individuals and legal entities like companies and institutions.

Licence compatibility

It is tempting to believe that all the source code that is available under an open source licence can be adapted and combined without restriction in order to produce new open source software. Unfortunately this is not the case. Two licences that each meet the requirements of the Open Source Definition individually may nevertheless contain terms that make them incompatible with each other. The GNU GPL (all versions) provides an example of this: it mandates that code that incorporates GPL-licensed code must itself be licensed under the GPL as a whole if it is distributed. It also mandates that no additional restrictions on the rights it grants can be imposed on GPL-licensed code. These two conditions combine to mean that GPL-licensed code can only be merged easily with other GPL-licensed code, or with code whose licence imposes only conditions present in the GPL. Clearly it is not an easy task to establish whether a condition in one licence is the exact equivalent of a differently worded condition in another licence. The Free Software Foundation, which administers the GPL, makes available a list of licences that they consider to be compatible with it.

The issue of licence compatibility is a complex one, and determining whether two licences are compatible will require the help of a lawyer in all but the most simple of cases. Programmers working on a piece of software that is to be distributed under a licence (whether open source or otherwise) need to be aware of the potential difficulties in this area before attempting to merge in open source code. Often the simplest way of resolving licence conflicts is to ask the code’s owner(s) if they would be willing to relicense their code for inclusion. However, this approach is only really practical whe-re the number of owners is small.

Tracking intellectual property

The issues of licence compatibility and of complex multiple ownership of intellectual property mean that it is desirable, if not essential, for programmers and their managers to keep detailed records. Version control systems provide some of this record-keeping automatically, recording who made changes to the code and what they did. To complement this information, managers should keep records of the contractual and licensing status of contributors in order to establish who owns their work. They should also require and store explicit agreements f-rom copyright owners that their contributions may be licensed and distributed under the licence se-lected for the project as a whole. Whe-re code is brought in f-rom existing open source software, the details of the relevant licence must be recorded (having first established that this licence is compatible with the project’s overall licensing policy).

Summary

To briefly summarise the points made in this document:

• Software is intellectual property.

• Software is protected under copyright law.

• The ownership of software can be determined by a technical legal examination of any contracts under which it was produced, and any other legally relevant circumstances.

• Copyright law says that by default only the owner of software may copy, adapt or distribute it.

• The owner of software can agree to let another person copy, adapt or distribute the code - this agreement is called a licence.

• Open source licences grant these rights to anyone who chooses to take them up, with certain conditions.

• Open source licences aim to cre-ate a community of contributors who will fix and develop the software.

• Combining two pieces of software code under different licences can be complex.

• All projects that produce software need to keep complete, detailed records of the licensing and ownership of contributions to that software.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com