Open Source Insider


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.


January 20, 2020  10:42 AM

Open source licence series – Perforce: it was NEVER about the money

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. 

Rod Cope, CTO, Perforce Software and Justin Reock, chief architect, OpenLogic at Perforce Software write from this point forward.

Rod Cope: not in it for the money

I’ve been using open source software since the 80’s, long before we called it open source.  Back then, it was mainly developers ‘scratching their own itch’ and coming up with creative solutions they wanted to share with their peers.  

It was more about doing it right (where each developer was free to use their own definition of ‘right) than it was about schedules, business value, or any thought of making money. Over time, communities of these likeminded people formed to tackle larger projects that were beyond the scope of a single developer (in most cases).  

The final results were often very good, thanks to an unlimited time budget, peer reviews and a meritocracy where only the ideas mattered and no one in business management could come along and force a hasty decision.  

Again, in those early days (and for many developers now, still) profit wasn’t a motivator.  It was all about creating the best software possible and the freedom to try new approaches, architectures, languages, project management strategies and anything else that might improve the final result.

In many cases, contributors were professional software developers by day who worked on things like accounting software that weren’t as exciting to them as their nights and weekends spent perfecting an open source messaging system or web framework or NoSQL data store. They really enjoyed the freedom open source gave them to fail and innovate again as many times as they had the patience and energy for. 

Commercial cloud doesn’t hurt, as such

Today, we often think of open source as a grander idea about sharing software with the world and that all users should contribute back for the benefit of all.  

The rise of SaaS and cloud vendors that use open source without giving back obviously upsets people with the share-alike mindset, but does that really hurt open source?  Developers are still free to work on what they like, scratch their own itch, innovate, experiment, fail and try again. They can still use any tools they like, take as much time as they like and not worry about a business manager asking them to go in a direction contrary to the developer’s vision. Developers will continue to be creative, earn respect from their peers and know that they made something good that is improving the lives of their users, even if those users are paying a third party for a service based on their work.

After all, it was never about getting paid or requiring users to give back in the first place.

Justin Reock: open fairness – is reciprocity required?

The modern software deployment landscape is worlds away from what was predicted when the first free software project was released over forty years ago. Since that time, advances such as cloud-native applications have presented challenges to the altruistic obligations that complement free software.  

While the Free Software Foundation has always maintained that monetisation of the means of delivery of a piece of software isn’t strictly against their mission, would that sentiment have applied knowing the scale at which people would consume free software via the cloud? 

Is it time to look at the original intent of the GPL, the moral fabric of free software and see how it holds up against the reality of software deployment in 2020? Perhaps… and that’s another story. 

 


January 19, 2020  10:06 AM

Open source licence series – R3: The world needs audit licenses

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. 

Mike Hearn, lead platform engineer at enterprise blockchain company R3 writes from this point forward.

Why the world needs audit licenses

Many [software] programs grant the right to share and modify their source code.

The rapid spread of this model has enabled the software industry to scale up to larger codebases that would have been completely impractical if every component required a complex approval and purchase process. Just as importantly, it helped mitigate lock-in risk, enabling organisations to utilise ever bigger and more powerful platforms without associated exposure to vendor exploitation or stagnation.

I want to look at why the world needs audit licences.

Walking the open core tightrope

The so-called ‘open core’ model is hard to get right.

[As we know, the open-core model primarily involves offering a “core” or feature-limited version of a software product as free and open-source software, while offering “commercial” versions or add-ons as proprietary software.]

A common error is to open too much, leading to a Docker-style situation in which your commercial version is duplicated by other firms, leaving you with no business and a large maintenance bill. Other firms bet on becoming a managed service provider but find themselves forced into a license change when big cloud operators prove better at selling services than them.

The key is for open source platforms to get the balance right — so Corda is an example of an open source, decentralised database platform.

Editorial flag: Corda is developed by R3, so Hearn is talking about his own company’s product. The software is an enterprise blockchain platform that allows developers to write an application that is deployed on open source Corda and individual firms on the enterprise version can interoperate with those who are using open source.

Corda focuses on the needs of the largest companies and thus comes with an extended commercial version. Although still in its early days, it appears to be walking on the right side of the open core tightrope. As a result, customers choose to support the ecosystem and themselves by purchasing the enhanced version. Yet, some users do go live on the fully open source edition, pointing to a low lock-in risk.

Developers behind open source platforms need to recognise the importance of keeping customers happy, or else, they may simply leave the platform. By collectively insisting on open core licensing, enterprise blockchain users put themselves into a powerful position over vendors, befitting the decentralised ethos of the space.

I’d also point out that better security needs a new approach to licensing. With security demands increasingly coming to the fore across all sectors, a new approach to licensing is required to keep pace with this trend.

Enclave-oriented computing

Bringing enclave-oriented computing to the mainstream could be the security solution needed.

Enclave technology like Intel SGX enables a client to audit the code running on a remote server. A cryptographic ‘handshake’ reveals the hash of the program you’re securely connected to. Enclaves allow the removal of trust from a service operator: now anyone can audit the workings of a service and prove to themselves how data gets used. Think of it as an automatically enforced privacy policy. It is even possible to build services where the service provider doesn’t see any data at all.

Editorial flag: Hearn’s comments are valid and interesting, but it is worth noting that he is again steering the conversation towards technology that his company develops. As noted on Ledger Insights, Conclave – a play on enclave – is the name for R3’s research product which hopes to make ‘enclave-oriented computing’ (EoC) accessible to developers. 

For this scheme to work, users must be able to read and compile the source code of the service. Open source licenses automatically meet this requirement but it’s unreasonable to expect all enclaves to be fully open source. We need audit licenses – new agreements that allow understanding and replication of the enclave build without granting distribution or modification rights.

Trade secrets must be protected without creating awkward processes. There’s no reusable out-of-the-box license that meets these needs as it’s rarely been a requirement before. However, developing such licenses and open source text can enable a new era of enclave-oriented computing for everyone.

R3’s Hearn: there’s a balance to strike in open source, as in all things.

 

 


January 17, 2020  8:20 AM

MariaDB goes bigly on cloud-native smart apps

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

MariaDB Corporation is upping its cloud-native playbook.

At the same time, MariaDB is aiming to up its approach to so-called ‘smart’ applications., so before we define the parameters at play here, let’s look at the news.

The database company’s mysteriously named MariaDB Platform X4 is new to the table and is described as a cloud-native open source database for developers to build modern applications using smart transactions and cloud-native data storage. 

We know that modern applications (that aspire to be smart) require access to vast amounts of data — and that data needs to be optimised for analytical queries and Machine Learning (ML) models.

In this way, transactions can be augmented with data insights, turning them into smart transactions.

“The use of mobile devices and the rapid pace of technology has fundamentally changed how we interact with applications and what we expect from them,” said Gregory Dorman, vice president of distributed systems and analytics, MariaDB Corporation.

Dorman suggests that the trick that developers should be looking to pull off here is the ability to add the ‘smarts’ (plural) elements without impacting the performance of transactions, so this is why the company implemented a dual storage layout for data.

How does a  dual storage layout for data work? It’s row based for transactions and columnar based for ‘true’ analytics.

MariaDB insists that today, most web and mobile applications run on ‘dumb transactions’ or simple create, read, update and delete (CRUD) operations with a few complex queries. 

Smart transactions defined

With smart transactions, applications take advantage of what MariaDB calls “true” analytics before, during and/or after a transaction. 

So these are applications using smart transactions that can anticipate user needs, create context to be more helpful and take advantage of vast historical records to predict outcomes such as on-time flight performance, best pricing options or sales forecasts for better decision-making or automation. 

“Similar to newer analytical solutions such as Snowflake, MariaDB Platform X4 implements a cloud-native disaggregated architecture for analytics using an API compatible with AWS S3 for up to 70% cost savings over block storage, 99.999999999% durability and 99.99% availability, storage across multiple availability zones and unlimited storage capacity,” said the company, in a press statement.

Unlike pure analytical cloud-native solutions, MariaDB Platform X4 also uses block storage, such as AWS EBS, for fast transactions along with object storage, such as AWS S3, for fast, scalable analytics.

Developer enablement

MariaDB is publishing new material to try and help developers build modern applications using smart transactions. This new enterprise documentation includes install and deployment guides and outlines new platform functionality. 

MariaDB is also creating sample applications available on GitHub.


January 15, 2020  9:47 AM

Dynatrace ‘traces’ route to standardised (OpenTelemetry) observability with Google & Microsoft 

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

Dynatrace has connected, collaborated, corroborated and cooperated on a new software huddle with Google and Microsoft.

The organisation that calls itself a ‘software intelligence company’ is working with the two tech giants (Dynatrace is no tiddler, the firm now has over 2000 employees) on the OpenTelemetry project to shape the future of open standards-based observability. 

Dynatrace says it is contributing ‘transaction tracing’ know-how and manpower (Ed – we think they mean ‘personpower’) to the project. 

As detailed here, “A transaction trace records the available function calls, database calls, and external calls [that an application makes]. You [developers, sysadmins or other engineering staff] can use transaction traces to troubleshoot performance issues and to get detailed low-level insight into how your app is working.”

OpenTelemetry is an open source observability framework focused on providing standardised transaction-level observability through the generation, collection and description of telemetry data for distributed cloud-native systems. It is a CNCF Sandbox member, formed through a merger of the OpenTracing and OpenCensus projects. The goal of OpenTelemetry is to provide a general-purpose API, SDK and related tools required for the instrumentation of cloud-native software, frameworks and libraries. The term observability stems from the discipline of control theory and refers to how well a system can be understood on the basis of the telemetry that it produces.

OpenTelemetry provides a single set of APIs, libraries, agents and collector services to capture distributed traces and metrics from an application. You can analyze them using Prometheus, Jaeger and other observability tools.

Cloud observability

As OpenTelemetry becomes more widely adopted, it will serve as an additional data source that further extends the breadth of ‘cloud observability’ (that term the industry is really loving this year in 2020), including expanding the reach of what the Dynatrace Software Intelligence Platform already collects and ingests into Davis™, the firm’s ‘explainable’ AI engine. 

“Our goal is to ensure ‘run the business’ software underpinning digital enterprises works perfectly, so we feel it’s important to contribute our expertise to this open source project to improve and advance observability in a broader manner,” said Alois Reitbauer, chief technical strategist and head of the Dynatrace Innovation Lab. 

The road to standardised observability

Reitbauer says that the OpenTelemetry initiative will enable developers of cloud-native applications to build ‘standardised observability’ into their software. 

“As this gains momentum, observability will be increasingly differentiated by what can be done with data, versus simply how much data can be collected. That’s why we’re excited for the day when OpenTelemetry is widely adopted, as it will increase the breadth of the data and scope of the cloud ecosystem that organisations can observe,” he added.

Product manager at Google Morgan McLean thinks that the ultimate goal of OpenTelemetry is to become the default way that developers and operators capture performance information from their services. The Microsoft spokesperson said something about Dynatrace… and seemed happy, so that’s good.

Dynatrace is working with Microsoft, Google and others as a core contributor to OpenTelemetry in areas, including: 

  • Higher-level instrumentation APIs: offering higher-fidelity tracing code to enable developers to build observability into cloud-native applications and reduce monitoring blind-spots as new methodologies and programming languages emerge.
  • Integration of universal Trace Context: supporting the availability of transactional context across hybrid multi-clouds to maintain end-to-end observability.
  • Runtime management: helping organizations ensure the resources needed to gain observability into the individual components and software libraries underpinning their cloud-native applications are dynamically available.

 

 

 


January 14, 2020  12:24 PM

The open source licence debate: what we need to know

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

As we have already noted on Computer Weekly Open Source Insider, 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.

Open Source Insider has already looked at the issues relating to dead projects (that are still walking and running) and the need for workable incentivisation models. 

Chief operating officer (COO) for GitHub Erica Brescia noted that, from her perspective, she is seeing an “increasing tension” between open source projects and those that are building services on top of open source, such as cloud vendors with their database services. 

Brescia notes that licenses applied to open source projects a decade ago did not consider the possibility of a cloud vendor delivering an as-a-Service SaaS layer using the project without contributing back to it, which is leaving some open companies in a difficult position.

Computer Weekly’s Cliff Saran wrote, With friends like AWS, who needs an open source business? — and noted that a New York Times article suggested that Amazon Web Services (AWS) was strip-mining open source projects by providing managed services based on open source code, without contributing back to the community.

Security sources

We have also looked at the security aspects of open source licencing.

Exec VP at software intelligence company Cast is Rado Nikolov – for his money, the open source licencing debate also has a security element in it.

“Large organisations using open source code from GitHub, xs:code and other sources range from Walmart to NASA, collectively holding billions of pieces of sensitive data. Although open source code packages can be obtained at low or no cost, their various intellectual property and usage stipulations may lead to expensive legal implications if misunderstood or ignored,” said Niklov.

Ilkka Turunen, global director of solutions architecture at DevSecOps automation company Sonatype further reminded us that there are 1001 ways of commercialising open source software — but when releasing open source, the developer has a choice of publishing it under a license that is essentially a contract between them and the end user.

A multiplicity of complexities

So there’s security, there’s fair and just contributions back to the community, there’s layering over open for commercial use, there’s the complexity of just so many open source licences existing out there to choose from and there’s even concerns over whether trade sanctions can affect open source projects and see them becoming bifurcated along national borders. 

Open source is supposed to be built around systems of meritocracy and be for the benefit of all, we must work hard to ensure that we can do this and shoulder the nuances of licensing to keep open source software as good as it should be… let the debate continue.

 


January 9, 2020  9:25 AM

The open source licence debate: comprehension consternations & stipulation frustrations

Adrian Bridgwater Adrian Bridgwater Profile: Adrian Bridgwater

As we have noted here, 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.

Exec VP at software intelligence company Cast is Rado Nikolov – for his money, the open source licencing debate also has a security element in it.

“Large organisations using open source code from GitHub, xs:code and other sources range from Walmart to NASA, collectively holding billions of pieces of sensitive data. Although open source code packages can be obtained at low or no cost, their various intellectual property and usage stipulations may lead to expensive legal implications if misunderstood or ignored,” said Niklov.

Stipulation situation

Niklov argues that the crux of the matter lies in the fact that (whatever licencing agreement open source software is brought in under), the most ‘important stipulations’ are often lost over time.

“The case of Artifex v Hancom shows the risk of being held liable for improper use of source code, even when it’s open source. Company executives need to ensure they are covered for the code they use, wherever they get it from. Ignorance of the law is no defence. Regularly using software intelligence for automating the analysis of open source usage is one way to significantly reduce such risk exposures,” said Nikolov.

Ilkka Turunen is global director of solutions architecture at DevSecOps automation company Sonatype.

Turunen reminds that, generally speaking, there are 1001 ways of commercialising open source software — but when releasing open source, the developer has a choice of publishing it under a license that is essentially a contract between them and the end user.

“These licenses vary from fairly restrictive (i.e. must associate where the open source came from and publish source code) to fairly liberal (buy the author a beer if you like the software). It’s important to understand that all open source is licenced under some terms at all times,” said

He notes that there are then several ways of adding commercial components on top of that (above) – and indeed many commercial companies leverage fairly open types to be able to add their own commercial code on top, to be able to spin out other commercial issues.

Comprehension consternations

“Fundamentally, it boils down to open source software licencing being generally hard to [comprehend and] understand. Most devs start these projects as a passion project and just publish it with some basic license they might live to regret later when they consider their options. Fundamentally, this is another avenue for them to gain funding, but would imagine there are limits to the scalability of what can be achieved,” added Turunen.

 


January 8, 2020  9:41 AM

The open source licence debate: dead project walking & incentive models

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.

If you don’t accept the options offered by the community contribution model of development, then you risk becoming a Proprietary 2.0 behemoth… or so the T-shirt slogan might go.

But the issue of how open source software is licenced is still the stuff of some debate.

Chief operating officer (COO) for GitHub is Erica Brescia.

Brescia has pointed out that the industry is witnessing rising levels of tension between open source projects (and open source development shops) and those commercially motivated organizations that are building services on top of open source, such as cloud vendors with their database services

So how do we move forward with open source?

Dead project walking

Matthew Jacobs, director, legal counsel at Synopsys Software Integrity Group reinforces the suggestion that avoiding licence compliance issues and avoiding use of any software, open source included, that contains vulnerability risks is extremely important.

“However, many companies fail to consider the operational risks associated with the open source they are using. By this I mean the risk that a company will decide to leverage open source from a dead open source project or one that is failing to maintain a critical mass of contributors who are actively maintaining and improving that project. The viability of the project is only as good as the people behind it and those people need to support themselves,” said Jacobs.

He argues that providing avenues for developers to continue to do what they enjoy and for which we all benefit, but in a way that allows them to earn something along the way is important.

New incentive models, please

Shamik Mishra is Altran’s AVP of technology and innovation.

Mishra points out that in newer software development models, nobody really tries to reinvent the wheel and instead focuses on solving their own business problems – the ‘wheel’ comes from those pre-existing open source projects.

He says that many large open source projects survive because they enjoy a degree of investment from a supporting business entity to keep the community going as they hire experts and developers, but several brilliant projects have lost their momentum and have never come to fruition due to a lack of support.

“But, the industry badly needs incentive models. GitHub sponsor is a great example but still relies on the ‘donation’ mind-set. The other problem that organisations face is that they don’t exactly know which developer really contributed to that piece of brilliance that the organisation monetised, particularly within large projects. Collaborative models where developers can be compensated by interested organisations through smart contracts based on the level of contribution is perhaps the way forward,” said Mishra.

It seems clear that developers should also have a choice of providing licensed versions of open source and still have the ability to switch licences… but this subject is far from decisively closed as of 2020.

 

 

 


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: