[Acquisition diligence] Establish explicit repository licensing and copyright policy

[seonghobae]

Gap

Protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 has no root LICENSE file. A direct contents lookup returns 404, while historical buyer-facing README text assumed [LICENSE](LICENSE) existed. This makes redistribution, reuse, contribution, acquisition diligence, binary/container distribution, and third-party notice handling ambiguous.

This is a governance/legal-product decision, not a defect that should be solved by an agent choosing a favorite open-source license without authority.

RCA boundary

Before adding any license text, determine:

1. who owns copyright in current repository code and documentation, including imported/vendor-origin history;
2. whether mightyETL is intended to be proprietary source-available, private/commercial, or open source;
3. whether all current code can legally be distributed under the selected terms;
4. which direct/transitive dependencies, container bases, bundled assets, example configs, generated artifacts, and docs require attribution/NOTICE or reciprocal-source obligations;
5. whether old xtrmETL history includes third-party or employer/vendor material whose rights differ from new ContextualWisdomLab work;
6. whether CLA/DCO/contributor policy is needed before accepting outside contributions.

Material options to evaluate

• proprietary/commercial terms — if the product is not intended for open redistribution;
• permissive OSS — e.g. Apache-2.0/MIT only if ownership and product strategy support it;
• copyleft OSS — only if reciprocal obligations match commercial strategy;
• dual licensing — only with clear copyright control and operational need;
• defer_until_owner_decision — keep the repository's redistribution posture explicitly all rights reserved / no license granted by absence, while buyer-facing docs say so truthfully.

Do not create a license file until the owner/legal/product decision is explicit. Absence of a license generally does not grant public reuse rights and must not be represented as an OSS license.

Acceptance criteria

• explicit owner-approved licensing decision and scope;
• copyright/provenance inventory for repository-owned code and material third-party/imported code;
• dependency/container/license inventory with incompatible or notice-requiring items identified;
• selected root LICENSE or explicit proprietary licensing artifact;
• NOTICE / third-party attribution artifact when required;
• source headers only where required by the selected license—not noisy boilerplate by default;
• README, SECURITY, packaging/container/release docs and generated artifacts aligned;
• SBOM contains license metadata where tooling exposes it;
• release/packaging tests fail if required license/notice files are absent from distributable artifacts;
• acquisition-diligence documentation records the decision and any residual rights uncertainty;
• no certification, ownership, or redistribution claim is invented by automation.

Non-goals

This issue does not ask an autonomous agent to provide legal advice or unilaterally select the commercial license. It asks the repository to make a currently ambiguous, buyer-material decision explicit and testable.

[seonghobae]

2026-08-10 repository-owned rights-evidence inventory

Fresh protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 inspection separates work this loop can execute autonomously from the owner/legal decision it must not invent:

• root LICENSE is absent (direct contents lookup: 404);
• root NOTICE is absent (direct contents lookup: 404);
• root Maven pom.xml contains no <licenses> declaration and still identifies the reactor as com.xtrmetl:xtrmETL:1.0-SNAPSHOT;
• the public repository therefore exposes source but currently provides no repository-owned outbound-rights artifact that automation may truthfully label MIT, Apache-2.0, copyleft, proprietary-commercial, or dual-licensed;
• the active release/provenance issue [Release/Supply chain] Establish reproducible exact-head artifacts and provenance #165 independently inventories distributable JAR/image/Compose surfaces and mutable container dependencies, so release/license evidence must converge rather than create a separate fabricated policy.

Classification

• execute_now / repository-owned: keep README/package/release claims fail-closed; inventory direct/transitive/container license metadata once exact tooling is available; add future consistency/package tests that verify the owner-approved LICENSE/NOTICE policy without choosing it; retain exact source/provenance evidence for imported/legacy material.
• external_only: owner/legal/product choice of outbound license model and confirmation that historical xtrmETL/vendor/employer/imported material is actually owned or sublicensable under that choice.
• reject: silently adding MIT/Apache/GPL text, inferring rights from public visibility, or claiming acquisition-transferability from an SBOM alone.

This issue should remain open, but the blocker is now narrowed: no new technical secret/permission is required to inventory evidence; the irreducible external input is the outbound-rights/ownership decision itself. Once supplied, repository-owned LICENSE/NOTICE/package/SBOM/release consistency work is immediately actionable.

[seonghobae]

Owner policy is now explicit for this repository/eccosystem: ContextualWisdomLab-owned source must use a commercially usable license, with Apache-2.0 or MIT as the normal permissive baseline; noncommercial/research-only restrictions are not acceptable, and GPL/LGPL/AGPL inbound software is not an acceptable default without an explicit repository-level exception and compatibility determination.

PR #149 now implements the first-party decision for mightyETL: root LICENSE grants Apache-2.0 to mightyETL original source/documentation, and README/CHANGELOG/Documentation Assessment carry the same boundary. The repository license explicitly does not relicense third-party dependencies, container bases, bundled tools/assets, standards, or generated artifacts.

Keep this issue open for the remaining diligence rather than treating the new root license as full closure: complete third-party/imported provenance, identify any NOTICE/attribution obligations, remove/replace commercially incompatible inbound material if found, ensure distributable artifacts carry required license/notice material, bind SBOM/package evidence, and reconcile the branch non-destructively with current protected develop before protected integration. Do not revert the first-party grant to “license undecided” unless new provenance evidence demonstrates that ContextualWisdomLab lacks rights to license a specific first-party file.

[seonghobae]

Protected-develop reconciliation is now complete on the canonical documentation/license lane. PR #149 exact head 074d7cf17032a4487cae195f6dcc2dac469c78d3 non-destructively merges current protected develop@ba8911f50ed20a39927a0d51c0cf20f9b7c91820; fresh comparison is behind_by=0. The merge preserves the branch's Apache-2.0 first-party grant plus protected develop's newer digest-pinned Docker base-image changelog evidence and all 31 protected runtime/test/config commits.

This removes the prior "reconcile with current protected develop" blocker from this issue. Keep #151 open only for the remaining material diligence: third-party/imported provenance, NOTICE/attribution obligations, GPL/LGPL/AGPL/noncommercial intake detection/removal if found, and distributable LICENSE/NOTICE/SBOM/package evidence. The Apache-2.0 repository grant does not relicense those inbound materials.