Closed chaals closed 2 years ago
@chaals ... it is up to an implementation to ensure that. The facts and circumstances vary wildly. Hence, this is intentionally vague. Think of it as a compliance hook. The standard cannot opine on an implementation. One implementation option would be to instantiate the state object between two or more parties using a signed hash of the document with a resolvable URI to e.g. a PDF together with a zkp attesting to the correctness of the assertion. Or use a VC for that matter using the evidence property in the spec to link to a PDF of that contract ... see I gave you 2 very different options. See also the start of the implementation guide here with yet another example -- https://docs.google.com/document/d/1og-QseEO6B7w37h_Ik2P1pqKd8_dysRapU1PO8GeDB4/edit?usp=sharing ... hope that makes sense. I do not see this as a hold-up in any way.
All of these proposals merely assert that there is a contract. None of them demonstrate for any practical purpose that it is "legally binding".
Any contract is trivially "legally binding", by definition. But that only means that provisions it contains that are legal are subject to judgement by a court. Until a court decides that the terms of the contract are enforceable, that's nothing more than a written statement of claim.
Many contracts even have specific language anticipating that some part of them will be determined not to be legally enforceable, under some heading such as "separability". This habit reflects what happens to contracts in dispute.
@chaals ... only a contract signed by all required counterparties is legally binding, an unsigned contract is not. Hence, and to anticipate compliance requests, "legally binding" was added on purpose. Since building off this, as the genesis state so to speak,, commercially viable and audit-compliant workflows can be built.
@chaals ... per decision in the WG meeting, please, respond to the above response. Otherwise, the issue will be closed at the next WG meeting.
only a contract signed by all required counterparties is legally binding, an unsigned contract is not.
As a general statement, this is not true.
While jurisdictions vary, it is a widespread practice that a contract is essentially an agreement that provides for exchange of value under some set of terms. Verbal contracts are legally binding in the general case, and certain patterns of behaviour (e.g. going through an online process that sets up a request for something in exchange for an offer of payment) will often be considered as establishing a contract.
(Whereas certain things that people write in terms and conditions are regularly not binding in practice, because the governing law explicitly states that such terms are not legally binding).
In general, the requirement is a demonstration that the parties agreed on something. This is often established by showing that they respectively handed over, and accepted money. Disputes generally arise about precisely what was agreed, not whether there was a contract of some kind.
This requirement seems to duplicate R1 and extend it, but the insistence that the agreement be a "legally binding contract" doesn't add anything meaningful.
If the goal is to state that a Baseline Implementation needs to clearly present what is offered and accepted as a contract, I think there needs to be a more substantial rewrite to make that clear. In the meantime, it is not clear what value R2 adds, nor how to test whether an implementation conforms to the requirement.
There is no statutory definition of a legally binding document in common law systems such as the US or UK. In common law systems, verifiable, specific, criteria signifying offer, acceptance, and consideration can make a contract legally binding in a court of law. However, while it is true that it is for the courts in the jurisdiction of application to decide if a contract can be construed as legally binding or not, entering into a contract that the counterparties consider to be legally binding is a statement of intent requiring clear identification of rights and responsibilities of the transacting parties. The intent to make a contract legally binding as laid out in the standards can make it contingent upon the transacting parties to use the proper care to record offer, acceptance, and consideration. Given the diversity of business uses that will use the Baseline Protocol, the responsibility for a commercial contract that can be construed as legally binding by a court of law would have to fall on the transacting parties.
Therefore, R1 and R2, not only lay out a rigorous process of use of the baseline standards, they make the responsibilities of the transacting parties i.e. the implementation clear from the standpoint of the baseline protocol. However, it is correct to question the necessity of R2 given R1. It is also correct to state that the requirement of “legally binding” while vague is intentionally so to put the onus on the implementation by the transacting parties.
I suggest that we solve this by merging R1 and R2. Furthermore, we could retain reference to a commercial agreement while removing the reference to “legally binding” since a commercial agreement would be expected to be written in a manner that can be construed as legally binding by a court of law in the jurisdiction of choice.
Closing. Addressed with merged PR https://github.com/eea-oasis/baseline-standard/pull/173
R2 says that parties must have legally binding contracts.
It's not clear how to test whether the contract is legally binding, nor in what circumstances it needs to be binding.
If this requirement is necessary, there should at minimum be something about the contracts being relevant to the transactions being carried out through a BPI.
(Why doesn't a BPI offer and acceptance process establish a specific agreement "at run time"?)