Các trách nhiệm về quyền sở hữu

The responsibilities of ownership

Friday, July 22nd, 2011 by Mark Shuttleworth

Theo: http://www.markshuttleworth.com/archives/687

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

Lời người dịch: Mark Shuttleworth nói về các trách nhiệm và quyền sở hữu đối với các bản vá cho Ubuntu dòng chính thống và quan điểm của ông. Ông nói về sự chia sẻ: “Đó là thứ yêu thuật về sự sáng tạo và quyền sở hữu. Nó tạo ra khả năng cho sự hào phóng. Bạn không thể thực sự trao thứ gì đó mà bạn không sở hữu, nhưng nếu bạn có, thì bạn đã làm một sự đóng góp đích thực. Một món quà là khác với một món vay nợ. Nó không đặt ra sự ràng buộc nào, nó trang bị cho người nhận và nó giải phóng người cho khỏi những trách nhiệm về quyền sở hữu. Chúng ta có xu hướng nghĩ rằng giải quyết các vấn đề của chúng ta để sản sinh ra một bản vá là thú vị cho chúng ta và hữu dụng cho chúng ta là một sự hào phóng. Không phải thế. Cơ hội cho sự hào phóng tới sau đó. Và trong hệ sinh thái của chúng ta, sự hào phóng là quan trọng. Nó nằm trong trái tim của đạo lý Ubuntu, và nó là quan trọng thậm chí giữa các đối thủ cạnh tranh, vì các đối thủ cạnh tranh bên ngoài hệ sinh thái của chúng ta sẽ không thể bị đánh nếu chúng ta không đem lại sự giúp đỡ lẫn nhau”.

Trong cộng đồng nguồn mở chúng ta thực hiện một vụ làm ăn rất lớn về các quyền về sở hữu. Nhưng còn về các trách nhiệm thì sao?

Bất kỳ tài sản nào cũng đi kèm với các chi phí, rủi ro và trách nhiệm. Và bất kỳ ai mà không coi những điều này quan trọng đều là những người quản gia tồi đối với tài sản đó.

Trong thế giới vật lý, chúng ta biết điều này rất tốt. Nếu bạn sở hữu một ngôi nhà, thì sẽ có các thứ thuế phải trả mỗi năm, sẽ có một số hóa đơn cho điện và duy trìm và các công việc giấy tờ phải điền. Tôi từng bị nhắc nhở một cách sống sượng về điều này khi tôi có một SMS vào lúc 2 giờ sáng nay, chăm sóc British Gas, nhắc nhở tôi một cách hữu ích giải quyết hóa đơn gas mà tôi thuê. Nếu chúng ta không chăm sóc các trách nhiệm này, thì chúng ta gặp rủi ro là tài sản sẽ xuống cấp hoặc bị lấy đi khỏi sự chăm sóc của chúng ta. Một ngôi nhà bỏ hoang cuối cùng sẽ bị xử phạt và bị phá hủy hơn là nằm đó như một mối nguy hại về sức khỏe. Một chiếc ô tô không được kiểm thử và cấp phép thì không thể được lái một cách hợp pháp trên những con đường công cộng. Ngắn gọn, quyền sở hữu đi cùng với một số công việc nhất định, và công việc đó phải được quản lý tốt.

Trong thế giới số và trí tuệ, mọi thứ hơi khác một chút. Không có miếng vải rõ ràng nào để gấp hoặc bức tường nào để vẽ. Nhưng sẽ vẫn có những trách nhiệm. Ví dụ, các thương hiệu cần phải được bảo vệ hoặc chúng sẽ bị mờ đi và bị mất. Các câu hỏi cần phải được trả lời. Các dự án lành mạnh phát triển và thích nghi qua thời gian trong một thế giới năng động; sự thay đổi là không thể tránh khỏi và những nhu cầu sẽ được điều tiết.

Việc duy trì một mẩu phần mềm tự do là một nỗ lực không bình thường. Phần còn lại của cái kho là việc thay đổi liên tục - thay đổi các trình biên dịch, thay đổi các phụ thuộc, thay đổi các qui ước. Trách nhiệm duy trì không nên bị thắt lại, nếu bạn muốn dự án của bạn vẫn phù hợp và hữu ích. Nhưng chế độ duy trì rất thường là trách nhiệm của các lập trình viên “cốt lõi”, chứ không phải của những người đóng góp thoảng qua. Những người đóng góp bất chợt đã tự gãi chỗ ngứa của riêng họ hoặc đáp ứng một bổn phận công việc bằng việc viết một miếng vá thường trao, như là một lý do cho sự đóng góp, mong muốn của họ có được gánh nặng của sự duy trì đó được triển khai bởi dự án, chứ không phải bởi bản thân họ.

In the open source community we make a very big deal about the rights of ownership. But what about the responsibilities?

Any asset comes with attendant costs, risks and responsibilities. And anybody who doesn’t take those seriously is a poor steward of the asset.

In the physical world, we know this very well. If you own a house, there are taxes to pay every year, there will be some bills for energy and maintenance, and there’s paperwork to fill out. I was rudely reminded of this when I got an SMS at 2am this morning, care of British Gas, helpfully reminding me to settle up the gas bill for a tenant of mine. If we fail to take care of these responsibilities, we’re at risk of having the asset degraded or taken away from our care. An abandoned building will eventually be condemned and demolished rather than staying around as a health hazard. A car which has not been tested and licensed cannot legally be driven on public roads. In short, ownership comes with a certain amount of work, and that work has to be handled well.

In the intellectual and digital world, things are a little different. There isn’t an obvious lawn to trim or wall to paint. But there are still responsibilities. For example, trademarks need to be defended or they are deemed to be lost. Questions need to be answered. Healthy projects grow and adapt over time in a dynamic world; change is inevitable and needs to be accommodated.

Maintaining a piece of free software is a non-trivial effort. The rest of the stack is continuously changing – compilers change, dependencies change, conventions change. The responsibility for maintenance should not be shirked, if you want your project to stay relevant and useful. But maintainership is very often the responsibility of “core” developers, not light contributors. Casual contributors who have scratched their own itch or met a work obligation by writing a patch often give, as a reason for the contribution, their desire to have that maintenance burden carried by the project, and not by themselves.

Khi một người duy trì bổ sung một miếng vá vào một công việc, họ cũng đang nhận trách nhiệm về sự duy trì của mình, trừ phi họ có một vài tình huống đặc biệt, như miếng vá là một trình cài cắm và về cơ bản được duy trì bởi người đóng góp. Đối với các trường hợp chung, việc bổ sung bản vá giống như trộn màu - nó bổ sung cho cơ thể duy trì chung theo một cách thức mà không dễ dàng làm bỏ dở hoặc phân tách riêng được.

Và việc sở hữu một tài sản có thể tạo ra những món nợ thực sự. Ví dụ, tại một số quốc gia, nếu bạn sở hữu một ngôi nhà và ai đó trượt chân trên cầu thang, bạn có thể bị truy cứu trách nhiệm. Nếu bạn sở hữu một chiếc ô tô và nó đang được cho mượn, và phanh hỏng, thì bạn có thể phải chịu trách nhiệm. Trong trường hợp của mã nguồn, việc nhận một bản vá ngụ ý, dù thích hay không, nhận một vài trách nhiệm đối với bản vá đó. Dù có trở thành một trách nhiệm thực tế, hay chỉ là một trách nhiệm liên đới, thì là thứ gì đó mà chỉ có thời gian mới nói lên được. Nhưng quyền sở hữu đòi hỏi bảo vệ trong trường hợp có một cuộc tấn công, và điều đó có thể là đắt giá, thậm chí nếu cuộc tấn công đó là không có cơ sở.

Vì thế, một trong những lý do tôi hạnh phúc để tài trợ (hoàn toàn hoặc không hoàn lại) một bản vá cho một người duy trì, và vì sao Canonical thường chỉ định các bản vá cho thượng nguồn tới những ai yêu cầu nó, là việc tôi nghĩ các quyền và các trách nhiệm về quyền sở hữu nên được trùng khớp. Nếu tôi muốn ai đó khác nắm công việc - trách nhiệm - về duy trì, thì tôi cũng hoàn toàn hạnh phúc vì họ triển khai các quyền đó. Điều đó dường như được cân bằng. Trong trường hợp thông thường, sự duy trì đó biến thành công việc nhiều y như việc nhào nặn ban đầu của bản vá đó, và thành thật mà nói, đây là phần “công việc nhàm chán”, trong khi phần vui vẻ đã giải quyết vấn đề ngay lập tức khi tới tay.

Tất nhiên, cũng có những trường hợp không bình thường nữa.

When a maintainer adds a patch to a work, they are also accepting responsibility for its maintenance, unless they have some special circumstance, like the patch is a plugin and essentially maintained by the contributor. For general cases, adding the patch is like mixing paint – it adds to the general body of maintenance in a way that cannot easily be undone or compartmentalised.

And owning an asset can create real liabilities. For example, in some countries, if you own a house and someone slips on the stairs, you can be held liable. If you own a car and it’s being borrowed, and the brakes fail, you can be held liable. In the case of code, accepting a patch implies, like it or not, accepting some liability for that patch. Whether it turns out to be a real liability, or just a contingent one, is something only time will tell. But ownership requires defence in the case of an attack, and that can be expensive, even if it turns out the attack is baseless.

So, one of the reasons I’m happy to donate (fully and irreversibly) a patch to a maintainer, and why Canonical generally does assign patches to upstreams who ask for it, is that I think the rights and responsibilities of ownership should be matched. If I want someone else to handle the work – the responsibility – of maintenance, then I’m quite happy for them to carry the rights as well. That only seems balanced. In the common case, that maintenance turns out to be as much work as the original crafting of the patch, and frankly, it’s the “boring work” part, while the fun part was solving the problem immediately at hand.

Of course, there are uncommon cases too.

Một trong những cuộc đấu tranh thần thánh về quyền sở hữu mã nguồn, giữa Sun và Novell, đã xoay quanh một trình cài cắm cho OpenOffice mà đã làm ra một số thứ rất hay ho. Sun đã kết thúc việc sáng tạo lại công việc đó vì Novell không muốn trao nó cho Sun. Thành thật mà nói, tôi nghĩ Sun đã ngốc ngếch. Trình cài cắm từng là toàn bộ công việc, nó đã phục vụ cho một mục đích cố kết tất cả bằng bản thân nó. Novell đã thiết kế và triển khai thành phần đó, và có thiện chí và động lực tuyệt vời để duy trì nó. Trong trường hợp đó, có ý nghĩa với tôi rằng Sun nên có thiện chí chừa chỗ cho công việc tuyệt vời của Novell, để nó như là của Novell. Thay vào đó, họ đã kết thúc bằng việc làm lại công việc, và nhiều người đã cảm thấy khó làm xong. Nhưng đó là trường hợp không bình thường. Kịch bản thường thấy hơn là việc một đóng góp cải tiến cho lõi, nhưng bản thân nó không có giá trị mà không có phần mã nguồn còn lại trong dự án đã có sẵn rồi.

Tất nhiên, “giá trị” là tương đối. Một bản vá chỉ áp dụng đối với một kho mã nguồn đang tồn tại có giá trị trong khả năng của nó để dạy những người khác cách làm dạng công việc này. Và nó có giá trị như nghệ thuật - bạn có thể đặt nó vào một chiếc áo T-shirt, hoặc một bức tường.

Nhưng việc đóng góp - thực sự đóng góp, thực sự tài trợ - một bản vá cho một người duy trì không phải làm giảm đi các dạng giá trị đối với người sáng tạo ban dầu. Tôi cho nó là thực tiễn tốt nhất mà một sự tài trợ được đáp ứng bằng một giấy phép rộng lớn trở ngược lại. Nói cách khác, nếu tôi trao bản vá của tôi cho người duy trì, sẽ là dễ chịu nếu họ trao cho tôi một tập hợp đầy đủ các quyền trở ngược lại. Trong khi một công việc tồi làm với nhiều thứ khác, thì thỏa thuận đóng góp của Canonical lại làm được điều này: Khi bạn thực hiện một đóng góp cho nó, thì bạn có một giấy phép rộng lớn ngược trở lại. Bằng cách đó, người sáng tạo tất cả còn lại các quyền hữu dụng, bao gồm khả năng xuất bản, cấp phép lại, bán, hoặc làm một chiếc áo T-shirt, mà cũng không mang tất cả các trách nhiệm đi cùng với quyền sở hữu đó.

One of the legendary fights over code ownership, between Sun and Novell, revolved around a plugin for OpenOffice that did some very cool stuff. Sun ended up re-creating that work because Novell would not give it to Sun. Frankly, I think Sun was silly. The plugin was a whole work, that served a coherent purpose all by itself. Novell had designed and implemented that component, and was perfectly willing and motivated to maintain it. In that case, it makes sense to me that Sun should have been willing to make space for Novell’s great work, leaving it as Novell’s. Instead, they ended up redoing that work, and lots of people felt hard done by. But that’s an uncommon case. The more usual scenario is that a contribution enhances the core, but is not in itself valuable without the rest of the code in the project being there.

Of course, “value” is relative. A patch that only applies against an existing codebase still has value in its ability to teach others how to do that kind of work. And it has value as art – you can put it on a t-shirt, or a wall.

But contributing – really contributing, actually donating – a patch to a maintainer doesn’t have to reduce those kinds of value to the original creator. I consider it best practice that a donation be matched by a wide license back. In other words, if I give my patch to the maintainer, it’s nice if they grant me a full set of rights back. While does a bad job with many other things, the Canonical contribution agreement does this: when you make a contribution under it, you get a wide license back. So that way, the creator retains all the useful rights, including the ability to publish, relicense, sell, or make a t-shirt, without also carrying all the responsibilities that go with ownership.

Vì thế một thỏa thuận đóng góp được làm tốt có thể làm rõ ai gánh vác các trách nhiệm đó, và không giảm bớt một cách hữu hình các quyền của những người mà đang đóng góp. Và một chính sách được làm tốt về sự đóng góp có thể nhận thức được rằng có những trường hợp không bình thường, nơi mà một sự đóng góp trong thực tế bản thân nó là một miếng toàn phần, và không đòi hỏi sự tài trợ đối với miếng toàn phần đó để trở thành một phần của một tổng thể tổng hợp.

Thế còn những trường hợp nơi mà không có người duy trì hoặc người chủ sở hữu một cách rõ ràng thì sao?

Vâng, ngoài thế giới bản quyền và mã nguồn, chúng tôi có một số mô hình để tham chiếu tới. Ví dụ, các công ty đưa ra các cổ phần cho các nhà đầu tư của họ, phản ánh sự đóng góp tương ứng của họ và vì thế cả quyền sở hữu cổ phần tương ứng trong công ty. Những công ty đó kết thúc với các chủ sở hữu đa dạng, mỗi người trong số đó sẽ có các ý kiến, những ưu tiên, những ý tưởng và những ràng buộc của riêng họ.

Chúng tôi có lẽ không bao giờ nghĩ phải yêu cầu sự đồng thuận về từng quyết định của ban lãnh đạo, hoặc công ty, trong số tất cả những cổ đông. Điều đó có thể không làm việc được - trong thực tế, nhiều bộ máy điều hành công ty tồn tại một cách đặc biệt để trao tiếng nói cho những mong muốn của các cổ đông trong khi cùng lúc giữ cho các cơ sở hoạt động được. Điều đó không nói lên rằng các cổ đông không bị lạm dụng - có đủ các trường hợp điển hình về quản lý tận dụng được các vị thế của họ để điền vào một cuốn sổ lợi nhuận dài lâu và ốm yếu. Các qui định về điều hành công ty, và đặc biệt sự bảo vệ những lợi ích của thiểu số trong các công ty, cũng như sự hiện đại của những thỏa thuận có tính xây dựng của các cổ đông để đạt được cùng các mục tiêu y hệt, vẫn luôn luôn tiến hóa. Nhưng cuối ngày, các quyết định cần phải được thực hiện mà là sự ràng buộc vào công ty và vì thế ràng buộc vào những cổ đông. Các quyền sở hữu mở rộng tới quyền chỉ ra và được thể hiện, và để tham gia vào sự thảo luận, và thường là một tiếng nói của một số dạng. Vì thế quyết định được thực hiện va (thường) đa số sẽ gánh vác.

Trong tâm lý chuyên chế của chúng tôi, chúng tôi có xu hướng nghĩ rằng một dòng lệnh duy nhất, hoặc một bản vá nhỏ duy nhất, mang theo cùng sức nặng như phần còn lại của một kho mã nguồn cố kết. Dễ dàng để cảm thấy cách này: khi một bản vá nhỏ được chia sẻ, nhưng không được tài trợ, thì người sáng tạo vẫn còn nguyên một mình quyền sở hữu của bản vá đó. Vì thế về lý thuyết, bất kỳ sự thay đổi nào ở tình trạng tổng thể phải đòi hỏi sự tán thành của từng người chủ sở hữu. Điều này là hơn cả lý thuyết - đây là luật trong nhiều chỗ.

Nhưng trong thực tế, tiếp cận đó không chịu nổi bất kỳ kiểm thử khắc nghiệt nào.

So a well-done contribution agreement can make clear who carries which responsibilities, and not materially diminish the rights of those who contribute. And a well-done policy of contribution would recognise that there are uncommon cases, where a contribution is in fact a whole piece in itself, and not require donation of that whole piece in order to be part of an aggregate whole.

What about cases where there is no clear maintainer or owner?

Well, outside of the world of copyright and code, we do have some models to refer to. For example, companies issue shares to their shareholders, reflecting their relative contribution and therefor relative shared ownership in the company. Those companies end up with diverse owners, each of whom is going to have their own opinions, preferences, ideals and constraints.

We would never think to require consensus on every decision of the board, or the company, among all shareholders. That would be unworkable – in fact, much of the apparatus of corporate governance exists specifically to give voice to the desires of shareholders while at the same time keeping institutions functional. That’s not to say that shareholders don’t get abused – there are enough case studies of management taking advantage of their position to fill a long and morbidly interesting book. Rules on corporate governance, and especially the protection of minority interests in companies, as well as the state of the art of constructing shareholder agreements to achieve the same goals, are constantly evolving. But at the end of the day, decisions need to be taken which are binding on the company and thus binding on the shareholders. The rights of ownership extend to the right to show up and be represented, and to participate in the discussion, and usually a vote of some sort. Thereafter, the decision is taken and (usually) the majority will carries.

In our absolutist mentality, we tend to think that a single line of code, or a single small patch, carries the same weight as the rest of a coherence codebase. It’s easy to feel that way: when a small patch is shared, but not donated, the creator retains sole ownership of that patch. So in theory, any change in the state of the whole must require the agreement of every owner. This is more than theory – it’s law in many places.

But in practice, that approach has not withstood any hard tests.

Có nhiều trường hợp nơi mà các công việc lớn khổng lồ, gồm các “bản vá” tổng hợp của nhiều chủ sở hữu khác nhau, từng được cấp phép lại. Mozilla, Ubuntu wiki, và tôi nghĩ thậm chí Wikipedia tất cả đã trải qua các qui trình công khai để chỉ ra cách để chuyển giấy phép của một công việc tổng hợp sang thứ gì đó mà sự lãnh đạo của dự án được coi là phù hợp hơn.

Tôi có thiện chí để đánh cược rằng, nếu một số lỗi pháp lý sống còn đã được hé lộ trong GPLv2, thì Linus có thể dẫn dắt một qui trình rà soát lại và thảo luận và tranh luận về những gì phải làm về nhân Linux, có thể là phật ý hay kiện tụng, nhưng cuối cùng ông có lẽ quyết định và hầu hết tuân theo một giấy phép mới và tốt hơn. Cá nhân mà nói, tôi là một người bảo vệ GPLv3, nhưng cuối cùng được biết rõ rằng tôi không phải là một cổ đông lớn trong công ty đặc biệt đó, nên để nói, nên tôi có thể không trông chờ có được bất kỳ tiếng nói nào. Những người mà đã không muốn tuân theo có thể tự họ từ chức để các đóng góp của họ được thay thế, và hầu hết có thể không gây phiền để tạo ra một cuộc họp, đưa ra sự tán thành không bằng lời.

There are multiple cases where huge bodies of work, composed of the aggregate “patches” of many different owners, have been relicensed. Mozilla, the Ubuntu wiki, and I think even Wikipedia have all gone through public processes to figure out how to move the license of an aggregate work to something that the project leadership considered more appropriate.

I’d be willing to bet that, if some fatal legal flaw were discovered in the GPLv2, Linus would lead a process of review and discussion and debate about what to do about the Linux kernel, it would be testy and contentious, but in the end he would take a decision and most would follow to a new and better license. Personally, I’d be an advocate of GPLv3, but in the end it’s well known that I’m not a big shareholder in that particular company, so to speak, so I wouldn’t expect to have any say Those who did not want to follow would resign themselves to having their contributions replaced, and most would not bother to turn up for the meeting, giving tacit assent.

Vì thế quan điểm thông thái rởm của chúng tôi rằng mỗi dòng mã lệnh là thiêng liên không được giữ dưới áp lực của thế giới thực. Các dự án PHẢI trả lời cho những thay đổi chủ chốt trong thế giới xung quanh chúng. Có thể sẽ không khôn ngoan để cho vay một bản vá cho một dự án với tin tưởng rằng dự án sẽ không bao giờ, theo bất kỳ hoàn cảnh nào, ra một quyết định khác với các quan điểm cá nhân của họ. Cuộc sống không thích thế. Thay đổi là không thể tránh khỏi, và chúng tôi tất cả chỉ bị rung động về một số tập hợp con của thay đổi đó.

Và đó là thứ như nó cần phải thế. Việc đeo bám vào thứ gì đó nhỏ là một phần của cuộc sống và kế sinh nhai của ai đó khác sẽ không lành mạnh. Tốt hơn hoặc gửi tới một tiếp cận quyền sở hữu được chia sẻ hợp lý, mà có sự thiện chí để chỉ ra tại cuộc họp, đóng góp và duy trì và chấp nhận thiện chí của đa số về những dịch chuyển chủ chốt có thể là không ngon lành, hoặc làm một món quà thực sự không đi với chuỗi gắn kèm nào.

Đôi khi tôi thấy mọi người nói họ hạnh phúc để tài trợ miễn là nó có một số ràng buộc có liên quan tới việc đó.

Có một gia đình ở Nam Phi đã sống trong những hoàn cảnh kỳ dị nhiều thế hệ vì một tổ tiên giàu có đã chỉ định rằng họ phải làm điều đó nếu họ muốn truy cập tới gia tài của họ. Điều đó gọi là “qui định từ nấm mồ”, và điều đó thực sự là hoàn toàn phi xã hội. Hoặc bạn cho ai đó những gì bạn đang cho họ, và chấp nhận rằng họ sẽ mang những quyền và trách nhiệm đó một cách không ngoan và tốt, hoặc bạn đừng trao nó cho họ hoàn toàn. Bạn đừng có loanh quanh sau khi thiện chí của bạn được thực hiện, và không thể biết trước mọi thứ có thể xảy ra. Điều này cực kỳ không hay, theo quan điểm của tôi, để làm cho mọi người bị kẹt.

So our pedantic view that every line of code is sacred just would not hold up to real-world pressure. Projects have GOT to respond to major changes in the world around them. It would be unwise to loan a patch to a project in the belief that the project will never, under any circumstances, take a decision that is different to your personal views. Life’s just not like that. Change is inevitable, and we’re all only going to be thrilled about some subset of that change.

And that’s as it should be. Clinging to something small that’s part of someone else’s life and livelihood just isn’t healthy. It’s better either to commit to a reasonable shared ownership approach, which involves being willing to show up at meetings, contribute to maintenance and accept the will of the majority on major moves that might be unpalatable anyway, or to make a true gift that comes with no strings attached.

Sometimes I see people saying they are happy to make a donation as long as it has some constraints associated with it.

There was a family in SA that lived under weird circumstances for generations because a wealthy ancestor specified that they had to do that if they wanted access to their inheritance. It’s called “ruling from the grave”, and it’s really quite antisocial. Either you give someone what you’re giving them, and accept that they will carry those rights and responsibilities wisely and well, or you don’t give it to them at all. You’re not going to be around after your will is executed, and it’s impossible to anticipate everything that might happen. It’s exceedingly uncool, in my view, to leave people stuck.

Thật khó để dự đoán, trong thời gian 50 hay 100 năm nữa, định nghĩa về “tính mở” sẽ là gì, và ai sẽ có sự định nghĩa mà bạn có thể đồng ý nhất. Trong ngắn hạn tất cả chúng ta có sự yêu thích, nhưng mỗi 5 năm hay 10 năm thế giới thay đổi và điều đó xô đẩy một vòng các định nghĩa, giấy phép, khái niệm mới. Hãy coi GPLv2 và GPLv3, nơi mà hóa ra là một nhu cầu thực để giải quyết những thách thức mới theo cách của phần mềm tự do đang được sử dụng. Hoặc Tuyên ngôn Đường phố của Franklin, về các dịch vụ web. Bất chấp có những ý kiến như AGPL, vẫn chưa có bất kỳ sự đồng thuận nào về cách tốt nhất để quản lý các kịch bản đó như thế nào.

Một người có thể chọn các cơ quan, những các cơ quan cũng thay đổi. Hãy ngoảnh lại và nhìn vào các vị trí lịch sử của bất kỳ đảng chính trị dài hạn nào, như UK Whigs, và bạn sẽ thú vị với cách mà một nhóm có thể dịch chuyển các vị trí của họ qua một sự thành công của những người lãnh đạo. Tôi hoàn toàn tin vào FSF ngày hôm nay, nhưng ý tưởng nhỏ điều gì sẽ xảy ra trong vòng 100 năm nữa. Điều đó không phải là bôi xấu gì FSF, chỉ là một bài học mà tôi đã học được từ việc nhìn vào các mẫu hành xử của các cơ quan về dài hạn mà thôi. Nó là y hệt đối với OSI hoặc Creative Commons hoặc bất kỳ nhóm chính trị hoặc tư tưởng hoặc tập đoàn nào khác. Mọi người di chuyển, mọi người chết, thời gian thay đổi, các ưu tiên dịch chuyển, các nền kinh tế suy sụp và tan chảy, các liên minh và liên kết và cạnh tranh dịch chuyển địa hình địa thế tới điểm mà nhóm tự do ngày hôm nay sẽ là bảo thủ vào ngày mai hoặc ngược lại.

Vì thế, nếu một người định đặt các chuỗi gắn vào một tài trợ, người đó sẽ làm gì? Hãy nhặt một giấy phép đặc biệt chăng? Không có giấy phép hiện hành sẽ còn là phù hợp tuyệt vời hoặc hữu dụng hoặc quyến rũ vô hạn định. Hãy chọn một cơ quan chăng? Không có cơ quan nào là tự do về sự năng động của con người về lâu dài.

Nếu có một nơi tự nhiên để đặt bản vá, thì đó là với mã nguồn mà nó vá. Và thông thường, điều đó có nghĩa với cơ quan mà là sự thuê mướn neo đậu, tốt hơn hoặc tệ hơn. Và vâng, điều đó tạo ra các quyền thực sự mà có thể thực sự bị lạm dụng, hoặc ít nhất được sử dụng theo các cách thức mà một người có thể không chọn cho những dự án của riêng họ.

Và điều đó mang chúng tôi tới vấn đề khó nhất. Làm thế nào chúng tôi cảm thấy về thực tế là một công ty sở hữu kho mã nguồn có thể tạo ra các sản phẩm cả sở hữu độc quyền và mở từ mã nguồn đó/

Và kịch bản “nấm mồ” thực sự là một vấn đề, trong trường hợp của bản quyền cũng vậy. Khi mọi người đã tranh luận những thay đổi tới các kho mã nguồn có ở xung quanh trong khoảng thời gian bất kỳ, thì thật buồn nhưng có lẽ đúng thực sự rằng có những người đóng góp đã chết, và không để lại chăng chối gì cho cách mà công việc của họ sẽ được quản lý. Thường là như thế hơn là không phải thế, di sản theo yêu cầu sẽ không đủ chi cho những yêu cầu pháp lý có liên quan.

Lần đầu tiên tôi được yêu cầu phải ký một thỏa thuận đóng góp nhân danh Canonical, nó từng là vì một đối thủ cạnh tranh, và tôi đã từ chối. Tối nay, nó đã giày vò lương tâm tôi. Chúng tôi đã có lợi nhuận của một số công việc đáng kể từ đối thủ cạnh tranh đó, và vâng tôi đã từ chối trao cho họ ngược trở lại *một cách phù hợp* sự đóng góp khiêm tốn của riêng chúng tôi. Tôi thực lòng cảm thấy khủng khiếp, và ngày hôm sau đã ký thỏa thuận, và đã thay đổi nó thành chính sách của chúng tôi mà chúng tôi sẽ làm như thế, bất kể điều gì chúng tôi nghĩ về bản thân công ty. Vì thế chúng tôi bây giờ đã làm chúng cho hầu hết tất cả các đối thủ cạnh tranh của chúng tôi, và tôi cảm thất tốt về điều đó.

Đó là thứ yêu thuật về sự sáng tạo và quyền sở hữu. Nó tạo ra khả năng cho sự hào phóng. Bạn không thể thực sự trao thứ gì đó mà bạn không sở hữu, nhưng nếu bạn có, thì bạn đã làm một sự đóng góp đích thực. Một món quà là khác với một món vay nợ. Nó không đặt ra sự ràng buộc nào, nó trang bị cho người nhận và nó giải phóng người cho khỏi những trách nhiệm về quyền sở hữu. Chúng ta có xu hướng nghĩ rằng giải quyết các vấn đề của chúng ta để sản sinh ra một bản vá là thú vị cho chúng ta và hữu dụng cho chúng ta là một sự hào phóng. Không phải thế. Cơ hội cho sự hào phóng tới sau đó. Và trong hệ sinh thái của chúng ta, sự hào phóng là quan trọng. Nó nằm trong trái tim của đạo lý Ubuntu, và nó là quan trọng thậm chí giữa các đối thủ cạnh tranh, vì các đối thủ cạnh tranh bên ngoài hệ sinh thái của chúng ta sẽ không thể bị đánh nếu chúng ta không đem lại sự giúp đỡ lẫn nhau.

It’s difficult to predict, in 50 or 100 years time, what the definition of “openness” will be, and who will have the definition that you might most agree with. In the short term we all have favourites, but every five or ten years the world changes and that precipitates a new round of definitions, licenses, concepts. Consider GPLv2 and GPLv3, where there turned out to be a real need to address new challenges in the way free software is being used. Or the Franklin Street Declaration, on web services. Despite having options like AGPL around, there still isn’t any real consensus on how best to handle those scenarios.

One can pick institutions, but institutions change too. Go back and look at the historical positions of any long-term political party, like the UK Whigs, and you’ll be amazed at how a group can shift their positions over a succession of leaders. I have complete trust in the FSF today, but little idea what they’ll be up to in 100 years time. That’s no insult to the FSF, it’s just a lesson I’ve learned from looking at the patterns of behaviour of institutions over the long term. It’s the same for the OSI or Creative Commons or any other political or ideological or corporate group. People move on, people die, times change, priorities shift, economics ebb and flow, affiliations and alliances and competition shift the terrain to the point that today’s liberal group are tomorrows conservatives or the other way around.

So, if one is going to put strings attached to a donation, what does one do? Pick a particular license? No current license will remain perfectly relevant or useful or attractive indefinitely. Pick an institution? No institution is free of human dynamics in the long term.

If there’s a natural place to put the patch, it’s with the code it patches. And usually, that means with the institution that is the anchor tenant, for better or worse. And yes, that creates real rights which can be really abused, or at least used in ways that one would not choose for ones own projects.

And that brings us to the toughest issue. How should we feel about the fact that a company which owns a codebase can create both proprietary and open products from that code?

And the “grave” scenario really is an issue, in the case of copyright too. When people have discussed changes to codebases that have been around for any length of time, it’s a sad but real likelihood that there are contributors who have died, and left no provision for how their work is to be managed. More often than not, the estate in question isn’t sufficiently funded to cover the cost of legal questions concerned.

The first time I was asked to sign a contribution agreement on behalf of Canonical, it was for a competitor, and I declined. That night, it preyed on my conscience. We had the benefit of a substantial amount of work from this competitor, and yet I had refused to give them back *properly* our own modest contribution. I frankly felt terrible, and the next day signed the agreement, and changed it to be our policy that we will do so, regardless of what we think about the company itself. So we’ve now done them for almost all our competitors, and I feel good about it.

That’s the magical thing about creation and ownership. It creates the possibility for generosity. You can’t really give something you don’t own, but if you do, you’ve made a genuine contribution. A gift is different from a loan. It imposes no strings, it empowers the recipient and it frees the giver of the responsibilities of ownership. We tend to think that solving our own problems to produce a patch which is interesting to us and useful for us is the generosity. It isn’t. The opportunity for generosity comes thereafter. And in our ecosystem, generosity is important. It’s at the heart of the Ubuntu ethic, and it’s important even between competitors, because the competitors outside our ecosystem are impossible to beat if we are not supportive of one another.

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

letrungnghia.foss@gmail.com