Industry requirements for FLOSS governance tools to facilitate the use of open source software in commercial products

Harutyunyan, Nikolay; Bauer, Andreas; Riehle, Dirk

doi:10.1016/j.jss.2019.08.001

Cited by 9 publications

(16 citation statements)

References 24 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The usage of only approved FLOSS components helps to avoid legal compliance risks introduced by unknown components. In our previous studies about industry requirements on FLOSS governance and compliance tools, we found that companies want to have an automated process of adding new FLOSS components and their metadata into a common architectural model [11], captured in the following requirement:…”

Section: Resultsmentioning

confidence: 99%

“…"The tool should allow automated adding of FLOSS components and their metadata into the repository using the product architecture model" -Requirement 5.b. [11] But in reality, users of FLOSS components often have to provide information about a component by hand. This manual step of collecting information is timeconsuming and can slow down the whole approval process.…”

Section: Resultsmentioning

confidence: 99%

“…We found a hierarchical list of requirements that indicated the following four key categories: Tracking and reuse of FLOSS components, License compliance of FLOSS components, Search and selection of FLOSS components, and Other requirements (security, education, etc.). We then extended our findings in a subsequent journal article [11] with a new round of qualitative data analysis using five additional interviews, which added the fifth category to the proposed theory focusing on the architecture model for software products.…”

Section: Related Workmentioning

confidence: 85%

“…For example, using unique SPDX license identifier instead of unstructured text to describe the declared license. Our previous studies cover the requirements for automation of the FLOSS compliance process, but those requirements are not fulfilled by tools to the extent which is required [10,11]. An elaborate representation of inter-dependency relationships should be an inherent part of the architectural model.…”

Section: Discussionmentioning

confidence: 99%

“…grounded theory, experiments) because of its suitability for the emerging and complex phenomena that can be best studied in their practical contexts [18]. Given the complexities of the corporate FLOSS use, governance, and compliance in general [9] and of the software dependency documentation issues in particular [11], we chose a case study company that actively uses open source components in products, while encountering issues in tracking and documenting this use as part of the complete product architecture.…”

Section: Methodsmentioning

confidence: 99%

See 4 more Smart Citations

Challenges of Tracking and Documenting Open Source Dependencies in Products: A Case Study

Bauer¹,

Harutyunyan²,

Riehle³

et al. 2020

IFIP Advances in Information and Communication Technology

Self Cite

View full text Add to dashboard Cite

Software vendors need to manage the dependencies of the open source components used in their products. Without this management, license compliance would be impossible, export restrictions could not be maintained, and security vulnerabilities would remain unknown to the vendor.The management of these dependencies has grown in an ad-hoc fashion in most companies. As such, vendors find it hard to learn from each other and improve practices.To address this problem, we performed exploratory single-case study research at one large established software vendor. We gathered and analyzed the key challenges of tracking and documenting open source dependencies in products. We wanted to understand whether these ad-hoc solutions could be based on a single unified conceptual model for managing dependencies.Our study suggests that underlying the various point solutions that we found at this vendor lies a conceptual model that we tentatively call the product (architecture) model. In future cross-vendor work, we will investigate whether this conceptual model can be expanded to become a unifying model for all open source dependency management.

show abstract

Section: Resultsmentioning

confidence: 99%

Section: Resultsmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 85%

Section: Discussionmentioning

confidence: 99%

Section: Methodsmentioning

confidence: 99%

See 3 more Smart Citations