Google Summer of Code 2026 application

[GMishx]

Hello all!

SW360 as an org is planning to apply for Google Summer of Code this year. In preparation to do so, we are creating this discussion to gather ideas for the GSoC-2026 projects.

Since 2022, there are some changes made by Google in the program. You can read more about it on their website. But as a summary,

• Three sized projects are acceptable by program:
  • Small sized projects (~90 hour)
  • Medium sized projects (~175 hours)
  • Large projects (~350 hours)
• The program is open to 18 years and older people.
  • No longer limited to college students only.
• Flexible time lines between 12 and 22 weeks.

Also, starting this year, 2026, Google has strong advice about the usage of Generative AI in the GSoC program. Please check them at:

• For Mentoring Orgs: Usage of AI tooling in Google Summer of Code 2026 (for Mentoring Orgs)
• For Contributors: Guidance for GSoC Contributors using AI tooling in GSoC 2026 doc

Based on the suggestions from Google, SW360 has following guidelines for GSoC contributors:

• Usage of AI in proposal writing: The proposal writing is a core part of the GSoC program and it should never be offloaded to the AI completely. This is the place where you would most probably meet the organization for the first time and show your creativity, so use this space wisely.
  • Generative AI usage is allowed, but to do tasks like formatting, rearranging, etc.
  • Usage of Generative AI is strictly prohibited for creating the proposal idea itself (includes the end goal, the approach) and proposal will be penalized if such usage found.
• Usage of AI in coding: We have seen in previous contributions that people do not install SW360 at all while they are working on their contributions. If you cannot see the tool, if you cannot test your changes, how can you validate the changes you have done are correct. It then becomes the responsibility of the maintainer to do a thorough testing, always, which takes more time than for the person contributing the changes. AI also does not know everything. Even if you are using coding agents to help you, but you cannot provide them the right input, their output will only be garbage.
  • For you first few PR, we require you to provide evidence of SW360 installation by providing information like API version, SW360 version, screenshot/example output from the changes.
  • Taking help from AI is fine, but completely relying on it is not good for the project and for you.
  • Take suggestions from the AI, but always understand changes before pushing them. If you cannot understand the code generated, do not push it.
  • If you are pushing the code, you are responsible for it, it does not matter a human wrote it or an AI. Thus, take your contributions seriously. We like to work with humans more than machines.
  • If the code changes are not clear and without any human explanation, the maintainers hold the rights to close the PR without further explanation.
• Acceptance criteria: Last year SW360 did not had any acceptance criteria to make it easy for everyone to apply. However, this lead to number of proposals which became impossible to manage. Thus, starting this year, we want to add following to the list of criteria for your proposal to be considered:
  • There should be at least one contribution with significant enough changes (simple typo fix for example do not qualify).
  • If you could not have created a PR, you should at least had communicated with one of the Org member and they should vouch for you.

Please feel free to drop any questions here (or start a new discussion) you have regarding the program, you want to submit a proposal idea, you want to be mentor in the program, etc.

While submitting a project idea, please tag it to be "Medium" or "Large" sized and who you'll prefer working on it "student" or "professional".
Some resources from Google:

• https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
• https://google.github.io/gsocguides/mentor/making-your-ideas-page
• https://google.github.io/gsocguides/student/
• https://opensource.googleblog.com/2024/10/celebrating-20-years-google-summer-of-code-nurturing-next-generation-contributors.html

You can also check the detailed documentation of previous students from FOSSology GSoC-2024.

Here is the list of the people who would be volunteering as mentors & org-admins for GSoC-2026.

• @EttingerK (OrgAdmin)
• @GMishx (OrgAdmin)

Want to mentor this GSoC-2025 ? Please contact OrgAdmins.

[GMishx]

Idea!

Title: Sample project idea 1

Goal: Example Automate the process of model training using pipelining.

Detailed explanation about the project idea. What is expected, if there is already any workflow, etc to be added here.

Bellow are rating out of 3.

Category	Rating
Low Hanging Fruit	**
Risk/Exploratory	*
Fun/Peripheral	**
Core Development	*
Project Infrastructure	**
Project size	Large
Preferred contributor	Student/professional
Skills needed	Python, ML And Data

Contact: @GMishx

[GMishx]

Idea!

Title: 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.

Category	Rating
Low Hanging Fruit	*
Risk/Exploratory	**
Fun/Peripheral	**
Core Development	*
Project Infrastructure	***
Project size	Large
Preferred contributor	Student/professional
Skills needed	Java, Spring, Microservices

Contact : @GMishx @bibhuti230185 @amritkv @rudra-superrr

[Htrxxxxx]

@GMishx @amritkv @bibhuti230185 @rudra-superrr I am interested in working on this Idea . I have the required skills .

[hasanravda]

I am interested in working on this idea, as I have expertise in microservices architecture with spring

[durga-277]

I have expertise in microservices and Spring Boot, and I’d interested in contribute on this idea.

[GMishx]

Idea!

Title: 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

Category	Rating
Low Hanging Fruit	-
Risk/Exploratory	*
Fun/Peripheral	***
Core Development	*
Project Infrastructure	**
Project size	Large
Preferred contributor	Student/professional
Skills needed	Java, Spring

Contact : @amritkv

[GMishx]

Hey @manhuu14 ,
Quick answer to your questions:

1. Priority is for CycloneDX (easy to work with), but we want to support both.
2. Will let @amritkv to answer this.
3. Do we want this? @amritkv
4. This can be a separate endpoint/page where user can upload and visualize their SBOMs. In addition, before exporting the SBOM, SW360 can run the validator to make sure all fields are there, else fail the generation.
5. Field completeness. Different governing bodies requires different fields in the SBOM, and they should be prioritized. Intrinsically, they all are designed to minimize security vulnerabilities.

[manhuu14]

Hi @GMishx Thank you for the clarification.

[amritkv]

Hey @manhuu14 !
For your queries :

2. We need to decide between React Flow and D3.js. Both of these has their own benefits which can be beneficial for us.
3. This is an additional feature and not a necessary one.

[manhuu14]

Hi @amritkv, Thank You for the clarification.

[MrButtCode]

Hi @amritkv @GMishx
I’ve been into Issue #2298 (CycloneDX importer silently dropping the group field, causing name collisions like @sentry/browser merging into browser).

I traced the logic to createComponent() in CycloneDxBOMImporter.java and confirmed the omission. To figure out the cleanest architectural fix, I checked components.thrift to see if SW360 had a dedicated namespace or packageGroup field we could map this to. Since the current schema only uses group fields for user/owner permissions, it seems the most viable approach for now is string concatenation (group/name).

I have a patch running locally that prepends the group. I also added a guard clause to handle edge cases where certain SBOM generators (like some versions of cdxgen) might already embed the scope in the name field, preventing double-prefixing. The importer unit tests are passing locally.

Before I open a Draft PR for this, does the team have a standard protocol for documenting migration concerns when we change how component names are ingested?

[GMishx]

Idea!

Title: 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.

Category	Rating
Low Hanging Fruit	*
Risk/Exploratory	*
Fun/Peripheral	***
Core Development	**
Project Infrastructure	**
Project size	Medium
Preferred contributor	Student/professional
Skills needed	Java, XML, NextJS

Contact : @amritkv @rudra-superrr @deo002

[Guntupalli-Sabarish]

Hi maintainers @amritkv @rudra-superrr @deo002

I am interested in working on the CLIXML Visualizer for Release Attachments project.I have experience with Java and frontend development, and I would like to contribute to designing the parser, work on parsing the reports and building a clear, user-friendly visualization

[GMishx]

Idea!

Title: 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:
3. OAuth Integration: Implementing Machine-to-Machine OAuth flow between SW360 and LicenseDB.
4. 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.
5. Data Persistence: Ensuring that the fetched data is correctly saved and updated within SW360's database for ongoing use and reference.
6. 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

Category	Rating
Low Hanging Fruit	*
Risk/Exploratory	*
Fun/Peripheral	**
Core Development	***
Project Infrastructure	**
Project size	Medium
Preferred contributor	Student/professional
Skills needed	Java, Spring, REST API

Contact : @GMishx @deo002

[melbiialy]

I am interested in working on this idea, and I believe I have the required skills to contribute effectively.

[clapppp]

Hi mentors,
I am currently preparing a proposal for this idea. While studying the SW360 code, I came up with two questions about how the architecture should work.

How to handle the Thrift removal?
I saw that another idea is about removing Thrift and using Spring Beans instead.
Since my project also touches the backend-licenses-core module, I'm wondering how to handle this.
Should I build my logic using the current Thrift method? Or should I write it as Spring Boot components from the start?

M2M Authentication Setup Scope
To implement the OAuth M2M connection, SW360 needs to get the Client credentials from LicenseDB.
For GSoC scope, should I just write the code to read these credentials from environment variables and test it with a mock setup? I assume the actual LicenseDB registration and production token management will be handled by the maintainers later. Is this correct?

Thank you so much for your time!

[AaryanCode69]

Hi Mentors,

I've been studying the current SW360 license and obligation lifecycle in depth including creation, storage, linking to releases (mainLicenseIds), obligation handling, SPDX/OSADL imports, and SBOM generation- and I'm exploring an architectural direction for the proposed LicenseDB integration. From my analysis, SW360 currently acts both as a compliance engine and as a license data authority, with license/obligation data entering through multiple independent paths (manual REST creation, SPDX import, OSADL import, CSV upload, and implicit creation during updates). This leads to fragmented ingestion, manual refresh requirements, limited provenance clarity, and potential divergence from upstream sources over time.

My proposed high-level direction is:

LicenseDB becomes the authoritative source of license and obligation core data

SW360 treats CouchDB as a synchronized read-through cache

Core license/obligation fields originate from LicenseDB

SW360 retains:

    Release linking via mainLicenseIds

    Whitelist handling

    Moderation workflows

    Project-level obligation status tracking

    SBOM/license info generation

Synchronization would be periodic (delta-based), support on-demand single-license fetch, and remain backward-compatible during migration.

Before refining this further, I would appreciate clarification on a few key points:

Strict vs gradual removal: Should LicenseDB strictly replace all local creation/import paths (manual, SPDX, OSADL, CSV), or should a hybrid model exist behind a configuration flag during transition? Is the long-term goal a hard dependency on LicenseDB, or a logical authority with optional offline capability?

Failure model: If LicenseDB is temporarily unavailable, should SW360 operate fully from its local cache? Is a fail-open read / fail-closed write model acceptable?

Obligation ownership: Should all obligations originate exclusively from LicenseDB, or should SW360 continue to allow project-specific custom obligations?

ID contract: Can we assume LicenseDB will expose stable SPDX-compatible identifiers usable as SW360 _id values for mainLicenseIds, or is an ID translation layer expected?

Sync expectations: Should integration rely on updated_since style delta APIs from LicenseDB, or full comparison sync? Is webhook-based push sync envisioned long term?

My intention is not to aggressively remove existing functionality, but to reduce duplication, introduce a clear ownership model, and keep migration safe and incremental. I'd greatly appreciate feedback on the authority model, expected removal scope, sync assumptions, or any architectural constraints I may be overlooking.

[Bharatpathania7]

Hi everyone,

I’m Bharat, a Java/Spring backend developer interested in contributing to SW360 for GSoC 2026.

I’ve started reading the documentation and exploring the repository structure, and I’ve forked and cloned the project locally.

I’d like to start contributing and would appreciate guidance on beginner-friendly issues.

Looking forward to working with you all.

[ADITYA-CODE-SOURCE]

Hello sir @GMishx (https://github.com/GMishx) @deo002 (https://github.com/deo002),
I'm interested in working on the Integration of SW360 and LicenseDB project.
I have been actively working on this implementation and have already submitted several PRs:

• feat(license): add LicenseDB connection configuration properties #3738 - Main LicenseDB integration (open)
• feat(client): add LicenseDB sync methods to SW360LicenseClient #3768 - REST client methods for LicenseDB (open)
• feat(importer): Add LicenseDB as source option in LicsImporter #3770 - LicsImporter LicenseDB support (open)
• feat(cli): Add CLI commands for LicenseDB sync operations #3772 - CLI framework for sync (open)

I've created related issues: #3685, #3766, #3767, #3769, #3771
The implementation includes:

• LicenseDB configuration properties
• REST client with OAuth2 client_credentials
• License import endpoints
• CLI sync commands
• LicsImporter integration

Looking forward to submitting my proposal!

[GMishx]

Idea!

Title: 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

Aspect	Current State	Expected State
Service Layer	Thrift IDL (.thrift files) generates interfaces	Plain Java interfaces with Spring @service
IPC Mechanism	ThriftClients + THttpClient + TCompactProtocol	Direct @Autowired injection (in-process)
External API	Thrift servlets (Sw360ThriftServlet)	REST controllers (existing resource-server)
Dependencies	libthrift, Thrift compiler toolchain	Removed—pure Spring Boot
Code Generation	Required for model classes	POJOs, no generation step

Category	Rating
Low Hanging Fruit	**
Risk/Exploratory	**
Fun/Peripheral	**
Core Development	***
Project Infrastructure	***
Project size	Large
Preferred contributor	Student/professional
Skills needed	Java, Spring, Microservices

Contact : @GMishx @bibhuti230185 @amritkv @rudra-superrr

[Aman-Cool]

Hi @GMishx @bibhuti230185 @amritkv @rudra-superrr,

I'm very interested in the "Remove Apache Thrift and Migrate to Direct Spring Service Calls" project.

I've already made contributions to SW360:

• PR fix(rest): prevent silent data loss in obligation update #3614 (merged)
• PR fix(cyclonedx): use full createRelease overload to preserve metadata #3695 (approved)
• PR fix: report errors instead of unconditional SUCCESS in CycloneDX SBOM… #3718 (approved )
• PR fix(licenseinfo): accumulate all obligations per license in DOCX reports #3748

I have experience with Java, Spring, Microservices, and REST APIs. I'm comfortable with large-scale refactoring and understand this is a significant architectural change.

I'd like to discuss:

1. Preferred migration strategy (big bang vs incremental)
2. Backward compatibility requirements
3. Testing approach for such a large change

Looking forward to working on this!

[Harsh-Dev9]

Hi @GMishx @bibhuti230185 @amritkv @rudra-superrr,

I'm very interested in the "Remove Apache Thrift and Migrate to Direct Spring Service Calls" project.I have experience with Java, Spring, Microservices, and REST APIs. I'm comfortable with large-scale refactoring.

[umeshgupta05]

Hi @GMishx @bibhuti230185 @amritkv @rudra-superrr,

I’m very interested in the “Remove Apache Thrift and Migrate to Direct Spring Service Calls” project.

I understand that this involves removing Thrift-based IPC, eliminating IDL/code generation overhead, and transitioning fully to Spring-managed services and REST APIs. This is a significant architectural refactor that simplifies service communication and reduces coupling within the backend.

I have strong experience with Java, Spring Boot, REST APIs, and backend system design, and I’m comfortable working with large codebases and core infrastructure changes.

I’d like to understand the current dependency footprint of Thrift across modules and any external integrations that may rely on it.

Looking forward to contributing and discussing this further.

[mast3RGG]

Hi @GMishx @bibhuti230185 @amritkv @rudra-superrr,
Hi everyone, I'm Alin. I've been looking over the "Remove Apache Thrift" project and spent some time today digging through the backend code.

Honestly , the ChangeLogController (and most of the others too) is pretty overloaded with logic that shouldn't be there. There’s a lot of manual data shifting and try-catches that make it hard to follow , I’m thinking of starting a POC where I move all that logic into a proper Spring Service layer and use @service beans instead of the Thrift handlers.

Also, we could really use a @RestControllerAdvice to handle errors globally , it would save us from all that boilerplate code that's now in almost every method. My idea is to test this out on the ChangeLog module first because from what i analyzed it s simple and if it works well , I can apply the same pattern to the rest of the services like Projects or Components. I think this would make the whole backend way more "Spring-native" and finally get rid of the Thrift overhead which is not necessary nowadays.

Would love to hear what you guys think about this or if I should focus on a different area first.

[GMishx]

Idea!

Title: 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

Category	Rating
Low Hanging Fruit	*
Risk/Exploratory	***
Fun/Peripheral	**
Core Development	*
Project Infrastructure	***
Project size	Large
Preferred contributor	Student/professional
Skills needed	Java, CouchDB/No SQL

Contact : @GMishx @amritkv @rudra-superrr

[taanvi2205]

Hi @GMishx, @amritkv , @rudra-superrr i’m interested in this topic but I have a doubt-

The archival workflow should allow complete removal of a Project or Component or Release from the SW360 server

If we completely remove the archived data from SW360 server, where will we store it for restoration if needed? Do we have to we integrate with cloud storage or maybe as couchDB attachments?

[GMishx]

Hey @taanvi2205 , we have already clarified this in our dev call, but I am documenting it here as well:
The idea of archival is to bind all the related data about the entity (Release/Component/Project) such as the meta data and the attachments, should be exported in an external file/format (for example a tar of .json and all attachments). In the most preferred way, this method should allow me to extract 100s of entities at once.
This data is now preserved in this archive and not required in the DB anymore and thus should be removed from there to improve the performance. Then it is upto the server admin where they store this archive.
When the admin wants, the retrieval functionality should be able to recreate the data from this archive back in the Database. Since the functionality did not provide ways to upload to S3, for example, it should not provide way to retrieve from there as well. Admin should provide the file and the entities they want to restore (some ids, names, etc. or all) since the archive can contain 100s of entities, one might not want to restore all, but only a subset.

Hope this provides more clarification.

[taanvi2205]

@GMishx, Thanks for the clarification!

[GMishx]

Idea!

Title: 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.

Category	Rating
Low Hanging Fruit	**
Risk/Exploratory	**
Fun/Peripheral	**
Core Development	*
Project Infrastructure	*
Project size	Medium
Preferred contributor	Student/professional
Skills needed	Java, Rest API, NextJS

Contact: @amritkv @rudra-superrr @deo002

[Ali620563]

Hii maintainers

The "Project 360° View" idea is interesting as it addresses the lack of a single overview for compliance status.

A consolidated view that summarizes vulnerabilities, license obligations, and release readiness across parent and child projects would help product owners quickly assess risk before a release. Showing compliance-relevant changes since the last release would further improve audit readiness.

This appears suitable for a medium-sized project and could be built incrementally by first exposing aggregated data via REST APIs and then adding a simple UI view.

[MennaBashir]

Hello @amritkv, @rudra-superrr, @deo002

I’m interested in contributing to the "Project 360° View" idea.
I have experience developing dashboards and visualizing hierarchical data, which I believe aligns well with the project’s goal of providing a comprehensive compliance view for parent and child projects.

[GMishx]

Idea!

Title: 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.

Category	Rating
Low Hanging Fruit	***
Risk/Exploratory	*
Fun/Peripheral	*
Core Development	***
Project Infrastructure	*
Project size	Small
Preferred contributor	Student
Skills needed	Java, Spring, NextJS

Contact : @GMishx @deo002

[Ali620563]

I am interested in the "Customize Copy Project" idea.

From a user perspective, copying a project is often used to create a new version, but carrying over all fields also copies outdated compliance and metadata. Allowing users to select which fields should be copied (for example components, licenses, or basic metadata, while resetting compliance or approval states) would reduce manual cleanup and errors.

This looks like a focused improvement suitable for a small-sized project, and I would be interested in working on both backend and UI changes.

[ADITYA-CODE-SOURCE]

Hello maintainers,

I am interested in working on the Customize Copy Project idea for GSoC 2026.

I have already contributed to the SW360 organization through multiple pull requests, and I would like to continue contributing while preparing a strong proposal for this feature.

To better understand the expected behavior and design, I would like to clarify a few points:

• Which project fields should be selectable during copy (for example: components, releases, licenses, attachments, metadata, etc.)?
• Should compliance and approval states be reset by default in the newly created project?
• Would you recommend starting with the backend API and data model design before implementing the UI selection workflow?

I would greatly appreciate any guidance on the preferred design approach or related areas I should explore first.

Thank you for your time and support.

[ruturajjadhav07]

Idea!

Title: 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.

Category Rating
Low Hanging Fruit ***
Risk/Exploratory *
Fun/Peripheral *
Core Development ***
Project Infrastructure *
Project size Small
Preferred contributor Student
Skills needed Java, Spring, NextJS
Contact : @GMishx @deo002

Hello @GMishx @deo002,

I’m interested in working on the “Customize Copy Project” idea for GSoC 2026.

I have been working with Java and Spring Boot for about a year, building backend applications and contributing to Java/Spring-related issues on GitHub. I’m also comfortable working with REST APIs and database-driven features. I’m interested in understanding how the current “Copy Project” functionality is implemented in SW360 and exploring how we can make it more flexible and user-driven.

[GMishx]

Idea!

Title: 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.

Category	Rating
Low Hanging Fruit	*
Risk/Exploratory	*
Fun/Peripheral	**
Core Development	**
Project Infrastructure	*
Project size	Small
Preferred contributor	Student
Skills needed	Java, Jackson, NextJS (is a plus)

Contact: @amritkv

[hasanravda]

I am interested in working on this idea, as I have expertise in microservices architecture with spring
@amritkv

[paudel-milan]

"Hey @amritkv and @hasanravda, I've been looking into this issue and I'd love to help out.
I’m particularly interested in the automation side of this -making sure tools like "capycli" can actually find when a component is deprecated so they can pull the right data automatically. I've already started digging into the backend code to see how we can best add the successor_id and status fields to the Component model.

@hasanravda, since you mentioned your Spring/Microservices background, maybe we could team up? I'm happy to focus on the API/Data model changes or work on the UI banners if that's easier.
What’s the best way to get started?

[sneha4175]

Hi @GMishx @amritkv @bibhuti230185 @rudra-superrr,

I'm Sneha Khoreja, currently pursuing a Master's in Applied Computer Science and exploring potential GSoC 2026 contributions to SW360.

I’ve been going through the repository and the project ideas listed here, particularly the “Remove Apache Thrift and Migrate to Direct Spring Service Calls” proposal.

My background is mainly in Java/Spring microservices. Over the past couple of years I’ve worked on backend systems built with Spring Boot, Hibernate, Docker, and Kafka, including projects involving service discovery and inter-service communication patterns.

While reading through the idea, a few implementation questions came up:

1)For the Thrift removal, is the expectation to migrate incrementally (module/service by module) or move toward a single larger refactor?

2)Are there specific modules in SW360 where Thrift usage is more isolated and could serve as a good starting point for the migration?

3)During the transition, should the goal be to maintain temporary compatibility with existing Thrift interfaces, or is a clean replacement acceptable for the initial scope?

At the moment I’m setting up SW360 locally and reviewing how Thrift is currently used across the backend modules so I can identify a reasonable starting point for a first contribution.

I’m also interested in the “Creating Components as a separate service” idea, since it involves service decomposition and standalone deployment.

If there are particular areas of the codebase that would be useful to explore first, I’d appreciate the direction.

GitHub: https://github.com/sneha4175

Thanks.

Sneha