White Papers

White Papers

Real-Time Location Analytics: Use Cases

This white paper will focus on the business benefits of a real-time location analytics solution for large as well as small organizations in any industry. We first explain the concept of real-time location analytics and how organizations can benefit by incorporating such a solution.

Sep, 2017

Digital Transformation Through PSD2 and Open Banking

The European Banking Authority (EBA) took the EU financial markets by storm in 2016 when it mandated that all banks operating in the region must be PSD2 compliant by January 2018. This whitepaper covers how you can leverage PSD2 to Enter the New World of Open Banking, and why WSO2 Open Banking should be your solution of choice.

Sep, 2017

Devices - At the Forefront of Your Digital Transformation Journey

The Internet of Things is already playing a key role in the business world as organizations increasingly look for innovative ways to maintain their competitive edge. This white paper discusses the role of devices in digital transformation and best practices you must follow when picking your device management strategy.

Aug, 2017

Real-time Analytics in Retail: Use Cases

Consumers today have ready and easy access to information on anything, anytime, and anyplace. Likewise, enterprises too have access to large amounts of data that contain customer demographics, usage patterns, and preferences. This white paper will discuss key analytics solutions that will help organizations to manage and derive insights from this data and improve the way they do business.

Aug, 2017

Real-Time Analytics in Banking & Finance: Use Cases

The world of banking & finance is a rich playground for real-time analytics. The ability to correlate, analyze and act on data, such as trading data, market prices, and company updates is imperative to organizations within this industry. This white paper will discuss key analytics solutions that can manage and analyze this data and offer business benefits to organizations within this vertical.

Aug, 2017

The Different Levels of Streaming Analytics: Use Cases

The Gartner report titled ’The Five Levels of Stream Analytics' outlines five maturity levels for streaming analytics, which provide a roadmap for organizations to follow. This white paper discusses how enterprises can implement each of these levels using the WSO2 Analytics Platform to derive value from streaming data.

Jul, 2017

A Pragmatic Approach to Rock Your API Strategy

Your APIs are to your business what a panel and controls are to a car. Most people have no clue about how a car works under the hood, but knows that if you push the accelerator, the car goes faster, and if you apply your brakes, the car will eventually stop. Similarly, things like climate control, blind spot detection, and adaptive cruise control provide a safer and more enjoyable driving experience without you having to worry about how those systems do what they do. Well, that is exactly how good APIs should work! This white paper explains why you need to and how you can adopt an effective API strategy. It demonstrates the most pragmatic way to do this with general insights and real experiences from some of our consultants on the field.

Jun, 2017

Leveraging a Winning API Management Strategy for Digital Transformation

With emerging digital businesses that create novel products and services, digital transformation is key for both established and modern organizations. This paper will analyze industry surveys conducted by independent and reputed establishments that explore the challenges faced when adopting a digital transformation strategy. It will then discuss the aspects an organization must consider when evaluating an API management solution and will examine how WSO2 API Manager can be used to solve their digital transformation needs.

Jun, 2017

Building an API Strategy Using an Enterprise API Marketplace

An API marketplace goes above and beyond simple API management; a marketplace involves the technology, business and human aspects of API management, ensuring the APIs achieve what they were intended for in the first place: the consumption and usage of APIs. This white paper discusses the advantages of building an enterprise API marketplace and the steps for launching an effective enterprise API marketplace.

Jun, 2017

An Iterative Approach to Digital Transformation

There is no finish line in a digital transformation journey. As you adapt to one technology, the need to change to another one is on the horizon. This white paper will look at a pragmatic and repeatable way to plan, build, and deliver innovative ideas with an iterative approach, spanning both technical and non-technical elements of a digital enterprise.

Feb, 2017

A Platform for Digital Transformation

Digital products improve your business prospects in three fundamental ways: New digital services can expand your line of products and services or add value to existing products or services. This white paper looks specifically at fundamental components of the architecture and infrastructure supporting digital transformation.

Feb, 2017

Convergencia soa – api. Estrategia y tácticas

A pesar de que todo el mundo reconoce que la adopción de una Arquitectura Orientada a Servicios (SOA) y las API son los enfoques más apropiados para un gran número de desarrollos y soluciones en sistemas empresariales, las curvas de aprendizaje y adopción pueden ser muy pronunciadas. Para obtener beneficios a nivel corporativo, los equipos TI deben entender los objetivos de negocio, definir la visión adecuada tanto SOA como API, describir cómo se implementarán los objetivos de negocio y las API públicas además de definir las prácticas de gobierno de los servicios.

Jan, 2017

Reduce los costes de infraestructura y aumenta la agilidad con WSO2

La plataforma middleware de WSO2 reduce significativamente el coste de las infraestructuras en comparación con otros proveedores de soluciones y plataformas similares (no en la nube) propietarias y licenciatarias. Con la adopción de la plataforma de middleware WSO2 en tu organización los costes se reducen hasta en un 75% adquiriendo así, una solución completa con una cuarta parte del coste total si lo comparamos con despliegues en plataformas propietarias.

Dec, 2016

Boas Praticas para uma plataforma de Dados Abertos e Transparencia

O tema transparência, lei de acesso à informação, já não é novidade para muitos na esfera e indústria do Governo. Entretanto, ainda é extremamente complexo obter as informações de forma ágil, embora muitos orgãos tenham seus sites e portais, em muitos deles as informações ainda que disponíveis, muitas vezes estão em formatos complexos, com acesso burocrático e ainda pior: Captchas! Para que captchas se o acesso deveria ser estimulado e não restringindo?

Dec, 2016

Uma visão pragmática para sua iniciativa de APIs

A busca por uma estratégia assertiva em expor essas funcionalidades internas nas organizações, de uma forma reutilizável, fácil de consumir por diversas aplicações e gerar receitas com este novo negócio é o que conhecemos como Estratégia de APIs e Economia das APIs. Uma colocação no mercado que conota bem este momento que vivemos é: "se na década de 90 era ruim uma empresa não ter um website, hoje dia é extremamente ruim uma empresa não ter uma API".

Vamos economizar um pouco de histórias e ir direto ao ponto: o que muitas empresas devem buscar em suas iniciativas de APIs?

Dec, 2016

API Management Platform Technical Evaluation Framework

This white paper will describe innovative digital business goals, outline transformative API oriented IT initiatives, and present API Management platform requirement categories.

Nov, 2016

Capacity Planning for Application Design

This white paper attempts to explore the science of this discipline – it will look at the theory of capacity planning, and discuss the important concepts and parameters, and some practical examples.

Nov, 2016

IoT Analytics: Using Big Data to Architect IoT Solutions

A typical IoT system would comprise of sensors that would collect data and transfer them to a gateway, which in turn would send them to a processing system (analytics cloud).This white paper aims to explain the challenges of IoT analytics and will discuss how big data analytics is used to architect IoT solutions.

Nov, 2016

Connected Retail Reference Architecture

This white paper will discuss the importance of creating a connected retail system today and explain how a complete middleware platform can help address these challenges and meet your retail IT requirements. It will discuss a connected retail reference architecture with actual customer use cases.

Nov, 2016

Connect the World: A Definitive Guide For Your Enterprise Architecture Needs

This white paper will focus on how becoming a connected enterprise can help your organization 1) get close to your customers by way of becoming increasingly visible in the customer’s environment; 2) become a viral business by enabling a generative platform that lets users generate new innovations leveraging the power of the platform; and 3) extend your boundaries by providing capabilities and leveraging those that have been offered to your enterprise. It will further explain the key steps an enterprise should take to leverage the benefits of a connected world. The paper also illustrates these benefits with real use cases (connected airplane, connected health, connected car, connected government).

Nov, 2016

A Reference Architecture for Deploying WSO2 Middleware on Kubernetes

Kubernetes is an open source container management system for automating deployment, operations, scaling of containerized applications and creating cluster of containers. It provides advanced platform as a service (PaaS) features, such as container grouping, auto healing, horizontal auto-scaling, DNS management, load balancing, rolling out updates, and resource monitoring, and make container as a service (CaaS).

Nov, 2016

Connected Health Reference Architecture

This white paper explains the benefits of a healthcare ecosystem, and will discuss how enterprise middleware can help industry players overcome key challenges, enabling disparate systems to work together in an interoperable manner.

Nov, 2016

The Business Value of Open Source

Open source software was first conceived as a concept in the late 90s, and had the great merit of being described as a really dangerous idea. Simon Phipps, former president of the Open Source Initiative (OSI), presented a keynote at WSO2Con EU 2015 in which he discussed the business value of open source today.

Nov, 2016

Everything You Need to Know About the WSO2 Analytics Platform

This white paper will discuss how enterprises today leverage batch and real-time, predictive, and interactive analytics to gain valuable information and make business decisions. It will discuss the key requirements of a comprehensive analytics platform and introduce WSO2’s fully open-source, comprehensive analytics platform.

Nov, 2016

Connected Identity: Benefits, Risks, and Challenges

SAML, OpenID, OpenID Connect, WS-Federation all support identity federation – in other words, all of these standards enable cross-domain authentication. Yet, most federation systems today operate in silos - i.e., a SAML federation silo, an OpenID Connect federation silo, an OpenID federation silo, etc.

Nov, 2016

Connected Education Reference Architecture

Connected education environments exhibit unique requirements to optimally support research projects, curriculum advancement, and effective learning environments, IT teams rely on a connected education reference architecture that streamlines provisioning, delivers self-service access, federates security, and encourages creative experimentation.

Oct, 2016

Microservices in Practice - Key Achitectural Concepts of an MSA

This whitepaper will focus on the key architectural concepts of a microservice architecture (MSA) and discuss how you can use those concepts in practice.

Oct, 2016

Open Source - Why Contribute

White Paper

The Open Source Primer: Part 3 - Why Contribute


By Jonathan Marsh
Vice President - Strategy, WSO2

Open source communities grow strong when there are many and diverse participants. For many popular projects, there are a few major contributors – usually the authors of the original code – but a long tail of community members that help keep a project current, relevant, and of the highest quality.

There are many motivations for joining an open source community – a software vendor relying on the project has a clear interest in participating. Individuals may participate for their own enjoyment or to build skills and a reputation that boost their career.

But this essay focuses on participation from users, especially for employees of a user organization who participate as part of their job duties. What could be the benefits for contributing such resources to an open source project, for which there are no direct returns?

Protecting Technology Investment

One of the primary drivers for sponsoring an open source project is to protect your investment in the technology. As a user, you value the longterm benefits of a project that remains stable and reliable while evolving along with the new demands that may be placed upon it. By being an active contributor, your needs are represented directly in the project and help drive its direction in a way that aligns well with your needs.

In addition, participation helps build expertise that may be useful should the vendors you use in conjunction with a project become misaligned. In the worst cases a vendor could go out of business, or be acquired by a company with poor alignment with your vision. In this case, any expertise you have in the project will help maintain, influence, or in worst case fork the project to extricate yourself from the commercial relationship.

One common benefit of contributing is to relieve yourself of the sole responsibility to support extensions or improvements. Code you write and successfully contribute is supported and evolved further by the community and by vendors providing additional services.

If you rely on a project and want it to be supported by a vibrant, diverse community, it behooves you to be an integral part of that community. If not you, who?

Awesome Employees

Open source is very attractive to technical staff. With an open source license it’s extremely amenable to go-getters who proactively build expertise in the product (as a user or as a contributor.) Technical staff views the ability to participate and contribute to an open source project as an employee benefit, that is both enjoyable as well as builds their professional capabilities and stature.

Collaboration with peers around a technology helps bring new insights into your organization, and discover what is working well (or not) within other companies.

Being part of a community can also be a source of job candidates. Nothing like seeing someone in action!

Cause It's The Tight Thing To Do

Open source essentially opens up a technology in a way that gives you many of the rights of ownership – influence on the direction, ability to evolve it, decisions about process. If you are a “part-owner” of a technology, and are deriving benefit from it, it is the right thing to do to support the community in proportion to the value you receive and not just be a freeloader. Sure it's technically possible to mooch off a project and let others put up all the investment while you reap the rewards, but if everyone did that where would we be?

Many Ways to Contribute

Now that you are convinced that some level of support or contribution to an open source community is in both your interest and the interest of the society at large, how do you start and what commitment is required?

There are many levels of commitment, you can choose one today and increase or pull back on your commitment as you need to.

Contribute as a Community Member

There are many ways to contribute that don't take much commitment, or even legal review. You can and should get started with them right away.

Spread the word: one of the simplest but indispensable ways you can contribute to an open source project is simply to promote it. Mention it to your peers. Tweet or blog about it. Share your experiences with it. Attend a community event. This helps attract more community and builds momentum around the project. It's simple and it's free!

File bugs/suggest improvements: if you see something that needs to be improved, please share it! Open source benefits hugely from direct interaction with users, and anything positive or negative that you can share will affect the project quickly.

Help others: building some expertise on the product? Share it with others. There are always questions on user forums like stackoverflow.com that could benefit from your knowledge. And by helping others you are building your own reputation as an expert.

Contribute as a Developer

Open source project typically reserve commit and process voting rights to individuals who have proven their capabilities and commitment to the project. But there are many ways to contribute technically to a project that don’t require elevation to committer status – although these activities are precisely what will earn you that status.

Evaluate source code: Take a look at the source code. Ask questions. Engage in the discussion of new features. Suggest improvements. More eyes makes for better code!

Submit fixes as patches: If you see something that needs fixing, just fix it! Without committer access to the source code you can still submit your fix as a "diff." A committer will evaluate it and if it is good will check it in for you. Note that typically these diffs require you to agree to a "Contribution License Agreement," that basically confirms that you will allow the contribution to be released as open source and you don’t know of any intellectual property that it violates. This is basic housekeeping to ensure the open source project maintains clear provenance.

Test release candidates: Let's face it, you can never test too much! If there is a release candidate, try it in your environment to see if it meets the quality bar.

Improve the documentation: Or the home page. Or create a cool logo. Or develop some good training material. Lots of ways to help a project beyond the source code itself, and there is always a need for these less glamorous of tasks.

Become a Committer

Most projects follow a well-established governance process that supports massively distributed work and decision making by a highly distributed group of individuals. One of the best known, and the one WSO2 uses, is the Apache Way.

The Apache Way reserves “committer” status, rights, and obligations to those who have demonstrated their capability and commitment to the project. These rights include full write access to the source code, the ability to vote (primarily on releases, adding new committers, and new features.)

New committers are voted in by existing committers, based solely on their contributions, without regard to who their employer is. It’s a pure meritocracy.

Contributing to WSO2 Projects

At WSO2, there is no corporate interference in project governance. The existing committers vote in new committers based solely on their history of meaningful contribution. This means committers from outside WSO2 are encouraged to participate and welcomed to earn committer status.

Committer status is given to individuals and transcends the employment relationship. A committer changing jobs but still committed to the project retains their status. Please see the collaboration process from the Apache Way ( http://www.apache.org/foundation/how-it-works.html#management) which WSO2 uses as our governance model for all our projects.

Please also see the Community page for instructions on how to make a contribution.

Also see TCO Factor and Open Source Primer

Go to Top


Interested in similar content?

Oct, 2016

Open Source - TCO Factors

White Paper

The Open Source Primer: Part 2 - TCO Factors


By Jonathan Marsh
Vice President - Strategy, WSO2

Total Cost of Ownership (TCO) figures are often published by vendors but can be hard to relate to your own organization or a specific project. Often they involve an over-idealized model of the business. Small deviations between reality and the TCO model assumptions can easily overwhelm the supposed logic of the calculation. In addition too narrow a focus solely on costs (TCO) versus the subtle factors that affect the Return On Investment (ROI) can obscure the true goal.

For these reasons we’d like to begin our discussion of TCO by presenting some factors inherent to open source software that are hard to quantify in a TCO context but have significant impact on the long term outcome:

1. Unimpeded ability to experiment. With open source licensing, you can begin experimenting immediately – no need to obtain a software license, apply for a key to unlock the software, or wait for business hours somewhere to get permission. You can try – and even fail which is a critical part of any innovative environment – with little consequence in terms of time or money.

2. Flexibility. Open source code puts a significant emphasis on flexibility – a wide community representing many diverse interests and points of view naturally leads to software that is fully instrumented with extension points, caters to a wide variety of use cases, and allows faster iteration to accommodate changing requirements. The cost of a tool inflexible in the face of changing requirements or environments can be very steep – either in diminishing ROI or requiring a costly migration to an alternate solution.

3. Protection against lock-in. Software without an open source license by definition provides – by definition – a monopoly to the software vendor. Sometimes this monopoly position develops into tendencies towards arrogance and laziness, and customers have no choice but to put up with this situation because abandoning a vendor also means abandoning the software. With open source licensing, the vendor and the technology are not legally locked together. If you can find a better vendor to support the technology the open source license ensures that you are free to do so. You can support it yourself if you are willing to invest in developing that capability. Alternative vendors are free to spring up without the permission of the original vendor.

4. Keeping vendors honest. As just discussed, under open source licensing, alternatives will spring up or customers will develop the capability to self-support if the there is good technology but the vendor fails to provide value. Where there is a primary vendor, there is constant pressure to ensure that the services and relationship are so good that there is no need to consider an alternative. Ideally, so good that there is little room in the market for alternatives.

5. Developer satisfaction. Many developers are happier and more productive when using open source technologies. They know they can reuse their skills, build a personal relationship with the community, use the technology for DIY projects at home or for charity. They know they will not hit a stone wall where corporate sluggishness or misaligned interests can halt progress. With open source there are no limits to their ability to learn from, debug, commit fixes, and even develop new features for the code.

Let's look at the more traditional measures of TCO and how open source can contribute to them as well:

1. Acquisition cost. Typical software licensing involves a pre-paid license fee upon commencement of development, followed by annual maintenance and support fees. An open source license forgoes the initial license fee typically in favor of an annual subscription specifically designated for support and maintenance. The subscription cost coincides with successful deployment and doesn’t require a large lump sum.

Subscription fees also can be treated as operational expenses instead of capital expenses, which may have advantages in some organizations.

Open source software plays well with other open source software and ensures that the TCO and ROI of each level of the stack can be evaluated independently. Open source software will typically not have hard dependencies on proprietary operating systems, databases, or other technologies.

2. Operating costs. A key component of cost is maintaining “modern” software – upgrading regularly as improvements are made, obtaining service packs, and availability of patches to fix specific issues. Open source tends to provide a faster cadence of point releases, so any improvement or fix can be taken advantage of quickly. There are typically no charges for upgrading an open source product to a new version.

Comparing the cost of a commercial license to an open source support subscription isn't hard – determine a time frame, and estimate the initial license fees, licenses for major upgrades, and annual maintenance fees and compare them over the same period with an annual open source subscription cost.

3. Personnel costs. Personnel costs are related primarily to software quality and ease of use, not necessarily to the type of license. But open source software typically attracts talent, supports the availability of a wide set of third party services such as development and system integration.

WSO2 TCO Factors

WSO2's business model does not allow us to charge license fees for our products. Instead we provide subscription support services and development assistance. When performing a cost comparison, the following considerations may be helpful:

Factor Proprietary license Factor
License fees for production use Requires one-time fees based on CPUs or PVU No fees
License fees for upgrades Major upgrades usually require new license fees No fees
Annual support/ maintenance Annual fee, typically a 15-25% of initial license fees Annual per-JVM subscription fee.
License fees for passive standby use Generally requires fees Supported with no additional fees
License fees for development use Generally requires fees, check the license to see what the non-production permitted uses of each license are No fees Development Support available in hourly bundles
License fees for testing Generally requires fees No fees required – subscription only if SLA support is desired
License fees for staging Generally requires fees No fees required – subscription only if SLA support is desired
License fees for passive standby use May require fees No fees

Go to Top


Interested in similar content?

Oct, 2016

Open Source Primer

White Paper

The Open Source Primer: Part 1


By Jonathan Marsh
Vice President - Strategy, WSO2

Software Licensing 101

Software is a strange product. It exists entirely in the information space, so the marginal cost of a copy is near zero. As DVD distribution has given way to Internet downloads software has even escaped the bonds of corporeal formats - like an advanced intelligence from Star Trek evolving into pure energy - and can be delivered anywhere virtually instantly, at virtually no cost.

The impalpable form of software posed challenges to the early creators of software who wanted to sell it as a valuable new type of product. If you sell a copy that can be copied and distributed at no cost how can you spread the cost of creation across a large set of paying users?

Software licenses were the answer. By not “selling” the software outright creators retain full ownership and use copyright law to limit anyone else from making copies. Then, usually in exchange for a fee, the creator loosens up just enough of the restrictions to attract users to the software. The restrictions usually include:

  • Limiting the use of the software to those paying fees
  • Limiting the installation of the software to a certain set of (physical or virtual) machines
  • Limiting sharing, renting, or reselling of the software
  • Limiting certain uses of the software
  • Limiting examining the source code (traditionally, source code was not licensed and simply kept hidden)
  • Limiting reverse engineering
  • Limiting extending the software or building new software upon it

When you read a software licenses you find it’s mostly about LIMITS.

Limits are reasonable in ensuring that the creator is adequately compensated for their creative investments. But limits on use of the software also translate directly into limits on the business value you can obtain from the software. Some of the unpleasant side effects of these limits on a business include:

  • Dependence on a single vendor. Typically the vendor retains enough rights that you cannot ultimately obtain the software or obtain services from anywhere else. If the interests of the vendor differ from yours, too bad.
  • Lack of control over license fees – the vendor sets them and even after negotiating vigorously the vendor still has final control over the price and any price increases in the future.
  • Misalignment of long term goals. The vendor makes the bulk of their money simply by selling the license – not by ensuring it gets deployed effectively (the problem of shelfware) or by providing the highest quality support. Support is often judged as a cost, instead of a revenue stream tied directly to customer satisfaction. A license sale is not inherently aligned with user value, which is realized by getting the software in production and keeping it going over the long term.
  • Accidental license violations can carry stiff repercussions. For instance, moving from one machine to another is increasingly an automatic process – but does the license allow this? Are additional fees due if for instance the number of cores changes during the move?
  • The customer has limited options for influencing product features and fixes. All they can do is plead with the vendor and hope for the best.
  • The customer has little to no visibility into how the software actually works. This is especially damaging in the security space where more eyes on the source code make for a more secure solution.

And Then Came Open Source

It is no wonder that open source is so attractive – it reverses the premise that software licenses are about limits on the use. It eliminates many of the unpleasant side effects of traditional licensing by promising that the creator will NOT impose such limits.

Open source software is licensed under principles of freedom to use, study, improve, and share the software. The creator of the software, while still owning the intellectual property behind the software, has agreed that others may use the software without the traditional limits of a proprietary license. An open source license has:

  • No fees
  • No limits to installation
  • No limits to sharing, renting, or even reselling
  • No limits to usage
  • No limits to changing, altering, or evolving the software - source code is even provided to encourage this

Many of the negative side effects of commercial licenses are correspondingly reversed:

  • You are NOT dependent on a single vendor. If the vendor isn’t providing value, there is no monopoly over the source code preventing competition. You can switch (or threaten to switch) to another vendor.
  • There are NO license fees on the basic product.
  • The vendor makes money directly proportional to immediate and ongoing value – such as support, documentation, consulting, training, additional warranties, additional features.
  • There is little chance of, and correspondingly less harm from, accidental license violations.
  • The customer has a much greater variety of options for influencing product features and fixes – including sponsoring feature development or contributing features back themselves.
  • The source code is fully available and can be rigorously examined by multiple parties for efficiency, reliability, and security.
  • The source code can be readily archived by anyone – eliminating the complications of code escrow contractual provisions.

Now, it should be clear – while it’s easier to build a quality product using open source collaboration methods, it’s much HARDER to build a viable business creating software if you choose open source licensing. Disarming of the monopoly power of traditional licenses is not for the faint of heart. Many users will use your product for free if they are allowed to do so. You can’t just write great code and wait for the money to flow in, you also have to also invest in value-added services and keep them attractive.

The only thing harder, in the long run, than developing a successful open source business is NOT going open source and trying to compete with vendors who have committed and succeeded at this model.

Open Source Business Models

In fact many, if not most, open source businesses have cheated a little bit on their open source commitment in order to make their businesses grow more reliably. The most common model is an "open core" model, where the core software is available open source, released under a designation such as "community edition." But as soon as enterprise features are needed customers must obtain an "enterprise edition." The enterprise edition typically abandons pure open source licensing and reverts to a traditional license – and the customer therefore loses to a large degree the advantages of open source licensing.

Over time, many customers have found this dual license model disadvantageous. The most demanded new features typically appear in the "enterprise" version rather than in the “community” version – it's a natural move to keep as much monopoly control as possible once you’ve stepped down that path. But at some point the community version really just becomes a teaser, providing a façade of open source, collecting some free improvements contributed by the community, but retaining the majority of the value of those contributions commercially for the vendor.

WSO2 is committed to a 100% Apache-compatible model. There is no community/enterprise version split – every product has all features and is enterprise ready. We provide support services, maintenance, consulting, training, and a variety of other valuable services around the free software, for which we work hard to build a strong value proposition and earn customer loyalty.

Open Source License Types

We would be remiss in omitting a notice that not all open source licenses are created equal. In general there are two families of open source licenses – "permissive" and "copyleft."

Permissive is as it sounds – the user is free to do virtually whatever they like with the software – including creating derivatives and releasing them under a traditional commercial license.

Copyleft licenses require that any derivative works, which might be simple improvements or could be a combination of copyleft code with other pre-existing code, must also be made available under the copyleft license. This requirement scares many in the software industry, as it behooves them to commit upfront to open source license terms in any derivatives, or any other code they have which might be combined with the copyleft software.

This stifles their ability to start coding now and assess the ultimate value of the work, and the appropriate license to apply, later.

In one sense, copyleft protects the authors of the code, from being exploited by others building on and profiting from their work without giving back to the original creators. That is an admirable goal. But it is not one that a lot of businesses are able to commit to in advance. A permissive license allows a business to adopt code, improve it, share it, profit from it, or whatever, without having to make a decision up front about whether to share the derivative back to the community.

WSO2 encourages contributions and derivative works released under an open source license, but does not demand that users pre-agree to return improvements to the community. Especially in the middleware space, it is fairly common that an internal application evolves into a marketable standalone product. It is wise not to constrain future business models. For these reasons WSO2 exclusively provide customers with permissive open source licenses, specifically the most well known, the Apache 2.0 license.


Peter Cochran has said "The world is divided into two kinds of people, those who spend a great deal of time saving money, and those who spend a great deal of money saving time."

WSO2 believes that the combination of free open source software – which can be used and improved by all – together with valuable business services that help customers save time at a reasonable cost – are the ultimate future of the industry. We believe permissive open source licenses provide the greatest alignment between the interests of creators and users of software.

So we encourage you to download and try out our products under the open source "no obligation" license. We encourage you to engage with the WSO2 community – share your experiences, contribute back to the projects, or if you put a value on saving time, explore a commercial relationship with WSO2. We are highly motivated to ensure you are satisfied.

Also see TCO Factor and Why Contribute

Go to Top


Interested in similar content?

Oct, 2016

A Reference Architecture for the Internet of Things

This white paper introduces a Reference Architecture for the Internet of Things (IoT): this includes the devices as well as the server-side and cloud architecture required to interact with and manage the devices. The aim of this is to provide architects and developers of IoT projects with an effective starting point that covers the major requirements of IoT projects and systems.

Oct, 2016

WSO2 Rest API Design Guidelines

This white paper provides guidelines, based on proven industry best practices, on how to develop a REST API that reaches Level 2 of the Richardson Maturity Model.

Sep, 2016

Scope Versus Size: a Pragmatic Approach to Microservice Architecture

This white paper will focus on the key fundamentals of microservice architecture (MSA) and how technology has evolved to what it is today. It will also discuss the role of enterprise middleware in building an MSA.

Sep, 2016

Connected Finance Reference Architecture

Customers today want to feel empowered and want to do things on their own, prompting banks to increasingly incorporate the concept of self service for all banking requirements. Customers today are also opting for systems that are socially connected as well as simple and useful.

Sep, 2016

Event-Driven Architecture - The Path to Increased Agility and High Expandability

This white paper will discuss the basic functions of an event-driven architecture (EDA) and explain the key advantages it could potentially offer enterprises across many industries, both for traditional enterprises and for the new Platform-3.0 based connected enterprises.

Sep, 2016

The Value of Connecting Everything to Everything

This eBook will highlight the value of connecting everything to everything and explain this via common use cases in the IoT space.

Jul, 2016

Connected Government - Cloud Enabling Public Services

This white paper looks at the functional and nonfunctional challenges that arise in building an e-Government stack and how an enterprise-ready Platform as a Service can help in solving these challenges.

Dec, 2015

Selecting a Cloud Platform: A Platform as a Service Scorecard

This whitepaper will help enterprise architects and solution architects evaluate and select PaaS offerings. Use the proposed evaluation framework and quick start roadmap as guides assisting your choice of goals, requirements, key metrics, use cases, and PaaS providers.

Dec, 2015

Promoting Service Reuse Within Your Enterprise and Maximizing SOA Success

API management is a strategic component within your Service Oriented Architecture initiative. Many development teams publish services, yet struggle to create a service architecture that is widely shared, re-used, and adopted across internal development teams. SOA governance programs often fall far short of encouraging consumer adoption, tracking service consumption, and illustrating business value.

Dec, 2015

Managing Big Data for the Intelligence Community

This white paper explores the nature of the intelligence Big Data problem, posits an architectural solution that leverages well-vetted and established tools and demonstrates how this solution can be implemented in cost-effective and timely manner through the use of open source software.

Dec, 2015

Enterprise Integration Patterns with WSO2 ESB

Enterprise Application Integration (EAI) is key to connecting business applications with heterogeneous systems. Over the years, architects of integration solutions have invented their own blend of patterns in a variety of ways. Most of these standards are described in the Enterprise Integration Patterns Catalog. In this whitepaper, you will see how each pattern in the patterns catalog can be simulated using various constructs in WSO2 ESB.

Dec, 2015

SOA Solutions & Middleware Testing

This white paper discusses how to test solutions built using SOA. This is also known as Beta testing, which usually involves live data. Brief descriptions on test planning and designing is provided along with other important testing tools such as debugging and monitoring tools.

Dec, 2015

Application Services Governance: Automate IT Best Practices and Enforce Effective and Safe Application Service Delivery

Application Services Governance is a mechanism to achieve business agility, build a responsive IT organization, and optimize IT effectiveness. Effective governance automates IT best practices, improves service levels, and facilitates safe, rapid iterations. Governance facilitates safe and rapid change by mitigating risks and reducing uncertainty when teams evolve IT systems. When enhancing governance effectiveness, successful teams smartly remixes IT skills, tooling, and processes; development and operation teams adopt agile processes, introduce automation tooling, and streamline collaboration.

Dec, 2015

Big Data Analytics In Sports - Introducing Football's New 12th Man

This white paper will look at why data analytics is important in football, and for that matter in any sport, along with the case for data analytics. It will also discuss the details of a solution and explain the features such a solution or technology can provide. Moreover, the paper will also take you through how this can be achieved with a technology stack that supports big data analytics.

Dec, 2015

White Papers

Jul, 2001