Hội nghị thượng đỉnh máy để bàn: cấp bản quyền

Desktop Summit: Copyright assignments

By Jake Edge, August 10, 2011

Theo: http://lwn.net/Articles/454391/

Bài được đưa lên Internet ngày: 10/08/2011

Lời người dịch: Tại hội nghị thượng đỉnh máy để bàn Linux, đã có một nhóm hội thảo giữa một số thành viên cao cấp của thế giới nguồn mở tranh luận về một số vấn đề còn gây tranh cãi như thỏa thuận cấp bản quyền (CAA) và thỏa thuận cấp phép bản quyền (CLA) cho mã nguồn của những người đóng góp, cụm từ “và sau này” đối với việc cộng các giấy phép nguồn mở, vấn đề về bằng sáng chế phần mềm và vấn đề các lập trình viên và các công ty đã chết. Còn có nhiều ý kiến khác biệt và chắc chúng ta sẽ còn thấy trong tương lai những tranh luận tiếp tục.

Các thỏa thuận cấp bản quyền (hoặc cấp phép) cho các dự án là một vấn đề khá tranh cãi, phản ánh những quan điểm khác nhau về cách mà phần mềm tự do sẽ được định vị tốt nhất để phát triển những năm tới. Vài quan điểm đã được thể hiển tại “Nhóm về Cấp Bản quyền” đã diễn ra hôm 06/08/2011 tại Hội nghị thượng đỉnh cho máy tính để bàn tại Berlin. Nhóm này gồm 2 phe đối lập đối với những thỏa thuận như vậy, Michael Meeks và Bradley Kuhn, cũng như có lẽ người phản đối nổi tiếng nhất, Mark Shuttleworth, với giám đốc điều hành Quỹ GNOME Karen Sandler giữ chủ trì hội thảo nhóm. Cuối cùng, mỗi quan điểm đã được trình bày tốt, nhưng, như dự đoán, không phe nào thuyết phục được phe kia; mỗi phep có lẽ sẽ bám đuổi theo con đường của mình trong những năm tới.

Sandler đã yêu cầu khán phòng tổng hợp chung - với hơn 400 người tham dự - có bao nhiêu người đã biết về các vấn đề có liên quan tới cấp bản quyền và khoảng một nửa đã giơ tay của họ. Ít nhiều hơn khoảng một nửa còn lại đã trả lời rằng họ đã có những cảm giác mạnh mẽ về chủ đề này, dù theo hướng nào còn chưa rõ sự cần thiết từ bản thân câu hỏi. Dựa vào cảm giác chung trong thế giới phần mềm tự do - có lẽ được phản ánh trong tỷ lệ 2-1 trong nhóm - điều này có lẽ là hợp lý để giả thiết rằng hầu hết những cảm giác mạnh mẽ là nằm ở phe phản đối.

Những khác biệt giữa những thỏa thuận cấp bản quyền (CAA - Copyright Assignment Agreements) và những thỏa thuận cấp phép bản quyền (CLA - Copyright Licensing Agreements) - sự khác biệt giữa cấp bản quyền cho một tổ chức đối lại với việc trao cho tổ chức đó một giấy phép rộng lớn để làm bất kỳ thứ gì tổ chức đó muốn với sự đóng góp - thực sự không nằm trong thảo luận như Sandler đã chỉ ra trong phần giới thiệu. Đối với hầu hết các phần, những khác biệt giữa 2 phe là không phù hợp để thảo luận. Bà sau đó đã hỏi mỗi trong số những người trong nhóm tự giới thiệu bản thân họ và đưa ra quan điểm của họ.

Copyright assignment (or licensing) agreements for projects is a rather contentious issue that reflects differing views of how free software will be best-positioned to grow over the coming years. Several perspectives were on display at the "Panel on Copyright Assignment" held on August 6 at the Desktop Summit in Berlin. The panel consisted of two opponents of such agreements, Michael Meeks and Bradley Kuhn, as well as perhaps their most outspoken proponent, Mark Shuttleworth, with GNOME Foundation executive director Karen Sandler handling the moderation duties. In the end, each position was well-represented, but, as might be guessed, neither side convinced the other; each will likely continue to pursue its path over the coming years.

Sandler asked the assembled room—packed with 400 or more attendees—how many knew about the issues surrounding copyright assignment and around half raised their hands. More or less the same half responded that they already had strong feelings about the subject, though in which direction wasn't necessarily clear from the query itself. Based on the general feeling in the free software world—perhaps reflected in the 2-1 ratio on the panel—it is probably reasonable to assume that most of the strong feelings were in the opposition camp.

The differences between copyright assignment agreements (CAAs) and copyright licensing agreements (CLAs)—the difference between assigning copyright to an organization vs. giving the organization a broad license to do what it wishes with the contribution—was not really under discussion as Sandler pointed out in the introduction. For the most part, the differences between the two are not germane to the dispute. She then asked each of the panelists to introduce themselves and to outline their position.

Thiết lập nền tảng

Cao thủ lâu năm của LibreOffice và GNOME Michael Meeks lên trước với các phản đối của ông mà ông nói tới theo 3 đầu đề riêng rẽ: tính có thể mở rộng theo phạm vi, xung đột và quyền sở hữu. Những thứ này tạo thành một cụm từ với những ký tự đầu mà cũng tóm tắt được cảm giác của ông, ông nói (ám chỉ SCO). Meeks từng một thời là một người bảo vệ của những thỏa thuận về bản quyền, và sau đó đã thay đổi vì ông đã “thấy nó đi hoàn toàn sai”.

Vấn đề về tính có thể mở rộng được về phạm vi là trao các quyền cho mã nguồn của bạn cho một công ty dẫn chúng tới việc có một sự độc quyền. Công ty đó thường có một giấy phép ràng buộc ra bên ngoài là copyleft mạnh (như GPL) để dẫn dắt bất kỳ việc cấp phép SHĐQ nào đối với công ty. Điều này có thể dẫn tới những xung đột, ông nói, như “các cao thủ chống lại các vụ kiện” hoặc cộng đồng chống lại công ty. Nếu những người đóng góp không cảm thấy thích việc họ sở hữu một phần của mã nguồn, họ “cảm thấy rất khác về dự án”, ông nói. Họ không cần cảm thấy bất kỳ lòng trung thành nào đối với công ty, nhưng mất quyền sở hữu có thể làm cho họ cảm thấy họ thực sự không phải là một phần của dự án. Điều đó có thể làm cho các cộng đồng ít thú vị và mạnh mẽ hơn.

Nhà sáng lập Canonical và Ubuntu Mark Shuttleworth nói rằng ông nghĩ về bản thân ông như một người làm vườn và “nhìn xem các hệ sinh thái phát triển và thịnh vượng như thế nào”. Như một người kinh doanh, ông muốn sẽ là một phần của một hệ sinh thái thịnh vượng cho máy tính để bàn Linux, ông nói. Thậm chí đối mặt với sự áp đảo của Microsoft, iOS và Android đã và đang xây dựng được các hệ sinh thái thịnh vượng và ông muốn thấy máy tính để bàn Linux làm được y hệt.

“Sự tự do không phải là ở trên bàn trong các cuộc thảo luận”, Shuttleworth nói. Trong khi mã nguồn được đóng góp theo một trong những thỏa thuận có thể thành SHĐQ, thì bản thân mã nguồn lại không bị rủi ro khi nó sẽ luôn sẵn sàng theo giấy phép tự do mà nó đã được phân phối. Hệ sinh thái Linux cần nhiều công ty nhỏ và mới khởi nghiệp tham gia vào, nhưng điều đó đang không xảy ra, ông nói, khi mà họ đang phát triển cho Android, iOS, hoặc các công ty web khác - và họ sẽ không ở trong Hội nghị thượng đỉnh Máy tính để bàn.

Setting the stage

LibreOffice and longtime GNOME hacker Michael Meeks went first with his objections that he said came under three separate headings: scalability, conflict, and ownership. Those make a nice acronym that also summarizes his feelings, he said. Meeks was at one time an advocate of copyright agreements, and then changed his mind because he has "seen it go badly wrong".

The scalability problem is that giving the rights to your code to a company leads to them having a monopoly. The company typically has a strong copyleft outbound license (e.g. GPL) to drive any proprietary licensing to the company. This can lead to conflicts, he said, like "hackers vs. suits" or the community vs. the company. If contributors don't feel like they own part of the code, they "feel very differently about the project", he said. They don't necessarily feel any allegiance to the company, but the loss of ownership can make them feel like they aren't really part of the project either. That can cause less vibrant and excited communities.

Canonical and Ubuntu founder Mark Shuttleworth said that he thinks of himself as a gardener and "looks at how ecosystems grow and thrive". As a businessman, he wants to be part of a thriving ecosystem and believes that others in the room share that view. Today, we don't have a thriving ecosystem for the Linux desktop, he said. Even in the face of Microsoft domination, iOS and Android have built thriving ecosystems and he would like to see the Linux desktop do the same.

"Freedom is not on the table in these discussions", Shuttleworth said. While code that is contributed under one of these agreements could go proprietary, the code itself is not at risk as it will always be available under the free license that it was distributed under. The Linux ecosystem needs lots of smaller companies and startups to be involved, but that isn't happening, he said, as they are developing for Android, iOS, or the web—and are not at the Desktop Summit.

Có vài cách thức để các công ty tham gia vào một dự án phần mềm tự do, Shuttleworth nói. Một cách là để một “dự án với các mối quan hệ” giống như Nhân Linux, nơi mà các công ty phải tham gia trong sự phát triển của nó, dù họ “ghét nó” và muốn rằng họ có thể được yêu cầu để làm thế, ông nói. Cách khác là có một “nền tảng chia sẻ cốt lõi” với một giấy phép cho phép (permissive) cho phép các công ty bổ sung “các mở rộng nước sốt bí mật”, và đã chỉ tới cộng đồng PostgreSQL như một ví dụ. Sự tổng hợp là một con đường khác - được các phát tán Linux sử dụng - lấy công việc của nhiều cộng đồng, đóng gói chúng lại, và thực hiện những lời hứa về chất lượng hoặc sở hữu trí tuệ (IP) vè việc đánh đống để lôi cuốn các khách hàng. Cuối cùng, ông đã nhắc tới mô hình nhà cung cấp duy nhất rõ ràng nói rằng có một tổ chức đứng đằng sau dự án, giống như Mozilla. Có những nỗi sợ hãi về mô hình đó, ông nói, nhưng cách thức mà những nỗi sợ hãi đó được làm việc là trong các thị trường chín muồi là thông qua sự cạnh tranh.

Brandley Kuhn của tổ chức Bảo vệ Sự tự do cho Phần mềm đã không đồng tình với Shuttleworth: “sự tự do của phần mềm luôn nằm trên bàn”, ông nói, và nó luôn nằm trong mối đe dọa. Kuhn từng là giám đốc điều hành của Quỹ Phần mềm Tự do (FSF) và hiện phục vụ trong ban lãnh đạo của nó. Ông đã lưu ý rằng FSF đặt nhiều nỗ lực vào việc đưa cùng nhau ra được một khung pháp lý nơi mà các dự án có thể làm việc được với các công ty một cách bình đẳng. Giấy phép được một cộng đồng sử dụng theo một số cách thức chính là thể trạng của cộng đồng đó, như một thỏa thuận bản quyền có thể thay đổi thể trạng đó theo những cách thức đơn phương từ một phía. Copyleft được thiết kế để đảm bảo chắc chắn rằng những dẫn xuất của mã nguồn luôn sẵn sàng theo những điều khoản mà mã nguồn gốc ban đầu đã được đưa ra.

Kuhn đã lưu ý rằng một số người có lẽ hơi ngạc nhiên trong quan điểm của ông, biết rằng FSF đòi hởi chấp bản quyền cho các dự án của mình. Ông đã và đang bảo vệ việc tạo ra sự lựa chọn đó hơn là bắt buộc, nhưng cho tới này còn chưa thuyết phục được ban lãnh đạo tiến hành thay đổi đó. Nhưng có “một số lượng khổng lồ các giá trị” trong việc cấp các bản quyền cho một tổ chức mà mã nguồn và các dẫn xuất của nó sẽ luôn sẵn sàng theo một giấy phép tự do, nhưng trừ phi một công ty làm cho những thứ đó thành dạng y hệt những hứa hẹn, thì sẽ không có sự đảm bảo như vậy nữa. Cho tới nay những yêu cầu của ông tới một số công ty thực hiện các lời hứa dạng đó đã và đang gặp phải một sự thay đổi trong chủ đề này, ông nói.

There are several ways to get companies to participate in a free software project, Shuttleworth said. One way is to a "nexus project" like the Linux Kernel, where companies have to participate in its development, though they "hate it" and wish that they weren't required to do so, he said. Another way is to have a "core shared platform" with a permissive license that allows companies to add "secret sauce extensions", and pointed to the PostgreSQL community as an example. Aggregation is another path—used by Linux distributions—to take the work of multiple communities, package them up, and make quality or IP promises about the bundle to attract customers. Lastly, he mentioned the single vendor model which clearly states that there is an organization behind the project, like Mozilla. There are fears about that model, he said, but the way those fears are dealt with in mature markets is via competition.

Bradley Kuhn of the Software Freedom Conservancy disagreed with Shuttleworth: "software freedom is always on the table", he said, and it is always under threat. Kuhn was formerly the executive director of the Free Software Foundation (FSF) and currently serves on its board. He noted that the FSF put a lot of effort into putting together a legal framework where projects can work with companies on equal footing. The license that is used by a community is in some ways the constitution of that community, but a copyright agreement can change that constitution in unilateral ways. Copyleft is designed to make sure that derivatives of the code are always available under the terms which the original code was released under.

Kuhn noted that some might be a bit surprised at his opposition, given that the FSF requires copyright assignment for its projects. He has been advocating making that optional rather than mandatory, but has so far been unable to convince the board to make that change. But there is "a tremendous amount of value" in assigning copyrights to an organization that is "completely aligned with free software" such as the FSF. The FSF has made promises that the code and its derivatives will always be available under a free license, but unless a company makes those same kind of promises, there is no such guarantee. So far his requests to some companies to make promises of that sort have been met with a change in the subject, he said.

Độc quyền

Meeks đã hỏi Shuttleworth liệu ông có đồng ý rằng việc ký một thỏa thuận bản quyền với một công ty có trao cho công ty đó một sự độc quyền hay không, và Shuttleworth nói rằng ông ta đã không đồng ý. Nếu mã nguồn là sẵn sàng theo GPL, thì sẽ không có độc quyền, ông nói, dù công ty với đa số bản quyền là theo “quan điểm về lợi ích”. Kuhn đã viện lý rằng Shuttleworth đã đang thay đổi chủ đề, vì độc quyền là về khả năng cấp phép cho mã nguồn theo các điều khoản SHĐQ. Đó là một sự giám sát “nhàm chán và rõ ràng”, Shuttleworth nói, đồng ý rằng nó trao dạng sức mạnh độc quyền đó cho người nắm giữ bản quyền.

Meeks nói rằng lý do có 2 dự án môi trường đồ họa cho máy tính để bàn Linux chính xuất phát từ vấn đề cấp phép SHĐQ, tham chiếu tới việc cấp phép Qt không tự do mà đã tồn tại vào lúc hình thành dự án GNOME. Ông tin tưởng rằng có cả 2 thứ đó là một “sự lãng phí đáng buồn”. Một phần của vấn đề đối với Linux là nhiều “sự trùng lặp vô nghĩa”, ông nói. Trả lời cho một câu hỏi từ Shuttleworth, Meeks nói rằng có cả các trình duyệt Firefox và Chrome từng là sự trùng lặp vô nghĩa theo quan điểm của ông. “Tôi thấy không có gì sai với Firefox”, ông nói.

Ký các yêu cầu và “sự xích mích”

Shuttleworth đã chỉ ra rằng các thỏa thuận bản quyền “có thể gây ra những vấn đề và chúng ta nên cẩn thận đề cập tới chúng”. Một trong những vấn đề là “xích mích” được gây ra bằng việc phải ký một thỏa thuận hoàn toàn, lưu ý rằng một trong những sức mạnh lớn của GPL là việc bạn không phải ký nó. Nhưng, trong các trường hợp nơi mà một thỏa thuận là cần thiết, thì chúng ta có thể giảm xích mích, như những gì dự án Harmony đã thiết lập để làm, ông nói. Bằng việc giảm số lượng các thỏa thuận, các công ty như Canonical có thể không phải nhìn vào 300 thỏa thuận khác nhau mỗi năm, ông nói.

Kuhn nói rằng mục tiêu của ông có thể là vì Canonical và những người khác không bao giờ ký một thỏa thuận như vậy hoàn toàn. Nếu giấy phép theo đó mã nguồn được đóng góp là y hệt như giấy phép theo đó dự án được tung ra (nghĩa là “bên trong = bên ngoài”), thì có thể sẽ không cần một thỏa thuận. GPL được thiết kế để điều khiển tình trạng đó một cách phù hợp, Kuhn nói. Ông cũng đã lưu ý rằng ông đã có quan tâm về những thỏa thuận của Harmony vì chúng có thể dẫn tới dạng bối rối y hệt mà các giấy phép Creative Commons (CC) đã làm. Bằng việc có nhiều dngj bối rối khác nhau các thỏa thuận theo cùng tên của mức cao nhất (như Harmony hoặc CC), có thể có sự bôi sroois như những gì là có nghĩa, ông nói. Mất thời gian để tách biệt các giấy phép CC hướng tự do từ những lựa chọn không tự do và ông lo rằng một tình huống tương tự có thể nảy sinh với Harmony.

Monopolies

Meeks asked Shuttleworth if he agreed that signing a copyright agreement with a company gives that company a monopoly, and Shuttleworth said that he didn't. If the code is available under the GPL, there is no monopoly, he said, though the company with a majority of the copyright is in a "beneficial position". Kuhn argued that Shuttleworth was changing the subject, because the monopoly is on the ability to license the code under proprietary terms. That is a "trite and obvious" observation, Shuttleworth said, in agreeing that it does give that kind of monopoly power to the copyright holder.

Meeks said that the reason that there are two major Linux desktop projects stems from the proprietary licensing problem, referring to the non-free Qt licensing that existed at the time of the GNOME project's founding. He believes that having both of those is a "sad waste". Part of the problem for Linux is lots of "pointless duplication", he said. In response to a question from Shuttleworth, Meeks said that having both the Firefox and Chrome browsers was pointless duplication in his view. "I see nothing wrong with Firefox", he said.

Signing requirements and "friction"

Shuttleworth pointed out that copyright agreements "can cause problems and we should be careful to address them". One of those problems is the "friction" caused by having to sign an agreement at all, noting that one of the great strengths of the GPL is that you don't have to sign it. But, in cases where an agreement is needed, we can reduce the friction, which is what Project Harmony was set up to do, he said. By reducing the number of differing agreements, companies like Canonical would not have to look at up to 300 different ones every year, he said.

Kuhn said that his goal would be for Canonical and others to never have to sign such an agreement at all. If the license under which the code is contributed is the same as that under which the project is released (i.e. "inbound == outbound"), there would be no need for an agreement. The GPL is designed to handle that situation properly, Kuhn said. He also noted that he was concerned about the Harmony agreements because they could lead to the same kind of confusion that the Creative Commons (CC) licenses did. By having multiple different kinds of agreements under the same top-level name (e.g. Harmony or CC), there can be confusion as to what is meant, he said. It took time to separate the freedom-oriented CC licenses from the non-free choices, and he worries that a similar situation may arise for Harmony.

Hoặc sau này

Sandler đã hỏi những người trng nhóm về việc sử dụng cụm từ “hoặc sau này” (như GPLv2 hoặc sau này, nghĩa là “cộng” các giấy phép) khi việc cấp phép cho mã nguồn và những gì triển khai diễn ra. Kuhn đã lưu ý rằng nhân nổi tiếng Linux không sử dụng “hoặc sau này”. Ông nói rằng làm thế là đặt sự tin tưởng vào tổ chức khác, và rằng nếu bạn không tin tổ chức khác đó “một cách sâu sắc”, thì đừng ký một thỏa thuận bản quyền với họ hoặc bổ sung một cụm từ “hoặc sau đó” vào một giấy phép theo sự kiểm soát của họ.

Nhưng Shuttleworth lo ngại rằng việc sử dụng cấp phép “bên trong = bên ngoài” là “việc tin tưởng rằng thế giới sẽ không thay đổi”. Trong khi việc cấp phép sẽ không thay đổi trong một đêm, thì nó cuối cùng sẽ đề cập tới những thay đổi trong bức tranh pháp lý. Chỉ như có sự cần thiết phải có một GPLv3 để giải quyết những khiếm khuyết trong v2, rồi sẽ có GPLv4 và GPLv5 một ngày nào đó, ông nói. Richard Stallman sẽ không đâu đó mãi mãi, nên bạn đang đặt niềm tin của bạn vào cơ quan của FSF, ông nói. Có thể sẽ là tốt hơn để đặt niềm tin đó vào bản thân dự án và cho phép nó quyết định liệu bất kỳ thay đổi nào về giấy phép sẽ cần thiết đi ra ngoài đường.

Về cơ bản việc không đồng tình với cả 2, Meeks nghĩ rằng “hoặc sau này” là “sống còn”. Ông nói rằng ông tin tưởng FSF và nghĩ rằng những người khác cũng nên thế, nhưng hơn nữa, “FSF là ít rủi ro hơn so với việc giết chết dự án của bạn thông qua sự quan liêu”. Một lý do mà các công ty muốn có khả năng có được các giấy phép SHĐQ đối với phần mềm tự do sao cho “họ có thể có được sự bảo vệ các bằng sáng chế mà không sẵn sàng đối với chúng ta”, ông nói.

Or later

Sandler asked the panelists about using the "or later" clause (e.g. GPLv2 or later, aka "plus" licenses) when licensing code and what the implications were. Kuhn noted that the Linux kernel famously does not use "or later". He said that doing so is putting trust in another organization, and that if you don't trust that organization "deeply", don't sign a copyright agreement with them or add an "or later" clause to a license that is under their control.

But Shuttleworth is concerned that using "inbound == outbound" licensing is "believing that the world won't change". While licensing won't change overnight, it will eventually to address changes in the legal landscape. Just as there needed to be a GPLv3 to address shortcomings in v2, there will be a GPLv4 and a GPLv5 some day, he said. Richard Stallman will not be around forever, so you are placing your trust in the institution of the FSF, he said. It would be better to place that trust in the project itself and allow it to decide if any license changes are needed down the road.

Essentially disagreeing with both, Meeks thinks that "or later" is "vital". He says that he trusts the FSF and thinks that others should too, but beyond that, "the FSF is less of a risk than killing your project through bureaucracy". One reason that companies want to be able to get proprietary licenses to free software is so that "they can get patent protection that isn't available to us", he said.

Các lo ngại về bằng sáng chế

Cũng có câu hỏi về các giấy phép bằng sáng chế, Meeks nói Những thỏa thuận của Harmony chỉ định các bằng sáng chế cùng với những quyền khác và nếu mã nguồn được tung ra theo một giấy phép cho phép (permissive) (như BSD), thì các quyền về bằng sáng chế mà công ty tích lũy sẽ không nhất thiết chảy ngược lại tới những người mà nhận mã nguồn. Điều này có thể tốt lành để nhờ cộng đồng ngồi chung thuyền với sự tôn trọng các bằng sáng chế như những công ty khác mà cấp phép cho mã nguồn, nhưng điều đó có thể sẽ không đúng nếu những thỏa thuận của Harmony sẽ được sử dụng, ông nói. “Harmony làm cho nó phức tạp hơn, chứ không phải đơn giản hơn”, ông nói.

Patent concerns

There is also the question of patent licenses, Meeks said. The Harmony agreements assign patent rights along with the other rights and if the code is released under a permissive license (e.g. BSD), the patent rights accumulated by the company don't necessarily flow back to those who receive the code. It would be nice to have the community be in the same boat with respect to patents as the other companies that license the code, but that may not be true if the Harmony agreements are used, he said. "Harmony makes it more complicated, not simpler", he said.

Các bằng sáng chế từng như một phần “được tranh cãi sôi nổi” của quá trình hình thành nên các thỏa thuận của Harmony, Shuttleworth nói. Ông từng là một “người quan sát tiệm cận” của qui trình này, ông nói, nhưng đã thấy rằng vấn đề bằng sáng chế đã được thảo luận dài dài. Vấn đề là bạn phải cẩn thận những gì bạn hỏi cho bên trong (inbound) đối với các bằng sáng chế nếu bạn muốn có khả năng sử dụng một loạt dạng các giấy phép bên ngoài (outbound), ông nói. Các bằng sáng chế là “một vấn đề rất nghiêm trọng”, nhưng những thỏa thuận của Harmony chỉ trao khả năng để chuyển mã nguồn với một giấy phép cho bất kỳ bằng sáng chế nào được giữ bởi người đóng góp mà đọc được trong sự đóng góp.

GPLv3 đã được thiết kế để đảm bảo rằng mỗi người đang có các quyền như nhau về bằng sáng chế, Kuhn nói. Một phần lý do cho sự cập nhật từng là vì GPLv2 đã không tốt theo khía cạnh này, ông nói.

Những lập trình viên và các công ty đã chết

Vấn đề “lập trình viên đã chết” là một nơi mà một số dạng thỏa thuận bản quyền có thể giúp, Sandler nói. Nếu có một nhu cầu để cấp phép lại cho một dự án nơi mà một hoặc nhiều người nắm giữ bản quyền hơn là chết rồi hoặc nếu khác đi không thể với tới họ được, điều gì có thể làm nếu không có thỏa thuận, bà hỏi. Meeks nói rằng “lý lẽ về công ty chết cũng thú vị”. Có nhiều lập trình viên hơn là các công ty, ông nói. “Cộng” các giấy phép có thể giúp ở đó, ông nói. Meeks cũng nói rằng ông từng hạnh phúc để nghe rằng Canonical từng sử dụng công các giấy phép, nhưng Shuttleworth đã nhanh chóng chỉ ra rằng không phải thế. Giấy phép ưu tiên chọn của Canonical là GPLv3, dù hãng sẽ đóng góp vào các dự án với cộng các giấy phép, ông nói.

Chúng ta đã thấy các vấn đề với các công ty chết mà đã gây ra cho những công ty khác tới “nhặt xác”, Kuhn nói. Đôi khi một phần của những cái xác đó là những dự án phần mềm tự do nơi mà công ty mới sau đó thay đổi tất cả các chính sách sẽ đi tiếp, ông nói. Tình huốn các lập trình viên bị chết là rất khác khi có những quyết định rất cá nhân mà các lập trình viên có thể muốn thực hiện đối với mã nguồn của họ sau khi họ mất. Điều đó có thể bao gồm chỉ định ai đó tiến hành các quyết định đó - như Kuhn đã làm - sau khi họ mất Shuttleworth đã nghi ngờ về việc dựa vào những người có những ông việc của họ trước khi họ mất.

Thảo luận nhóm đã khép lại với một tranh luận ngắn về sự cạnh tranh, với Shuttleworth nói rằng thế giới phần mềm tự do sợ cạnh tranh và cố gắng ngăn cản bất kỳ ai có được một ưu thế cạnh tranh.

Meeks tin tưởng rằng đã có đủ sự cạnh tranh từ các công ty phần mềm SHĐQ, nên việc bổ sung thêm nó vào cộng đồng phần mềm tự do là không cần thiết. Quan điểm của Kuhn là “hệ sinh thái đã làm việc cho tới này là một hệ sinh thái copyleft” mà không có bất kỳ dạng thỏa thuận bản quyền nào.

Trong khi là thú vị, hội thảo nhóm đã đưa ra quá ngắn về thời gian, nên cảm thấy rất có áp lực. Hơn nữa, đã không có khả năng cho khán phòng đưa ra các câu hỏi, thứ gì đó mà Kuhn đã lưu ý là một trong những phần quan trọng nhất của bất kỳ dạng thảo luận nhóm nào. Sự cần bằng trong nhóm cũng dường như bị méo mó một chút, dù, như được lưu ý ở trên, điều đó có thể phản ánh một cách thô ráp ý kiến của cộng đồng về vấn đề này. Một thành viên trung lập thứ 3 của nhóm, thay thế cho cả Meeks và Kuhn, có thể là tốt hơn, dù Sandler đã không làm công việc dễ chịu trong việc chỉ đạo mọi thứ như một người điều tiết trung lập. Theo một số cách thức như bản thân chủ đề này, nhóm hoàn toàn là thú vị, nhưng không thỏa mãn lắm. Chắc chắn không phải là những câu trả lời dễ dàng, và có lẽ chúng ta sẽ vật lộn với nó trong nhiều năm tới nữa.

Patents were "debated vigorously" as part of the process of coming up with the Harmony agreements, Shuttleworth said. He was a "tangential observer" of the process, he said, but did see that the patent issue was discussed at length. The problem is that you have to be careful what you ask for inbound with respect to patents if you want to be able to use various kinds of outbound licenses, he said. Patents are "a very serious problem", but the Harmony agreements just give the ability to ship the code with a license to any patents held by the contributor that read on the contribution.

The GPLv3 was designed to ensure that everyone is getting the same patent rights, Kuhn said. Part of the reason for the update was because the GPLv2 was not as good in that regard, he said.

Dead developers and companies

The problem of the "dead developer" is one place where some kind of copyright agreement can help, Sandler said. If there is a need to relicense a project where one or more copyright holders is dead or otherwise unreachable, what can be done if there is no agreement, she asked. Meeks said that the "dead company argument is also interesting". There are more developers than companies, so maybe they die more often, but we have already seen problems coming from dead companies, he said. "Plus" licenses can help there, he said. Meeks also said that he was happy to hear that Canonical was using plus licenses, but Shuttleworth was quick to point out that was not the case. Canonical's preferred license is GPLv3, though it will contribute to projects with plus licenses, he said.

We have seen problems with dead companies that have resulted in other companies coming in to "pick at the carcass", Kuhn said. Sometimes part of that carcass is free software projects where the new company then changes all of the policies going forward, he said. The dead developer situation is very different as there are very personal decisions that developers may want to make regarding their code after they are gone. That could include appointing someone to make those decisions—as Kuhn has done—after they pass. Shuttleworth was skeptical about relying on people to get their affairs in order before they go.

The panel wrapped up with a short discussion of competition, with Shuttleworth saying that the free software world fears competition and tries to prevent anyone from getting a competitive advantage. Meeks believes that there is already enough competition from the proprietary software companies, so adding it into the free software community is not needed. Kuhn's position is that the "ecosystem that has worked so far is a copyleft ecosystem" without any kind of copyright agreement.

While interesting, the panel was given too short of a slot, so that it felt very compressed. In addition, there was no opportunity for the audience to ask questions, which is something that Kuhn noted as one of the most important parts of any kind of panel discussion. The balance on the panel also seemed a bit skewed, though, as noted above, that may roughly reflect the community's opinion on the matter. A neutral third member of the panel, replacing either Meeks or Kuhn, might have been better, though Sandler did a nice job of steering things as a neutral moderator. In some ways like the topic itself, the panel was quite interesting, but vaguely unsatisfying. There are certainly no easy answers, and we will likely struggle with it for many years to come.

Dịch tài liệu: Lê Trung Nghĩa

letrungnghia.foss@gmail.com