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?Continue reading “What is Open Collaboration?”
Open source collaboration requires open communication, they say. Just what is open communication, exactly? Drawing on past research , 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).
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?Continue reading “The GNU Public License v2 in the Land of Microservices”
Interpreting open source licenses requires considerable skills and experience. Ideally, engineers and lawyers work together: Lawyers know the meaning and consequences of legal terms, and engineers can make sense of it in the context of software. There are some basics, however, that help set your thinking straight.
A critical aspect is: What is a (re-)distribution ? You distribute code (binary or source, doesn’t matter), if you pass it on to another legal entity. Legal entities can be both regular people (“natural person”) or companies (“juristic person”). If the code does not cross such a boundary, it is not being distributed.Continue reading “How to Read Open Source License Obligations”
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.Continue reading “Open Source License Compliance and Work-for-Hire”
I’m happy to report that the eigth article in the Open Source Expanded column of IEEE Computer has been published.
|Title||Managing Your Open Source Supply Chain—Why and How?|
|Keywords||Open Source, Software Supply Chain|
|Authors||Nikolay Harutyunyan, Friedrich-Alexander-University Erlangen-Nürnberg|
|Publication||Computer vol. 53, no. 6 (June 2020), pp. 77-81|
Abstract: More than 90% of software products include open source components, most of which are not directly added by your own developers. Instead, they are an inseparable part of the software supply chains that virtually all companies depend on. This article covers the related risks of ungoverned open source use and provides industry best practices to practitioners.
Also, check out the full list of articles.
Most corporate compliance departments believe developer collaboration in inner source projects is like shipping boxes with stuff (products) between the involved parties, for example, companies in a holding. Therefore, they don’t have to change anything about tax accounting and transfer pricing.
They couldn’t be more wrong.Continue reading “Is Inner Source Collaboration Like Shipping Boxes Between Companies? (Hint: No!!)”
Inner source is the use of open source best practices inside companies to develop shared components for use in the company’s products. Inner source software doesn’t have to become open source (but might). Like open source software development, inner source software development is inherently asynchronous, distributed, and multi-timezone.
Inner source is a match made in heaven for the new world of work-from-home.
All signals are clear: Many people love working from home, and developers are no exception. They will only return to the office, if forced, and it will come with a price for the company. Hence, those companies will be better off which can make work-from-home work out for their developers. This is in clear conflict with agile methods practices of co-location, regular stand-ups, etc.Continue reading “Inner Source and Work-from-Home”
Most of my software development is through my professorship, where I guide my student teams in developing (mostly) open source software. We have clear rules in place for how and which open source can be used in our projects and which can’t, like any competent organization. Mostly, it is about license compliance. We owe this to the users of our open source projects as well as our industry partners.
As a small organization, we rely on rules rather than lengthy approval processes, component repositories, and the like. One rule is to look at the source (location) of the open source project and see whether we have it white-listed, gray-listed, or black-listed. The Apache Software Foundation website is white-listed and Stackoverflow is black-listed. Github is gray-listed, meaning “it depends”.Continue reading “Why I Gray-listed Github for Open Source”