GSoC Idea List - 2026

Welcome to the idea page for all GSoC 2026 related information.

• Check https://github.com/eclipse-sw360/sw360/discussions/3631

Intro

SW360 is applying as a mentoring org again in GSoC 2026 with the ambition to make it as awesome as the GSoC 2025!

Please see two main resources for finding out more SW360 in general:

• Check https://eclipse.dev/sw360/ and development and deployment section.
• Try to install SW360 from source or your can try the Docker

Meetings: Checkout the Meetings table

AI Policy

Please out our AI Policy documenting our understanding and requirements about the usage of Generative AI with respect to Google Summer of Code program as well as its usage in general at our policy page.

Interested in Application? - Getting Grip

If you are interested in an application - great! We encourage your application. So the question is how to get started with the topic, just a few points:

• Check https://eclipse.dev/sw360/docs/ for development and operational guides.
• Check the frontend project for UI: https://github.com/eclipse-sw360/sw360-frontend
• Try to install SW360, either from source or Docker
  • https://github.com/eclipse-sw360/sw360/blob/main/docker-compose.yml
• Read the proposed topics
• Use the mailing list sw360-dev@eclipse.org or contact proposed mentors for further steps.
• Matrix group
• GitHub discussion
• If you are interested in trying to make contributions, see contribution guidelines.
• Check out our new AI Guidelines

Mentors

Interested in becoming a mentor? Please reach out to us!

Volunteers so far:

• Amrit Kumar Verma
• Anupam Ghosh
• Gaurav Mishra
• Katharina Ettinger
• Kouki Hama

Topic Proposals

Please reach out to us to add more proposals for GSoC 2026.

Currently, discussion happening on https://github.com/eclipse-sw360/sw360/discussions/3631

Topic Proposals for 2026

Following are the topics proposed by the community (in no particular order):

1. Creating Components as a separate service in SW360
2. SBOM Validator
3. CLIXML visualizer for release attachments
4. Integration of SW360 and LicenseDB
5. Remove Apache Thrift and Migrate to Direct Spring Service Calls
6. Archival of Components and Projects
7. Project 360 view
8. Customize Copy Project

Creating Components as a separate service in SW360

Goal: Idea is to create a Components as a service that can then be used by multiple Org to reuse common component repository.

Decompose SW360 backend and extract out the Component and related modules like Releases, Packages. This new service should be capable of running with its own DB and as a standalone service.

SBOM Validator

Goal: Design and implement an SBOM Validator that ensures uploaded SBOMs meet organizational and regulatory requirements by validating completeness, consistency, and structure

The SBOM Validator processes SBOMs generated by different tools and provided in various standard formats (such as SPDX and CycloneDX). It validates that all mandated fields are present and correctly populated according to defined policies and compliance requirements.

The validator may optionally convert incoming SBOMs into a standardized internal representation. When enabled, this internal format is used to simplify validation logic, ensure consistent behaviour across SBOM sources, and reduce format-specific handling. When not enabled, validation can be performed directly against the original SBOM structure.

During processing, the validator consolidates duplicate or overlapping packages and components, resolving inconsistencies such as multiple representations of the same dependency. Additionally, the validator supports SBOM enrichment by augmenting existing data with derived or externally sourced information, such as normalized package identifiers or additional metadata.

Before final import, users are provided with a clear graphical and navigable visualization of the parsed and consolidated SBOM data instead of boaring flat list view, allowing them to review structure, metadata, and detected issues.

In a summary:

• Validate SBOMs from multiple formats (e.g., SPDX, CycloneDX) and generators for completeness and correctness.
• Ensure all mandated and policy-required fields are present and properly populated.
• Optionally normalize uploaded SBOMs into a standardized internal format to simplify validation and ensure consistent processing.
• Provide a graphical visualization of SBOM data prior to import for user review.

CLIXML visualizer for release attachments

Goal: The idea here is to provide a clearance report visualizer for the CLIXML coming from FOSSology.

Currently, SW360 users must download separate CLIXML files or log into FOSSology to understand the clearance status of a release. This feature would allow SW360 to parse the CLIXML report directly within the browser. The key features to this idea can be pointed out as follows:

• CLIXML Parser and UI Renderer in SW360
• If FOSSology can provide item ID in the report, provide a hyperlink to file directly. Next to every file listed in the SW360 preview, provide a “View in FOSSology” icon.
• Compare the CLIXML of the current release with the previous version. Highlight New Licenses or Changed Copyrights in red/green within the UI. This helps the user focus only on what has changed in the latest code drop.

Integration of SW360 and LicenseDB

Goal: To establish LicenseDB as the sole source for all license and obligation data within SW360, streamlining data management and ensuring consistency.

Currently, SW360 relies on a fragmented approach for managing license and obligation information. Licenses can be imported from external sources like OSADL or SPDX, or created manually. Obligations, which define the requirements associated with each license, can only be created manually within SW360. This decentralized system can lead to inconsistencies, manual overhead, and difficulty in maintaining a single, accurate view of license compliance.

This project aims to change how SW360 manages this data by integrating it directly with LicenseDB. The successful completion of this project will involve:

1. Removing Redundant Data Entry Methods: All existing functionalities within SW360 that allow for manual license creation or direct import from OSADL/SPDX will be deprecated and removed.
2. Integration: Develop a robust integration layer to enable SW360 to fetch license and obligation data directly from LicenseDB. This will likely involve:
   1. OAuth Integration: Implementing Machine-to-Machine OAuth flow between SW360 and LicenseDB.
   2. Data Translation/Mapping: Creating mechanisms to translate and map data structures from LicenseDB’s format to SW360’s internal data model for licenses and obligations.
   3. Data Persistence: Ensuring that the fetched data is correctly saved and updated within SW360’s database for ongoing use and reference.
3. Adapting Existing Workflows: Review and modify existing SW360 CLI (Command Line Interface) and XML-based workflows. These workflows currently create licenses and obligations if they don’t already exist. They must be updated to leverage the new LicenseDB integration, ensuring they now fetch and sync data from LicenseDB rather than creating it independently.

Checkout LicenseDB at: https://github.com/fossology/LicenseDb

Remove Apache Thrift and Migrate to Direct Spring Service Calls

Goal: Eliminate Apache Thrift dependency from SW360 and replace inter-service communication with direct Spring Bean injection and REST APIs.

SW360 currently uses Thrift for backend service communication (ThriftClients, *Service.Iface). This adds complexity, requires .thrift IDL files, and creates tight binary coupling. Migrate to Spring-managed services with direct injection for in-process calls and REST for external integrations.

Current state vs Expected state

Archival of Components and Projects

Goal: Creation of an archival and restore functionality to remove unnecessary Projects and Components from SW360 server

As an SW360 instance grows over years of use, the database becomes cluttered with “stale” projects and deprecated component versions that are no longer in active use. This feature introduces an Archival Workflow. The archival workflow should allow complete removal of a Project or Component or Release from the SW360 server (with entire metadata like changelogs, attachments, etc.) into a single compressed package (e.g., a ZIP or TAR containing JSON metadata), and purges them from the active database. At the same time, there should be a Workflow to restore these archived projects/components/releases individually for the purpose of audit, reuse, etc. This archival process will allow usage of cold storage backups and improve upon the performance of application by reducing index size, speeds up UI responsiveness, and saves significant disk space.

Feature points to consider:

• Comprehensive Data Bundling (The “Snapshot”)
• Database Cleanup & Performance Optimization
• Seamless Re-Import & Restoration
• Archival Metadata Registry

Project 360 view

Goal: To empower product owners and compliance teams with a single, trusted source of compliance truth

Project 360° View delivers a holistic compliance dashboard for both parent and child projects, offering complete visibility into software usage, security risks, and license obligations.

It consolidates vulnerability data across the entire project hierarchy, clearly highlighting severity levels, affected components, and overall compliance impact. All license and obligation information is aggregated to identify notice, disclosure, and copyleft requirements, ensuring legal and regulatory adherence.

The view also presents approved and pending releases, along with clearing request and legal approval status, giving product owners a clear picture of release readiness. Additionally, all compliance-relevant changes since the last release—including newly introduced components, license changes, new vulnerabilities, and removed items—are tracked and visualized.

By unifying security, legal, and release data into a single interface, Project 360° View enables faster audits, reduces compliance risk, and supports confident, data-driven release decisions.

• Provide a good overview of the project to the product owners.
• Project 360° View provides a hierarchical compliance view of parent and child projects, ensuring full traceability of software usage.
  • It consolidates vulnerability data across the project hierarchy, highlighting severity, affected components, and compliance impact.
  • License information and obligation data are aggregated to identify notice, disclosure, and copyleft requirements.
  • The page presents approved and pending releases, including clearing request and legal approval status.
  • Compliance-relevant changes since the last release—new components, licenses, vulnerabilities, and removals—are clearly tracked.
  • This enables faster, audit-ready compliance verification and release approval decisions.

Customize Copy Project

Goal: Idea is to allow users to provide fields they want to carry over while using the “Copy Project” feature

Currently, when a user wants to use duplicate/copy projects to create, lets say a new version, they do not have a choice of fields to be carried over. SW360 copies all and everything to the new Project and the user has to manually make sure everything is up-to-date.

This new feature will allow users to pick and choose the fields they want to carry over into the new Project and leave the rest. To implement this feature, the changes would have to be done at both front-end and back-end side.

Provide alternative Component link

Goal: Provide a data structure to deprecate a Component and provide link to new Component.

Depending on how Admins are using the SW360 instance, they want to manage the Component naming/grouping in a different way. There can also be scenarios where an OSS project decided to rename themselves over period. In such cases, you might want to mark a Component as deprecated and provide an alternative to be used instead.

All this information still needs to be preserved and documented in SW360 but needs to be machine-readable as well. When using automation to generate SBOM and import in SW360 like with capycli, adding all such customization makes them tool specific and someone using different tool might not understand this.

The main idea of this project is to provide such fields in the Component DataStructure where user can mark a Component (and all its Releases) as deprecated. At the same time, make it easy to provide link to alternatives to be used. Such information, when provided over REST API, can be used by frontend to display information like bellow. At the same time allow tools to use this information to make smart decisions. As an add-on, SW360 can be allowed to completely disallow changes in deprecated Components and use the alternative instead to create new Releases.