Evergreen – Software Research and the Industry

2022-11-222022-11-25

Open Source Legal Debt

Open source legal debt is unwanted open-source code in your products and projects.

Code may be unwanted, if it does not fit your (a company’s) business model. An example is code that has been copied from StackOverflow into your code base. That’s because code from StackOverflow has a copyleft license, which means that as you distribute your software, you can only use the license StackOverflow uses, not your own. According to this license, those who receive your software are free to pass it on, for free, and you can’t do anything about it.

2022-11-022022-11-02

Non-Software-Industry User-Led Open-Source Consortia

tl;dr We observe sustained growth in what we call non-software-industry user-led open-source consortia. These are open-source consortia (non-profit organizations) created by companies from outside the software industry with the goal of developing the applications these companies need to run their business. Their behaviors are different from other open-source consortia and we can see this expressed in their governance rules.

2022-10-292022-10-31

Open Source and the Hyphen

You may have seen the repeated fights over whether open-source software should be spelled with a hyphen or not. It just flared up on Wikipedia, again.

The rules are clear, in my opinion. Still, the situation is a misery.

2020-06-29

What is Open Collaboration?

Open collaboration was popularized by open source projects, and since has made its way into wikis and Wikipedia, the mix and remix culture and open content, open educational resources, and so forth. Just what exactly is it?

2020-06-28

What is Open Communication?

Open source collaboration requires open communication, they say. Just what is open communication, exactly? Drawing on past research [1], here are the four principles that make communication open. Open communication is communication that is

Public: All communication takes place in the public eye, and none or very little behind closed doors; private side-discussions are discouraged.
Complete: All communication is complete to the extent possible. Assumptions are made explicit and conclusions of discussions are summarized.
Written: All communication is in written form, allowing folks to participate at their own pace; any non-written communication will be transcribed.
Archived: All communication is archived for search and later retrieval. This documents communication for those not around (or awake).

2020-06-17

The GNU Public License v2 in the Land of Microservices

Another question I get asked is how containers and new architectural styles like microservices-based architectures relate to copyleft licenses, in particular the GPLv2 license.

First things first: I don’t recommend taking a “let’s work around this pesky license” approach. You should follow both a license’s spirit and letter; license evasion (“Umgehungsversuch”) may not hold up in court. Someone is trying to do you well, but only under certain conditions, so take it (properly) or leave it.

With that: If you package copyleft-licensed code in a container image and distribute this image, does the copyleft-licensed code affect any other container it communicates with?

2020-06-15

Open Source License Compliance and Work-for-Hire

A common question that I am asked in my seminar on license-compliant delivery of products that contain open source software is:

But what about a work-for-hire? We are a consulting company: As we work for our clients, and use open source software, do we have to create all those legal notices?

The answer, as so often is: It depends. With that, let’s tease the different situations apart.

2019-03-11

CTO vs. VP of Engineering

In tech companies, startups and large companies alike, of the many roles you need to define, two seem to be particularly confusing to German startups: The CTO and the VP of Engineering role. Many German startups I’ve seen simply have a person titled CTO who does both (and sometimes neither). These two roles are very different! They require different skill sets and while temporarily one person may be able to fill both shoes, longer term they are better filled by two different people. In more detail:

2019-03-08

Escalating Levels of Complexity in Inner Source Projects

Yesterday, I discussed what makes a good pilot project in inner source. The main thrust of the suggestion was not to start with a big bang but rather to choose a relevant but not too large project. This begs the question of complexity of projects, specifically viewed from an inner source perspective. How should you escalate and grow your ambition for inner source projects? I see a 1 + 3 structure of levels.

2019-03-07

Getting Started With Inner Source

I received several requests recently for my inner source charter document to provide it in DOC format, after I thought this work had fallen dormant (or perhaps the PDF version was sufficient). So I wanted to add my thoughts on how to take first steps in inner source, in particular in the selection of a pilot project.