A Software Bill of Materials (SBOM) is becoming an essential tool for effective software dependency management. An SBOM is a list of components used in software, including details such as component names, versions, and licenses. Using SBOMs, developers can quickly identify software components and assess whether their software depends on vulnerable libraries. Numerous tools support software dependency management through SBOMs, which can be broadly categorized into two types: tools that generate SBOMs and tools that utilize SBOMs. A substantial collection of accurate SBOMs is required to evaluate tools that utilize SBOMs. However, there is no publicly available dataset specifically designed for this purpose, and research on SBOM consumption tools remains limited. In this paper, we present a dataset of SBOMs to address this gap. The dataset we constructed comprises 46 SBOMs generated from real-world Java projects, with plans to expand it to include a broader range of projects across various programming languages. Accurate and well-structured SBOMs enable researchers to evaluate the functionality of SBOM consumption tools and identify potential issues. We collected 3,271 Java projects from GitHub and generated SBOMs for 798 of them using Maven with an open-source SBOM generation tool. These SBOMs were refined through both automatic and manual corrections to ensure accuracy, currently resulting in 46 SBOMs that comply with the SPDX Lite profile, which defines minimal requirements tailored to practical workflows in industries. This process also revealed issues with the SBOM generation tools themselves. The dataset is publicly available on Zenodo (DOI: 10.5281/zenodo.14233414).

Current software development takes advantage of many external libraries, but it entails security and copyright risks. While the use of the Software Bill of Materials (SBOM) has been encouraged to cope with this problem, its adoption is still insufficient. In this research, we analyzed the challenges that developers faced in practicing SBOM use by examining questions about SBOM utilization on Stack Overflow, a Q&A site for developers. As a result, we found that (1) the proportion of resolved questions about SBOM use is 15.0% which is extremely low, (2) the number of new questions has increased steadily from 2020 to 2023, and (3) SBOM users have three major challenges on SBOM tools.

Libraries have become integral to modern software development, yet their management often falls short, resulting in issues such as delayed responses to vulnerabilities. To address these issues, the use of a Software Bill of Materials (SBOM) is recommended. Despite the recommendation, there is a lack of tools supporting software management using SBOM. In this paper, we present “Osmy”, a tool designed to facilitate effective software management using SBOM in the SPDX format-one of the major SBOM formats. Osmy is designed to simplify and streamline SBOM-based software management for end users. It automates vulnerability assessment and file integrity verification, operating periodically to ensure continuous protection. Users receive timely notification of any identified issues, ensuring a proactive approach to software security. Osmy is available at https://github.com/higolab/Osmy.

It is useful if a bug tracking system can detect bug report duplication with unfinished bug reports. To investigate the feasibility, we study relations between accuracy of duplicate bug report detection using features extracted from textual information in bug reports and the number of words in bug reports in this paper. The results show that increasing the number of words to be used in duplicate detection over a certain number does not affect the accuracy very much. The results also indicate that we had better use about 100 and 80 words in Eclipse and OpenOffice, respectively, in the detection because we may have many wrong candidates of duplication if we use words of more than the numbers. We thus think that detecting bug duplication in writing a new bug report has potential of giving duplicate bug report candidates.

The reuse of free and open source software (FOSS) components is becoming more and more popular. They usually contain one or more software licenses describing the requirements and conditions which should be followed when been reused. Licenses are usually written in the header of source code files as program comments. Removing or modifying the license header by re-distributors will result in the inconsistency of license with its ancestor, and may potentially cause license infringement. But to the best of our knowledge, no research has been devoted to investigate such kind of license infringements nor license inconsistencies. In this paper, we describe and categorize different types of license inconsistencies and propose a feasible method to detect them. Then we apply this method to Debian 7.5 and present the license inconsistencies found in it. With a manual analysis, we summarized various reasons behind these license inconsistencies, some of which imply license infringement and require the attention from the developers. This analysis also exposes the difficulty to discover license infringements, highlighting the usefulness of finding and maintaining source code provenance.

Econo-ESA is an economic scheme of the explicit semantic analysis (ESA). The scheme properly decreases the ESA index matrix dimensions to achieve faster process with similar results. This paper discusses index matrix dimensional reduction schemes of econo-ESA. We did experiments with several schemes: random selection, k-means clustering, norm-based clustering, densest, and sparsest schemes. Each resulted matrix had different element values and density. Our experimental results showed that the random selection scheme, which had the nearest density to the original index matrix, gave the best results. We thus conclude that the index matrix density is an additional feature which has to be considered in econo-ESA.

When we reuse a code fragment in an open source system, it is very important to know the history of the code, such as the code origin and evolution. In this paper, we propose an integrated approach to code history tracking for open source repositories. This approach takes a query code fragment as its input, and returns the code fragments containing the code clones with the query code. It utilizes publicly available code search engines as external resources. Based on this model, we have designed and implemented a prototype system named Ichi Tracker. Using Ichi Tracker, we have conducted three case studies. These case studies show the ancestors and descendents of the code, and we can recognize their evolution history.

This paper summarized experiences of practical software development exercise in PBL style activities from organizer perspective. The object of this PBL is nurturing advanced knowledge as advanced information and communication technology (ICT) engineers. A main pillar of this report is trace the 5-year history of three sub environments such as development, development support and teaching support environment which are badly need to hold our software development PBL, from problem and its solutions viewpoint.

The reuse of free and open source software (FOSS) components is becoming more prevalent. One of the major challenges in finding the right component is finding one that has a license that is e for its intended use. The license of a FOSS component is determined by the licenses of its source code files. In this paper, we describe the challenges of identifying the license under which source code is made available, and propose a sentence-based matching algorithm to automatically do it. We demonstrate the feasibility of our approach by implementing a tool named Ninka. We performed an evaluation that shows that Ninka outperforms other methods of license identification in precision and speed. We also performed an empirical study on 0.8 million source code files of Debian that highlight interesting facts about the manner in which licenses are used by FOSS