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.
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:
lateststartup modeinitialsnapshot modeCONTINUEThe 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 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:
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:
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:
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:
Conceptually:
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:
The CDC event mapping is currently:
The snapshot-to-streaming transition has also been tested.
In particular, the incremental reader resumes from the snapshot watermark using the OLR
CONTINUErequest with: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.