GitHub Universe the elephant in the room for open source is called ‘going commercial’ – Diginomica

The cloud is a key component of any companys digital transition path. Most businesses now understand that coming to grips with the cloud model and how to exploit it is an inevitable, unavoidable step. It is perhaps less understood that a consequence of this is that they must also come face to face with using open source software, even if only indirectly.

Such an observation might at first promote a `so what? response, the what? in question being just how much the world of applications development has changed as part of that cloud transition process. But in practice the change is significant, for a couple of important reasons.

For example, even as recently as 10 years ago the majority of applications development work was built around single vendor, proprietary code of one sort or another. Open source code was very much on the periphery, providing a way of building some of the then bleeding edge applications that were starting to appear.

Now, of course, it is reckoned that there is hardly an application produced that does not contain at least some open source code in it, with many being complex amalgams of existing open source components and new code. Couple this with its particular prominence throughout the world of cloud-specific applications and services and it is easy to see the reliance that enterprise users are now putting on it.

The other main issue is that open source code is developed by a global community of developers rather than companies. And even if, as now, the majority of those developers do work for companies, they are still part of that community and its spirit and sense of direction. What happens in that community can be more important to enterprise users than might ever have been the case in days gone by.

This has put new pressures high up the enterprise CIOs check list. Two particularly important areas concern what licences are being used by every component of an open source application, not least because that can be a cause of legal problems and contentions, and whether some of the older open source components are now being properly maintained. A third issue now emerging is the possibility that the open source community may take a dislike to some aspects of their work and decide not to do it.

That last point is, at least in part, a reference to GitHub itself, and the subject did raise its head at last weeks GitHub Universe conference in San Francisco. The organisation not only acts as a repository of the worlds open source contributors, ranging from major software companies down to individual developers, but also acts as their distributor and sales agent. This is where the issue comes to a head.

The involves GitHubs contract with ICE, the US Government Agency, Immigration and Customs Enforcement. This is the agency which many in the USA feel is responsible for the separation of Mexican children from their parents at the US-Mexico border, and many including some in the open source community and some staff at GitHub itself. Employees have asked GitHub CEO, Nat Friedman, to cancel the contract, and one staff member has publicly resigned over the matter.

But rather than digress into the details of that issue, which has already been widely reported, it is worth considering the sea-change that is shaping up in the world of applications development. Whereas an employee of a software house had the option of leaving if they did not like what their employer was producing or the customers which bought, there was no other measure of control over matters than departing the fold. The all-important software licence was held by the employer.

With open source, however, that does not hold true. These days most software businesses are at least starting to build open source applications it makes sense in a cloud environment so they hold the licence for that application. But only up to a point.

The key advantage of open source is that developers can use code from a wide range of repositories held and maintained by GitHub, many of which are public. This makes application development much easier and quicker because lots of routine processes do not have to be `rewritten they are there in one of the repositories to be used. Indeed, GitHub makes its money from selling their use to commercial software developers.

But many of those code components have been developed by individuals or small teams of them and this is where problems can, and do, arise. It can be that the licence for a component does not allow for commercial use and this is getting to be far more likely as components once developed for, say, gaming purposes amongst groups of individuals for fun and entertainment, find their way into other commercial projects. The increasing use of both gaming and mobile app coding models in new cloud-native business applications means the use of existing code designed for that use makes a great deal of sense, but potentially opens up a large number of problems.

Similarly, it is these old open source code components that run the risk of being left unmaintained, yet unknowingly used in new applications that could, for example, leave business users at risk of finding themselves non-compliant with regulations covering their industry, or worse still with software failures that are very difficult to trace.

In a brief conversation with me, CEO Friedman did acknowledge that there was a growing risk that enterprises might feel increasingly threatened by the change in the balance of power and said it is something that GitHub is starting to address. In particular, he sees two of its most important announcements at the Universe Conference as directly addressing these problems.

There was, as might be expected, a goodly clutch of new products and services announced at the event, including a completely new environment for mobile applications that covers both Android and i/OS, both of which should be available early next year, and a re-engineering of the code repositories to make them more readily deliverable to users. The two key ones, particularly when it comes to helping enterprises manage their open source portfolios, are a new Sponsorship Scheme, and the new Code Vault.

The Sponsorship Scheme is the work of Project Manager Devon Zeugal, and is aimed at two audiences: one of them is the individual coder, where a person is felt by others (individuals or companies) to be making a contribution that is, for whatever reason, worthy of financial support to the work can continue. So now GitHub has engineered a service whereby the sponsorship monies can be managed and directed to that individual.

The same approach is being targeted at project management and it is this one that Friedman sees as being the tool through which user businesses can target those code components that are regularly used, but are no longer supported. It is hoped that the appearance of financial support to the code itself as a project will attract members of the community to provide on-going support into the future. This should prove significantly cheaper than a software house having to re-engineer the code itself to ensure on-going compliance.

The Archive idea has been developed by Director of Product Management, Kyle Daigle and Thomas Dohmke, Vice President of Special Projects. Its goal is to capture every bit of detail possible about every bit of open source code that has been written. This will include not only the source code but information about the developer(s), the modifications and updates and, of course, the licence information.

This is complementary to the work being done by the Software Heritage Foundation of the French Institute for Research in Computer Science and Automation, (INRIA), with which GutHub is collaborating on the project. One of its novel side issues is that it marks a new use for QR coding in that all the data about a code component is stored in that form on photographic film using a specially-prepared, long-lasting silver-oxide coating, according to Dohmke, it provides extremely high density, long-lasting storage.

It also provides commercial users with something of an audit trail for all the open source software components they are ever likely to use, together with information on the type of licence that applies. This could prove invaluable as open source code components become the backbone of just about every application being written. Access to code provide users with a high level of protection against a wide range of legal `gotchas.

All this comes back to the one issue that GitHub is currently not looking at, yet may have to at some time even if it will certainly raise some complex issues, especially when dealing with the hidden use of old, but perfectly workable code components in new applications. This is the question as to whether GitHub needs to address the commercial use question by developing some licensing structure of its own that specifically addresses the issue.

A discussion with Erica Brescia, GitHubs Chief Operating Officer, suggested that this not something the organisation is currently considering. In her view it is not GitHubs role to play in the ecosystem, and she doesnt see it being well received by developers if it were to prescribe the ways that developers should think about code licensing:

Now there are some things that we can do, like tell developers, that if they don't have any licence assigned their code, they might want to think about doing that. But I don't think we should be very prescriptive and how people think about that. We are at the centre in a way, but I think our role in the ecosystem is to educate, not to direct around licensing or anything else.

In her view, the problem does not occur that often, for with most licensing within bigger projects, when an individual or organisation contributes code to a project, there is usually a contributor licence agreement that gives the project the rights to that code moving forward. And so the project controls it and the contributor signs over their rights:

Now, there are cases where, if a company violates the licence terms of a particular piece of open source software, they can and have been successfully sued.

But the contentiousness of legality surrounding this area is only likely to get worse, especially where individual businesses then try to insert their own licences into the legal mix, especially when a competitor, say, addresses the same market requirement with a solution broadly based on the same open source code.

Companies with projects that they develop, have been looking at changing the licences to try to combat what they feel is kind of IP theft. But the perspective on that, for me is, if you put code out there under licence, you need to understand what people have the right to do with it and they're within their rights to build services on top of it.

Put simply, the terms of the several open source licences are geared towards protecting the interests of the contributors in ways that suit them. But they do not fit well with the needs of commercial software houses, especially when they have their own world of licensing to preserve and protect. There have already been legal incidents in the area, and it will quite likely get worse. It most certainly will not be easy, but there does seem to be a time coming when a new licensing structure for open source will be necessary, and GitHub, together with its contemporary/rival GitLab, would be well placed to develop, front up, and manage.

Here is the original post:
GitHub Universe the elephant in the room for open source is called 'going commercial' - Diginomica