Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
In most cases, software today is not built from scratch, but rather assembled from various prepackaged third-party software components. As a result, organizations face the following challenges:
- Verifying various aspects of compliance when using third-party software components: license compliance, ECC checks, IP assessments, etc.
- Sharing knowledge about software components and their qualities. For example, which software components should be recommended, which should be phased out based on which criteria?
- Providing a broad overview of the components used: An organization and its supply chain management must have information about which assets are integrated into which products or solutions.
These three main use cases target different roles in an organization: quality managers, software developers, legal counsels, software architects, R&D managers etc. However, all these use cases share a common need for a central hub that manages insights into software components.
SW360 is an open source software project licensed under the EPL-1.0 that provides both a Web application and a repository to collect, organize and make available information about software components. It establishes a central hub for software components in an organization. SW360 allows for
- tracking components used by a project/product,
- assessing security vulnerabilities,
- maintaining license obligations,
- enforcing policies, and
- generating legal documents.
- Integration with other tools and data sources (e.g. license scanner, static code analysis, build infrastructure, etc.)
For example, SW360 can trigger a clearing process in the open source compliance tool FOSSology and import the resulting clearing reporting.
Data is either stored in SW360’s database or on the fly imported from external sources. In future it is planned to have federations of SW360 instances that share selected information. Besides its Web-based UI, all functionality of SW360 is available through an API that allows an integration into existing DevOps tools.
Eclipse SW360 is a software catalogue system to ease the management of software components (no matter whether FOSS, commercial or internal software) in organizations. In detail the system covers three areas:
- Provide information about software licenses and their consequences
- Enable software component management as a community effort in the sense of identifying useful ones against less useful components
- Identify experts for open source components in an organization (e.g. committers or contributors in a project) to ease the coordination with open source projects
- Provide component related information residing in / generated by other tools, for informed selection
- Component identification
- Exchanging (usage and adoption) information about software components
- Share knowledge about software, such as sharing integration experience or for example, experience with certification of a software component in a regulatory certification effort.
- Managing software components for facilitating a component clearing process
- Trigger component clearing workflows involving external systems (e.g. initiating FOSSology scans as described here https://github.com/sw360/sw360portal/wiki/User-Workflows:-sw360-and-FOSSology)
- Managing Security Vulnerabilities in open source components used in projects
- Track vulnerability handling for projects
- Managing of approved licenses and their legal implications
- Up to date software asset management
- Managed build processes
The system makes use of standards, such as Software Package Data Exchange (SPDX), Common Platform Enumeration (CPE) and Common Vulnerability and Exposure (CVE) to ensure consistent identification of licenses, components and vulnerabilities.
Out of scope
1. License scan: not in scope, because SW360 interacts with and delegates to specialzed tools and exchanges data: SW360 has FOSSology integrated which is a license scanner server software
2. Source code scan: not in scope, because SW360 interacts with and delegates to specialzed tools and exchanges data: SW360 has code to import project from specialiazed tools.
3. Code repository: while SW360 uses couchdb to store and efficently manage large amount of software packages and other files and archives, it is not meant to serve as concurrent versioning control system such as a git server.
Eclipse SW360 is a software catalogue application designed to provide a central place for sharing information about software components used by an organization. It is designed to neatly integrate into existing infrastructures related to the management of software artifacts and projects by providing separate backend services for distinct tasks and a set of portlets to access these services. A complete deployment unit exists (vagrant box or docker container) that contains a complete configuration of all services and portlets.
Currently SW360 comprises the following main use case areas:
- Component: Handling of information and processes related to components, e.g. name, vendor
- License: Handling of information regarding licenses, e.g. obligations, license texts etc.
- Project: handling of project information providing a context for the use of components.
- Vulnerability: Collecting Security Vulnerability Management Information and matching them with components stored in the component service.
as well as connectors to interact with external systems such as FOSSology or commercial code scan tools, e.g. to import data or trigger source code scan jobs.
Features at a glance
- Maintain component meta data such as involved licenses, name, project URL, involved contributors in organization, type of software, etc
- Attach all kinds of information including clearing reports, SPDX documents etc to components
- Store and retrieve license data and relate licenses with standardized obligations to ease comprehensibility of licenses for project (and guide projects responsible how to implement license obligations)
- Maintain project metadata and project BOM to put component’s use into context
- Notification if vulnerabilities exist for components
- Trigger clearing jobs for components in FOSSology
- Our vision is that SW360 will be the central hub in an organization to consolidate and share all meta information available about software components to help architects and developers to quickly make informed decisions about software components.
- Meta information of software components comprises legal information (license and copyright), software quality, project characteristics and health, security and project roles such as developers, supports and users.
- Fully integration in state of the art build / delivery infrastructure to realize continuous delivery of high quality software with all required artefacts (BOM, licenses, copyright information, etc)
- Build federations of SW360 instances to share selected information.
Eclipse Foundation provides a legal framework for commercial open source usage. This is one aspect why e.g. Bosch and Siemens consider contributing to open source projects at the Eclipse Foundation. Integral part of commercial use of open source is a proper management of legal information about OSS components.
SW360 can help in that respect and therefore eases the commercial development of open source software for organizations. The legal framework of the Eclipse Foundation and tools like SW360 appear to be a logical fit. Furthermore we expect to improve community building and involving further contributing parties.
The initial contribution consists of a fully functional system that covers the services described above. It comprises:
- Libraries with base and utility functionality for the other components
- Backend services with Thrift API
- Portlets implementing UI functions
- JSPs implementing different views, themes and CSS for layouts
- Provisioning tools (puppet, vagrant, docker scripts)
The copyright of the source code for the initial contribution is owned by Siemens AG and Bosch Software Innovations GmbH.
The entire SW360 codebase contributed by Siemens and Bosch so far is currently licensed under the EPL-1.0.
The current code base uses the following third-party libraries and Liferay as prerequisite.
- Apache-1.1, Sun-IP dom4j : dom4j : 1.6.1
- Apache-2.0 commons-codec : commons-codec : 1.10
- Apache-2.0 org.codehaus.woodstox : woodstox-core-asl : 4.2.0
- Apache-2.0 br.com.thiagomoreira.liferay.plugins : bootstrap-jumbotron-theme : war : 0.1
- Apache-2.0 com.github.ldriscoll : ektorplucene : 0.2.0
- Apache-2.0 com.google.code.gson : gson : 2.4
- Apache-2.0 commons-collections : commons-collections : 3.2.1
- Apache-2.0 commons-io : commons-io : 2.0.1
- Apache-2.0 commons-lang : commons-lang : 2.4
- Apache-2.0 commons-logging : commons-logging : 1.1.1
- Apache-2.0 commons-logging : commons-logging : 1.2
- Apache-2.0 joda-time : joda-time : 1.6.2
- Apache-2.0 log4j : log4j : 1.2.17
- Apache-2.0 or EPL-1.0, MIT org.eclipse.jetty : jetty-util : 8.1.7.v20120910
- Apache-2.0 org.apache.commons : commons-csv : 1.0
- Apache-2.0 org.apache.cxf : cxf-rt-bindings-soap : 2.7.6
- Apache-2.0 org.apache.cxf : cxf-rt-bindings-xml : 2.7.6
- Apache-2.0 org.apache.cxf : cxf-rt-core : 2.7.6
- Apache-2.0 org.apache.cxf : cxf-rt-databinding-jaxb : 2.7.6
- Apache-2.0 org.apache.cxf : cxf-rt-frontend-jaxws : 2.7.6
- Apache-2.0 org.apache.cxf : cxf-rt-frontend-simple : 2.7.6
- Apache-2.0 org.apache.cxf : cxf-rt-transports-http : 2.7.6
- Apache-2.0 org.apache.cxf : cxf-rt-ws-addr : 2.7.6
- Apache-2.0 org.apache.cxf : cxf-rt-ws-security : 2.7.6
- Apache-2.0 org.apache.cxf : cxf-tools-common : 2.7.6
- Apache-2.0 org.apache.cxf.xjcplugins : cxf-xjc-boolean : 2.6.2
- Apache-2.0 org.apache.cxf.xjcplugins : cxf-xjc-bug671 : 2.6.2
- Apache-2.0 org.apache.cxf.xjcplugins : cxf-xjc-ts : 2.6.2
- Apache-2.0 org.apache.httpcomponents : httpclient : 4.3
- Apache-2.0 org.apache.httpcomponents : httpclient-cache : 4.3
- Apache-2.0 org.apache.httpcomponents : httpcore : 4.3.3
- Apache-2.0 org.apache.logging.log4j : log4j-api : 2.4.1
- Apache-2.0 org.apache.logging.log4j : log4j-core : 2.4.1
- Apache-2.0 org.apache.neethi : neethi : 3.0.2
- Apache-2.0 org.apache.poi : poi : 3.9
- Apache-2.0 org.apache.poi : poi-ooxml : 3.9
- Apache-2.0 org.apache.poi : poi-ooxml-schemas : 3.9
- Apache-2.0 org.apache.thrift : libthrift : 0.9.3
- Apache-2.0 org.apache.velocity : velocity : 1.6.4
- Apache-2.0 org.apache.ws.security : wss4j : 1.6.12
- Apache-2.0 org.apache.ws.xmlschema : xmlschema-core : 2.0.3
- Apache-2.0 org.apache.xmlbeans : xmlbeans : 2.3.0
- Apache-2.0 org.ektorp : org.ektorp : 1.4.2
- Apache-2.0 org.jetbrains : annotations : 13.0
- Apache-2.0 org.opensaml : opensaml : 2.5.1-1
- Apache-2.0 org.springframework : spring-aop : 4.1.5.RELEASE
- Apache-2.0 org.springframework : spring-beans : 4.1.5.RELEASE
- Apache-2.0 org.springframework : spring-context : 4.1.5.RELEASE
- Apache-2.0 org.springframework : spring-context : 4.1.5.RELEASE
- Apache-2.0 org.springframework : spring-expression : 4.1.5.RELEASE
- Apache-2.0 org.springframework : spring-web : 4.1.5.RELEASE
- Apache-2.0 org.springframework : spring-webmvc : 4.1.5.RELEASE
- Apache-2.0 stax : stax-api : 1.0.1
- Apache-2.0 xml-resolver : xml-resolver : 1.2
- Apache-2.0, BSD-3-Clause org.springframework : spring-core : 4.1.5.RELEASE
- Apache-2.0, LGPL-2.1 com.fasterxml.jackson.core : jackson-annotations : 2.2.2
- Apache-2.0, LGPL-2.1 com.fasterxml.jackson.core : jackson-core : 2.2.2
- Apache-2.0, LGPL-2.1, com.fasterxml.jackson.core : jackson-databind : 2.2.2
- Apache-2.0, OASIS, W3C org.apache.cxf : cxf-rt-ws-policy : 2.7.6
- Apache-2.0, Public Domain com.google.guava : guava : 18.0
- Apache-2.0, Public Domain, Sun-IP xml-apis : xml-apis : 1.0.b2
- Apache-2.0, W3C org.apache.cxf : cxf-api : 2.7.6
- Apache-2.0, W3C org.apache.santuario : xmlsec : 1.5.6
- Apache-2.0, com.github.stephenc.findbugs : findbugs-annotations : 3.0.1-1
- BSD-2-Clause org.codehaus.woodstox : stax2-api : 3.1.1
- BSD-3-Clause com.jcraft : jsch : 0.1.51
- CDDL-1.0 javax.activation : activation : 1.1
- CDDL-1.0, Sun-IP javax.mail : mail : 1.4
- CDDL-1.1 or GPL-2.0, CDDL-1.1 or GPL-2.0-CPE com.sun.xml.messaging.saaj : saaj-impl : 1.3.12
- CDDL-1.1 or GPL-2.0-CPE com.sun.xml.bind : jaxb-impl : 2.2.4-1
- CDDL-1.1 or GPL-2.0-CPE javax.xml.bind : jaxb-api : 2.2.3
- CDDL-1.1 or GPL-2.0-CPE, Apache-2.0, BSD-3-Clause, MIT com.sun.xml.bind : jaxb-xjc : 2.2.4-1
- CDDL-1.1 or GPL-2.0-CPE, WernerRandelshofer javax.xml.soap : saaj-api : 1.3.4
- CPL-1.0, wsdl4j : wsdl4j : 1.6.2
- MIT org.slf4j : slf4j-api : 1.7.7
- MIT org.slf4j : slf4j-log4j12 : 1.7.7
- MIT, Apache-2.0 org.slf4j : jcl-over-slf4j : 1.6.4
- MIT, args4j : args4j : 2.0.28
- Public Domain aopalliance : aopalliance : 1.0
Currently, the SW360 frontend is built with portlets that need to be deployed into a portlet container. We deploy the portlets to Liferay Portal Server as portlet container that is LGPL licensed in its community edition. SW360 works with the community edition of Liferay. There is no feature nor any possible / optional dependency on the commercial edition of Liferay. In fact, no developer / contributor of SW360 has used / installed the commercial edition of Liferay for SW360.
However, the involved contributions need Liferay Portal Server as prerequisite to be deployed to. Liferay does not require modification in order to run as prerequisite for the SW360 solution, the Liferay packages are used as original downloads by the user.
We have one transitive dependency to finbugs.annotations which is LGPL licensed. Prior to the initial contribution we will replace this dependency.
Our project schedule has three horizons:
In short-term (end of Q3/2016)
- Wish to prepare the initial contribution to Eclipse Foundation, which comprises adjustments to use Liferay as prerequisite
- Remove transitive dependency to findbugs.annotations
- Improve deployment with Docker
- Improve data model with feedback from already productive usage
- Maintain vulnerability information about involved components
- More overview listings for understand what is involved in a product BOM.
In mid-term (end of Q4/2016)
- Generators for disclosure documents / notice files and source code bundles
- More features for data curation such as component info merge
- CPE ID suggestion support for new components entries
In long-term (2017)
- Integrate functionality to automatically identify components in order to retrieve information for them (binary hashing and other mechanisms called as service)
- Interfaces to state of the art software development/deployment infrastructure
- Interfaces to other tools providing information about components
- Dynamic workflow component
- Federation of SW360 deployments connecting organizations or to implement organizational structures
- Public SW360 instance as SaaS solution
see project scheduling