Cấp phép đôi như một mô hình kinh doanh

Dual-licensing as a business model

By Elena Blanco, Published: 14 August 2006, Reviewed: 12 March 2012

Theo: http://www.oss-watch.ac.uk/resources/duallicence2

Bài được đưa lên Internet ngày: 14/08/2006; Rà soát lại ngày: 12/03/2012

Lời người dịch: Trong các cộng đồng nguồn mở, thường có những tranh cãi về mô hình cấp phép đôi. Bài viết này giải thích rõ về mô hình kinh doanh nguồn mở theo cách thức cấp phép đôi này. Tuy nhiên, mô hình cấp phép đôi cũng có những tác động tiêu cực lên cộng đồng những lập trình viên đóng góp cho dự án. Bạn hãy đọc và sẽ hiểu vì sao.

Một cách đơn giản, việc cấp phép đôi mô tả tình huống nơi mà mẩu phần mềm y hệt có thể có được theo 2 giấy phép phần mềm khác nhau. Thường thì một trong các giấy phép đó là một giấy phép nguồn mở do OSI phê chuẩn và cái còn lại là một giấy phép sở hữu độc quyền.

Các mô hình kinh doanh nguồn mở

Dù nhận thức về phần mềm nguồn mở (PMNM) đã trở nên rộng rãi hơn, nhiều người vẫn còn có khó khăn với khái niệm rằng một mô hình kinh doanh nguồn mở có thể tồn tại. Câu hỏi phổ thông nhất là 'Làm thế nào mà mọi người có thể kiếm tiền được từ PMNM nếu họ cho nó đi một cách tự do?' Thông thường, phí giấy phép chỉ là một trong những cách thức mà một nhà bán hàng phần mềm kiếm tiền, thường như họ cũng đưa ra những dịch vụ có phí bổ sung như hỗ trợ và tư vấn. Những dịch vụ hỗ trợ đó thường sẵn sàng từ các bên thứ 3. Ví dụ, một cơ quan có thể mua một số phần mềm sở hữu độc quyền bằng việc trả phí cho một giấy phép cho nhà bán hàng phần mềm đó nhưng có thể sau đó thương thảo một hợp đồng hỗ trợ với một bên thứ 3 mà có thể có hoặc không liên quan theo một số cách thức với nhà bán hàng đó. Điều này có thể, ví dụ, có liên quan tới việc mua Microsoft SharePoint từ Microsoft và mua các dịch vụ hỗ trợ từ Cap Gemini. Kịch bản sử dụng riêng rẽ các nhà bán giấy phép và hỗ trợ cũng là phổ biến trong thế giới nguồn mở, nơi mà phần mềm có thể sẵn có một cách tự do theo một giấy phép của PMNM, không có chi phí giấy phép, nhưng một hợp đồng hỗ trợ hoặc các dịch vụ tư vấn có thể được mua từ một doanh nghiệp là bên thứ 3 chuyên về mẩu phần mềm đặc biệt đó. Một ví dụ tốt về điều này từ khu vực giáo dục là việc Moodle, một môi trường học tập ảo phổ biến, có thể được triển khai trong một viện trường mà không có chi phí giấy phép, nhưng một hợp đồng hỗ trợ thương mại có thể được mua từ một đối tác của Moodle để hỗ trợ cho sự triển khai của nó.

Cấp phép đôi như một mô hình kinh doanh

Việc hỗ trợ các dịch vụ không chỉ là cách duy nhất một doanh nghiệp nguồn mở có thể kiếm tiền. Họ cũng có thể kiếm tiền từ việc cấp phép. Rõ ràng, nếu phần mềm được phát hành theo một giấy phép nguồn mở thì không thực thế để lấy tiền phần mềm khi mà hàng xóm của bạn có thể cho nó đi một cách tự do. Tuy nhiên, một nhà bán hàng PMNM có thể chọn cấp phép đôi cho phần mềm của mình. Điều này có nghĩa là phần mềm của nhà bán hàng đó được làm cho sẵn sàng cả theo một giấy phép nguồn mở lẫn theo một sơ đồ cấp phép khác mà có thể phải có một phí giấy phép. Nhưng vì sao bất kỳ ai cũng có thể chọn giấy phép mất phí nhỉ? Có một số lý do rất tốt vì sao điều này có thể xảy ra. Cho tới nay phổ biến nhất là PMNM được phát hành theo một giấy phép áp đặt những hạn chế nhất định mà người được cấp phép trong tương lai không thấy hạnh phúc. Một ví dụ là khi mã nguồn mở sẽ cần phải sử dụng lại trong một sản phẩm phần mềm sở hữu độc quyền; một số giấy phép nguồn mở không cho phép điều này.

Một ví dụ

Một công ty, Databases-r-us, đang phát triển một ứng dụng cơ sở dữ liệu nhằm vào người sử dụng cơ sở dữ liệu lần đầu tiên. Họ muốn phát triển và bán một ứng dụng bao gồm một phụ trợ (back end) cơ sở dữ liệu với một bộ công cụ dễ sử dụng trên đỉnh mà làm cho việc thiết kế, duy trì và sử dụng một cơ sở dữ liệu trở thành một tác vụ bình thường. Họ muốn sử dụng cơ sở dữ liệu phổ biến MySQL, một ứng dụng nguồn mở, nó được phát hành theo Giấy phép Công cộng Chung GNU (GPL) từ công ty làm chủ. Các điều khoản của giấy phép này là thế này, nếu Databases-r-us phát triển và phát hành phần mềm có mã của cơ sở dữ liệu MySQL thì ứng dụng dựa vào MySQL đó phải được phân phối lại theo một cách thức nơi mà đầy đủ mã nguồn cho ứng dụng đó cũng phải được phát hành theo GPL. Trong tình huống này, Databases-r-us không muốn làm thế vì họ cảm thấy rằng mã nguồn phần mềm mà họ đã phát triển là một phần của ưu thế kinh doanh của họ. Tuy nhiên, họ rất sắc bén về cơ sở dữ liệu MySQL và vẫn muốn đưa nó vào với phần mềm của họ. May thay đối với Databases-r-us, khi mà cơ sở dữ liệu MySQL là một sản phẩm được cấp phép đôi nên điều này quả thực là có thể.

Theo mô hình kinh doanh cấp phép đôi của MySQL, những người sử dụng có thể chọn sử dụng các sản phẩm MySQL theo GPL nguồn mở hoặc theo một giấy phép thương mại. Bất kỳ ai mà đang phát triển và phân phối các ứng dụng nguồn mở theo GPL được tự do sử dụng MySQL theo GPL. Bổ sung thêm, bất kỳ ai đang phát triển và phân phối các ứng dụng nguồn mở theo một giấy phép do OSI phê chuẩn mà không phải là GPL, có thể tận dụng sự ngoại lệ của giấy phép GPL của PMNM mà cho phép những giấy phép đặc thù sẽ được sử dụng.

Đối với bất kỳ ai mà muốn phát triển và phân phối nhưng không muốn phát hành mã nguồn đối với ứng dụng của họ, thì MySQL có khả năng cung cấp một giấy phép thương mại. Vì MySQL có quyền sở hữu đầy đủ đối với mã nguồn MySQL, có khả năng để điều chỉnh các điều khoản cấp phép thương mại của mình để đáp ứng được những yêu cầu độc nhất vô nhị của những người sử dụng có quan tâm trong việc nhúng hoặc đưa MySQL vào.

Việc cấp phép đôi có thể có lợi cho thế giới nguồn mở hay không?

Đôi khi một công ty có thể chọn sử dụng ngay từ đầu giấy phép thương mại nhưng sau đó quyết định chỉnh sửa mô hình kinh doanh của họ và mở nguồn cho sản phẩm của họ. Quyết định này có thể tới vì vài lý do. Có thể trọng tâm của công ty đã chuyển từ phát triển phần mềm và hướng tới thị trường tư vấn. Ví dụ, Databases-r-us có thể thay đổi sang sử dụng phiên bản nguồn mở của MySQL và phát hành mã nguồn của riêng họ theo GPL. Công ty có thể chọn làm điều này với sự tin tưởng rằng một hiệu ứng phụ làm cho mã nguồn của họ thành nguồn mở có thể làm cho sản phẩm của họ trở nên được sử dụng rộng rãi hơn. Kho người sử dụng lớn hơn này có thể tới lượt nó cung cấp một cơ hội cho Databases-r-us gia tăng doanh số được tạo ra từ các dịch vụ tư vấn của mình. Rõ ràng, quyết định này chỉ có thể có ý nghĩa nếu mô hình kinh doanh của công ty đã thay đổi, nhưng nếu sự thâm nhập thị trường là một mục tiêu đáng kể thì dạng mô hình kinh doanh này có ý nghĩa tốt. Vì thế, trong trường hợp như vậy, thế giới nguồn mở hưởng lợi từ mô hình cấp phép đôi vì mã nguồn được Databases-r-us phát triển bây giờ có sẵn cho bất kỳ ai muốn sử dụng nó.

Tuy nhiên, cần phải lưu ý rằng việc cấp phép đôi có thể có hiệu ứng tiêu cực lên những đóng góp của cộng đồng cho các dự án nguồn mở. Đó là, bằng việc cho phép một số người giữ những sửa đổi riêng tư, trong khi những người khác bị ép phải tiến hành những thay đổi của họ một cách công khai, một số lập trình viên sẽ bị khóa khỏi qui trình đó. Tuy nhiên, đối với một dạng mô hình kinh doanh đặc thù, việc cấp phép đôi có thể là một phần quan trọng của một kho vũ khí marketing của công ty.

Việc cấp phép đôi cho tính tương thích của giấy phép

Lý do khác cho việc sử dụng một mô hình cấp phép đôi là để phá vỡ một số sự không tương thích giữa các giấy phép do OSI chứng thực. Ví dụ, Quỹ Mozilla sử dụng một mô hình cấp phép 3 bằng việc sử dụng Giấy phép Công cộng Mozilla (MPL), Giấy phép Công cộng Chung (GPL), và Giấy phép Công cộng chung Ít hơn (LGPL) để cấp phép cho những phần mềm nhất định trong một nỗ lực giải quyết vấn đề về tính không tương thích với các giấy phép nguồn mở khác.

Các sản phẩm được cấp phép đôi khác

MySQL không phải là công ty nguồn mở duy nhất đưa ra các sản phẩm được cấp phép đôi. Những ví dụ khác bao gồm:

• Qt, một bộ công cụ đa nền tảng được sử dụng để phát triển các giáo diện đồ họa người sử dụng GUI, từ Nokia (gốc ban đầu từ Trolltech)

• Berkeley DB, một hệ quản trị cơ sở dữ liệu, từ Oracle (ban đầu là Sleepycat software)

• Asterisk, một bộ phần mềm truyền thông nguồn mở, từ Digium

và những thứ khác.

Các mô hình cấp phép có liên quan

Dạng mô hình cấp phép khác có thể được thấy khi một công ty quyết định đưa ra 2 phiên bản sản phẩm của mình, một phiên bản nguồn mở mà đưa ra chức năng cơ bản và một phiên bản sở hữu độc quyền mà đưa ra một tập tính năng được cải thiện. Điều này cho phép mọi người mà yêu cầu chỉ phiên bản cơ bản của sản phẩm sẽ sử dụng phiên bản nguồn mở trong khi các khách hàng với những yêu cầu phức tạp hơn có thể mua phiên bản sở hữu độc quyền. Tất nhiên các lập trình viên có thể lấy phiên bản nguồn mở và bổ sung những tùy biến được yêu cầu của riêng họ vào mã nguồn này theo một cách thức thông thường của nguồn mở nhưng những người mà không thể hoặc không muốn tiến hành sự phát triển của riêng họ có thể chọn trả tiền cho phiên bản sở hữu độc quyền. Thường thì, một số tính năng hoặc tùy biến bổ sung của phiên bản sở hữu độc quyền có cách để đi vào phiên bản nguồn mở. Vì thế phiên bản sở hữu độc quyền giúp trả tiền cho sự phát triển của phiên bản nguồn mở.

Những ví dụ các sản phẩm mà được cấp phép theo mô hình này bao gồm:

• Sendmail - Mail Transfer Agent huyền thoại có sẵn như là PMNM từ sendmail.org, trong khi Sendmail, Inc. sản xuất ra phần mềm thông điệp sở hữu độc quyền nhằm vào các giải pháp doanh nghiệp rộng lớn

• Jaspersoft sản xuất cả một thư viện nhúng nguồn mở và một phiên bản dựa trên máy chủ sở hữu độc quyền các công cụ của chúng cho sự truy cập, phân tích và báo cáo dữ liệu.

• SugarCRM đưa ra một phiên bản cộng đồng của phần mềm CRM của họ tải về được tự do

Một số nhà bán hàng vận hành một mô hình cấp phép nơi mà họ đưa ra một phiên bản phần mềm của họ là tự do để sử dụng nhưng vẫn được cấp phép sở hữu độc quyền cùng với các sản phẩm phần mềm thương mại của họ. Dù mô hình này đặc biệt giống một mô hình kinh doanh nguồn mở thì nó không phải là mô hình kinh doanh nguồn mở. Trừ phi phần mềm được phát hành theo một giấy phép được OSI phê chuẩn, nó sẽ không phải là nguồn mở. Các phiên bản tự do sử dụng đó thường có ý định để giới thiệu cho các khách hàng tiềm năng trong tương lai về các sản phẩm của một nhà bán hàng, một thực tiễn marketing được sử dụng phổ biến trong tất cả các thị trường và thường được biết tới như là một người đi đầu thua thiệt.

Put simply, dual-licensing describes a situation whe-re the same piece of software can be obtained under two different software licences. Usually one of these licences is an OSI-approved open source licence and the other is a proprietary licence.

Open source business models

Although awareness of open source software has become more widespread, many people still have difficulty with the concept that an open source business model can exist. The most common question is ‘How can anyone make money f-rom open source software if they give it away for free?’ Generally, the licence fee is only one of the ways that a software vendor makes its money, as usually they also offer additional c-hargeable services such as support and consultancy. These supporting services are often available f-rom third parties. For example, an institution may purchase some proprietary software by paying a licence fee to that software’s vendor but may then negotiate a support contract with a third party that may or may not be affiliated in some way with the vendor. This might, for example, involve purchasing Microsoft SharePoint f-rom Microsoft and purchasing support services f-rom Cap Gemini. This scenario of using separate licence and support vendors is also common in the open source world, whe-re the software may be freely available under an open source software licence, incurring no licence cost, but a support contract or consultancy services may be purchased f-rom a third party business specialising in that particular piece of software. A good example of this f-rom the education sector is that Moodle, a popular virtual learning environment, may be deployed in an institution with no licence cost, but a commercial support contract may be purchased f-rom a Moodle partner to support its deployment.

Dual-licensing as a business model

Supporting services are not the only way that an open source business can make money. They can also make money f-rom licensing. Clearly, if software is released under an open source licence it is not practicable to c-harge for the software as your neighbour can give it away for free. However, an open source software vendor may choose to dual-license its software. This means that its software is made available both under an open source licence and under a different licensing scheme that may incur a licence fee. But why would anyone choose the c-hargeable licence? There are some very good reasons why this might happen. The most common by far is that the open source software is released under a licence that imposes certain restrictions that the prospective licensee is unhappy with. An example is when the open source code will need to be re-used within a proprietary software product; some open source licenses do not allow this.

An example

A company, Databases-r-us, is developing a database application aimed at the first time database user. They wish to develop and sell an application that consists of a database back end with a suite of easy-to-use tools on top that make designing, maintaining, and using a database a trivial task. They would like to use the popular MySQL database, an open source application, which is released under the GNU General Public License (GPL) by the owning company. The terms of this licence are such that if Databases-r-us develops and releases software that contains the MySQL database code then that MySQL-based application must be redistributed in a way whe-re the complete source code for the application is open and available for redistribution. In practical terms this means that the resulting application must also be released under the GPL. In this situation, Databases-r-us do not want to do this because they feel that the software code they have developed is part of their business advantage. However, they are very keen on the MySQL database and still want to bundle it with their software. Fortunately for Databases-r-us, as the MySQL database is a dual-licensed product this is indeed possible.

Under MySQL’s dual-licensing business model, users may choose to use MySQL products under the open source GPL or under a commercial licence. Anyone who is developing and distributing open source applications under the GPL is free to use MySQL under the GPL. Additionally, anyone who is developing and distributing open source applications under an OSI-approved licence that is not the GPL, may take advantage of the FLOSS exception of the GPL licence that allows specific licences to be used.

For anyone who wants to develop and distribute but does not want to release the source code for their application, MySQL is able to provide a commercial licence. Because MySQL has full ownership of the MySQL code, it is able to tailor its commercial licensing terms to meet the unique requirements of users interested in embedding or bundling MySQL.

Can dual-licensing benefit the open source world?

Sometimes a company may choose to use the commercial licence initially but then decide to al-ter their business model and open source their product. This decision may come about for several reasons. Perhaps the company’s focus has shifted away f-rom software development and towards the consultancy market. For example, Databases-r-us could change to using the open source version of MySQL and release their own code under the GPL. The company might choose to do this in the belief that a side effect of making their code open source would be that their product became more widely used. This larger user base would in turn provide an opportunity for Databases-r-us to increase the revenue generated by its consultancy services. Clearly, this decision would only make sense if the business model of the company had changed, but if market penetration is a significant goal then this type of business model makes good sense. So, in a case like this, the open source world benefits f-rom the dual-licensing model as the code developed by Databases-r-us is now available to anyone who wishes to use it.

However, it should be noted that dual-licensing may have a negative effect on community contributions to open source projects. That is, by allowing some people to keep modifications private, while others are forced to make their changes public, a number of developers will be locked out of the process. Nevertheless, for a specific type of business model, dual-licensing can be an important part of a company’s marketing armoury.

Dual-licensing for licence compatibility

Another reason for using a dual-licensing model is to circumvent some of the incompatibilities between OSI-certified licences. For example, the Mozilla Foundation uses a tri-licensing model employing the Mozilla Public License (MPL), the General Public License, and the Lesser General Public License (LGPL) to license certain software in an effort to address the issue of incompatibility with other open source licences.

Other dual-licensed products

MySQL is not the only open source company providing dual-licensed products. Other examples include:

• Qt, a cross platform toolkit used to develop GUIs, f-rom Nokia (originally Trolltech)

• Berkeley DB, a database system, f-rom Oracle (originally Sleepycat software)

• Asterisk, an open source telecommunications software suite, f-rom Digium

amongst others.

Associated licensing models

A different type of licensing model can be seen when a company decides to offer two versions of its product, an open source version that offers basic functionality and a proprietary version that offers an enhanced feature set. This allows people who require only the baseline version of the product to use the open source version while customers with more complex requirements can purchase the proprietary version. Of course developers can take the open source version and add their own required customisations to this code in the normal way of open source but those who either cannot or do not want to do their own development can choose to pay for the proprietary version. Often, some of the additional features or customisations of the proprietary version make their way into the open source version. Thus the proprietary version helps pay for the development of the open source version.

Examples of products that are licensed under this model include:

• Sendmail - the legendary Mail Transfer Agent is available as open source software f-rom sendmail.org, while Sendmail, Inc. produces proprietary messaging software targeting enterprise wide solutions

• Jaspersoft produces both an open source embedded library and a proprietary server based version of their tools for data access, analysis and reporting

• SugarCRM offer a community edition of their CRM software that is freely downloadable

Some vendors operate a licensing model whe-re they offer a version of their software that is free to use but still proprietarily licensed alongside their commercial software products. Although this model is superficially similar to an open source business model it is not an open source business model. Unless software is released under an OSI- approved licence, it is not open source. These free-to-use versions are usually intended to introduce prospective customers to a vendor’s products, a marketing practice in common use across all markets and often known as a loss leader.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com