Open Source Insider


February 6, 2020  3:01 PM

Open source licence series – Cockroach Labs: Scaling a sustainable open source business model

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

Open source grew, it proliferated… and it became something that many previously proprietary-only software vendors embraced as a key means of development… but the issue of how open source software is licenced is still the stuff of some debate.

The Computer Weekly Open Source Insider team now features a series of guest posts examing in the ups & downs and ins & out of open source software licencing.  

Spencer Kimball, co-founder & CEO of Cockroach Labs writes from this point forward.

Edging out

Big cloud vendors have preyed upon open source R&D by providing open source software (OSS) software as-a-service to edge out small competitors. Combine that with the platform benefits of economies of scale and greater opportunities for integration… and you can see how the big cloud providers can drown open source startups.

That said, companies eclipsing growth-stage and legacy companies looking to store mission-critical data in the cloud are becoming wary of big vendors not investing in their R&D.

Competitors have historically been legally allowed to offer another company’s OSS product as their own service and over the last few years, we are seeing this become increasingly common. Highly-integrated vendors are taking advantage of their unique position to offer “as-a-service” versions of OSS products, facilitating a superior user experience as a consequence of their integrations and draining demand from the smaller open source software providers.

That’s why, in 2019, we, and many others, changed our open source licensing to combat this breed of competitor.

Pernicious predators

We’ve seen many companies, ourselves included, change their open source licensing structure in response to these predatory behaviours. In June 2019, we adopted an extremely permissive version of the Business Source License (BSL). This allows customers to scale our technology to any number of nodes and use or embed our database in their applications (whether they ship those applications to customers or run them as a service).

They can even run CockroachDB as a service internally. The one and only thing that you cannot do is offer a commercial version of our core brand as a service without buying a license.

Although it is not recognised by the OSI as officially open source, our new BSL license carries with it many of the benefits of open source. Anyone is still free to build applications on top of our code base and license them accordingly, as the code is freely available for inspection… and contributions to the project are both welcomed and encouraged.

As with all open source projects, there is a community of developers and practitioners for the software.

Our labs engineering team participates in and actively contributes to many open source projects that are adjacent to and power our own product. Most notably, the BSL license has a rolling time limit: three years after each release, that version’s license converts back to the standard Apache 2.0 license.

The big issue

While this approach is effective in helping to scale an open source business model amidst predatory competitors, the situation signals a larger issue in the open source industry as a whole.

As big tech players snatch other vendor’s innovations and sell them as-a-service, investment in their own R&D decreases. This means that while big vendors, such as AWS, are powerful for growth-stage companies, they won’t be well-suited for supporting enterprises migrating mission-critical data to the cloud.

Given the constantly evolving nature of open source and cloud technology, this lack of R&D investment will prove an unsustainable approach for vendors as businesses consider how, where, and with whom they’re migrating to ensure they’re getting access to the best in breed solutions and products.

Kimball: The one and only thing that you cannot do is offer a commercial version of our core brand as a service without buying a license.

February 6, 2020  12:34 AM

Open source licence series – OpenStack Foundation: Protecting open source freedoms

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

Open source grew, it proliferated… and it became something that many previously proprietary-only software vendors embraced as a key means of development… but the issue of how open source software is licenced is still the stuff of some debate.

The Computer Weekly Open Source Insider team now features a series of guest posts examing in the ups & downs and ins & out of open source software licencing.  

Thierry Carrez, vice president of engineering at the OpenStack Foundation writes from this point forward.

Freedom encoded

Reduced to its essence, free and open source software is defining a set of freedoms, encoded into software licences.

The Open Source Initiative (OSI) maintains an open source definition and a list of compatible licences, with the double goal of guaranteeing those essential freedoms and rights… and facilitating adoption by limiting licence proliferation.

This standardisation effort was critical to the success of open source software and its wide adoption in our industry. However, our narrow focus on software licences has created an opening for businesses to co-opt open source. They respect the letter but not the spirit of free and open source software, ultimately depriving users of most of the benefits that the original freedoms were designed to provide.

Over the past 15 years, companies evolved ways to do open source while retaining control, depriving users of key benefits like the ability to rely on multiple vendors, or the ability to influence the future direction of the software.

At the same time, new business models around operating software inserted a layer between the user and developer, depriving end users of key benefits like the ability to look at the code, self-service issues, or try the software with all of its functionality.

Open attack on openness

This evolution culminated last year, during which open source was clearly under attack.

It had been challenged before, but those attacks had come from the outside, from the proprietary software world, trying to convince everyone that open source was dangerous or inferior. The new attacks are coming from the inside, from commercial open source companies, trying to confuse everyone on what open source means.

It started with successful companies wanting to artificially protect their business model against competition, and trying to push new licences that prevent others from building a business on top of the same open source project.

This is based on the illusion that they own the open source project. But by making the choice of releasing their software under an open source licence, they abandoned that control in favour of giving their users key freedoms, which is probably why they ended up being successful in the first place.

Guardians of the open galaxy

The OSI resisted those attempts… and denied those new licences. Some of those companies then decided to attack the legitimacy of OSI as guardians of the open source definition.

There is nothing evil about proprietary software, I just think that open source software is a more efficient way to produce better software. But there is a form of short-sighted evil in companies that want to blur the lines on what “open source” actually is, in order to better align with their evolving business model.

So what should we do about it?

We need to clearly communicate four things:

1- Open source is business-friendly, but it’s not a business model.

It is just a set of freedoms and rights — and if you abide by those freedoms and rights, then you can’t really own an open source project.

Monetisation based on pure ownership of open source is therefore doomed to fail.

2- The value of open source directly lies in the freedoms it grants.

The value does not come from the “open source” label.

Redefining “open source” to remove freedoms is short-sighted, as it will ultimately destroy its value.

3- How open source software is built affects the benefits you get out of it.

All open source software is not equal.

Open collaboration on a level playing field is the best way to preserve user benefits, like the ability to rely on multiple vendors or to influence the future direction of the software.

4- Licences are not the only tool we can use.

Licences for example are terrible ways to say how the software should be built.

We should use other tools to drive those agendas, like classification or labellisation.

The open source community is facing powerful opponents, who spread confusion for their benefit.

Only through clarity and education will we be able to prevail.

Carrez: Proprietary is not evil, open is just a more efficient way to produce better software.


February 1, 2020  12:52 PM

Open source licence series – Delphix: Rent vs buy, which fits your licencing cost model?

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

Open source grew, it proliferated… and it became something that many previously proprietary-only software vendors embraced as a key means of development… but the issue of how open source software is licenced is still the stuff of some debate.

The Computer Weekly Open Source Insider team now features a series of guest posts examing in the ups & downs and ins & out of open source software licencing.  

Colin Rand, Delphix’s VP cloud products writes from this point forward.

Choosing an open source licensing model can feel a lot like a first-time home buying experience. It’s a big commitment, and deciding whether to “rent” versus “buy” a software license can have a lasting effect on the entire lifecycle of a product. You first need to decide where your software is going to run before you even decide what to do with it. That decision comes down to whether you’re running on-prem or in the cloud.

Everything stems from that first choice, and suddenly you’re faced with difficult technical selection criteria at every step of the open-source journey. At the heart of it all is licensing – or in layman’s terms: who’s running the operation.

Of course, if you’ve got a greenfield, it’s much easier to make these decisions. But more often than not, you’re tasked with modernising a main application that’s been around for 10 or even 15 years – that’s when it gets especially hard. You could be stuck with a proprietary database on-prem, and for whatever reason, the cloud provider can’t offer an equivalent licensing cost model. Several recent examples with both open source (e.g., Elastic and MongoDB) and proprietary (e.g. Oracle) have shown database vendors changing licensing terms to combat competition with public cloud providers. In other words, the developer-friendly OSS companies are turning into customer pain points!

Let’s take a look at two different scenarios when approaching your cost-models and how they’re affected by who ultimately operates the platform the application runs on.

“Renting” aka the managed approach

When an application follows a rented (or managed) approach, you’ll often see a selection process for new components as follows:

1)    Use the built-in component provided by a public cloud

2)    Use a service provided by a trusted third party

3)    Use an off-the-shelf library component

4)    Write custom code

If you use this model, you’re inherently selecting productivity for developers and ease of operational scale over cost optimisation. At each step of the way, the component could be open source or proprietary, but the big benefit here is reducing the effort to run or operate the component versus a license granting permission. Cost modeling in this situation is therefore based on usage as the primary driver. While capital is cheap, enterprises can benefit greatly from the short-term flexibility this type of approach provides.

“Buying” aka the owned approach

The other option is to go the owned route. When an application follows an owned model, the selection process follows a different pattern:

1)    Compatibility with the ecosystem

2)    Compliant with policies

3)    Vendor support

In this scenario, the dominant benefit is enterprise control as opposed to developer productivity. Costs here are often negotiated upfront and renewed on a multi-year basis, leading to models with better long-term visibility. After the big cloud hype cycle of the last decade, I believe we’ll see a return trend in which long-term cost management frequently wins over short-term productivity for the enterprise.

Two is not always better than one

Depending on the context of the application, both of the above models can prove to be effective for a business. The real challenge comes in when these two models are mixed, such as when a component or service with the short-term benefit of flexibility is added to a platform that is optimised for long-term control. This tension will complicate any cost strategy, often leading to a situation in which the “worst of both worlds” results in long-term dependency on a cost structure that’s extremely difficult to control.

Ultimately, when developers make selections for components, open source is often their go-to choice, offering benefits that accrue to productivity goals. However, the cost strategy must always take into account the full picture, including vendor lock-in and operations. Once you’ve made the initial, crucial decision for where your software will run – cloud or on-prem – the cost implications of that decision will have an impact on the entire life cycle of the application. If you carefully consider that ripple effect in the first decision-making stage, you’ll be far better prepared for what’s to come.

 


January 31, 2020  5:18 PM

Open source licence series – Tidelift: Ethical source-available licenses challenge open source

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

Open source grew, it proliferated… and it became something that many previously proprietary-only software vendors embraced as a key means of development… but the issue of how open source software is licenced is still the stuff of some debate.

The Computer Weekly Open Source Insider team now features a series of guest posts examing in the ups & downs and ins & out of open source software licencing.  

Tidelift is the largest provider of commercial support and maintenance for the community-led open source software behind modern applications.

Luis Villa is co-founder of Tidelift writes from this point forward.

In September of 2019, Coraline Ada Ehmke released the Hippocratic License, named after the “first, do no harm” Hippocratic Oath taken by doctors.

This license barred any use that “actively and knowingly … harms individuals or groups.” This was the logical next step for a rising movement, since late 2018, of “ethical licenses” that attempt to restrict usage of software in ways that align with the creator’s own ethical principles.

As we look ahead to 2020, I suspect that—because of the massive success of open source—they’ll continue to be in the headlines and maybe gain traction.

Ethics matters

Free software, as advanced by Richard Stallman and the Free Software Foundation, has always been about ethics—a very specific set of ehics that held that source code access was the key to human freedom and used licensing to achieve that goal. But since those early days, the open source movement has become bigger and broader. In particular, it has gone from a niche interest of a handful of developers to a mandatory skill for everyone who participates in the software industry. This means that participants are now much more diverse, many with very different ethical perspectives than early participants.

As software eats the world, much like Marc Andreessen predicted, it becomes inextricably linked with everything—including political headlines and moral challenges. One thing is certain: no matter where you fall on the political spectrum, there are now FOSS developers who hold different views than your own. 

This combination has led us to the current moment—where many developers are participating in FOSS while questioning traditional FOSS beliefs —- in particular the historical belief that any use that complies with the terms of traditional licenses, like MIT and GPL, is unquestionably ethical.

Here are some specific examples where this ethical license movement is playing out: 

  • Chinese labor and the 996.icu license: Chinese software developers have extremely long (and apparently illegal) working hours, called “996” (9am-9pm, six days a week). In response, developers who say they were inspired by open source wrote the 996.icu license, which bans use by companies who violate relevant labor laws.  
  • Immigration, Chef and other anti-ICE licenses: Many American and European developers are immigrants, or friends or children of immigrants, so there have been a variety of protests about software used by the US’s Immigration and Customs Enforcement agency, including a license change by the Lerna project. That change was fairly quickly reverted amid doubts about its efficacy and whether most authors of the project had agreed to it.  
  • Anti-carbon licenses: As people who often have scientific or engineering backgrounds, many developers are concerned about the climate. To that end, at least two anti-carbon licenses have been written that attempt to prohibit use in the carbon extraction industries: the Climate Strike and Atmosphere licenses. 

Why licensing & what’s next

Since the Free Software Foundation and Open Source Initiative spent decades educating the industry that licensing was an effective tool, it should not surprise anyone that developers have seized on licensing as a possible answer to effecting social change. The Chinese labor law license, for example, is currently the second-most-starred project on GitHub. 

Despite this interest, the open source legal community’s near-consensus is that licensing is (at best) a poor tool for promoting ethical beliefs. Drafting such clauses in a way that has no loopholes, but also does not negatively impact “innocent” companies, is very difficult, especially without support from lawyers. 

Enforcement 101

Without dedicated enforcement resources, licenses have a tendency to be ignored—especially by those who are already acting unethically in some way! Of course these licenses break what has long been believed to be a core part of free and open source software’s success—that anyone can use the software without restrictions. (Advocates for ethical licenses point out, perhaps with some justification, that there were similar concerns about the GPL when it was drafted.)

Given this combination of grass-roots interest and expert scorn, it is unclear what will happen in 2020. I strongly suspect that, like GPL, at least some motivated and concerned people will continue experimenting and some of these new ethical licenses will gain a foothold in the overall licensing ecosystem.

If your business is above reproach, sleep tight! Otherwise, keep an eye on this space.

Luis Villa is co-founder of Tidelift.


January 31, 2020  12:11 PM

Open source licence series – Puppet: consumption without collaboration equals consternation

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

Open source grew, it proliferated… and it became something that many previously proprietary-only software vendors embraced as a key means of development… but the issue of how open source software is licenced is still the stuff of some debate.

The Computer Weekly Open Source Insider team now features a series of guest posts examing in the ups & downs and ins & out of open source software licencing.  

Puppet is an open source systems management tool for centralising and automating configuration management tasks relating to both hardware and software.

Nigel Kersten, Field CTO at Puppet writes from this point forward.

Open source has been a key part of our culture and business model since day one — and if there’s one lesson we’ve learned, it’s that open source has always proven to be far more of an opportunity than a threat to our business. 

There’s been a lot of chatter about the threat the big cloud providers pose to open source business models such as open core over the last few years. I believe this angst misses the point. 

Open source is about far more than just code and licensing. It’s about community.

Authenticity affects

If you have authentic community engagement, an open source platform that is not deliberately impoverished, an environment that enables individuals to healthily interact as they build novel workflow solutions that benefit the collective group and nurture contributions that are more than just code, then it’s far more difficult for an external party to come in and negatively impact your business model.

If you just focus on the code and use licences as a defensive weapon, your defenses are weak. The greater threat (and corresponding opportunity!) is the massive amount of people capital and brain power locked up inside large enterprises when it comes to open source. 

Just about every company of every size these days is heavily reliant upon open source in one way or another, whether it be components in the applications you’re building, middleware, databases, operating systems, virtualisation systems or the entire infrastructure orchestration layer. Yet large companies tend to be mere consumers of open source, often paying for commercial distributions or support, without contributing back to the code or communities. These companies contribute by way of dollars. 

Don’t get me wrong.

We all need revenue for our businesses, but this feels like a massive missed social opportunity. 

Large enterprises often create significant institutional barriers to make various forms of open source contribution challenging. It takes people with lots of passion and skill to overcome those barriers in individual cases. Again, this doesn’t just mean code.

Outside sharing

If you look at the 2018 Puppet State of DevOps Report, you see that even at the highest levels of DevOps evolution, only 4% of respondents are sharing best practices and patterns outside their organisation. 

I see this over and over again as I work with enterprise customers. They waste significant time and resources reinventing the wheel in slightly different ways to accommodate existing teams instead of accepting standardised solutions and focusing their energy on true differentiators. 

More importantly, the workflow and business processes that sit on top of all these new IT capabilities are being developed in isolation rather than collaboratively. 

I’m optimistic that we can change this. As open source vendors, we need to continue to invest in online community platforms, not just for communication and code contribution, but also to create spaces and lower the barriers for the community to contribute documentation, workflows and integrations with other technology. 

At Puppet we’ve been pivoting the Puppet Forge (our repository of over 6,300 infrastructure-as-code modules)in this direction and the community response has been fantastic.

Consumption to collaboration

As vendors, we should also make it easier for our commercial enterprise customers to nurture contributions of all forms from this world that has such a massive investment in IT and consumes open source at such a gigantic scale. There are a lot of opportunities to shift the balance from consumption to collaborative production. 

If we can work with users inside large enterprises, work out how to minimise the barriers they face to external contribution and sharing, and get them engaged in the wider open source communities, then the opportunities in front of us all will dwarf any of the supposed threats the cloud providers may pose to the future of open source.

Nigel Kersten, Field CTO at Puppet.

Puppet coders, they don’t play around.


January 27, 2020  5:04 PM

Open source licence series – Rancher Labs: Why vendor ‘strip-mining’ is an opportunity, not a threat

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

Open source grew, it proliferated… and it became something that many previously proprietary-only software vendors embraced as a key means of development… but the issue of how open source software is licenced is still the stuff of some debate.

The Computer Weekly Open Source Insider team now features a series of guest posts examing in the ups & downs and ins & out of open source software licencing.  

Shannon Williams, co-founder and president of Rancher Labs writes from this point forward.

In the land of giants

As an open-source upstart in the container orchestration space, we play in a market populated by giants.

The question of how we protect the value of our technology while freeing it for the good of the community is, naturally, a preoccupation. The beauty of being open source is there’s no barrier to use or experimentation – which is where the really cool projects tend to emerge.

Open source is, by nature, user and community-oriented but it’s that same nature that leaves it open to what some see as commercial exploitation.

Rather than a threat, we see the notion of open source ‘strip-mining’ by large cloud vendors [where the big vendors come in and ‘tap a seam’ of open source gold and mine that for wider smelting and crafting] as an opportunity. The value of the big cloud providers is always intrinsically tied to the ecosystem they’re building around. More and more, organisations want to access those ecosystems, but they know that there is a complex set of relationships between all ecosystems and no single organisation is capable of living in just one of them. They want variety. The more, therefore, those ecosystems integrate with each other and help teams run technologies side-by-side, the bigger and more varied the benefits.

The ‘strip-mining’ analogy is a rough one. While it’s true that some providers don’t put a lot back into the community (there’s definitely been some ugly competition between open source and commercial companies), for the most part, the relationship has been mutually beneficial for both cloud providers and open-source software developers.

The struggle muddle

The struggle occurs when an organisation [or smaller development team] doesn’t have a great business plan or route to market with an open source project. Perhaps it hasn’t been able to commercialise its product and, suddenly, it becomes embedded into something larger – with monetisation happening in the cloud. That’s where the majority of issues arise.

We see it all the time.

Great ideas, not taken properly or aggressively to market, become fair game for savvy cloud players that know these ideas will accelerate ecosystem development. That’s business. It can happen in any space and in any sector – open-source or not.

Having an open source business model is not enough to guarantee commercial success. It does, though, put you in a position where you have a greater chance of listening to what customers and users think are necessary next steps; what they’re excited about using your platform for; and what they are willing to pay to create commercial value from the technology.

Genuine value

As long as we continue to push for greater innovation and offer the kind of open source support model that we do (that helps customers get genuine commercial value from their K8s infrastructure) they’ll want to work with us.

Companies will benefit as long as we continue to improve the technology and take feedback from our users and the wider community. For those considering an open source future, the opportunity is ripe but know what you’re getting into.

It shouldn’t be a huge shock if you build an open source product and someone else does something cool with it. That’s the idea!


January 27, 2020  10:36 AM

Open source licence series – Altus: open source is big business, get used to it

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

Open source grew, it proliferated… and it became something that many previously proprietary-only software vendors embraced as a key means of development… but the issue of how open source software is licenced is still the stuff of some debate.

The Computer Weekly Open Source Insider team now features a series of guest posts examing in the ups & downs and ins & out of open source software licencing. 

Technical Consultant, Sarah Bateman at financial services software company Altus writes from this point forward.

Ain’t no hobby

 The idea that open source developers are college students, creating some really cool software that big organisations then exploit and don’t give anything back may have been valid 20 years ago, but not today, it’s not how things work. 

Open source is now big, with major players driving innovation, like the OpenBank Project, the Banking API platform and OpenLogic. 

For a working example, AT&T is (obviously) a household name and very large quoted business. The organisation provides the majority of engineering, design and architectural resource for the ONAP open source project. 

ONAP is a network virtualisation orchestration product used in the telco world, big telco’s use this tool to meet their fluctuating network capacity requirements and to provide new services. 

These companies will make a lot of money through using ONAP, a piece of open source software.

Exploit factor? 

Are these telcos exploiting poor little AT&T? AT&T is neither poor nor little, it is doing this for a whole raft of sound commercial reasons: it gives the company control of the market, technical profile (kudos) and most importantly allows it to strongly influence the future direction of a key technology and how it is used.

In the insurance world we have OpenUnderwriter, an insurance distribution tool and ‘Lemonade’, the Home Insuretech company is debuting an open source insurance policy that it says all users can help shape. 

In these examples open source is used to drive take-up and help cross borders. Lemonade specifically see the move both ways, to increase innovation with a large pool of contributors and increased customers through the improved perception of openness and trust in an industry that can be seen very much as a black box. 

These motivations will be common for many of the open source development solutions out there, a lone person developing code for the betterment of humanity is no longer the norm. It’s businesses deciding they want to develop software, software that is, on the surface free, but may result in revenue, for example through consultancy, it raises their profile, makes them look good and enables them to get really good talent to work for them.

Understanding the misunderstanding

If we take a look at insurance, it should be remembered that it is a high volume, small margin business; companies setting themselves up as a tech business on the other hand, will enable them to get a higher multiplier for any planned IPO and founder exit. 

To think these organisations, or any software company using open source software, are exploiting the open source providers and they should be giving back to the community, is a misunderstanding of that community. 

I would argue that a lot of companies do feedback changes, look at the thriving Drupal community, thriving due to contributions from developers working for web companies; employing a Drupal master gives a web agency credibility.

Therefore, I believe, it’s a naïve perspective to think of an open source community as being vulnerable, creative types being exploited by big business.

 

Altus’ Bateman: don’t hold naïve perspectives about open source.


January 24, 2020  6:31 AM

Open source licence series – Instaclustr: Is open core a rotten deal?

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

Open source grew, it proliferated… and it became something that many previously proprietary-only software vendors embraced as a key means of development… but the issue of how open source software is licenced is still the stuff of some debate.

The Computer Weekly Open Source Insider team now features a series of guest posts examing in the ups & downs and ins & out of open source software licencing. 

Instaclustr is known for its managed and supported open source solutions for Apache Cassandra, Apache Kafka, Apache Spark, Elasticsearch, Apache Zeppelin, Kibana & others. Ben Bromhead, chief technology officer at Instaclustr writes from this point forward.

Open idealism

The driving promise of open source licensing is allowing for technology that can extend far beyond the limitations of what any single entity’s proprietary solutions can offer. 

Ideally, open source software should be, well, free and open. 

It should bring prosperity to a robust community of organisations large and small – who then contribute back to the project in proportion to their capabilities. 

Unfortunately, the reality now too often falls short of these ideals.

I’d argue that more than ever before, anyone committing to using an open source technology needs to first do a thorough risk assessment that carefully vets the licensing terms, in addition to assessing the strength of the community and the business motivations of commercial entities involved with the project. Those that require vendors or managed service providers (disclosure: what we are and what we do) to implement open source technologies effectively, must do their due diligence to understands those businesses’ interests.

Is open core a rotten deal?

We also need to consider ‘open core’ solutions offered by companies that build on top of OSS projects by adding proprietary features in order to create commercialised versions that they control.

While open core providers will often market these features as enterprise-grade improvements, in my view the reality is that the business model that ‘open core’ companies utilize invariably includes deep conflicts of interest.

Before all the pitchforks come out: let me also say that yes, open core providers do meaningfully contribute to the open source projects at the heart of their solutions (and doing so invariably also helps improve their own product). However, when the best interests of open core providers are at odds with those of their open source project’s community and contributors, it is not uncommon for those with an open core business model to leverage their influence and steer a project in a more self-serving direction (sometimes to the detriment of the project’s userbase).

For example, take a scenario where the community around an open source project plans to introduce features that would effectively offer an open core provider’s ‘enterprise features’ for free. While these new bells and whistles may be universally beneficial to the rest of the community, an open core provider would almost certainly wield its influence to oppose them as fiercely as they could – because their business motivations conflict with users’ needs. 

These incentives just conflict to much with the spirit of open source.

Incentivised betrayal of trust

Businesses also risk direct negative impacts of their own when they become reliant on open core offerings. They often require the expertise of external providers to navigate OSS complexity; unfortunately, open core support teams can be incentivised to betray this trust, and may press customers to utilise proprietary features instead of free alternative – even when the result is a sub-optimal deployment. 

In the worst scenarios, open core code may not be portable, leading to vendor and technical lock-in that makes it extremely challenging for businesses to change providers or wrest away control of their own solutions. 

I’d also add a last word of caution around the trend of managed services for complex solutions delivered by major cloud providers – for example, AWS’ recently-announced Apache Cassandra Service (MCS) – because these businesses are motivated to add users to their cloud platforms, not necessarily to deliver exceptional or expert service. As a result, cloud providers can fail to drive innovation or contribute proportionally to open source projects.

CTO of Instaclustr Ben Bromhead: A sharp view on real openness and proprietary skew.

 

 

 

 


January 23, 2020  10:44 AM

Open source licence series – WhiteSource: permissive is winning, but is there a hurt factor?

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

Open source grew, it proliferated… and it became something that many previously proprietary-only software vendors embraced as a key means of development… but the issue of how open source software is licenced is still the stuff of some debate.

The Computer Weekly Open Source Insider team now features a series of guest posts examing in the ups & downs and ins & out of open source software licencing. 

Rhys Arkins, director of product at open source license management and security solution company WhiteSource writes from this point forward.

We’ve come a long way, baby

We’ve come a long way since open source licenses were drafted to protect open source projects from the big bad corporations that insisted on keeping code private and [strictly] monetised. 

Today, open source components are the basic building blocks of our software products, and open source projects mean big business, re-awakening the contentious debate over open source licensing. 

Permissive win factor

When we look at the types of open source licenses that organisations choose, we see that most users choose permissive licenses: the open source licenses with the fewest strings attached. 

Our research into open source licensing trends in 2019 shows permissive open source licenses are more popular than ever, while the use of copyleft licenses, especially the GPL-family, continues to decrease. Permissive MIT and Apache 2.0 licenses remain first and second on our list of top 10 popular open source licenses of the year, each continuing to trend. According to our data, 67% of open source components have permissive licenses, while only 33% of the 10 most popular open source licenses are copyleft, compared to 59% in 2012.

We believe that open source becoming mainstream explains this shift from copyleft to permissive. With companies like Microsoft and Google behind today’s most popular open source projects, the “Us” vs. “Them” mentality from open source’s early days is no longer relevant. Open source has become an integral part of business, so the question isn’t whether an organization will use open source, rather how to ensure an open source component is accessible and easy to share. 

Permissive licenses are winning because they are user-friendly, especially to corporate users, but what about smaller companies? 

Many startups today base their business on an open source project and a freemium plan. ElasticSearch, Docker and more have learned the hard way that this strategy is risky. 

While this model helps build a large community, it also allows the software giants to build services based on their open source projects, arguably taking a chunk out of the smaller company’s business. 

An open betrayal?

As a result, Redis Labs, MongoDB, and others adjusted their open source licenses, moving to licenses like SSPL and other more restrictive licenses in an attempt to protect their business, only to get called out by some in the community for betraying the open source ethos. 

It seems that it’s time to re-examine the role of open source licensing today. 

Who are open source licenses supposed to protect, and what from? Can open source licenses protect projects from being ‘strip-mined’ by the big corporations, while still maintaining the integrity of the open source philosophy?

A swing of the pendulum

The past five years have seen a rise in the popularity of permissive licensing, but the pendulum might begin to swing the other way, as organisations continue to search for the right balance between supporting the open source community and maintaining solid business models

As the open source ecosystem continues to evolve we will probably see more open source projects with a new breed of open source licensing. License Zero, for example, is a welcome innovation enabling independent developers to allow free use of their software for open source or noncommercial work, and sell private licenses to other devs who want to use it for profit or in closed source. 

Finding a solution won’t be easy, but thinking out of the regular permissive-vs-copyleft-debate box to create models that are permissive while protecting patent rights and limiting services offered might be what the industry needs.

The debate goes on, there is still much to discuss…

WhiteSource’s Arkins: There’s a swinging pendulum between community concerns and workable business models.

 

 


January 22, 2020  11:26 AM

Open source licence series – Percona: is the battle won, or is this a different war?

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

Open source grew, it proliferated… and it became something that many previously proprietary-only software vendors embraced as a key means of development… but the issue of how open source software is licenced is still the stuff of some debate.

The Computer Weekly Open Source Insider team now features a series of guest posts examing in the ups & downs and ins & out of open source software licencing. 

Peter Zaitsev, CEO of Open source database management and monitoring services company Percona writes from this point forward.

For years there has been a ‘battle’ between the proponents of ‘free and open source’ software and ‘proprietary’ software. The GNU General Public License (GPL) was famously once called a “cancer” by Microsoft’s ex-CEO Steve Ballmer, and a killer of intellectual property by Jim Allchin.

This battle did not lead to the complete annihilation of either side. 

Both open source and proprietary are thriving, just in different areas. Open source software has even [now] won ubiquitous recognition from an old arch-enemy, Microsoft, which has made a complete turnaround to embrace open source.

However, there is now a new battle raging, the battle for open source Itself. 

Open source proved [I would argue] that it can provide superior value compared to proprietary software, so there is now a great deal of value in the marketplace by being able to call your software open source.

No trademark, no problem

Interestingly, the terms of free and open source software are not trademarked, like organic labels are for food products. There is a general understanding of what open source software is along with a few published (and respected) definitions: The Free Software Definition by Free Software Foundation, Open Source Software Definition by Open Source Initiative (OSI) and Debian Free Software Guidelines. Out of these, only OSI takes an active role in this — you can submit a licence to OSI for evaluation and receive an OSI badge of approval for your licence.

In recent years, the black and white nature of free and open source software definitions has started to face some challenges. First, as a result of trying to prevent unfair competition by cloud vendors, companies are offering as-a-service versions of open source products without sharing the spoils or their own innovations with the public at large. Second, on the ethical side, free and open source software is not placing any restrictions on how software can be used, which can be for good as well as for evil, a concept found repugnant by some activists. While the good and versus question is specifically covered by the OSI FAQ with the clear position, “giving everyone freedom means giving evil people freedom, too,” it is the more nuanced cases that expose the cracks in the system.

No whom, but how

Recently, the Cryptographic Autonomy License (CAL) was submitted for OSI consideration. As Holo’s co-founder Arthur Brock explains in his blog post, his goal is to protect end-user privacy and autonomy. Restrictions in this case focus not on whom, but how the software should be used. 

While many on the OSI board seem to support the licence, Bruce Perens, OSI co-founder and the person who drafted the original Open Source Definition (OSD), resigned from OSI saying, “… it seems to me that the organisation is rather enthusiastically headed toward accepting a licence that isn’t freedom-respecting. Fine, do it without me, please.” 

What does this tell us? Is the previously unified community fractured at the core? Does it affect what free and open source software means? There are a couple of outcomes possible here.

Open, but by another name

First, it is possible the definition of free and open source will be diluted by allowing restrictions such as those placed by CAL or MongoDB’s Server Side Public License (SSPL), which have not been approved by OSI to stand. If this happens, it is likely the hardcore open source advocates will have to find a different name to use.

Second, it is possible there will be a need for two (or more) definitions to be recognised and a different name will be determined that is more restrictive than the classic open source definition, but still not quite the same as proprietary. For this to happen, we need to recognise the need for more than one definition and switch arguments to it, rather than trying to define what open source is, or is not. 

Interestingly, in the past, the open source community accepted two very different approaches to licensing which have existed in parallel for many years. Specifically, “copyleft” licenses, like GPL which place restrictions on the “derived work” and “permissive” licenses which do not place such restrictions.

Marketing muscle

My hope is for the second outcome, but because of the high marketing value of the term “open source” it would be hard to see the industry preferring a diluted open source definition. 

Understanding how open source licensing reflects the wide variety of differences across the industry, from individuals and single software projects through to large enterprises and entire markets founded on open source, should help in this process. However, this means recognising that this is also a battle that cannot be won in the conventional sense, as there are no longer two sides involved.

The truth is that there are no simple answers to the questions around what should happen to open source licensing, even though we should encourage everyone involved to do the right thing for the whole community. Instead, there will only be context.

Percona CEO Peter Zaitsev: We could be on the fringe of new open source definitions.


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: