Suy nghĩ về phần mềm nguồn mở giấy phép đôi

Thoughts about Dual – licensing Open Source software

2009-08-04

By Michaela “Monty” Windenius

Theo: http://monty-says.blogspot.com/2009/08/thoughts-about-dual-licensing-open.html

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

Lời người dich: Một bài viết tuyệt vời về cách cấp giấy phép đôi cho các phần mềm nguồn mở của các công ty muốn kinh doanh dựa trên các phần mềm nguồn mở.

Lịch sử

Ví dụ đầu tiên về giấy phép đôi cólex là Ghostscript, mà Peter Deutsch đã cấp phép lần đầu theo GPL và sau này theo Aladdin Free Public License, nhưng cũng theo một giấy phép sở hữu độc quyền. Được truyền cảm hứng bởi ý tưởng của ông, David Axmark và tôi đã tung ra MySQL theo các điều khoản giấy phép đôi tương tự. Giấy phép đôi từ đó đã trở thành một trong những cách thức phổ biến và chung nhất để tạo ra các trung tâm lợi nhuận xung quanh phần mềm tự do nguồn mở, bổ sung cho sự hỗ trợ và các dịch vụ xung quanh sản phẩm.

Để có khả năng khởi động MySQL Ab, chúng tôi ban đầu đã có một giấy phép mà đã cho phép sử dụng một cách tự do, nhưng còn có một giấy phép “trả tiền” nếu bạn sử dụng MySQL cho mục đích sử dụng thương mại hoặc trên nền tảng Windows. Trong năm 2000 chúng tôi đã thay đổi giấy phép tự do này sang GPL, hầu hết để tránh phải giải thích cho mọi người về giấy phép riêng của chúng tôi.

Ý tưởng cơ bản cho giấy phép đôi của chúng tôi là thế này: Nếu bạn đã mua một giấy phép rồi sau đó chúng tôi đã từ bỏ hạn chế của GPL mà bạn phải phân phối lại mã nguồn của bạn như GPL. Bạn có thể thay đổi, sửa đổi, mở rộng, phân phối, và phân phối lại bản sao đó theo cách bất kỳ bạn muốn. (nhưng tất nhiên không thay đổi giấy phép về mã nguồn của MySQL). Giấy phép này là đối với bất kỳ phiên bản và sự sử dụng nào của MySQL, bây giờ và vĩnh viễn.

Điều này vẫn còn được phản ánh trong MySQL FAQ (xem đường link bên dưới) về chủ đề này.

Đây là những gì cá nhân tôi nghĩ là các thức sở hữu độc quyền đối với phần mềm nguồn mở giấy phép đôi và cách mà chúng tôi mong đợi làm nó trong công ty mới của tôi, Monty Program Ab, cho các phần mềm mà chúng tôi sản xuất.

History

The first example of dual-licensing was probably Ghostscript, which Peter Deutsch licensed first under the GPL and later under the Aladdin Free Public License, but also under a proprietary license.
Inspired by his idea, David Axmark and I released MySQL under similar dual-licensing terms. Dual licensing has since become one of the most common and popular ways to create profit centers around Open Source/Free Software, in addition to support and services around the product.

To be able to bootstrap MySQL Ab, we originally had a license that allowed free usage, but a "pay-for" license if you used MYSQL for commercial usage or on the Windows platform. In 2000 we changed the free license to GPL, mostly to avoid having to explain our own license to everyone.

The basic idea for our dual-licensing was this: if you bought a license then we waived the GPL restriction that you have to redistribute your code as GPL. You could change, modify, extend, distribute, and redistribute the copy in any way you wanted (but of course not change the license of the MySQL code). The license was for any version and usage of MySQL, for now and forever.

This is still reflected in the MySQL FAQ on this topic.

This is what I personally think is the appropriate way to dual-license open source software and how we intend to do it in my new company, Monty Program Ab, for the software we produce.

Giấy phép MySQL cho các nhà sản xuất thiết bị gốc (OEM)

Gần đây tôi đã nhận thức được rằng thứ ở trên không còn là trường hợp với thoả thuận của MySQL cho các OEM nữa. Bây giờ Sun, mặc định, đang đặt ra những hạn chế sau đây lên những người được cấp phép:

(Sun có, tất nhiên, tất cả các quyền để đặt ra bất kỳ hạn chế nào lên mã nguồn của họ, nhưng khi điều này là không phải là cách mà các giấy phép đôi sử dụng để làm việc với MySQL hoặc cách mà nó làm việc với các dự án nguồn mở khác (Xem ví dụ, thông ti về giấy phép cho Ghostscript theo đường link bên dưới)). Tuy nhiên, bạn phải nhận thức được những vấn đề này nếu bạn mong đợi để có được bao giờ đó một giấy phép thương mại cho MySQL).

• Bạn không thể sửa đổi MySQL theo cách (ví dụ để sửa lỗi, tối ưu hoá MySQL cho các ứng dụng của bạn, bao gồm những cải tiến sẵn có một cách công khai (như khi BSD được cấp cho “bản vá của Google” hoặc biên dịch nó với máy lưu trữ khác) để cải thiện MySQL của bạn như một phần của sản phẩm của bạn.

• Bạn không thể sử dụng bất kỳ rẽ nhánh nào của MySQL (như Drizzle, ExtSQL hoặc MariaDB).

• Bạn bị trói vào phiên bản chính hiện hành của MySQL Enterprise (nghĩa là bạn phải trả tiền cho những nâng cấp). Điều này có thể là thông thường trong một môi trường nguồn đóng, nhưng lại không thông thường khi nó là nguồn mở.

• Có những hạn chế nghiêm trọng đối với dạng các ứng dụng mà bạn có thể xây dựng với mã nguồn của MySQL, ví dụ, thoả thuận mặc định ngăn cấm những cài đặt triển khai trong các trang thiết bị chủ hoặc để sử dụng phiên bản của bạn như một máy chủ SQL.

• Người sử dụng đầu cuối không thể truyền/bán giấy phép cho ai đó khác nữa được (phải sử dụng theo các điều kiện y hệt[giấy phép ban đầu]).

The MySQL OEM License

I was recently made aware that the above is no longer the case with the standard MySQL OEM agreement. Sun is now, by default, putting the following limitations on their licensees:

(Sun has, of course, all rights to put any restrictions on their code, but as this is not how dual licenses used to work with MySQL or how it works with other Open Source projects (See for example, the license information for Ghostscript and .) You should however be aware of these issues if you intend to ever acquire a commercial license for MySQL)

• You cannot modify MySQL in any way (for example to fix bugs, optimise MySQL for your applications, include publicly available enhancements (such as the BSD licensed "Google patch" or compile it with another storage engine) to improve your MySQL as part of your product.

• You cannot use any forks of MySQL (such as Drizzle, ExtSQL or MariaDB).

• You are tied in to the current major release of MySQL enterprise (i.e. you have to pay for upgrades). This may be normal in a closed source environment, but not normal when it comes to Open Source.

• There are serious limitations for what kind of applications you can build with the MySQL code, for instance, the default agreement prohibits installations in hosting facilities or to use your version as a SQL server.

• The end user can't transfer/sell the license to someone else (to be used under the same conditions).

Các khuyến cáo cho những người được cấp phép và cho những người xem xét mua một giấy phép MySQL

Với những hạn chế như ở trên, bạn phải xem xét liệu có đáng giá với bạn để mua các giấy phép MySQL theo các điều kiện hiện hành hay không. Cũng vậy, nếu bạn là một người được cấp phép cũ của MySQL, bạn phải thận trọng xem xét lại bất kỳ những điều kiện gì khi giấy phép của bạn tới lúc phải ký lại. Lưu ý rằng cảnh báo này không phải là thứ gì đó đặc biệt đối với Sun mà được áp dụng khi làm việc với bất kỳ nhà cung cấp phần mềm nào.

Nếu bạn đang chạy một phiên bản cũ, được sửa đổi, của cộng đồng, hoặc được rẽ nhánh của MySQL tại công ty của bạn, thì bạn cần nhận thức được rằng thoả thuận mặc định của các OEM là không áp dụng được cho bạn. Điều này cũng là vấn đề nếu bạn là một nhà cung cấp phần cứng mà muốn chỉnh MySQL cho thiết lập của bạn.

Nếu bạn cần mua một giấy phép thương mại, vì bạn không thể sử dụng GPL, bạn cần xem xét một cách nghiêm túc liệu bạn có thể áp dụng những hạn chế mặc định này không. Nếu không, thì bạn phải liên hệ với Sun và thoả thuận lại các điều khoản. Tôi biết có những ví dụ nơi mà các giấy phép MySQL đã được cho phép để thay đổi mã nguồn của MySQL và cũng có quyền để xuất bản những thay đổi đó (Infobright quảng cáo một cách công khai rằng học đã làm thế). Bạn phải hỏi để có những quyền y như vậy.

Nếu bạn có kế hoạch tự mình đưa ra các giấy phép đôi, thì bạn cũng cần chắc chắn rằng giấy phép này cho phép bạn sử dụng một phiên bản nguồn mở của MySQL với sản phẩm nguồn mở của bạn.

Khi thoả thuận về một giấy phép, hãy đảm bảo rằng bạn có đủ quyền tự do để làm những gì được yêu cầu cho công việc kinh doanh của bạn và bạn hoàn toàn không phụ thuộc vào một nhà cung cấp vì sự thành công của bạn!

Recommendations to licensees and those considering the purchase of a MySQL license

With above limitations in place, you should consider if it's worth it to you to buy licenses for MySQL under the current terms. Also, if you are an old licensee of MySQL, you should be careful to review any new conditions when your license is up for renewal. Note that this warning is not something specific to Sun but applicable when working with any software vendor.

If you are running an old, modified, community, or forked version of MySQL at your company, you need to be aware that the default OEM agreement is not applicable to you. This also the case if you modify MySQL code to implement a new storage engine, MySQL extensions or if you are a hardware vendor that wants to to tune MySQL for your setup.

If you need to buy a commercial license, because you cannot use the GPL, you need to seriously consider if you can accept the default restrictions. If not, then you should contact Sun and renegotiate the terms. I know there are examples where MySQL licensees have been allowed to change MySQL code and also have the right to publish those changes (Infobright openly advertises that they've done so). You should ask to get those same rights.

If you plan to do dual licensing yourself, you also need to make sure that the license allows you to use an Open Source version of MySQL with your Open Source product.

When agreeing to a license, ensure that you get enough freedom to do what is required for your business and you are not completely dependent on one vendor for your success!

Những khuyến cáo cho các công ty làm giấy phép đôi

Tôi tin tưởng một người phải rất được phép khi tiến hành các giấy phép đôi với nguồn mở nếu không thì bạn sẽ đánh mất nhiều ưu thế kinh doanh mà bạn có được từ nguồn mở. Cộng đồng nguồn mở là một hệ sinh thái rất hiệu quả và nếu bạn cho phép nó tham gia vào với việc kinh doanh của bạn thì bạn có một cơ hội tốt hơn để thành công.

Hạn chế duy nhất mà bạn cần khi cấp phép lại là việc người được cấp phép phải không có khả năng thay đổi giấy phép của mã nguồn của bạn và họ chỉ có thể sử dụng và/hoặc phân phối số lượng các bản sao đã được thoả thuận trước về nó.

• Việc cho phép các thay đổi đối với mã nguồn được cấp phép cho phép người được cấp phép kết hợp mã cộng đồng và mã của riêng họ trong việc tạo ra một sản phẩm tốt hơn. Nó cũng trao cho khách hàng của bạn sự tin tưởng hơn về sản phẩm của bạn khi họ không cảm thấy bị khoá trói vào chỉ một nhà cung cấp về mọi thứ như sửa lỗi và cải tiến.

• Làm cho dễ dàng sử dụng sản phẩm của bạn hoặc một phần mã nguồn của bạn với các sản phẩm khác.

• Việc cho phép phân phối lại sản phẩm sẽ tạo ra một thị trường cho mọi người làm các phần bổ sung (addons), những cải tiến và những sản phẩm mới hoàn toàn dựa trên các sản phẩm của bạn.

• Đừng sợ bị rẽ nhánh. Họ mở rộng hệ sinh thái của bạn và bất kỳ ai mà muốn mua một giấy phép cho những rẽ nhánh này cũng phải mua một giấy phép từ bạn.

• Đừng hạn chế giấy phép đối với một phiên bản cụ thể nào đó; nếu bạn cho phép thay đổi thì điều này cũng sẽ là vô nghĩa khi một người có thể dễ dàng đi quanh nó. Về lâu dài sẽ không là một đề xuất thắng lợi để bán đi bán lại cùng một phần mềm mãi cho cùng một khách hàng. Thay vào đó hãy làm việc về phần mềm này và với khách hàng để gia tăng sự sử dụng phần mềm này.

• Đừng hạn chế bằng bất kỳ cách nào cách mà sản phẩm/mã nguồn có thể được sử dụng; nó chỉ thúc ép mọi người chọn hoặc phát triển các sản phẩm khác mà sẽ cạnh tranh với bạn và sẽ hạn chế việc kinh doanh mà bạn có thể tạo ra.

• Hãy tạo giấy phép của người sử dụng đầu cuối có thể truyền được. Điều này sẵn sàng được cho phép trong nhiều quốc gia, đây là những gì mà những người thông thường mong đợi từ hầu hết mọi thứ mà họ mua và sẽ tạo ra những cơ hội cho những việc kinh doanh mới của những người khác. Nếu bạn phải trả tiền vì bất kỳ bản sao nào của phần mềm của bạn mà nó đang tồn tại, thì bạn có thực sự quan tâm ai sử dụng nó những bản cũ hay không?

Bằng cách thẳng thắn công bằng đối với những người khác, bạn sẽ có được uy tín như một đối tác kinh doanh đáng tin cậy và bạn sẽ có được công việc nhiều hơn về lâu dài.

Recommendations for companies doing Dual-Licensing

I believe one should be very permissive when doing dual licenses with Open Source as otherwise you lose many of the business advantages you get from being Open Source. The Open Source community is a very effective ecosystem and if you allow it to participate with your business you have a better chance to succeed.

The only restriction you need when re-licensing is that the licensee should not be able to change the license of your code and they can only use and/or distribute the pre-negotiated number of copies of it.

• Allowing changes to the licensed code allows the licensee to combine community code and their own code in creating a better product. It also gives your customer more trust in your product as they don't feel locked into only one vendor for things like bug fixes and enhancements.

• Make it easy to use your product or part of your code with other products.

• Allowing re-distribution of the product creates a market for people doing addons, enhancements and totally new products based on yours.

• Don't be afraid of forks; They enlarge your ecosystem and anyone that wants to buy a license for these forks also has to buy one from you.

• Don't limit the license to a specific version; If you allow changes this is meaningless anyway as one can easily go around it. In the long run it's not a winning proposition to sell the same software over and over again to the same customer. Instead work on the software and with the customer to increase the usage of the software.

• Don't limit in any way how the product/code can be used; it just forces people to choose or develop other products that will compete with you and will limit the business you can create.

• Make the end-user license transferable. This is already allowed in many countries, it is what normal people expect from most things they buy and will create opportunities for new business by others. If you got paid for any copy of your software that exists, do you really care who uses it second hand ?

By being fair to others, you will get a reputation as a trustworthy business partner and you will get more business in the long run.

Những khuyến cáo cho những người đóng góp của cộng đồng

Tôi giả thiết là đối với blog này rằng rõ ràng vì sao có lợi cho bạn để đóng góp mã nguồn cho một dự án nguồn mở. (Nếu không, thì đây có thể là một chủ đề cho bài viết khác trên blog).

Tuy nhiên, khi tài trợ mã nguồn của bạn cho một dự án nguồn mở mà nó đang sử dụng giấy phép đôi, thì bạn cũng cần xem xét cách mà dự án này đang tiến hành sử dụng mã nguồn của bạn khi cấp phép lại nó theo một giấy phép không nguồn mở. Điều này rất quan trọng nếu bạn từ trước tới nay tự mình mong muốn cấp phép cho dự án theo một giấy phép thương mại (không phải nguồn mở).

• Những gì là những hạn chế về cách mà bạn có thể sử dụng công việc được cấp phép lại như thế nào? (Lý tưởng nó phải sử dụng được cho bất kỳ mục đích nào và stheo bất kỳ cách thức nào).

• Bạn có thể thay đổi những gì đối với mã nguồn khi bạn cấp phép lại? (Lý tưởng sẽ không có những hạn chế nào, ngoại trừ những thứ bạn không thể thay đổi giấy phép).

• Liệu một thoả thuận cấp phép có thể được sử dụng để hạn chế khả năng của người được cấp phép để xuất bản mã nguồn của riêng họ như nguồn mở, hoặc để đưa mã nguồn của nguồn mở vào trong sản phẩm của họ hay không?

• Liệu thoả thuận cấp phép lại có trói một phiên bản cụ thể nào của dự án hay không.

• Liệu thoả thuận của người đóng góp cho dự án có rõ ràng về các điều khoản về cách mà bạn có thể đóng góp mã nguồn cho nó hay không?

Liệu dự án có thể, ví dụ, lấy bất kỳ mã nguồn nào mà bạn từ trước tới nay gửi cho bất kỳ danh sách thư điện tử liên quan nào hoặc liệu bạn có cần thiết phải dứt khoát ký mọi đóng góp một cách riêng rẽ. (thoả thuận của người đóng góp của chúng tôi đã không rõ theo khía cạnh này, nên tôi gấn đây đã bổ sung: “Mỗi đệ trìnhp hải chắc chắn được đánh dấu rằng nó được đóng góp theo MCA”. Bạn có thể tất nhiên cũng đánh dấu mã nguồn để theo BSD).

Recommendations to Community contributors

I assume for this blog that it's clear why it's beneficial for you to donate code to an Open Source project. (If not, then this could be a topic for another blog post).

However, when donating your code to a an Open Source project that is using dual-licensing, you need to also consider how the project is going to use your code when re-licensing it under a non-Open Source license. This is very important if you ever want to license the project yourself under a commercial license (not Open Source).

• What are the restrictions on how you can use the re-licensed work? (Ideally it should be usable for any purpose and in any manner).

• What changes can you make to the code when you re-license it? (Ideally there should be no restrictions, except that you can't change the license).

• Can an licensing agreement be used to restrict the licensee's possibility to publish their own code as Open Source, or to include Open Source code in their product?

• Is the re-licensing agreement tied to a specific version of the project.

• Is the contributor agreement for the project clear in terms of how you may donate code to it? Can the project, for example, take any code you ever send to any related email list or do you need to explicitly sign every contribution separately. (Our contributor agreement wasn't clear in this aspect, so I recently added: "Each submission must explicitly be marked that it's donated under the MCA". You can of course also mark the code to be under BSD.)

Nếu bạn đồng ý với những thứ ở trên và bạn đã ký những thoả thuận đóng góp mà không đưa vào một lưu ý như vậy, thì bạn phải xem xét liên lạc với những dự án này và yêu cầu làm mới những thoả thuận với một mệnh đề như vậy hoặc có được một số đảm bảo công khai khác rằng dự án cấp phép lại cho mã nguồn theo một cách phù hợp thích đáng.

Lưu ý rằng việc cấp phép lại cho mã nguồn của bạn như là BSD đối với một dự án mà có hoặc có thể có các mã nguồn GPL sẽ không bảo vệ mã nguồn của bạn khỏi bị cấp phép đôi theo một cách không được thuận lợi đâu đấy. Cách duy nhất để đảm bảo sự tự do đầy đủ cho những người khác là chỉ đóng góp mã nguồn của bạn theo một thoả thuận của người đóng góp với một mệnh đề như được gợi ý bên dưới hoặc một dự án mà nó có những chỉ dẫn có thể thoả thuận được về cách mà họ cấp phép cho mã nguồn của họ!

Để đảm bảo cho những người sử dụng của chúng ta, những người đóng góp, và các khách hàng về cách mà chúng tôi tại Monty Program Ab dự kiến sẽ cấp phép lại cho các mã nguồn mà chúng tôi sản xuất ra hoặc mã nguồn mà mọi người đóng góp vào cho chúng tôi, tôi đã bổ sung lưu ý sau đây vào thoả thuận cho người đóng góp của chúng tôi:

“Monty Program Ab đồng ý rằng khi hãng cấp phép đôi cho mã nguồn, thì hãng sẽ không hạn chế cách thức mà giấy phép của bên thứ 3 sử dụng bản sao được cấp phép của mã nguồn này, cũng không hạn chế cách thức mà họ sử dụng mã nguồn riêng của họ”.

Nếu bạn có bất kỳ bình luận/ý tưởng nào xung quanh vấn đề này, xin hãy tham gí vào đội Khởi động (Launchpad) thoả thuận maria và danh sách thư có liên quan của nó và tranh luận về chủ đề này.

If you agree with the above and you have signed contributor agreements that do not include such a note, you should consider contacting those projects and asking for a new one with such a clause or get some other public guarantee that the project re-licenses code in an appropriate manner.

Note that releasing your code as BSD for a project that has or may have GPL code doesn't protect your code from being dual-licensed in an unfavorable way. The only way to ensure full freedom for others is to only donate your code under a contributor agreement with a clause as suggested below or to a project that has agreeable guidelines for how they license their code!

To assure our users, contributors, and customers of how we at Monty Program Ab intend to re-license the code we produce or the code people donate to us, I have added the following note to our contributor agreement:

"Monty Program Ab agrees that when it dual licenses code, it will not restrict the way the third party licensee uses the licensed copy of the code nor restrict how they use their own code."
If you have any comments/ideas around this, feel free to join the the maria-discuss Launchpad team and its associated mailing list and discuss this topic.

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

letrungnghia.foss@gmail.com