Clarification on Packaging Oracle JDBC Driver in Uber/Wrapper-Jar and Deployment to Maven Central

Dear Eclipse IP Team,

I would like to clarify a licensing and distribution question related to using the Oracle JDBC driver within an OSGi environment and potentially distributing a wrapper artifact.

Use Case:

I want to run the Oracle JDBC driver inside an OSGi Runtime. To do so, the driver JAR requires additional OSGi metadata in its MANIFEST.MF.

My planned approach is:

1. Not modifying the original Oracle JDBC driver JAR at all.

2. Creating a wrapper JAR that contains:

   • the unmodified Oracle JDBC driver JAR as a nested resource,
   • additional OSGi metadata in the MANIFEST.MF, and
   • a MANIFEST entry that adds the Oracle JAR to the classpath.

This wrapper would allow easy deployment in OSGi without altering Oracle’s binary.

I intend to make this wrapper JAR available (initially only as a snapshot) on Maven Central to simplify consumption for OSGi users.

License Context

According to Oracle’s Free Distribution, Hosting, and Use Terms (FDHUT) (https://www.oracle.com/database/technologies/appdev/jdbc-downloads.html) / (https://download.oracle.com/otn-pub/otn_software/jdbc/FDHUT_LICENSE.txt):

• I may not modify the Oracle driver.
• I may redistribute the unmodified driver along with the license text.
• I may include it as part of a value-added product or service (as long as it remains unmodified).

My reading is that wrapping the unmodified JAR in another JAR that only adds metadata does not constitute modification of the program itself, and redistribution of the original, unmodified Oracle JAR inside a wrapper is allowed, provided the Oracle license is included.

Could you confirm whether this interpretation is correct? Pros & Cons of This Approach

Pros:
  -  No modification of Oracle’s code.
  -  Easier integration into OSGi (no manual repackaging needed by users).
  -  License text can be preserved inside the wrapper.

Cons / Risks:
  -  Unclear if Oracle would consider wrapping as “redistribution with changes” (even though the binary is unchanged).
   - Publishing to Maven Central might imply “distribution” to third parties, which must comply strictly with Oracle’s terms.

Open Questions

Is it allowed to redistribute the Oracle JDBC driver (unmodified) inside a wrapper JAR under FDHUT?

If yes, under which license should the wrapper JAR itself be published? EPL-2.0 for the wrapper metadata? Or must the wrapper adopt the Oracle FDHUT license entirely because it embeds the Oracle binary?

Is publishing this wrapper JAR to Maven Central acceptable, even as a snapshot?

Are there any additional considerations from Eclipse’s side regarding third-party license compliance when redistributing Oracle binaries in this way?

My Current Assumption

• The Oracle JAR must remain unmodified.
• It can be redistributed if the license text is included.
• The wrapper JAR would be a separate artifact, with its own metadata, but would not alter the Oracle binary. - The wrapper JAR would need to clearly indicate that it contains Oracle’s proprietary software and include the required license notices.

Could you please confirm whether this approach complies with Eclipse Foundation’s guidelines for third-party redistribution, and whether any additional steps are needed?

Last thought:

The same issue seems to arise when creating a Docker container that includes the Oracle JDBC driver JAR and pushing it to a public Docker repository.

Thank you for your guidance!