5 thế lực dẫn dắt nguồn mở ngày nay - Phần 2

5 key forces driving open source today

Từ sự gia tăng của các quỹ tới sự nổi lên các mô hình doanh thu, phong trào nguồn mở mồi được cho tác động thậm chí còn lớn hơn trong các công nghệ của tương lai.

From the rise of foundations to emerging revenue models, the open source movement is primed for even greater impact on tomorrow's technologies

By Simon Phipps, October 15, 2012

Theo: http://www.infoworld.com/d/open-source-software/5-key-forces-driving-open-source-today-204429?page=0,1

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

Lời người dịch: Thế lực thứ 2 dẫn dắt sự phát triển của phong trào nguồn mở là sự lựa chọn các giấy phép nguồn mở. Cho tới nay, có hơn 70 loại giấy phép nguồn mở khác nhau. Các doanh nghiệp tham gia vào thế giới nguồn mở hầu hết có xu hướng chọn những giấy phép để đảm bảo cho những đóng góp độc quyền của họ, trong khi các cộng đồng lại không muốn những người chỉ biết lấy mà không biết cho. Chính vì vậy, sự chỉnh sửa các giấy phép sẽ vẫn tiếp tục diễn ra. Cho tới nay, giấy phép theo kiểu có đi có lại vẫn là lựa chọn lớn nhất trong thế giới phần mềm nguồn mở, với 68.9% trong tổng số khoảng 330.000 dự án phần mềm tự do nguồn mở tồn tại trên thế giới. Xem các phần [01], [02], [03], [04], [05].

2. The proliferation of open source licensing choices

2. Sự nở rộ các lựa chọn cấp phép nguồn mở

Một động lực chủ chốt khác của phong trào nguồn mở hôm nay là số lượng lớn các lựa chọn cấp phép có sẵn và cách mà sự lựa chọn giấy phép nguồn mở đang thay đổi, nhờ vào sự tham gia ngày một gia tăng từ các tổ chức tập đoàn nhận thực được tầm quan trọng của cộng đồng.

Tất cả những lợi ích một cách tự động của phần mềm từ sự bảo vệ bản quyền đối với tác giả của nó, trao cho nó sự kiểm soát đối với những ai có thể tạo ra các bản sao của mã nguồn hoặc các tác phẩm phái sinh, bao gồm cả những trích lọc ra nguồn và các tệp nhị phân được biên dịch. Vì phiên bản chạy được của phần mềm phải được sao chép vào một máy tính để được sử dụng và trong bộ nhớ để được chạy, điều cần thiết phải có một giấy phép từ người nắm bản quyền cho bất kỳ sự sử dụng nào của phần mềm.

Trong những ngày đầu của nguồn mở, từng có 2 lựa chọn phổ biến cho việc cấp phép bản quyền. Mọi người chia sẻ quan điểm thực dụng làm-những-gì-bạn-muốn của Bill Joy đối với các giấy phép được chọn như một người sử dụng trong Phát tán Hệ thống Berkeley Unix – BSD (Berkeley System Distribution) mà ông đi tiên phong. Những người khác chia sẻ quan điểm của Richard Stallman rằng sự tự do của phần mềm đòi hỏi thiết kế kỹ thuật xã hội chọn Giấy pháp Công cộng Chung – GPL mà ông đã đặt ra cho dự án GNU của ông - cái gọi là vì nó là một giấy phép có lợi cho công chúng nói chung.

Sự áp dụng các ý tưởng đó của các doanh nghiệp từng là một động lực chính cho việc tạo ra Định nghĩa Nguồn Mở như một công cụ cho việc phân loại các giấy phép như là nguồn mở. Vào năm 1998 từng rõ ràng rằng những người khác đã muốn nhân bản kinh nghiệm của dự án Mozilla và tuyên bố tác phẩm của họ là “tự do” trong khi thường không xét tới nhu cầu phân phối quyền tự do của phần mềm, như nhiều doanh nghiệp trong nền công nghiệp thực phẩm ngày nay tìm cách sử dụng khái niệm “hữu cơ” mà không có việc phân phối trong chỉnh thể luận đằng sau khái niệm đó. Để đấu tranh với điều này, Sáng kiến Nguồn Mở - OSI (Open Source Initiative) đã được thành lập để thúc đẩy khái niệm “nguồn mở” để đánh tín hiệu cho phần mềm thực sự “tự do”. Từ thời điểm đó, chỉ những giấy phép nào trao cho bất kỳ ai sự tự do để sử dụng, nghiên cứu, sửa đổi và phân phooiis phần mềm đó mới có thể được OSI như là một đại diện, phê chuẩn.

Các doanh nghiệp mong muốn tránh sử dụng GPL đã có xu hướng đi theo ví dụ của dự án Mozilla và đã tạo ra giấy phép của riêng họ. Kết quả là, hơn 60 giấy phép mới đã được OSI phê chuẩn trong những năm đầu của kỷ nguyên nguồn mở. Nhưng sự nở rộ này đã đi với một chi phí. Các giấy phép nguồn mở thường không pha trộn được; khi bạn tạo một cái riêng cho bạn, thì bạn kết án dự án của bạn tới sự cô lập. Việc tạo một giấy phép như thế là một vấn đề nảy sinh từ một sự hiểu sai cơ bản về vai trò của giấy phép trong nguồn mở, việc đối xử với nó như một thỏa thuận pháp lý đôi bên theo truyền thống. Thay vào đó, một giấy phép nguồn mở là một thỏa thuận đa phương, “hiến pháp cho cộng đồng”, như Eben Moglen từng đưa ra.

Trong những năm gần đây, những dự án mới đã nhận thức được nhiều hơn về vai trò của giấy phép trong việc xúc tác cho sự hình thành và vận hành của cộng đồng. Kết quả là đã có một xu thế hướng tới các giấy phép tự do như Apache License hoặc các giấy phép BSD/MIT, vì thế việc loại bỏ được các rào cản được thừa nhận đối với sự tham gia đối với những người đóng góp là các tập đoàn. OpenStack, ví dụ, sử dụng việc cấp phép tự do.

Thậm chí vẫn có những dự án sử dụng giấy phép BSD có những lúc chống lại các tập đoàn sử dụng tác phẩm của họ mà không có sự đóng góp, gợi ý vẫn có một vai trò cho copyleft. Hầu hết các cộng đồng bị mất lòng khi một người tiêu dùng có ích lợi tác phẩm của họ tất cả đều lấy mà không cho. Ý nghĩa về sự công bằng này có khả năng đẩy cái kim từng đung đưa hết cỡ từ GPL sang BSD ngược về với mặt đất trung gian, được thể hiện tốt nhất bằng giấy phép MPLv2 được rà soát lại gần đây.

MPLv2 là hoàn toàn tương thích với GPL, và nó không có các mệnh đề ngăn cản việc trộn lẫn với các giấy phép tự do, đưa nó đồng hành với những cảm giác của hầu hết các cộng đồng nguồn mở ngày nay. Nó bao gồm một yêu cầu copyleft yếu rằng những thay đổi tới các tệp được dự án quản lý phải được xuất bản, nhưng nó cho phép các lập trình viên sự tự do hoàn toàn để sử dụng các tệp nhị phân được biên dịch bất kỳ cách gì họ muốn, bao gồm việc trộn lẫn chúng với mã nguồn không phải là nguồn mở để tạo ra các sản phẩm sở hữu độc quyền.

Another key driver of today's open source movement is the sheer volume of available licensing choices and how choice of open source license is changing, thanks to increased participation from corporate organizations that recognize the importance of community.

All software automatically benefits from copyright protection for its author, giving her control over who can make copies of the source code or derivatives, including extracts of source and compiled binaries. Since the executable version of software has to be copied onto a computer to be used and into memory to be executed, it's necessary to have a license from the copyright holder for any use of the software.

In the earliest days of open source, there were broadly two choices for licensing copyright. People sharing Bill Joy's pragmatic do-what-you-want outlook picked licenses like the one used on the Unix Berkeley System Distribution (BSD) he pioneered. Others sharing Richard Stallman's view that software freedom demands social engineering picked the General Public License he devised for his GNU Project -- so called because it is a license benefiting the general public.

The adoption of these ideas by businesses was a key motivation for creating the Open Source Definition as a tool for categorizing licenses as open source. In 1998 it was clear that others wanted to replicate the experience of the Mozilla project and declare their work "free" while frequently disregarding the need to deliver software freedom, much as many businesses in today's food industry seek to use the term "organic" without delivering on the holism behind the term. To combat this, the Open Source Initative was formed to promote the term "open source" to signal truly "free" software. From that point, only licenses granting anyone freedom to use, study, modify, and distribute the software would be approved by OSI as representing.

Businesses wishing to avoid using the GPL tended to follow the example of the Mozilla project and created their own license. As a result, over 60 new licenses were approved by OSI in the first few years of the open source era. But this proliferation has come with a cost. Open source licenses often don't mix; when you make your own, you condemn your project to isolation. Creating a new license like this is a problem that arises from a fundamental misunderstanding of the role of the license in open source, treating it as a traditional bilateral legal agreement. Instead, an open source license is a multilateral agreement, "the constitution for the community," as Eben Moglen once put it.

In recent years, new projects have been much more aware of the role of the license in enabling community formation and function. The result has been a trend toward liberal licenses such as the Apache License or the BSD/MIT licenses, thereby eliminating perceived barriers to participation for corporate contributors. OpenStack, for example, uses liberal licensing.

Yet even projects that use the liberal BSD Unix license have at times railed against corporations who use their work without contribution, suggesting there's a role for copyleft, too. Most communities are offended when a profitable consumer of their work is all take and no give. This sense of justice will likely push the needle that has swung full-scale from GPL to BSD back to the middle ground, best represented by the recently revised Mozilla Public License, MPLv2.

MPLv2 is explicitly compatible with the GPL, and it contains no clauses that prevent mingling with liberal licenses, aligning it with the sensibilities of most of today's open source communities. It does include a weak copyleft requirement that changes to files managed by the project must be published, but it allows developers complete freedom to use the compiled binaries any way they want, including mixing them with non-open-source code to create proprietary products.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com