The UUIDs of library artifacts (25.abcd..., 1.efgh...) identify objects inside a Process Center repository; they are generated randomly (type-4 UUIDs) when an artifact is created and preserved by export / import. They can serve as evidence of origin but not as a legal copyright mechanism:
- Copyright exists automatically in the work (the models, scripts, coach views); the UUIDs help to prove that a toolkit found elsewhere came from yours - identical ids across repositories cannot arise by chance. Keep a signed inventory of the ids of each released snapshot (the twx package.xml lists them) with a timestamp; that supports a claim.
- They are not protection: anyone can copy the artifacts to a new project (Copy Items to) which assigns new ids, or edit a twx. Marking your work is stronger than relying on ids: put a license text into the toolkit's documentation, a copyright header in every JavaScript / Java file, your company name in the toolkit description and in the managed asset names, and version the toolkit visibly.
- Contractual protection is what actually works: license terms in the delivery contract, the toolkit delivered as a snapshot only (no tip, harder to modify casually), and, for products, an installation-package-only delivery (the .zip installation package cannot be opened in the designer).
# fingerprint of a released toolkit for your records
unzip -p MyToolkit-2.1.twx META-INF/package.xml | grep -o 'id="[0-9]*\.[0-9a-f-]*"' | sort | sha256sum
In short: UUIDs are a good fingerprint for disputes, a bad lock; use license text, visible attribution, snapshot-only delivery and contracts for protection.
References