Các mô hình bền vững và kinh doanh của phần mềm tự do nguồn mở

Free and open source software business and sustainability models

By Pete Cooper, Amir Nettler, Published: 03 November 2009, Reviewed: 14 May 2012

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

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

Lời người dịch: Bài viết đưa ra một số nhận xét về các vấn đề liên quan tới phần mềm tự do nguồn mở. Tuy nhiên, vì gốc của nó là một bài được trình bày từ tháng 01/2009 nên có một số khía cạnh pháp lý tới nay có thể không còn phù hợp nữa. Dù vậy, vẫn có giá trị để tham khảo, nhất là các mô hình kinh doanh của nguồn mở. Khi so sánh với những thực tiễn hiện nay, sẽ có một số khác biệt.

Tài liệu này từng là bài trình bày của Rowan Wilson tại một hội thảo của OSS Watch vào tháng 01/2009. Nó tập trung vào một số khía cạnh pháp lý xung quanh phần mềm tự do nguồn mở (FOSS) và nhìn vào những vấn đề như sự ép tuân thủ, các rủi ro và các bằng sáng chế, trích dẫn một số các vụ kiến pháp lý đáng kể gần đây. Nó cũng thảo luận các cách thức theo đó các dự án FOSS có thể thành công được khai thác và duy trì bền vững.

Sự ép tuân thủ, sự loại trừ và các rủi ro

Chúng ta sẽ bắt đầu với câu hỏi liệu một giấy phép FOSS có tạo thành một hợp đồng giữa lập trình viên và người sử dụng hay không. Có nhiều người trong cộng đồng FOSS mà từ chối ý tưởng rằng một giấy phép FOSS là một hợp đồng. Điều này chủ yếu vì lý do thực tế, khi luật hợp đồng khác nhau lớn giữa các nước và ít khác đắt để kiện tụng. Hệ quả là, nhiều người tin tưởng rằng các giấy phép sẽ được ép tuân thủ tốt hơn bằng việc sử dụng các luật sở hữu trí tuệ (IP) thống nhất hơn, mà, trong số những lợi ích khác, có những hiệp định và pháp luật đằng sau chúng, làm cho chúng dễ dàng hơn để cảnh sát.

Thú vị ở thời điểm này để nhìn vào một vài ví dụ các thách thức pháp lý đối với các giấy phép FOSS: trong vụ Wallace vs FSF nó từng bị tranh cãi không thành công rằng GPL đã tạo ra một dạng nghịch đảo cố định giá đối với luật chống độc quyền của Mỹ; Jacobsen vs Katzer đã chỉ ra rằng một người cấp phép FOSS tại Mỹ không tự tin vào luật hợp đồng để ép tuân thủ các điều kiện trong giấy phép FOSS của họ.

Các bằng sáng chế phần mềm và FOSS

Theo truyền thống, nhân viên có trách nhiệm với việc khai thác IP của phần mềm được sinh ra tại các viện trường nghiên cứu ở nước Anh đã xem xét việc giành lấy các bằng sáng chế phần mềm. Nhưng sự chăm sóc nên được tiến hành khi nghĩ về cách mà việc cấp phép của FOSS tác động tới các bằng sáng chế phần mềm. Điều này là vì tất cả các giấy phép FOSS, hoặc hoàn toàn hoặc rõ ràng, trao các quyền đối với các bằng sáng chế mà phần mềm là hiện thân cho bất kỳ ai trên thế giới, về bản chất không có chi phí.

Cũng đáng lưu ý rằng việc âm thầm nhấn sâu FOSS trong phần mềm của riêng bạn có thể là một sự cám dỗ - đặc biệt ở những nơi giấy phép FOSS theo yêu cầu có những điều kiện rầy rà trong sử dụng lại - nhưng điều này có thể kết thúc trong các vấn đề phí tổn và công khai. Trong cộng đồng, có một cơ quan tích cực của những người nhiệt thành, họ dịch ngược phần mềm, tìm kiếm các dấu hiệu sử dụng lại phần mềm FOSS không có phép, và họ đã chỉ ra trong quá khứ rằng họ có thể ép tuân thủ thậm chí các hàng CNTT chủ chốt thông qua hành động pháp lý và sự công khai thói xấu.

Các mô hình của FOSS

Các mô hình kinh doanh và bền vững khác nhau của FOSS là không hoàn toàn có đi có lại; rất thường thấy, chúng được sử dụng trong sự kết hợp, khi thầy phù hợp. Tuy nhiên, các mô hình kinh doanh nguồn mở là sự phát triển khá mới, nên ít được biết về cách tốt nhất để sử dụng chúng, hoặc tính hiệu quả tối thượng của chúng là những gì. Một số thành công hiện hành của sự khai thác FOSS có lẽ có thể được ghi nhận cho sự bất mãn với các phần mềm nguồn đóng, hơn là bất kỳ sự ưu việt bẩm sinh nào. Việc nhìn vào tương lai, sự khủng hoảng kinh tế hiện hành có thể cũng giúp hoặc làm khó cho sự thành công của các mô hình kinh doanh FOSS trong tương lai; các nhà phân tích hiện đang dự đoán cả 2.

Cộng đồng hàn lâm

Mô hình đầu tiên phải xem xét là việc xây dựng một cộng đồng hàn lâm xung quanh một giải pháp phần mềm cụ thể. Trong khi nó có thể xem rất giống một mô hình kinh doanh khi nhìn qua, thì trong thực tế 'việc sở hữu' một công cụ là nổi bật trong miền có các vấn đề đặc biệt có thể mang lại những lợi ích tích cực cho uy tín của viện trường và các cơ quan nghiên cứu hàn lâm theo yêu cầu. Điều này bổ sung thêm vào việc cấp vốn và quan hệ đối tác của giới công nghiệp.

Việc thiết lập một quỹ

Sự thiết lập một thực thể pháp lý riêng biệt hoặc quỹ có thể giúp nhiều với sự khai thác thành công một dự án FOSS. Cũng như một mô hình kinh doanh làm việc được mà cho phép những quyên góp và một tiếp cận đơn giản hơn về thuế, nó cũng cải thiện tính bền vững bằng việc truyền rủi ro khỏi công ty hoặc viện trường cha sang thực thể pháp lý được thiết lập riêng biệt. Ví dụ, một thực thể được kéo ra có thể được tạo ra với mong đợi rằng trách nhiệm pháp lý trong trường hợp của một hành động pháp lý có thể rơi vào đơn vị được kéo ra, hơn là vào cha của nó hoặc bất kỳ người đóng góp nào khác.

Có lẽ thậm chí hữu dụng hơn là vài tổ chức có ô FOSS có một số dự án. Qũy Phần mềm Apache là nhà của nhiều dự án, bao gồm Máy chủ HTTP Apache và Apache Cocoon. Software in the Public Interest (Phần mềm trong Lợi ích Công cộng) có trách nhiệm đối với Debian Linux và PostgreSQL, và Software Freedom Conservancy (Bảo vệ Tự do cho Phần mềm) là nhà cho - trong số các dự án khác - Samba và Wine. Ngắn gọn, những lợi ích tài chính của việc quản lý một quỹ là rõ ràng: quỹ sẽ cung cấp sự quản lý rủi ro và giữ gìn số sách cần thiết, làm giảm hơn nữa tiềm năng đối với rủi ro và/hoặc thiệt hại cho đơn vị cha.

Mô hình nguồn cộng đồng

Nguồn cộng đồng đưa ra con đường khác cho giá trị gia tăng từ phần mềm, dù một số có thể tranh luận rằng nó có thể thể hiện những vấn đề nhất định. Trong mô hình này, một nhóm các tài nguyên hùn cùng của các viện trường để tạo ra một giải pháp sử dụng phần mềm toàn bộ cho họ. Ban đầu, cộng đồng xung quanh phần mềm đó (và việc cấp phép của nó) là hạn chế đối với các viện trường có đóng góp, mặc dù một bước phổ biến tiếp sau là để phát hành một phiên bản FOSS một khi kiến trúc chủ yếu của mã là hoàn chỉnh. Ví dụ, các dự án được cấp vốn của Quỹ Mellon như Sakai và Kuali cả 2 đã bắt đầu theo mô hình này.

Cung cấp các dịch vụ trả tiền

Các tổ chức cũng có thể khai thác các tài nguyên tài chính của chúng bằng việc chào các dịch vụ tư vấn cho phần mềm mà họ tạo ra. Điều này có thể bao gồm những thứ như hỗ trợ có trả tiền, phát triển theo đơn đặt hàng hoặc chứng chỉ cho phần cứng đặc thù. Họ thậm chí có thể phát hành phần mềm một cách tự do, nhưng giữ lại tài liệu cho các khách hàng trả tiền. Đối với các viện trường giáo dục mà tạo ra phần mềm dẫn xuất từ các hoạt động nghiên cứu của họ, ví dụ, điều này có thẻ là một cách kiếm tiền từ các hoạt động đó. Tất nhiên, mọi người cũng có thể phát hành phần mềm nhưu vậy ở dạng sở hữu độc quyền và bán các giấy phép cho nó trong khi vẫn chào các dịch vụ, kiếm doanh số theo một giấy phép nguồn mở có thể làm gia tăng số lượng người sử dụng, và vì thế mở rộng được thị trường tiềm năng cho các dịch vụ khác.

Tiết kiệm chi phí nội bộ

Giảm chi phí là lý do khác cho một tổ chức để hỗ trợ một dự án FOSS được phát triển nội bộ, nếu nó đưa ra sự tiết kiệm cho tổ chức lớn hơn so với chi phí phát triển nó, hoặc nếu nó giải quyết được một vấn đề nội bộ. Hơn nữa, một dự án mà đã chứng minh được là hữu dụng cho một tổ chức có thể cũng hữu dụng cho các tổ chức khác. Điều này có thể dẫn dắt sự tăng trưởng của cộng đồng liên viện trường xung quanh dự án, và cũng có khả năng trở thành một nguồn doanh thu bằng việc tạo một thị trường cho, ví dụ, công việc tư vấn hoặc các dịch có vụ trả tiền khác.

Phần mềm như một dịch vụ dựa vào mạng

Sự chấp nhận ngày một gia tăng phần mềm được cung cấp như một dịch vụ dựa vào mạng có thể tính là dòng doanh thu khác. Sự cung cấp các dịch vụ đó bằng việc sử dụng phần mềm được cấp phép theo các nguyên tắc copyleft không phá vỡ bất kỳ điều kiện nào của giấy phép, khi mà phần mềm đó không được phân phối theo nghĩa truyền thống, và các trách nhiệm cấp phép có đi có lại vì thế không được yêu cầu. Điều này có thể cung cấp một mô hình lựa chọn nơi mà tính tương thích của giấy phép có thể nếu khác đi sẽ khóa sự khai thác dựa vào sự phân phối. Tuy nhiên, đáng lưu ý rằng những người đề xướng cấp phép copyleft coi điều này như một thiếu sót của các giấy phép hiện hành; các nỗ lực tạo ra một giấy phép mà không cho phép hoạt động này diễn ra đã tạo ra giấy phép AGPL. Những người đề xướng ra các giấy phép nguồn mở không phải là copyleft, ngược lại, sẽ có xu hướng xem hoạt động này như nằm trong tinh thần của các giấy phép đó.

Các phí quảng cáo và tham chiếu

Doanh thu cũng có thể có từ việc quảng cáo và/hoặc các dịch vụ tham chiếu. Trong năm 2007, phần lớn doanh thu trong 75 triệu USD của Quỹ Mozilla tới từ một vụ làm ăn với Google, nào đã thấy các điều khoản tìm kiếm được gõ trong hộp tìm kiếm của Mozilla Firefox được định tuyến về các máy chủ của Google. Thậm chí đối với các dự án nhỏ hơn, các đường liên kết được tham chiếu trong các nhà cung cấp như Amazon từ một website của dự án có thể cung cấp một dòng doanh thu. Việc có được một thương hiệu có liên quan tới một tên dự án và/hoặc logo dự án cũng có thể đưa ra các cơ hội cho cả việc thương mại hóa và cấp phép nhanh và xa hơn cho việc huấn luyện hoặc tạo ra sản phẩm của các bên thứ 3.

Các dẫn xuất nguồn đóng, và việc cấp phép đôi

Bây giờ hãy nhìn vào các kỹ thuật khai thác FOSS 'truyền thống' - cung cấp hỗ trợ có trả tiền, bán các phiên bản nguồn đóng hoặc các trình bổ sung (add-ons), và việc cấp phép đôi. Cái đầu đã được nhắc tới. Cái thứ 2 có liên quan tới việc bổ sung thêm các tính năng ở dạng không phải nguồn mở, theo đó những người sử dụng phải trả tiền. Điều này có thể được thực hiện hoặc bằng việc giữ lại các tính năng mong muốn nhất định cho một phiên bản không phải nguồn mở của một mẩu phần mềm hoặc - ở những nơi kiến trúc cho phép - việc phát hành các trình bổ sung không nguồn mở, riêng rẽ, theo đó một người sử dụng phải trả tiền. Cái sau là có khả năng khi phần mềm hoặc sẵn sàng theo một giấy phép dễ dãi (như Giấy phép Apache), nó cho phép bất kỳ ai tạo ra một dẫn xuất không phải nguồn mở, hoặc nếu tất cả những người nắm giữ bản quyền đồng ý tạo ra một dẫn xuất được cấp phép riêng rẽ, nguồn đóng.

Mô hình thứ 3 được nhắc tới, việc cấp phép đôi, cũng có liên quan tới việc phát hành một phiên bản không nguồn mở của một mẩu phần mềm cùng với một phiên bản nguồn mở. Đặc biệt, nó liên quan tới việc phát hành phần mềm theo một giấy phép copyleft mạnh như GNU GPL, và cũng làm cho sẵn sàng một phiên bản theo một giấy phép lựa chọn, cho phép những người sử dụng mà không muốn bị ràng buộc vào GNU GPL trả tiền cho phiên bản không copyleft đó. Thông thường, họ có thể làm điều này vì họ muốn tạo ra một sản phẩm dựa vào mã nguồn nhưng không bị bó buộc vì một giấy phép copyleft. Các mô hình như những gì được thảo luận trong phần này có thể cho phép một cộng đồng cộng tác trong một 'lõi' nguồn mở, trong khi cùng lúc cho phép một số thành viên của cộng đồng kiếm tiền bằng việc tạo ra và bán các biến thể nguồn đóng trên nó.

Một số ví dụ

Bây giờ hãy xem xét một số ví dụ đáng chú ý của các dự án FOSS mà làm thỏa mãn một số tiêu chí và tính năng mà chúng ta vừa thảo luận. Trước hết là Red Hat, một ví dụ về một công ty lấy tiền các dịch vụ cho phần mềm mà nếu khác thì là miễn phí. Các sản phẩm chính của nó là hệ điều hành Red Hat Enterprise Linux cấp độ chuyên nghiệp và hệ điều hành Fedora do cộng đồng phát triển. Red Hat Enterprise Linux tới như một phần của một phí thuê bao và có một bảng phân công tư vấn và hỗ trợ có trả tiền thân thiện với các doanh nghiệp, một chương trình huấn luyện tin cậy được, các nâng cấp được quản lý và bồi thường IP. Trong khi hệ điều hành Red Hat Linux cũng sẵn sàng không có trả tiền cho một thuê bao, thì nó tới ở dạng mà khó cài đặt hơn, và các dịch vụ quan trọng như các cập nhật được quản lý là không sẵn sàng. Hệ điều hành Fedora, ngược lại, là một dự án phát triển mở. Nó không có phí gắn kèm, và bao gồm nhiều tính năng kỹ thuật của Red Hat; Tuy nhiên, nó không có những bảo vệ đi theo và các dịch vụ mà Red Hat Linux có.

MySQL cung cấp một hệ thống cơ sở dữ liệu SQL theo một giấy phép đôi; phần mềm này sẵn sàng theo một gói giấy phép copyleft cũng như một giấy phép thương mại nhằm vào các nhà tích hợp hệ thống. Tương tự như Red Hat, MySQL đưa ra một bộ các dịch vụ huấn luyện và tư vấn và bồi thường IP. Sự khác biệt chính là việc cấp phép đôi của chúng; giấy phép copyleft là không phù hợp cho các lập trình viên mong muốn kết hợp phần mềm MySQL vào các phần mềm thương mại và/hoặc sở hữu độc quyền, nên một phiên bản được cấp phép thương mại cũng có sẵn.

Exim, đại lý truyền thông điệp được sử dụng rộng rãi, là một ví dụ của một dự án mà từng được nuôi dưỡng chính xác vì việc tiết kiệm chi phí chứng minh được cho viện trường chủ của nó. Exim đã bắt đầu như một dự án nội bộ tại phòng các dịch vụ điện toán của Đại học Cambridge vào năm 1996 và kể từ đó đã làm giảm được chi phí tại Đại học này. Sự hỗ trợ sau đó đã được nắm lấy ở dạng của các tài nguyên nhân viên và một chương trình huấn luyện được phân phối ra bên ngoài. Cuối cùng XenSource là một ví dụ của một dự án mà đã lớn lên từ nghiên cứu hàn lâm và đã cung cấp một dòng doanh thu cho những người sáng tạo của nó thông qua việc đóng bó quản lý được của hỗ trợ có trả tiền từ các nhà cung cấp là bên thứ 3.

Kết luận

Chúng ta đã thấy rằng FOSS và phần mềm thương mại là các khái niệm không chống nhau hoặc loại trừ lẫn nhau. Trong thực tế, các thành phần FOSS và mã đang ngày càng được chấp nhận như một phần của phần mềm thương mại và Gartner tiên đoán rằng FOSS sẽ hành thành một phần của 80% các chào mời phần mềm thương mại vào năm 2012. Điều này sẽ đưa ra một thách thức cho khu vực này, biết rằng các kỹ năng liên quan tới nguồn mở vẫn còn chưa sẵn sàng rộng rãi.

This document was informed by a presentation given by Rowan Wilson at an OSS Watch workshop in January 2009. It focuses on some of the legal aspects surrounding free and open source software (FOSS) and looks at such issues as enforcement, risks and patents, citing a number of significant legal cases of recent years. It also discusses ways in which FOSS projects can successfully be exploited and sustained.

Enforcements, exclusions and risks

We’ll begin with the question of whether a FOSS licence constitutes a contract between the developer and the user. There are many people within the FOSS community who reject the idea that a FOSS licence is a contract. This is mainly for practical reasons, as contract law varies greatly between countries and it is relatively expensive to litigate. Consequently, many believe that licences are better enforced using the more uniform intellectual property (IP) laws, which, among other benefits, have international treaties and legislation behind them, making them easier to police.

It is interesting at this point to look at a couple of examples of legal challenges to FOSS licences: in Wallace vs FSF it was argued unsuccessfully that the General Public License (GPL) cre-ated a kind of price-fixing contrary to US anti-trust law; Jacobsen vs Katzer showed that a FOSS licensor in the US is not reliant on contract law to enforce the conditions in their FOSS licence.

Software patents and FOSS

Traditionally, staff c-harged with exploiting software IP generated in UK research institutions have considered obtaining software patents. But care should be taken when thinking about how FOSS licensing affects software patents. This is because all FOSS licences, either explicitly or implicitly, grant rights to patents that the software embodies to anyone in the world, at essentially no cost.

It is also worth noting that silently engulfing FOSS within your own software can be a temptation - particularly whe-re the FOSS licence in question has troublesome conditions on reuse - but this can end in expense and publicity problems. Within the community, there in an active body of enthusiasts who decompile software, looking for signs of unlicensed FOSS software reuse, and they have shown in the past that they can force the compliance of even major IT firms through legal action and bad publicity.

Business models of FOSS

The various business and sustainability models of FOSS are not mutually exclusive; most often, they are used in combination, as appropriate. However, open source business models are quite a new development, so little is known about how best to use them, or what their ultimate effectiveness will be. Some of the current successes of FOSS exploitation can perhaps be attributed to dissatisfaction with closed source software, rather than any innate superiority. Looking to the future, the current economic downturn may either help or hinder the future success of FOSS business models; analysts are currently predicting both.

Academic community

The first model to consider is the building of an academic community around a particular software solution. While it may not seem much like a business model at first glance, in fact ‘owning’ a tool that is prominent in a particular problem domain can bring positive benefits to the reputation of the institution and academics in question. This is in addition to funding and industrial partnerships.

Establishing a foundation

The establishment of a separate legal entity or foundation can help greatly with the successful exploitation of a FOSS project. As well as being a workable business model that allows donations and a simpler approach to tax, it also enhances sustainability by transferring risk away f-rom the parent company or institution to the separately established legal entity. For example, a spun-off entity could be cre-ated with the intention that liability in the case of a legal action would fall on the spin-off, rather than on its parent or any other contributors. Perhaps even more useful are the several FOSS umbrella organisations containing a number of projects. The Apache Software Foundation is home to many projects, including the Apache HTTP Server and Apache Cocoon. Software in the Public Interest is responsible for Debian Linux and PostgreSQL, and the Software Freedom Conservancy is home to – among other projects – Samba and Wine. In short, the financial benefits of running a foundation are clear: the foundation will provide the necessary book-keeping and risk management, further reducing the potential for risk and/or damage to the parent.

The community source model

Community source provides another route to added value f-rom software, although some would argue that it can present specific problems. In this model, a group of institutions pool resources to cre-ate a software solution of use to them all. Initially, the community around the software (and its licensing) is limited to the contributing institutions, although a common next step is to release a FOSS version once the major architecture of the code is complete. For example, the Mellon Foundation-funded projects Sakai and Kuali were both begun under this model.

Provision of paid services

Organisations can also exploit their resources financially by offering consultancy services for software that they produce. This could include things like paid support, bespoke development or certification for specific hardware. They could even release the software freely, but reserve documentation for paying customers. For educational institutions that cre-ate software derived f-rom their research activities, for example, this can be a way of making money f-rom these activities. Of course, one could also release such software in proprietary form and sell licences to it while still offering services, gaining income f-rom both routes at once. However, it can be argued that releasing the software with no licence fees under an open source licence might increase the number of users, and thereby widen the potential market for the other services.

Internal cost-savings

Cost-reduction is another reason for an organisation to support an internally developed FOSS project, if it provides savings to the organisation greater than the cost of its development, or if it solves an internal problem. Furthermore, a project that has proved useful to one organisation may also be useful to others. This could drive the growth of a cross-institutional community around the project, and also possibly become a source of revenue by creating a market for, for example, paid consultancy work or other services.

Software as a network-based service

The increasing acceptance of software provided as a network-based service can account for another revenue stream. Provision of these services using software licensed on copyleft principles does not break any licence conditions, as the software is not distributed in the traditional sense, and the reciprocal licensing responsibilities are therefore not required. This can provide an al-ternative model whe-re licence compatibilities might otherwise block exploitation based on distribution. However, it should be noted that proponents of copyleft licensing regard this as a shortcoming of existing licences; efforts to cre-ate a licence that does not allow this activity have resulted in the Affero Public Licence. Proponents of non-copyleft open source licences, by contrast, will tend to see this activity as within the spirit of those licences.

Advertising or referral fees

Income can also be derived f-rom advertising and/or referral services. In 2007, the major proportion of the Mozilla Foundation’s $75m income came f-rom a deal with Google, which saw search terms typed into Mozilla Firefox’s search box directed to Google servers. Even for smaller projects, referred links into vendors like Amazon f-rom a project website can provide an income stream. Obtaining a trademark associated with a project name and/or logo can also provide opportunities for both merchandising and outward licensing for third-party training or product creation.

Closed source derivatives, and dual licensing

Now let’s look at the more ‘traditional’ FOSS exploitation techniques - provision of paid support, selling closed source versions or proprietary add-ons, and dual-licensing. The first has already been mentioned. The second involves adding extra features in a non-open source form, for which users have to pay. This can be done either by reserving certain desirable features for a non-open source version of a piece of software, or - whe-re the architecture permits - releasing separate, non-open source add-ons for which a user has to pay. The former is possible when software is either available under a permissive licence (such as the Apache License), which allows anyone to cre-ate a non-open source derivative, or if all the copyright holders agree to cre-ate a separately licensed, closed source derivative.

The third model mentioned, dual-licensing, also involves releasing a non-open source version of a piece software alongside an open source version. Specifically, it involves releasing software under a strong copyleft licence such as the GNU GPL, and also making available a version under an al-ternative licence, allowing users who do not wish to be bound by the GNU GPL to pay for the non-copyleft v4ersion. Generally, they would do this because they wish to produce a product based on the code but not be confined by a copyleft licence. Models such as those discussed in this section can allow a community to collaborate on an open source ‘core’, while at the same time allowing some members of the community to make money by creating and selling closed source variations on it.

Some examples

Now let’s take a look at some notable examples of FOSS projects that fulfil some of the criteria and features we have discussed. First up is Red Hat, an example of a company that c-harges for services for software that is otherwise free of c-harge. Its main products are the enterprise-grade Red Hat Enterprise Linux operating system and the community-developed Fedora operating system. Red Hat Enterprise Linux comes as part of a subscription fee and has an enterprise-friendly roster of consultancy and paid support, an accredited training program, IP indemnification and managed upgrades. While the Red Hat Linux system is also available without payment of a subscription, it comes in a form that is harder to install, and important services such as managed up-dates are not available. The Fedora operating system, by contrast, is an open development project. It has no fees attached, and includes many of the technical features of Red Hat; however, it does not have the accompanying safeguards and services that Red Hat Linux boasts.

MySQL provides an SQL database system under a dual licence; the software is available in a copyleft licence package as well as a commercial licence aimed at system integrators. Similar to Red Hat, MySQL offers a suite of training and consultancy services and IP indemnification. The key differentiator is their dual-licensing; the copyleft licence is not suitable for developers wishing to incorporate MySQL software into proprietary and/or commercial software, so a commercially licensed version is also available.

Exim, the widely used message-transfer agent, is an example of a project that has been nurtured precisely because of demonstrable cost-savings to its host institution. Exim began as an internal project at the University of Cambridge computing services department in 1996 and since then has reduced costs at the University. Subsequent support has taken the form of staff resources and an externally delivered training programme. Finally, XenSource is an example of a project that grew f-rom academic research and provided a revenue stream to its creators via managed bundles of paid support to third-party vendors.

Conclusion

We have seen that FOSS and commercial software are not antagonistic or mutually exclusive concepts. In fact, FOSS components and code are being increasingly accepted as part of commercial software and Gartner predicts that FOSS will form part of 80 per cent of commercial software offerings by 2012. This will provide a challenge for the sector, given that skills related to open source are still not widely available.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com