Skip to content

Request for Apache-compatible licensing or specification of the OLR network protocol #335

Description

@cjw0810

Background

Hi,

I am currently working on adding OpenLogReplicator (OLR) as an optional Oracle CDC adapter for Apache SeaTunnel.

Apache SeaTunnel currently uses Oracle LogMiner for Oracle CDC. I have implemented and locally validated an alternative OLR adapter that communicates with an external OpenLogReplicator process over its network protocol.

The implementation has already been validated with:

  • Oracle Database 19c
  • OpenLogReplicator 1.9.0
  • Apache SeaTunnel Oracle CDC
  • latest startup mode
  • initial snapshot mode
  • INSERT / UPDATE / DELETE
  • UPDATE / DELETE occurring while the initial snapshot is still running
  • checkpoint recovery using CONTINUE
  • Console Sink
  • Doris Sink

The implementation works correctly in my test environment.

However, before publishing the implementation to Apache SeaTunnel, the SeaTunnel maintainers raised an important licensing/provenance concern around the OLR network protocol.

Licensing / provenance concern

The current prototype implements the OLR client protocol based on the protocol structures used by OpenLogReplicator.

The SeaTunnel maintainers pointed out that the current protocol definition / generated protocol material cannot simply be copied or vendored into an Apache Software Foundation distribution if it is covered only by GPL/AGPL-compatible terms.

Therefore, before I publish the implementation as a SeaTunnel PR, they asked me to establish a clean and reviewable provenance boundary for the OLR wire protocol.

To be clear:

I am NOT asking to relicense the whole OpenLogReplicator project.

OpenLogReplicator would remain a completely separate and optional external process.

Apache SeaTunnel would NOT distribute:

  • the OpenLogReplicator executable
  • OpenLogReplicator source code
  • AGPL components from OpenLogReplicator
  • any other OLR server implementation artifacts

The only concern is how an Apache-2.0 licensed Java client may legally and independently implement the OLR network wire protocol.

Request

Would you be willing to provide one of the following options for the OLR network protocol?

Option 1 - Permissively licensed protocol specification

Provide a client-facing specification of the OLR network / wire protocol under an Apache-compatible permissive license, for example:

  • Apache License 2.0
  • MIT
  • BSD

This does not need to cover the OpenLogReplicator implementation itself.

Only the information necessary to independently implement a compatible client would be required, for example:

  • message framing
  • INFO request / response
  • START request
  • CONTINUE request
  • SCN fields
  • checkpoint index fields
  • event/message types
  • protobuf field numbers and enum values, if protobuf remains the wire format
  • expected reconnect / retry behavior

SeaTunnel could then independently implement the client from this specification without copying GPL/AGPL implementation code.

Option 2 - Dual-license the client-facing protocol definition

If possible, the client-facing protocol definition (for example OraProtoBuf.proto, or a smaller protocol-only definition) could be separately dual-licensed under an Apache-compatible permissive license.

This would allow Apache SeaTunnel to generate or independently implement the client-side protocol classes while keeping the OpenLogReplicator server implementation under its existing license.

Again, I am not requesting any license change for the whole OpenLogReplicator project.

Option 3 - Explicit permission / protocol grant

Alternatively, explicit permission from the relevant copyright holder allowing Apache SeaTunnel to independently implement and distribute an Apache-2.0 licensed client compatible with the OLR network protocol could also establish the required provenance boundary.

The intent would still be to independently implement the client side rather than copy OpenLogReplicator server implementation code.

Intended SeaTunnel architecture

The intended architecture is:

Oracle
  |
  | redo / archive logs
  v
OpenLogReplicator
  |
  | OLR network protocol
  v
Apache SeaTunnel Oracle-CDC
  |
  v
Sink

OLR remains outside SeaTunnel as an independently deployed external process.

The SeaTunnel configuration would simply allow selecting OLR as another adapter behind the existing Oracle CDC source, for example:

database.connection.adapter = "olr"

openlogreplicator.host = "192.168.x.x"
openlogreplicator.port = 5000
openlogreplicator.source = "ORACLE"

Conceptually:

Oracle-CDC
   |
   +-- LogMiner              (existing implementation)
   |
   +-- OpenLogReplicator     (optional adapter)

The existing Oracle CDC source abstraction, snapshot split model, checkpoint model and LogMiner behavior would remain unchanged.

Users who do not enable the OLR adapter would continue using the current LogMiner implementation exactly as before.

Current protocol behavior implemented

The current prototype supports the OLR protocol flow required by SeaTunnel CDC:

INFO
  |
  +-- START(SCN)
  |
  +-- CONTINUE(SCN, checkpoint index)

The CDC event mapping is currently:

OLR INSERT
    -> SeaTunnel INSERT

OLR UPDATE
    -> SeaTunnel UPDATE_BEFORE
    -> SeaTunnel UPDATE_AFTER

OLR DELETE
    -> SeaTunnel DELETE

The snapshot-to-streaming transition has also been tested.

In particular, the incremental reader resumes from the snapshot watermark using the OLR CONTINUE request with:

c_scn = snapshot/checkpoint SCN
c_idx = checkpoint index

This was validated with UPDATE and DELETE operations occurring while the initial snapshot was still running.

Why I am asking

Apache SeaTunnel maintainers are open to reviewing the OLR adapter, but they need a clear Apache-compatible provenance boundary for the network protocol before the implementation can be submitted.

I already have a working prototype, so the implementation itself is not currently the blocker.

The main blocker is establishing a protocol specification / licensing boundary that allows an Apache-licensed client implementation to be reviewed and distributed safely.

Before publishing the SeaTunnel PR, I therefore wanted to ask the OpenLogReplicator project directly rather than make assumptions about the protocol licensing.

Is there already an independently documented or permissively licensed specification for the OLR network protocol that I may have missed?

If not, would you be open to one of the options above, or is there another protocol integration approach you would recommend for an Apache-licensed client?

Thank you for your work on OpenLogReplicator and for considering this request.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions