Dual-licensing
as a business model
By Elena Blanco,
Published: 14 August 2006, Reviewed: 12 March 2012
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ở (bản
dịch tiếng Việt). 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 where 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.
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 from 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 chargeable services such as support and consultancy. These
supporting services are often available from 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 from Microsoft and purchasing
support services from Cap Gemini. This scenario of using separate
licence and support vendors is also common in the open source world,
where 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 from a third party business
specialising in that particular piece of software. A good example of
this from 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 from
a Moodle partner to support its deployment.
Supporting
services are not the only way that an open source business can make
money. They can also make money from licensing. Clearly, if software
is released under an open source licence it is not practicable to
charge 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
chargeable 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.
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 where 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.
Sometimes
a company may choose to use the commercial licence initially but then
decide to alter their business model and open source their product.
This decision may come about for several reasons. Perhaps the
company’s focus has shifted away from 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 from 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.
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.
MySQL
is not the only open source company providing dual-licensed products.
Other examples include:
- Qt, a cross platform toolkit used to develop GUIs, from Nokia (originally Trolltech)
- Berkeley DB, a database system, from Oracle (originally Sleepycat software)
- Asterisk, an open source telecommunications software suite, from Digium
amongst
others.
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 from 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 where 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
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.