Sergius Dyck, Daniel Haferkorn

Proceedings of the 29th World Multi-Conference on Systemics, Cybernetics and Informatics: WMSCI 2025, pp. 408-411 (2025); https://doi.org/10.54808/WMSCI2025.01.408

Sergius Dyck
Fraunhofer IOSB, Karlsruhe, Germany

Daniel Haferkorn
Fraunhofer IOSB, Karlsruhe, Germany

Cite this paper as:
Dyck, S., Haferkorn, D. (2025). A Critical Retrospect of OSS License Compliance: Lessons Learned and Next Steps. In N. Callaos, E. Gaile-Sarkane, N. Lace, B. Sánchez, M. Savoie (Eds.), Proceedings of the 29th World Multi-Conference on Systemics, Cybernetics and Informatics: WMSCI 2025, pp. 408-411. International Institute of Informatics and Cybernetics. https://doi.org/10.54808/WMSCI2025.01.408

In the rapidly evolving software development landscape, the integration of Open Source Software (OSS) has become commonplace, providing developers with extensive libraries and tools that enhance productivity and accelerate project timelines. However, the use of OSS comes with significant legal responsibilities, particularly regarding compliance with various Open Source Software Licenses (OSSL). An initial framework was designed to ensure OSS compliance, centering on automated creation of Software Bill of Materials (SBOMs) and a “License Playbook”. Automated checks were executed with tools such as Maven and Nexus, verifying license acceptability and required source-code inclusion.
In follow-up work, OSS notice lists were automated, domain-driven design was applied to improve communication, and Java-based tools for Maven were introduced to structure compliance data and reduce errors.
Over time, it became clear that the original framework no longer aligns with evolving requirements, especially as various web projects with focus on OSSL gained in importance. The existing license-management tool encounters challenges in handling large dependency sets, and post-release adjustments in Maven repositories remain difficult to perform. Consequently, alternative software suites are being evaluated to determine whether the proprietary tool should be adapted or replaced to meet evolving needs and strengthen the overall OSS compliance strategy.