In software engineering, the structure of research theses, most notably dissertations, is straightforward: (1) Formulate a research question, choose a method, build a theory, then (2) generate at least one interesting hypothesis, choose a method, and test the hypothesis as part of the theory’s attempted validation. A dissertation can do both parts 1 and 2 or just one of them, relying on or leaving stuff to others. The benefit of this structure is that it will be easily recognized by other researchers and make it eas(ier) to write great papers.Continue reading “How Not to Ask Your Research Question (And What to do About it)”
Today I gave my JValue Open Data Service talk at USM (University of Sciences, Malaysia, at Penang). I am grateful for the opportunity and the recording.
Abstract: Open data has the potential to create significant practical value for its users through open innovation. Yet, to realize this value, we need an open ecosystem, next to open data, that allows app developers to create that value. In this talk I present my view of this open ecosystem of open data and how it should be structured. I then present the JValue Open Data Service (ODS), an open source software under development at my research group, that provides a key piece of this ecosystem. The goal of the JValue ODS project is to enable open innovation through app developers.Continue reading “Enabling Open Innovation with Open Data using the JValue Open Data Service”
Abstract: Virtually all software products incorporate free/libre and open source software (FLOSS) components. However, ungoverned use of FLOSS components can result in legal and nancial risks, and risks to a rm’s intellectual property. To avoid these risks, companies must govern their FLOSS use through open source governance processes and by following industry best practices. A particular challenge is license compliance. To manage the complexity of governance and compliance, companies should use tools and well-de ned processes. This paper investigates and presents industry requirements for FLOSS governance tools, followed by an evaluation of the suggested requirements. We chose eleven companies with an advanced understanding of open source governance and interviewed their FLOSS governance experts to derive a theory of industry requirements for tooling. We list tool requirements on tracking and reuse of FLOSS components, license compliance, search and selection of components, and architecture model for software products. For practical relevance, we cast our theory as a requirements speci cation for FLOSS governance tools. We then analyzed the features of leading governance tools and used this analysis to evaluate two categories of our theory: FLOSS license scanning and FLOSS components in product bills of materials.
Keywords: Open Source Software, FLOSS, FOSS, Open Source Governance, FLOSS governance tools, company requirements for FLOSS tools.
Reference: Harutyunyan, N., Bauer, A., & Riehle, D. (2019). Industry Requirements for FLOSS Governance Tools to Facilitate the Use of Open Source Software in Commercial Products. Journal of Systems and Software vol. 158 (2019), 110390.
On a whim, I asked my Twitterverse (which includes a fair number of computer scientists) what they think about the following question:
Continue reading “Anecdotal Evidence on the Method Wars”
When peer-reviewing somebody else’s work submitted for publication, what should you do if you find that the authors have a different belief than you about what can be known?
Self-enlightened contributions to open source projects are (code) contributions that come about because a company chooses to contribute. The opposite is forced open sourcing, which typically happens when a reciprocal license like the GPLv2 forces a company to lay open some source code.
Self-enlightened contribution is hard!Continue reading “Why Self-Enlightened Contribution to Open Source Projects is Difficult”
I’m happy to report that the third article in the new Open Source Expanded column of IEEE Computer has been published.
|Title||Open Source License Compliance–Why and How?|
|Keywords||Open Source Software, Licenses, Software Packages|
|Authors||Hendrik Schoettle, Osborne Clarke, Munich, Germany|
|Publication||Computer vol. 52 (August 2019), pp. 63-67|
Abstract: Compliance with open source software (OSS) license requirements is necessary but often overlooked. This article explains how OSS license compliance differs from compliance with commercial software licenses, why it is necessary even though OSS is generally free, and what requirements have to be met with OSS.
Also, check out the full list of articles.
A professor, so my belief, can play an important role in generating startups from University research. Most professors don’t, but some do, and I wanted to summarize my experiences as to what would be the perfect combination in one person.
There are three ingredients to get a university startup set-up and off the ground: (1) team, (2) idea, and (3) seed funding. Team, as anyone in startup-land knows, is by far the most important ingredient, as the others ultimately follow from it.Continue reading “The Perfect Professor for University Startups”
I thought I’d illustrate how I’d solve the current licensing conundrum of single-vendor open source firms like MongoDB and Elastic using some graphics. In short: While open source application vendors can still dual-license, open source component vendors (like the companies just mentioned) need to triple-license to get the benefits of open source yet keep their competitors at bay.Continue reading “Triple-Licensing Single-Vendor Open Source Components (Illustrated)”
On a lighter note, someone with a similar name to mine just used one of my email addresses to register for the Lexus Remote app. Judging by the email I got, using this email address that I own, I can register for the app and presumably do something about the car behind it. Does Lexus already offer a “summon” feature? Seems like the car is based in the U.S. so it would be good if it was amphibious.
Abstract: Almost all software products today include open-source components. However, the obligations that open-source licenses put on their users can be difficult or undesirable to comply with. As a consequence, software vendors and related companies need to govern the process by which open-source components are included in their products. A key process of such open-source governance is license clearance, that is, the process by which a company decides whether a particular component’s license is acceptable for use in its products. In this article, we discuss this process, review the challenges it poses to software vendors, and provide unanswered research questions that result from it.
Keywords: Open source licenses, open source license compliance, software supply chain, product model
Reference: Riehle, D., & Harutyunyan, N. (2019). Open-Source License Compliance in Software Supply Chains. In Fitzgerald B., Mockus A., Zhou M. (eds) Towards Engineering Free/Libre Open Source Software (FLOSS) Ecosystems for Impact and Sustainability. Springer, Singapore, pp. 83-95.