One application can have many controlling instruments

A repository license, a package-manifest declaration, source visibility, registry access, a commercial agreement, and physical possession of files prove different things. None of them alone determines rights for every other application artifact.

The manifest on this page is a dated snapshot of 21 first-party manifests. It does not automatically cover tarballs, official modules in another repository, commissioned code, transitive dependencies, images, fonts, models, infrastructure, or deployment data.

What the exact MIT file says

The file grants a person receiving a copy the listed permissions to use, copy, modify, merge, publish, distribute, sublicense, and sell copies, and to permit others to do so. Its condition is inclusion of the copyright and permission notices in all copies or substantial portions of the Software.

The same file provides the Software as is, without the listed warranties, and includes a limitation of liability for authors and copyright holders. This page does not interpret enforceability in any jurisdiction.

Enterprise has a separate license boundary

The reviewed Enterprise file allows optional developer-only, non-production evaluation without a commercial license. It requires a valid commercial license for production or commercial use. Without one, it also lists prohibitions on reproduction, redistribution, sublicensing, publication, modification, refactoring, reverse engineering, derivation, and generating new features based on the package.

A signed agreement may add or supersede project-specific terms and needs direct review. Statements about support, updates, certification, environments, or production approval are time-sensitive commercial scope, not an offer from this site or a right granted by MIT.

Evidence for this section:

App code, third-party components, and ejection need separate evidence

A standalone app consumes versioned packages and contains app-local code. Its implementation agreement should separately address repository access, modification and sublicensing rights, background and commissioned code, third-party inclusions, notice files, builds, environments, documentation, defects, updates, supplier exit, and acceptance artifacts. Payment alone is not evidence of copyright assignment.

The install command can technically accept a first-party package or, after explicit opt-in, a third-party package. A lockfile, public repository, npm listing, or @open-mercato scope does not prove license compatibility. The exact package, version, license text, notices, and project-specific review are required.

Ejection copies an eligible module into local source and transfers technical maintenance to the application team. That fact alone does not prove copyright assignment, relicensing permission, or rights in other application code.

Data, services, and marks are separate questions

A software license does not by itself determine controller and processor roles, data and attachment export, formats, identifiers, backup custody, secret revocation, or deletion at exit. It also does not determine support access, future updates, supplier accounts, domains, marks, or brand assets.

No complete public trademark policy was found in the reviewed sources, so that row remains unresolved. The register keeps it for contract or legal review instead of inferring permission from a code license.

A material evidence gap stops acceptance

Stop review when a license file is missing, manifest and license conflict, a package is unpinned, copied code has unknown origin, notices are not inventoried, generated or media assets lack provenance, Enterprise lacks applicable commercial evidence, no reproducible build exists, data cannot be exported, credentials remain supplier-only, or code ownership is disputed.

The state “evidence complete for procurement review” means only that the informational gates are closed. It does not mean compliant, safe, owned, or legally approved. Those decisions remain with named owners and qualified counsel.

Dated first-party package manifest

Generated from every packages/*/package.json manifest at the pinned revision. A declaration is evidence to inspect, not legal clearance for an application.

Revision: 01911d00e28f44cf484d0b1d04860dcfef5370bf · Date: 2026-07-14

Generated from every packages/*/package.json manifest at the pinned revision. A declaration is evidence to inspect, not legal clearance for an application.
PackageVersionDeclared licensePublication accessFamilyPinned manifest
@open-mercato/ai-assistant0.6.5MITpublicAI and application moduleInspect manifest
@open-mercato/cache0.6.5MITpublicInfrastructure libraryInspect manifest
@open-mercato/channel-gmail0.6.5MITpublicCommunication providerInspect manifest
@open-mercato/channel-imap0.6.5MITpublicCommunication providerInspect manifest
@open-mercato/checkout0.6.5MITpublicCommerce moduleInspect manifest
@open-mercato/cli0.6.5MITpublicDeveloper toolingInspect manifest
@open-mercato/content0.6.5MITpublicContent moduleInspect manifest
@open-mercato/core0.6.5MITpublicCore platformInspect manifest
@open-mercato/enterprise0.6.5SEE LICENSE IN LICENSE.mdrestrictedSeparately licensed packageInspect manifest
@open-mercato/events0.6.5MITpublicInfrastructure libraryInspect manifest
@open-mercato/gateway-stripe0.6.5MITpublicPayment providerInspect manifest
@open-mercato/onboarding0.6.5MITpublicApplication moduleInspect manifest
@open-mercato/queue0.6.5MITpublicInfrastructure libraryInspect manifest
@open-mercato/scheduler0.6.5MITpublicInfrastructure moduleInspect manifest
@open-mercato/search0.6.5MITpublicSearch packageInspect manifest
@open-mercato/shared0.6.5MITpublicShared foundationInspect manifest
@open-mercato/storage-s30.6.5MITpublicStorage providerInspect manifest
@open-mercato/sync-akeneo0.6.5MITpublicIntegration packageInspect manifest
@open-mercato/ui0.6.5MITpublicUI foundationInspect manifest
@open-mercato/webhooks0.6.5MITpublicIntegration infrastructureInspect manifest
create-mercato-app0.6.5MITpublicApplication scaffolderInspect manifest

Reported manifest exceptions: None found in the reviewed fields; exact built artifacts still need project review.

Root license applies only to artifacts it covers.

Artifact boundary map

Artifact categoryCurrent evidence sourceLikely controlling instrumentWhat access or possession provesRights, update, and handover questionsAccountable reviewerUnresolved evidenceProduct source
Root and Core codeRoot LICENSE and exact Core manifestRepository license plus artifact manifestPublic source and public package metadata are visible.Confirm exact artifact, version, notices, use, modification, redistribution, update, and handover evidence.Technical and legal reviewersExact deployed artifact and notice bundleInspect manifest
First-party public packagesEvery exact packages/*/package.json manifest and root LICENSEPackage declaration plus referenced license textReviewed manifests declare public registry access.Confirm tarball, version, license text, dependencies, notices, modifications, update source, and exit copy.Technical and legal reviewersApplication bill of materials and distributed noticesInspect manifest
Enterprise packageEnterprise manifest, LICENSE.md, and applicable signed agreementSeparate package license and commercial agreementSource visibility and restricted publication metadata do not establish project rights.Confirm evaluation or production scope, commercial use, modification, redistribution, updates, termination, and handover.Procurement and legal reviewersApplicable signed terms and licensed deployment scopeInspect manifest
Official or ecosystem modulesExact repository, package, version, license, and noticesEach module license and any supplier agreementA first-party review label or module listing is not a license.Confirm origin, version, rights, notices, dependencies, security fixes, updates, and source handover.Technical, procurement, and legal reviewersExact installed module inventory and termsQualified counsel must decide rights for an actual project.
Third-party modules and providersExact package, provider terms, API terms, and lockfile entryThird-party license and service contractTechnical opt-in or npm access proves installation only.Confirm compatibility review, data access, credentials, remote terms, notices, updates, exit, and replacement.Technical, security, procurement, and legal reviewersProject-specific approval and exit evidenceInspect manifest
Standalone application codeApplication repository, history, manifests, and implementation agreementCommissioned-code agreement and licenses for included codeRepository possession must be verified for completeness and rights.Confirm background and new code, modification, sublicensing, source, history, build, defects, updates, and transfer.Product, technical, procurement, and legal reviewersExecuted agreement and accepted repository baselineInspect manifest
Custom modules and overridesApp source, exact public contracts, authorship, and change recordsCommissioned-code agreement plus upstream licensesApp-local source proves placement, not copyright assignment.Confirm authorship, reuse, contract rights, data changes, notices, tests, updates, disablement, and handover.Technical, procurement, and legal reviewersRights schedule and maintained-source inventoryQualified counsel must decide rights for an actual project.
Ejected module sourceEject record, original package/version/license, local diff, and app agreementOriginal license plus contract for later modificationsThe app loads and maintains a local copy.Confirm origin, license condition, modification rights, authorship of changes, upstream watch, merge process, and retirement.Technical and legal reviewersOriginal source evidence, diff, notices, and maintenance ownerInspect manifest
Transitive dependenciesApplication lockfile, resolved artifacts, license files, and notice reportEach dependency licenseA parent package declaration does not cover dependency terms.Confirm versions, sources, licenses, notices, conflicts, vulnerabilities, distribution, and replacement.Technical, security, and legal reviewersComplete resolved software bill of materialsQualified counsel must decide rights for an actual project.
Data, configuration, and secretsData model, exports, backups, configuration inventory, credential custody, and agreementsData terms, privacy agreements, service contracts, and operating policyDatabase access does not decide copyright or privacy roles.Confirm controller/processor roles, export formats, identifiers, attachments, backups, retention, deletion, and secret revocation.Data, security, procurement, and legal reviewersTested export, restoration, deletion, and credential transferQualified counsel must decide rights for an actual project.
Media, fonts, content, and modelsAsset inventory, source files, license records, releases, and consent evidenceAsset license, commission, or content agreementPresence in public or build directories proves possession only.Confirm origin, attribution, modification, redistribution, territory, duration, model usage, and source handover.Content, technical, procurement, and legal reviewersComplete provenance and required attributionQualified counsel must decide rights for an actual project.
Infrastructure, CI, and build artifactsInfrastructure repository, CI definitions, images, registries, scripts, and credentialsCode licenses, supplier terms, and implementation agreementA running environment does not prove a reproducible independent build.Confirm source, versions, registries, image licenses, pipelines, environment definitions, access transfer, and rebuild.Platform, security, and procurement reviewersIndependent build/run exercise and credential inventoryQualified counsel must decide rights for an actual project.
Documentation and runbooksDocumentation repository, decision records, support procedures, and acceptance listImplementation agreement and individual content licensesRead access does not prove delivery completeness or reuse rights.Confirm editable source, scope, update duty, reuse, training, operating procedures, and exit copy.Product, operations, procurement, and legal reviewersAccepted editable documentation setQualified counsel must decide rights for an actual project.
Support, updates, and future accessApplicable subscription, support, update, and service agreementsCommercial contracts and supplier policiesCurrent source or package access does not promise future service.Confirm term, coverage, security fixes, update access, response, expiration, post-contract use, export, and transition.Service owner, procurement, and legal reviewersExecuted terms and funded continuity planQualified counsel must decide rights for an actual project.
Names, marks, domains, and brand assetsTrademark policy if available, domain registrar, brand files, and agreementsTrademark permission, domain records, asset licenses, and contractNo complete public trademark policy was found in reviewed product sources.Confirm naming permission, domain control, social accounts, certificates, source artwork, transfer, and removal duties.Brand, procurement, security, and legal reviewersExplicit permission or documented replacement planQualified counsel must decide rights for an actual project.

Claim versus evidence

Phrase to testAdditional evidence required
MIT licensedExact artifact and version, controlling MIT text, included code boundaries, notices, modifications, and distribution context.
Open sourceExact artifact license and OSI status where relevant; separately licensed, third-party, asset, and service layers remain distinct.
Source includedComplete repository, history, build inputs, generated sources, credentials boundary, documentation, and contract rights to use and modify.
Self-hostedInfrastructure and data control, software and provider terms, support/update dependencies, backups, export, credentials, and exit test.
Full code ownershipCopyright or license evidence for every app artifact, commissioned-code terms, third-party schedule, notices, repository handover, and legal review.
No lock-inIndependent build and operation, source/history, data and attachment export, credentials, domain control, supplier revocation, replaceable dependencies, and funded maintenance.
No per-seat feeApplicable Core, Enterprise, provider, hosting, support, usage, and supplier contracts for the exact deployment and term.
Enterprise includedExact package version, separate license, applicable signed commercial scope, permitted environments, updates, termination, and post-contract use.

Procurement and exit checklist

  1. 1

    Is every licensed software layer and excluded layer named?

    Material stop condition
  2. 2

    Are exact package versions, resolved sources, and artifacts pinned?

    Material stop condition
  3. 3

    Has every manifest declaration been checked against its license file?

    Material stop condition
  4. 4

    Is the applicable Enterprise evaluation or commercial evidence on file?

    Material stop condition
  5. 5

    Does the agreement identify background code, commissioned code, modification, sublicensing, and post-contract use?

    Material stop condition
  6. 6

    Is every third-party package, provider, asset, version, license, and notice inventoried?

    Material stop condition
  7. 7

    Can the required copyright, permission, attribution, and notice bundle be reproduced?

    Material stop condition
  8. 8

    Does the buyer control a complete source repository and editable documentation repository?

  9. 9

    Are branches, tags, commit history, release artifacts, and authorship records delivered?

  10. 10

    Can an independent team reproduce the build from pinned inputs?

    Material stop condition
  11. 11

    Can an independent team run the application with documented environment requirements?

  12. 12

    Are CI, release, package registry, signing, and deployment definitions transferable?

  13. 13

    Are infrastructure definitions, images, supplier resources, and access owners inventoried?

  14. 14

    Has usable business-data export been tested with stable identifiers and documented formats?

    Material stop condition
  15. 15

    Has attachment export been reconciled to records and access controls?

  16. 16

    Are backup custody, restoration, retention, and deletion responsibilities proven?

  17. 17

    Can all supplier access be revoked and every secret, certificate, and key be rotated?

    Material stop condition
  18. 18

    Are domains, DNS, certificates, email, social, and brand accounts under transferable control?

  19. 19

    Are architecture decisions, operations, incidents, recovery, data, and security runbooks accepted?

  20. 20

    Are unit, integration, security, migration, performance, and acceptance tests delivered and runnable?

  21. 21

    Who receives, evaluates, and applies security advisories and fixes after handover?

  22. 22

    What update access, support coverage, expiration, and post-contract rights are evidenced?

  23. 23

    Do acceptance records list every repository, artifact, credential boundary, exception, and owner?

    Material stop condition
  24. 24

    Has an exit exercise proved rebuild, operation, export, revocation, supplier removal, and continuity?

    Material stop condition

Local evidence tool

Rights and handover evidence register

All 20 starter artifacts begin with missing evidence. The register can reach evidence complete for procurement review only when every row has a controlling document, source/version, notices, owners, disposition, and handover evidence.

Privacy: Entries remain in this browser and local exports. Do not enter contract text, source code, secrets, credentials, personal data, or confidential project details.

Register state

NOT READY

Open evidence gates: 380

All 20 starter artifacts begin with missing evidence. The register can reach evidence complete for procurement review only when every row has a controlling document, source/version, notices, owners, disposition, and handover evidence.
ArtifactSupplier or sourceRepository, package, and versionEvidence URL or pathDeclared license or contractLicense text reviewedRights and questionsRequired noticesSource and build accessUpdate and support dependencyData and secret relevanceTechnical roleProcurement roleLegal review roleMissing evidence or dispositionRequired actionHandover evidenceEvidence stateReview dateAcceptance note
Root and Core code
First-party public package set
Enterprise package and agreement
Official or ecosystem module
Third-party module or provider
Standalone application source
Commissioned custom module
App overrides and configuration code
Ejected module copy and later changes
Resolved transitive dependencies
Fonts, images, video, and content
Models, sample data, and generated assets
Infrastructure definitions and container images
CI, build, package registry, and release artifacts
Documentation, architecture records, and runbooks
Business data and identifier export
Attachments, backups, and restoration evidence
Secrets, certificates, domains, and supplier accounts
Support, security fixes, and future updates
Names, marks, domains, and brand source assets

Method, assumptions and limitations

Reviewed 14 July 2026. Product facts were checked against both the public code at the cited repository revision and official documentation. Where documentation and code differ, this guide describes behavior supported by code. Interpretations and recommendations concern implementation work, not product guarantees.

This material is not a quote, audit, certification, or legal, tax, or accounting advice. Edition, enabled modules, configuration, custom code, infrastructure, data, third-party providers, and operating practices affect the outcome.