Remove license restriction, reformat, rephrase

Also remove package.json

EIPS/eip-6956.md

@@ -13,15 +13,15 @@ requires: 165, 721
 
 ## Abstract
 
-This standard allows to integrate physical and digital ASSETS without signing capabilities into dApps/web3 by extending [ERC-721](eip-721.md).
+This standard allows integrating physical and digital ASSETS without signing capabilities into dApps/web3 by extending [ERC-721](eip-721.md).
 
 An ASSET, for example a physical object, is marked with a uniquely identifiable ANCHOR. The ANCHOR is bound in a secure and inseperable manner 1:1 to an NFT on-chain - over the complete life cylce of the ASSET. 
 
 Through an ATTESTATION, an ORACLE testifies that a particular ASSET associated with an ANCHOR has been CONTROLLED when defining the `to`-address for certain operations (mint, transfer, burn, approve, ...). The ORACLE signs the ATTESTATION off-chain. The operations are authorized through verifying on-chain that ATTESTATION has been signed by a trusted ORACLE. Note that authorization is solely provided through the ATTESTATION, or in other words, through PROOF-OF-CONTROL over the ASSET. The controller of the ASSET is guaranteed to be the controller of the Asset-Bound NFT.
 
 The proposed ATTESTATION-authorized operations such as `transferAnchor(attestation)` are permissionless, meaning neither the current owner (`from`-address) nor the receiver (`to`-address) need to sign. 
 
-Figure 1 shows the data flow of an ASSET-BOUND NFT transfer through a simplified example system employing the proposed standard. The system is utilizing a smartphone as user-device to interact with a physical ASSET and specify the `to`-address.
+Figure 1 shows the data flow of an ASSET-BOUND NFT transfer. The simplified system is utilizing a smartphone as user-device to interact with a physical ASSET and specify the `to`-address.
 
 ![Figure 1: Sample system](../assets/eip-6956/img/erc6956_concept.svg)
 
@@ -35,7 +35,7 @@ ERC-721 outlines that "NFTs can represent ownership over digital or physical ass
 
 However, we see integrity issues not solveable with ERC-721, primarily when NFTS are used to represent off-chain ASSETS ("ownership over physical products", "digital collectables", "in-game assets", "responsibilities", ...). Over an ASSET's lifecycle, the ASSET's ownership and posession state changes multiple, sometimes thousands, of times. Each of those state changes may result in shifting obligations and privileges for the involved parties. Therefore tokenization of an ASSET *without* enforcably anchoring the ASSET's associated obligation and properties to the token is not complete. Nowadays, off-chain ASSETs are often "anchored" through adding an ASSET-identifier to a NFT's metadata. 
 
-**NFT-ASSET integrity:** Contrary to common misconception from many NFT-investors, metadata is data that is firstly mutable and secondly off-chain. Therefore the link between an ASSET through an asset-identifier stored in mutable metadata, which is only linked to the NFT through tokenURI, can be considered weak at best.
+**NFT-ASSET integrity:** Contrary to a popular belief among NFT-investors, metadata is data that is, more often than not, mutable and off-chain. Therefore the link between an ASSET through an asset-identifier stored in mutable metadata, which is only linked to the NFT through tokenURI, can be considered weak at best.
 
 Approaches to ensure integrity between metadata (=reference to ASSET) and a token exist. This is most commonly achieved by storing metadata-hashes onchain. Additional problems arise through hashing; For many applications, metadata (besides the asset-identifier) should be update-able. Therefore making metadata immutable through storing a hash is problematic. Further the offchain metadata-resource specified via tokenURI must be made available until eternity, which has historically been subject to failure (IPFS bucket disappears, central tokenURI-provider has downtimes, ...)
 
@@ -75,7 +75,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 ### Definitions (alphabetical)
 
-- **ANCHOR** uniquely identifies the off-chain ASSET, being it physical or digital.
+- **ANCHOR** uniquely identifies the off-chain ASSET, whether it is physical or digital.
 - **ANCHOR-TECHNOLOGY** MUST ensure that
   - the ANCHOR is inseperable from the ASSET (physically or otherwise)
   - an ORACLE can establish PROOF-OF-CONTROL over the ASSET beyond reasonable doubt
@@ -439,11 +439,11 @@ interface IERC6956Floatable is IERC6956 {
 }
 ```
 
+
 #### Caveats for Floatable-Interface
 
 If `floating(anchor)` returns true, the token identified by `tokenByAnchor(anchor)` MUST be transferable without attestation, typically authorized via `ERC721.isApprovedOrOwner(msg.sender, tokenId)` 
 
-
 ### ValidAnchors-Interface
 
 Every contract compliant to this extension MAY implement the proposed [ValidAnchors interface](../assets/eip-6956/contracts/IERC6956ValidAnchors.sol) and is subject to [Caveats](#caveats-for-validanchors-interface) below:
@@ -536,7 +536,6 @@ The use case matrix below shows which extensions and settings must (additionally
 
 Note that for `Lockable` listed in the table below, the proposed EIP can be extended with any Lock- or Lien-Mechanism known to extend for ERC-721. Suitable extensions to achieve `Lockable` are for example [ERC-5058](eip-5058.md) or [ERC-5753](eip-5753.md). We recommend to verify whether a token is locked in the `_beforeTokenTransfer()`-hook, as this is called from `safeTransferFrom()` as well as `transferAnchor()`, hence suitable to block "standard" ERC-721 transfers as well as the proposed attestation-based transfers.
 
-
 | Use Case | approveAuthorization | burnAuthorization | `IERC6956Floatable` | `IERC6956AttestationLimited` | Lockable |
 |---------------|---|---|---|---|---|
 | **Managing Posession** |
@@ -551,17 +550,15 @@ Note that for `Lockable` listed in the table below, the proposed EIP can be exte
 | Buying a brand new car with downpayment | ASSET or OWNER_AND_ASSET | ANY | optional | optional | required |
 | Buying a barrel of oil by forward transaction | ASSET or OWNER_AND_ASSET | ANY | optional | optional | required |
 
-
 Legend:
 
 - required ... we don't see a way how to implement the use-case without it
 - incompatible ... this MUSTN'T be implemented, as it is a security risk for the use-case
 - optional ... this MAY optionally be implemented
 
-
 ## Backwards Compatibility
 
----- NEEDS FURTHER DISCUSSION ----
+<!-- NEEDS FURTHER DISCUSSION -->
 
 No backward compatibility issues found. 
 
@@ -574,25 +571,21 @@ Many ERC-721 extensions suggest to add additional throw-conditions to transfer m
 - The often-used ERC-721 `_beforeTokenTransfer()` hook must be called for all transfers including attestation-authorized transfers.
 - A `_beforeAnchorUse()` hook is suggested in the reference implementation, which only is called when using attestation as authorization.
 
-
-
 ## Test Cases
 
 Test cases are available:
 
 - For only implementing [the proposed standard interface](../assets/eip-6956/contracts/IERC6956.sol) can be found [here](../assets/eip-6956/test/ERC6956.ts)
-- For implementing [the proposed standard interface](../assets/eip-6956/contracts/IERC6956.sol), [the Floatable extension](../assets/eip-6956/contracts/IERC6956Floatable.sol) and [the AttestationLimited extension](../assets/eip-6956/contracts/IERC6956AttestationLimited.sol) can be found [here](../assets/eip-6956/test/ERC6956Full.ts)
+- For implementing [the proposed standard interface](../assets/eip-6956/contracts/IERC6956.sol), [the Floatable extension](../assets/eip-6956/contracts/IERC6956Floatable.sol), [the ValidAnchors extension](../assets/eip-6956/contracts/IERC6956ValidAnchors.sol) and [the AttestationLimited extension](../assets/eip-6956/contracts/IERC6956AttestationLimited.sol) can be found [here](../assets/eip-6956/test/ERC6956Full.ts)
 
 ## Reference Implementation
 
-The reference implementations are [MIT](../assets/eip-6956/LICENSE.md) licensed. They can be freely used with digital assets as defined in the present EIP. No general license is granted to the *commercial* use or application of the reference implementation or derived works with physical assets as defined in the present EIP. Visit metaanchor.io for further details. 
-
 - Minimal implementation, only supporting [the proposed standard interface](../assets/eip-6956/contracts/IERC6956.sol) can be found [here](../assets/eip-6956/contracts/ERC6956.sol)
-- Full implementation, support [the proposed standard interface](../assets/eip-6956/contracts/IERC6956.sol), [the Floatable extension](../assets/eip-6956/contracts/IERC6956Floatable.sol) and [the AttestationLimited extension](../assets/eip-6956/contracts/IERC6956AttestationLimited.sol) can be found [here](../assets/eip-6956/contracts/ERC6956Full.sol)
+- Full implementation, with support for [the proposed standard interface](../assets/eip-6956/contracts/IERC6956.sol), [the Floatable extension](../assets/eip-6956/contracts/IERC6956Floatable.sol), [the ValidAnchors extension](../assets/eip-6956/contracts/IERC6956ValidAnchors.sol) and [the AttestationLimited extension](../assets/eip-6956/contracts/IERC6956AttestationLimited.sol) can be found [here](../assets/eip-6956/contracts/ERC6956Full.sol)
 
 ## Security Considerations
 
---- NEEDS FURTHER DISCUSSION ---
+<!-- NEEDS FURTHER DISCUSSION -->
 
 **If the asset is stolen, does this mean the thief has control over the NFT?**
 Yes.The standard aims to anchor an NFT to the asset inseperably and unconditionally. This includes reflecting theft, as the ORACLE will testify that PROOF-OF-CONTROL over the ASSET is established. The ORACLE does not testify whether the controller is the legitimate owner,
@@ -614,9 +607,6 @@ For security- and gas-reasons. Except for limited collections, anchors will typi
 **Assume you have N anchors. If all anchored NFTs are minted, what use is a merkle-tree?**
 If all anchored NFTs are minted this implies that all anchors have been published and could be gathered on-chain. Consequently, the merkle-tree can be reconstructed. While this may not be an issue for many use cases (all supported anchors are minted anyway), we still recommend to add one "salt-leave" to the merkle-tree, characterized in that the ORACLE will never issue an attestation for an ANCHOR matching that salt-leave. Therefore, even if all N anchors are 
 
-
-
-
 ### Security Considerations for PHYSICAL ASSETS
 
 In case the ASSET is a physical object, good or property, the following ADDITIONAL specifications MUST be satisifed:
@@ -641,25 +631,18 @@ In case the ASSET is a physical object, good or property, the following ADDITION
 
 ### Security Considerations for DIGITAL ASSETS
 
---- NEEDS DISCUSSION ---
+<!-- NEEDS DISCUSSION -->
 
+<!--
 - TODO formal definition, shall extend to digital-only AND abstract assets (for example memberships)
 - Maybe use Physical and non-physical assets (to extend to abstract assets)?
 - Requirements on Oracles and Proof-of-Control for Digital ASSETs will not be defined in this EIP
-
-
-
-Needs discussion.
-
-Rough considerations and TODO
-
 - Valid anchors
   - Outline merkle-tree salt leaves
   - Why using merkle-trees and not simply store all available anchors on-chain (besides memory issues)
 - Maintainance-role over using ownership (Ownable is used by marketplaces to manage the collection)
+-->
 
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).
-
-The reference implementations are [MIT](../assets/eip-6956/LICENSE.md) licensed. They can be freely used with digital assets as defined in the present EIP. No general license is granted to the *commercial* use or application of the reference implementation or derived works with physical assets as defined in the present EIP. Visit metaanchor.io for further details.