Bruce Perens: Bạn cần bao nhiêu giấy phép nguồn mở?

February 16, 2009

By Bruce Perens

Theo: http://itmanagement.earthweb.com/osrc/article.php/3803101/Bruce-Perens-How-Ma...

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

Lời người dịch: Khi làm việc với phần mềm tự do nguồn mở, chúng ta thường không biết xoay sở thế nào với 73 loại giấy phép về chúng. Bài viết này của Bruce Perens dạy chúng ta làm thế nào để thoát khỏi những thứ đó mà vẫn đảm bảo đáp ứng được những mục tiêu kinh doanh của công ty và tránh được những vụ kiện cáo pháp lý về vi phạm bản quyền. Một tư vấn tuyệt vời cho các công ty.

Xem thêm: “Bruce Perens: Kết hợp GPL và phần mềm sở hữu độc quyền”, theo: http://vn.myblog.yahoo.com/ltnghia/article?mid=351&fid=-1&action=next 

Về tác giả: Bruce Perens là người tạo ra định nghĩa về nguồn mở, bản tuyên ngôn về nguồn mở và các tiêu chí cho việc cấp phép cho phần mềm nguồn mở. Perens đã đại diện cho nguồn mở tại Hội nghị thượng đỉnh thế giới của Liên hiệp quốc về xã hội thông tin theo yêu cầu của Chương trình phát triển của Liên hiệp quốc.

Tổ chứ Sáng kiến nguồn mở OSI, cho tới nay, đã phê chuẩn 73 giấy phép. Thực sự thì bạn cần bao nhiêu [giấy phép]? Nếu bạn là một công ty hoặc cá nhân sản xuất phần mềm nguồn mở, không cần hơn 4. Và bạn có thể đi cùng chỉ với 2 trong số đó.

Nhưng thực tế có 73 giấy phép là một vấn đề. Nhiều giấy phép này là không tương thích với nhau. Để hiểu được sự liên can của các phần mềm trộn lẫn theo 2 trong số các giấy phép này với nhau trong cùng một chương trình, bạn có thể phải học 5256 tổ hợp khác nhau!

Và điều tồi tệ nhất về điều này là, nó không phải là lỗi của tôi! Vâng, một phần. Khi tôi đã viết các luật lệ cho việc cấp phép nguồn mở vào năm 1997, như một tài liệu về chính sách của dự án Debian, không có nhiều người nắm lấy những gì mà chúng ta sau đó đã gọi làl “Phần mềm tự do” một cách nghiêm túc, và nó đã không nghĩ tới rằng 73 giấy phép khác nhau đã tuân theo với định nghĩa về nguồn mở của tôi có thể bao giờ đó được viết ra.

May thay, bạn không phải làm việc với nhiều trong số 73 giấy phép đó. Khi bạn cần phân phối hoặc sửa đổi các phần mềm mà theo một trong số đó, thì bạn sẽ cần hiểu cái giấy phép đó. Và đám người mà chỉ là những người sử dụng thì dễ dàng hơn: bạn thực sự không cần đọc một giấy phép nguồn mở chỉ để sử dụng phần mềm đó, vì các luật lệ mà tôi đã viết yêu cầu rằng giấy phép trao cho bạn quyền để sử dụng các phần mềm nguồn mở vì bất kỳ mục đích nào.

Việc hiểu các giấy phép thực sự không là một vấn đề của nguồn mở. Hầu hết các phần mềm được bảo vệ bản quyền và theo một vài dạng của giấy phép, và các giấy phép về phần mềm sở hữu độc quyền là nhiều độc hại hơn nhiều so với những giấy phép của nguồn mở.

Nhưng hầu hết các công ty, ngay cả những công ty lớn, còn chưa hoàn toàn có khả năng vượt qua được những liên can của việc cáp phép phần mềm. Tại cuộc họp tiếp theo của phòng của bạn, hãy hỏi có bao nhiêu người đã nháy vào chữ “Yes” (“Có”) trên một giấy phép của một website hoặc ứng dụng phần mềm khi làm việc. Sau đó, hãy hỏi có bao nhiêu người trong số đó được phép gõ vào một hợp đồng nhân danh công ty đó.

About the Author: Bruce Perens is the creator of the Open Source Definition, the manifesto of Open Source and the criterion for Open Source software licensing. Perens represented Open Source at the United Nations World Summit on the Information Society, at the request of the United Nations Development Program.

The Open Source initiative has, to date, approved 73 licenses. How many do you really need? If you're a company or individual producing Open Source software, no more than 4. And you can get along with just 2 of them.

But the fact that there are 73 licenses is a problem. Many of those licenses are incompatible with each other. To understand the legal implications of mixing software under two of those licenses together in the same program, you'd have to learn 5256 different combinations!

And the worst thing about this is, it's my fault! Well, partially. When I wrote the rules for Open Source licensing in 1997, as a policy document of the Debian project, not many people took what we then called “Free Software” seriously, and it was unthinkable that 73 different licenses that complied with my Open Source Definition would ever be written.

Fortunately, you don't have to deal with many of those 73 licenses. When you need to distribute or modify software that is under one of them, you'll need to understand that one. And folks who are just users get off easy: you don't really need to read an Open Source license just to use the software, because the rules I wrote require that the license give you the right to use Open Source software for any purpose.

Understanding licenses isn't really an Open Source issue. Most software is copyrighted and under some sort of license, and the licenses on proprietary software are much more pernicious than those on Open Source.

But most companies, even large ones, aren't yet completely able to cope with the implications of software licensing. At your next departmental meeting, ask how many people have clicked “Yes” on a license of a web site or software application while at work. Then, ask how many of those folks are authorized to enter into a contract on behalf of the company.

Hãy xem xét vấn đề chăng?

Để hiểu có bao nhiêu giấy phép nguồn mở mà bạn thực sự cần, điều quan trọng là thiết lập một vài mục tiêu. Trước tiên, các giấy phép tất cả phải tương thích với nhau. Sẽ không có điểm nào trong việc cấp phép cho nguồn mở của riêng công ty của bạn mà nó không tương thích với các phần mềm nguồn mở khác từ công ty của bạn. Và thứ hai, các giấy phép phải thi hành một loạt những mục tiêu kinh doanh khác nhau cho nguồn mở.

Nguồn mở có những mục tiêu kinh doanh ư? Nếu bạn là một doanh nghiệp. Có 2 mục tiêu chính là:

• Làm cho mỗi người có khả năng sử dụng phần mềm của bạn để làm những thứ theo đúng cách y như vậy:

Ví dụ, nếu bạn đang tạo ra một tiêu chuẩn mà bạn muốn mọi người sử dụng bất luận liệu phần mềm của riêng họ là nguồn mở hay sở hữu độc quyền. Vài năm trước, một nhà sản xuất phần mềm thiết kế mạng điện đã tạo ra một định dạng tệp tiêu chuẩn cho thiết kế mạng điện, và đã phân phối phần mềm nguồn mở mà các xưởng sản xuất chip mạng có thể sử dụng để đọc được định dạng đó theo giấy phép BSD, mà nó không có hạn chế nào đáng kể cả.

Vì các đối thủ cạnh tranh của công ty cũng có thể sử dụng cùng định dạng này với các phần mềm của họ, các xưởng đã có được sự khích lệ để triển khai định dạng này và đơn giản hoá những việc vận hành của họ. Vì thế, nhà sản xuất phần mềm thiết kế mạng điện này đã đảm bảo rằng kết quả phần mềm của họ về cơ bản có thể sử dụng được với tất cả các xưởng sản xuất chip.

• Để tạo ra một quan hệ đối tác cho sự phát triển phần mềm, nơi mà mọi người chia sẻ công việc:

Khoảng 14 năm trước, tôi đã tạo ra bộ công cụ cho các hệ thống nhúng của Busybox cho Linux. Tôi đặt nó trong một tháng chuyên buổi tối cho dự án, mà là để xây dựng một môi trường dòng lệnh có thể khớp trên chỉ một đĩa mềm, cho trình cài đặt của phát tán GNU/Linux Debian. Tôi đã tung ra sản phẩm này theo giấy phép GPL.

See the problem?

To understand how many Open Source licenses you really need, it's important to set some goals. First, the licenses must all be compatible with each other. There's no point in licensing your own company's Open Source so that it’s not compatible with other Open Source f-rom your company. And second, the licenses should fulfill the various different business purposes for Open Source.

Open Source has business purposes? If you're a business. The two main ones are:

• To get everyone possible to use your software to do things the same way:

For example, if you're creating a standard that you'd like everyone to use regardless of whether their own software is Open Source or proprietary. Some years ago, a manufacturer of circuit design software cre-ated a standard file format for circuit designs, and distributed Open Source software that circuit chip foundries could use to read that format under the BSD license, which has no significant restrictions.

Because the company's competitors could also use the same format with their software, the foundries had an incentive to implement the format and simplify their operations. Thus, the circuit design software manufacturer was assured that their software's output would be usable with essentially all chip foundries.

• To cre-ate a partnership for software development, whe-re everybody shares in the work:

About 14 years ago, I cre-ated the Busybox embedded systems toolkit for Linux. I put in a month's worth of evenings on the project, which was to build a command-line environment that would fit on a single floppy disk, for the Debian GNU/Linux distribution's installer. I released the product under the GPL license.

Sau đó, các công ty hệ thống nhúng đã áp dụng Busybox vì việc làm như vậy đã trao cho họ một vài ưu thế về thời gian trên thị trường trong việc đặt các chào hàng sản phẩm của họ cùng nhau: Họ có thể không phải làm lại công việc của tôi. Vì tôi đã sử dụng GPL, những mở rộng của chúng đối với phần mềm của tôi cũng phải theo giấy phép tương thích với GPL, và phải được làm cho sẵn sàng ở dạng mã nguồn.

Các công ty Linux nhúng khác nhau đã chia sẻ công việc đó với nhau và với toàn bộ cộng đồng nguồn mở. Ít nhất công việc cho 5 người trong một năm đã được bổ sung cho chương trình này, và tất cả công việc đó là sẵn sàng cho bất kỳ ai sử dụng. Liêu việc tôi đã sử dụng một giấy phép mà không có việc chia sẽ và chia sẻ những thứ dự trữ sẵn như vậy của GPL, thì những công ty nhúng đó mới có thể giữ cho những bổ sung của họ cho bản thân họ như các phần mềm sở hữu độc quyền được không. Và điều đó có thể sẽ không làm cho họ tốt hơn nhiều, vì Busybox đã không thể có khác biệt về kinh doanh đối với các công ty này.

Subsequently, embedded systems companies adopted Busybox because doing so gave them some time-to-market advantage in putting their product offerings together: they wouldn't have to re-do my work. Because I'd used the GPL, their extensions to my software had to be under a GPL-compatible license too, and had to be made available in source-code form.

The various embedded Linux companies shared that work with each other and the entire Open Source community. At least 5 person-years of work have been added to that program, and all of that work is available for anyone to use. Had I used a license without the share-and-share-alike provisions of the GPL, those embedded companies would have kept their additions to themselves as proprietary software. And that wouldn't have done them much good, because Busybox wasn't business-differentiating for those companies.

Nên, các công ty mà muốn chia sẻ, nhưng không muốn đối thủ cạnh tranh của họ chạy khỏi công việc của họ mà không chia sẻ cho bản thân họ, sẽ tốt khi được tư vấn sử dụng một giấy phép như GPL.

Vì thế, từ 2 mục tiêu kinh doanh này, chúng ta có thể đi đến các dạng giấy phép chúng ta cần:

1. Một giấy phép “quà tặng”:

Đây là một giấy phép không có hạn chế có thể được, mà nó cho phép người được cấp phép kết hợp công việc này với cả phần mềm nguồn mở hoặc sở hữu độc quyền.

2. Một giấy phép “chia sẻ với những qui định”:

Điều này nói “hãy là đối tác của tôi” ngay cả đối với các công ty bạn không phải lúc nào cũng tin tưởng, ví dụ các đối thủ tệ nhất của bạn trên thị trường, vì nếu họ cải tiến sản phẩm này, thì họ phải chia sẻ.

3. Một giấy phép “trung gian”:

Cái này là cho việc tạo ra các thư viện phần mềm theo mẫu “chia sẻ với những qui định”, nhưng chúng sẽ sử dụng được trong các phần mềm sở hữu độc quyền.

Với 3 dạng giấy phép này, chúng ta có thể đáp ứng hầu hết các mục tiêu kinh doanh khác nhau mà chúng có thể có cho sự phát triển của nguồn mở.

So, companies that want to share, but don't want their competitor to run away with their work without themselves sharing, are well advised to use a license like the GPL.

So, f-rom those two business purposes, we can arrive at the sorts of licenses we need:

1. A “gift” license:

This is as unrestrictive as possible, which allows the licensee to combine the work with either Open Source or proprietary software.

2. A “sharing with rules” license:

This says “be my partner” even to companies you might not always trust, for example your worst competitors in the market, because if they improve the product, they have to share.

3. An “in-between” license:

This is for making software libraries under the “sharing with rules” paradigm, but which are usable in proprietary software.

With these three sorts of licenses, we can fulfill most of the different business purposes that there might be for an Open Source development.

Individuals and Open Source Projects

Các dự án và các cá nhân nguồn mở

Động lực cho các cá nhân, hơn là các công ty, là thứ gì đó khác biệt. Chúng là quan trọng vì công ty lớn nhất làm việc về nhân Linux trong một khảo sát gần đây, là “Không có Hội đoàn nào cả”. Những cá nhân đóng vai trò chủ chốt trong nhiều dự án nguồn mở quan trọng.

Một vài cá nhân mãn nguyện đưa ra tất cả phần mềm nguồn mở mà họ tạo ra như một quà tặng. Không phải tôi. Tôi sử dụng giấy phép dạng “quà tặng” khi tôi được trả tiền để làm thế, và nếu không thì là các giấy phép “chia sẻ với những qui định”.

Hầu hết là thế vì tôi không muốn trở thành một nhân viên không được trả tiền của một số công ty mà sử dụng công việc của tôi và không trả ngược lại gì cho cộng đồng nguồn mở. Tôi muốn mọi người mà mở rộng phần mềm của tôi để trao cho những mở rộng của họ cho thế giới để chia sẻ, đúng như cách mà tôi đã trao cho họ chương trình gốc ban đầu của tôi. Vì thế, sự lợi tức thu được từ sự đầu tư cho việc viết nguồn mở là việc phần mềm của tôi làm cho gia tăng tiếp tục về số lượng các phần mềm nguồn mở sẵn có, ngoài sự đóng góp của cá nhân tôi.

Có một động lực khác cho việc sử dụng một giấy phép “chia sẻ với những qui định” trong phần mềm mà tôi hiện đang xây dựng: giấy phép đôi (Dual Licensing).

Các công ty mà muốn kết hợp phần mềm mới của tôi với sản phẩm sở hữu độc quyền của riêng họ, mà không phải tuân thủ với giấy phép “chia sẻ với những qui định”, hãy trả tiền cho tôi vì một giấy phép thương mại. Giấy phép đó không đòi hỏi bất kỳ sự chia sẻ nào, và cho phép công việc của tôi sẽ kết hợp được với sản phẩm thương mại của họ. Nhưng họ có thể có được công việc y hệt như vậy vì tự do, như mọi người có thể, nếu họ có thể tuân thủ với giấy phép “chia sẻ với những qui định”.

The motivations for individuals, rather than companies, are somewhat different. They're important because the largest company working on the Linux kernel, in a recent survey, was “No Affiliation.” Individuals play key roles in many important Open Source projects.

Some individuals are content to give all the Open Source software they cre-ate away as a gift. Not me. I use “gift” licenses when I'm paid to do so, and “sharing with rules” licenses otherwise.

This is mostly because I don't want to be the unpaid employee of some company that uses my work and gives nothing back to the Open Source community. I want the people who extend my software to give their extensions to the world to share, the same way I gave them my original program. So, my payback for writing Open Source is that my software drives a further increase in the amount of available Open Source software, beyond my individual contribution.

There's another motivation for use of a “sharing with rules” license in the software I'm currently building: dual licensing.

Companies that want to combine my new software with their own proprietary product, without having to comply with my “sharing with rules” license, pay me for a commercial license. That license doesn't require any sharing, and allows my work to be combined with their commercial product. But they can get the same work for free, as can everyone, if they can comply with the “sharing with rules” license.

Vì thế, tôi được trả tiền để làm ra Open Office, và có thể cùng một lúc tặng nó. Liệu tôi có sử dụng giấy phép “quà tặng” hay không, khi các công ty có thể không có động lực để trả tiền cho giấy phép thương mại của tôi.

Giấy phép đôi là một thứ hơi phức tạp một chút hơn là sự phát triển nguồn mở thông thường, vì công ty mà đưa ra các giấy phép đôi cần sở hữu toàn bộ bản quyền của chương trình, hoặc quyền để cấp phép lại cho tất cả các đóng góp cho chương trình này. Cần thiết phải trao cho những người đóng góp một số dạng khuyến khích, nếu không họ nói chung sẽ rất muốn ký qua bản quyền của họ hoặc quyền đẻ cấp phép lại những đóng góp của họ.

Vì thế, chúng ta có 3 dạng giấy phép của chúng ta. Hãy bắt đầu ánh xạ những thứ đó với các giấy phép thực tế. 3 Giấy phép ưu tiên của tôi là:

1. Giấy phép quà tặng: như giấy phép Apache License 2.0

Điều này là tương tự đối với các giấy phép MIT và BSD, đưa ra ít nhiều sự bảo vệ từ các vụ kiện bằng sáng chế phần mềm đối với người lập trình phát triển nguồn mở.

2. Giấy phép chia sẻ với các qui định: GPL 3

Có nguồn gốc từ GPL, giấy phép nguồn mở phổ biến nhất, giấy phép này được cập nhật để làm việc với số lượng khổng lồ hơn về bản quyền và vụ án đang tồn tại ngày nay.

3. Giấy phép trung gian: LGPL3

Giấy phép này là rất giống với văn bản của GPL3, vì thế bạn không cần học giấy phép khác.

Tất cả 3 thứ này đều tương thích với nhau, theo tổ chức phần mềm tự do FSF và các cơ quan khác.

Tại thời điểm này, một vài sự ngẫu nhiên tình cờ của khán thính giả chỉ giơ tay của họ lên và hét ÊÊÊÊÊÊ! Vì sao anh ta sử dụng GPL3?????

GPL3, không may, đã giành được một uy tín tồi trong một số nhóm vì nó là tham vọng, và vì Linus Torvalds đã không thoải mái với nó. Sự không thoải mái của Linus bắt nguồn từ một vấn đề cá nhân, nên tôi có xu hướng bỏ qua cho ông ta trong trường hợp này.

Một trong những thứ tham vọng nhất về GPL3 là nó mong muốn cấm việc quản lý quyền số DRM. Hừm, liệu bạn đã lưu ý rằng tuyên bố mà iTunes sẽ không sử dụng DRM nữa không? Giữa buổi đầu của GPL3 tới hôm nay nó dường như là nhiều người hơn đã nhận thực được rằng DRM không là một ý tưởng lớn đến thế.

Thứ tham vọng khác mà GPL3 làm là việc nó khăng khăng rằng phần mềm trong một thiết bị nhúng phải sửa đổi được. Đây là thứ mà vì thế các hệ điều hành nguồn mở vẫn có thể trong tương lai.

Thus, I am paid to make Open Source, and can give it away at the same time. Had I used the “gift” license, companies would have no motivation to pay for my commercial license.

Dual licensing is a bit more complicated than the usual Open Source development, because the company that offers dual-licensing needs to own the entire copyright to the program, or the right to re-license all contributions to the program. It's necessary to give contributors some sort of incentive, or they generally aren't very willing to sign over their copyrights or the right to re-license their contributions.

So, we have our three sorts of licenses. Let's start to map those to real licenses. My preferred three are:

1. Gift license: The Apache License 2.0

This is similar to the MIT and BSD licenses, but provides a little more protection f-rom software patent lawsuits to the Open Source developer.

2. Sharing-with-rules license: GPL 3

Descended f-rom the GPL, the most popular Open Source license, this license is up-dated to deal with the vastly larger amount of copyright and case law that exists today.

3. In-between license: LGPL 3

This is very similar to the text of GPL 3, so that you don't need to learn another license.

All three are compatible with each other, according to FSF and other authorities.

At this point, some contingent of the audience has just thrown up their hands and shouted EEEEEwwww! Why's he using GPL3?????

GPL3, unfortunately, gained a bad reputation in some camps because it is ambitious, and because Linus Torvalds was uncomfortable with it. Linus' discomfort stems f-rom a personal issue, so I tend to discount him in this case.

One of the most ambitious things about GPL3 is that it attempts to prohibit DRM. Hmmm, did you notice that announcement that iTunes isn't going to use DRM any longer? Between the debut of GPL3 and today it seems that more people have realized that DRM isn't such a great idea.

The other ambitious thing that GPL3 does is that it insists that the software in an embedded device be modifiable in situ. This is so that Open Source operating systems are still possible in the future.

Bạn thấy đấy, chúng ta cần các máy tính để chạy chúng. Ngày nay, chúng ta có thể có được những bo mạch chủ rẻ cho các máy tính để bàn, dựa trên đó chúng ta có thể cài đặt Linux và các phần mềm tự do khác. Trong tương lai, mọi người sẽ không sử dụng máy tính để bàn nhiều như họ sử dụng các thiết bị nhúng như các điện thoại cầm tay và các thiết bị web. Vì thế, chúng ta muốn chắc chắn rằng chúng ta có thể chạy những phần mềm tự do mới trên những thiết bị nhúng mà chúng đã đi cùng với các phần mềm tự do ngay từ đầu.

Vì thế, 2 thứ tham vọng lớn của GPL3 là đáng để khen ngợi. Nhưng ưu điểm lớn nhất của GPL3 là sự chắc chắn về pháp lý của nó. Trong quá trình tạo ra GPL3, đúng là hàng tá các luật sư, từ các công ty lớn nhất thế giới, đã xem xét từng từ của giấy phép này. Không có giấy phép nào ở bất kỳ nơi đâu có được 1/10 việc xem xét pháp lý như đối với GPL3.

Vì thế, bạn có thể khá chắc chắn rằng nó sẽ thể hiện tại toà cái cách mà nó mong muốn được làm việc. Việc quản lý hàng tá các luật sư là khó khăn, nhưng Ric-hard Stallman đã công bằng trong công việc, giữ cho kết quả này đúng với đặc tính của phần mềm tự do.

Rất nhiều công ty thích giấy phép MPL, từ dự án của Mozilla, cho là tốt hơn. Nhưng MPL thực sự chỉ phù hợp như “giấy phép trung gian”; những điều khoản của nó sẽ không đủ mạnh để cung cấp môi trường chia sẻ với những qui định mà là cần thiết để bảo vệ một số sản phẩm.

Vấn đề chính của tôi với MPL không phải là ở bản thân giấy phép này, mà là ở rất nhiều giấy phép mà chúng có nguồn gốc từ giấy phép này, mỗi thứ với chút ít những khác biệt của riêng nó, làm cho vấn đề tổ hợp của các giấy phép nguồn mở tồi tệ đáng kể. Tổ chức phần mềm tự do đã sáng suốt làm bản quyền cho văn bản giấy phép của họ và kiên định rằng có thể sẽ chỉ có những thứ có nguồn gốc từ nó mới có thể được FSF phê chuẩn.

You see, we need computers to run them on. Today, we can get cheap motherboards for desktops, upon which we can install Linux and other Free Software. In the future, people won't use desktops as much as they use embedded devices like cell phones and web slates. So, we want to make sure that we can run new Free Software on embedded devices that already come with Free Software out of the box.

So, those two big ambitions of GPL3 are worthy of praise. But the biggest advantage of GPL3 is its legal solidity. During the creation of GPL3, literally dozens of attorneys, f-rom the world's largest companies, reviewed every word of the license. No license anywhe-re has had 1/10 of the legal review that went into GPL3.

So, you can be reasonably sure that it will perform in court the way it's intended to work. Managing dozens of attorneys is difficult, but Ric-hard Stallman was equal to the task, keeping the result in line with the ethos of Free Software.

A lot of companies like the MPL license, f-rom the Mozilla project, better. But MPL actually only fits in the place of the “in-between license”; its terms aren't strong enough to provide the sharing-with-rules environment that is necessary to protect some products.

My main problem with MPL is not the license itself, but the very many licenses that have been derived f-rom it, each with its own little differences, making the combinatorial problem of Open Source licenses significantly worse. FSF was smart to copyright their license text and maintain that there would be FSF-approved derivatives only.

Có thể dễ dàng đặt vào cùng một danh sách khác 3 giấy phép mà chúng thoả mãn những yêu cầu ở trên. Nhưng điều này là một thứ mà tôi nghĩ rằng hầu hết các công ty, và các dự án nguồn mở, phải sử dụng.

Tôi sẽ nắm lấy nhiều nhân viên từ những người mà họ theo giấy phép BSD, những người đang gắn bó với GPL2, những người thích một trong 70 giấy phép khác, vân vân. Nhưng những giấy phép này làm những việc tương tự với những giấy phép ở trên, trong khi lại ít phù hợp hơn về cách mà chúng vượt qua được môi trường ngày nay về bằng sáng chế và vi phạm bản quyền và tất cả các vụ kiện được xây lên xung quanh nó. Khi GPL2 được viết, thì còn chưa có một Internet như chúng ta biết ngày hôm nay, còn chưa có các bộ chơi MP3, và thiết bị đầu vào phức tạp nhất trong nhà của hầu hết mọi người là một điện thoại bấm tiếng.

Nếu chúng ta tất cả xây dựng các tập hợp của 3 giấy phép này cho riêng chúng ta, thì chúng ta sẽ có vấn đề tổ hợp đó khi chúng ta trộn nguồn mở của chúng ta với những thứ của những người khác. Chúng ta sẽ vẫn có 70 giấy phép khác nhau, rất nhiều trong số chúng được sử dụng rộng rãi. Bạn có thể giúp để giải quyết vấn đề này.

It's easily possible to put together another list of three licenses that satisfies the requirements above. But this is the one that I think that most companies, and Open Source projects, should use.

I'll catch a lot of flack f-rom people who are partisan to the BSD license, who are sticking with GPL2, who like one of the other 70, etc. But those licenses do similar things to the ones above, while being less up to date regarding how they cope with today's environment of patent and copyright infringement and all of the case law that has built up around it. When GPL 2 was written, there wasn't an Internet as we know it today, there weren't MP3 players, and the most complicated input device in most people's homes was a touch-tone phone.

If we all build our own sets of three licenses, we'll still have that combinatorial problem when we go to mix our Open Source with that of other people. We'll still have 70 different licenses, many of them in wide use. You can help to solve the problem.

Bạn sẽ tham gia cùng tôi chứ?

Tôi đã nói bạn đã cần 4 giấy phép là nhiều nhất, và đã thảo luận chỉ với 3. Cái thứ 4 có thể xem xét là Affero GPL3.

Giấy phép này là được thiết kế đặc biệt để giữ cho Googlel khỏi chạy mất với sản phẩm của bạn mà không có sự chia sẻ những cải tiến của họ cho nó. Vâng, thực sự, nó làm việc với vấn đề các phần mềm như một dịch vụ (SaaS). Dòng giấy phép GPL không đòi hỏi rằng mọi người chia sẻ mã nguồn cho tới khi họ thực sự phân phối phần mềm đó. Nhưng Google không phân phối các phần mềm, hãng làm việc đó trên site của riêng hãng.

Vì thế, một giấy phép phải được viết để vượt qua hiện tượng SaaS này. Nếu bạn muốn giữ giấy phép chỉ ở con số 3, thì bạn có thể sử dụng Affero GPL3 thay cho GPL3.. Văn bản của Affero GPL3 là rất tương tự với bản GPL3, nên một lần nữa, bạn thực sự không phải học một giấy phép hoàn toàn mới.

Vì thế, tập hợp của tôi bao gồm 2 giấy phép cơ bản: Apache 2.0 và GPL3, và 2 dẫn xuất của GPL3: LGPL3 và Affero GPL3. Để sử dụng chúng, bạn sẽ phải họ 2 giấy phép, và 2 tập hợp dẫn xuất trên một trong nhữ giấy phép đó. Tất cả chúng là tương thích với nhau. Một cách bất ngờ, nguồn mở không phức tạp như những tổ hợp 5256 của 2 trong số 73 giấy phép được phê chuẩn đâu nhé!

Will you join me?

I said you needed 4 licenses at most, and have only discussed 3. The 4th you might consider is Affero GPL3.

This license is specifically engineered to keep Google f-rom running away with your product without sharing their improvements to it. Well, actually, it deals with the software as a service problem. The GPL class of licenses does not require that anyone share source code until they actually distribute the software. But Google doesn't distribute software, it performs it on its own site.

So, a license had to be written to cope with the SaaS phenomenon. If you want to keep the license count down to 3, you can use Affero GPL3 in place of GPL3. The text of Affero GPL3 is very similar to that of the plain GPL3, so again, you don't really have to learn an entire new license.

So, my set includes two base licenses: Apache 2.0 and GPL3, and two derivatives of GPL3: LGPL3 and Affero GPL3. To use them, you'll have to learn two licenses, and two sets of variations on one of those licenses. All of them are compatible with each other. Suddenly, Open Source isn't as complicated as those 5,256 combinations of two of the approved 73 licenses!

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

letrungnghia.foss@gmail.com