├── .prettierrc.json ├── LICENSE └── README.md /.prettierrc.json: -------------------------------------------------------------------------------- 1 | { 2 | "bracketSameLine": false, 3 | "singleAttributePerLine": true, 4 | "singleQuote": true, 5 | "tabWidth": 4, 6 | "trailingComma": "none" 7 | } 8 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2024 Demergent Labs LLC 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Open Value Sharing (OVS) 2 | 3 | Version: 0.0.0 4 | 5 | Open Value Sharing (OVS) is an open protocol for automatically sharing monetary value with software dependencies. 6 | 7 | OVS enables consumers of software dependencies to automatically pay for their use while minimizing or eliminating the friction involved. Though not restricted to open source software dependencies, one main goal of OVS is to enable a new open source native business model, facilitating automatic revenue streams to open source projects without requiring changes to their licenses. 8 | 9 | OVS embraces a number of core ideals: 10 | 11 | 1. Minimize or eliminate consumer (payer) friction 12 | 2. No changes required to existing dependency licenses 13 | 3. Voluntary participation from consumers and dependencies 14 | 4. Flexibility across platforms, payment mechanisms, sharing heuristics, and other parameters 15 | 5. Heuristics over perfection 16 | 17 | ## Definitions 18 | 19 | ### Consumer 20 | 21 | A software project with software dependencies. The consumer will be using and making payments to its dependencies. 22 | 23 | ### Dependency 24 | 25 | A software project that is used by a consumer. Dependencies are generally installed and incorporated into consumers using tools such as [npm](https://www.npmjs.com/), [PyPI](https://pypi.org/), or [crates.io](https://crates.io/). 26 | 27 | ### Platform 28 | 29 | The infrastructure or environment that hosts or executes the consumers and their dependencies. Platforms generally foster ecosystems or communities such as [Linux](https://en.wikipedia.org/wiki/Linux), [Android](), [Bitcoin](https://bitcoin.org/bitcoin.pdf), [Ethereum](https://ethereum.org/en/), [Solana](https://solana.com/), [ICP](https://internetcomputer.org/), [AO](https://ao.arweave.dev/), [AWS](https://aws.amazon.com/), [Azure](https://azure.microsoft.com/en-us), or [Vercel](https://vercel.com/). 30 | 31 | ### Asset 32 | 33 | The currency or medium of exchange that a consumer will use to pay a dependency. Most likely to be a cryptocurrency, fiat currency, or similar medium of exchange. Examples are [USD](https://en.wikipedia.org/wiki/United_States_dollar), [EUR](https://en.wikipedia.org/wiki/Euro), [USDC](https://www.circle.com/en/usdc), [USDT](https://tether.to/en/), [BTC](https://en.wikipedia.org/wiki/Bitcoin), [ETH](https://en.wikipedia.org/wiki/Ethereum), or [cycles](https://internetcomputer.org/docs/current/concepts/tokens-cycles#cycles). 34 | 35 | ### Payment Mechanism 36 | 37 | The actual mechanism used to facilitate the payment of an asset from a consumer to a dependency for a specific platform. Examples are [ACH](https://www.fiscal.treasury.gov/ach), [wire transfer](https://en.wikipedia.org/wiki/Wire_transfer), [ERC20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/), [SPL](https://spl.solana.com/token), or [cycles ledger](https://internetcomputer.org/docs/current/developer-docs/defi/cycles/cycles-ledger). 38 | 39 | ### Payment 40 | 41 | The transfer of an asset from the consumer to one of its dependencies. 42 | 43 | ### Batch 44 | 45 | A group of executed payments. 46 | 47 | ### Period 48 | 49 | The interval of time between batches. 50 | 51 | ### Sharing Heuristic 52 | 53 | A practical approach for determining and executing payments. For example, Burned Weighted Halving is the heuristic influencing this specification. It is explained below. Implementations may choose other heuristics which are not specified here. 54 | 55 | ### Burned Weighted Halving 56 | 57 | This heuristic is designed for the [ICP](https://internetcomputer.org/) platform and the [cycles](https://internetcomputer.org/docs/current/concepts/tokens-cycles#cycles) asset. It greatly influences this specification, and its basic concepts are expected to influence the default heuristic for most platforms. 58 | 59 | Burned Weighted Halving is a resource usage-based sharing heuristic. It attempts to measure resource usage at a high level rather than at the level of an individual dependency. That measurement combined with dependency weights and depths in the dependency tree are used to attempt to fairly compensate dependencies. 60 | 61 | The total payment amount to be divided between dependencies during a batch is determined by the amount of cycles burned between periods multiplied by the shared percentage. This amount is cut in half and assigned to the first level of the dependency tree. All dependencies at the first level share this half of the total payment amount. This amount is divided between dependencies at the first level based on their weight. The weight defaults to 1 but can be overriden individually by the consumer. 62 | 63 | The next level in the dependency tree shares half of the remaining half not assigned to the first level. This repeats until the final level. The final two levels receive the same amount to be shared between their dependencies. 64 | 65 | ### Shared Percentage 66 | 67 | If utilizing a resource usage-based sharing heuristic, this is the percentage of resource usage between periods used to determine the total payment amount to be divided between dependencies in a batch. For example in Burned Weighted Halving, this percentage is applied to the total number of cycles burned between periods. 68 | 69 | ### Dependency Tree 70 | 71 | The relationships between dependencies and their consumer can be modeled as a tree. The consumer is at the base of the tree. It will depend on a number of dependencies directly, which we will collectively call level or depth 0. The dependencies of those dependencies (transitive dependencies) create another level in the tree which we will call level 1. The dependencies of level 1 would create another level which we will call level 2. And the pattern repeats until there are no more dependencies. 72 | 73 | ### Depth 74 | 75 | The level at which a dependency is located in the dependency tree. 76 | 77 | ### Weight 78 | 79 | A number representing the proportion of the total payment assigned to a level for a batch that a dependency should receive relative to its siblings at the same level. 80 | 81 | ## Implementation 82 | 83 | The implementation is executed by the consumer. Dependencies must define a configuration available to the implementation. The implementation processes the dependency tree, gathering all dependency configuration information. This information is combined with sensible defaults or a consumer configuration to produce a final list of dependencies with dependency tree depth and weight information. This information is used to initiate a periodic payment process. The consumer must not be required to do anything for a default implementation to work. Dependencies must define configurations. 84 | 85 | This specification uses [WIT](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md) for type definitions. 86 | 87 | ### Dependency Configuration 88 | 89 | Dependencies must provide all of the necessary information to their consumer's implementation for proper payments to be made. Dependencies should define one or more of the following collections of properties in a configuration format and location that the consumer's implementation can automatically access. For example, dependencies may elect to store the information specified above in the JSON format in a file called `.openvaluesharing.json`. This file could be in the root directory of the project, and if downloaded by the consumer (as is the case with `npm` packages), it would be automatically available for processing. 90 | 91 | Dependency configuration data structures: 92 | 93 | ``` 94 | type custom_value = variant { 95 | number(u32), 96 | text(string) 97 | } 98 | 99 | type custom_item = record { 100 | key: string, 101 | value: custom_value 102 | } 103 | 104 | type dependency = record { 105 | platform: string, 106 | asset: string, 107 | payment_mechanism: string, 108 | custom: list 109 | } 110 | ``` 111 | 112 | ### Consumer Configuration 113 | 114 | Implementations must utilize sensible defaults and not require consumers to do anything for a default implementation to work. To do otherwise would violate ideal 1. Consumers must be able to override the sensible defaults. 115 | 116 | If necessary, a consumer configuration format and location should be specified to allow the consumer to override the following properties: 117 | 118 | ``` 119 | type weight = record { 120 | name: string, 121 | weight: u32 122 | } 123 | 124 | type consumer = record { 125 | kill_switch: bool, 126 | platforms: list, 127 | assets: list, 128 | shared_percentage: f32, 129 | period: u64, 130 | sharing_heuristic: string, 131 | weights: list 132 | } 133 | ``` 134 | 135 | The `kill_switch` turns OVS on or off and is required to comply with ideal 3. Most of the remaining properties should be self-explanatory. `weights` allows the consumer to control payment amounts for individual dependencies, including turning payments off with a weight of 0. 136 | 137 | ### Periodic Payment Processing 138 | 139 | The implementation must use the consumer configuration and dependency configurations to implement periodic payment processing. Every period payments should be made following the sharing heuristic. Payments should be peer-to-peer and logging/statistics may be implemented by consumers and dependencies. 140 | 141 | ## ICP Implementation 142 | 143 | The first MVP implementation of OVS is live on [ICP](https://internetcomputer.org/) in the [Azle project](https://github.com/demergent-labs/azle). Demergent Labs, the author of the initial draft of this specification, also authored the Azle project and its OVS implementation. 144 | 145 | - [Azle's implementation of consumer and dependency config processing](https://github.com/demergent-labs/azle/blob/main/src/compiler/get_consumer_config.ts) 146 | - [Azle's implementation of periodic payment processing](https://github.com/demergent-labs/azle/tree/main/src/compiler/rust/open_value_sharing) 147 | 148 | ## Economic Concerns 149 | 150 | Some have brought up the concern that consumers will decide to turn off OVS. Others fear that consumers will fork dependencies with OVS enabled. 151 | 152 | To the first concern, ideal 3 does allow for consumers to choose to turn off OVS. The rebuttal is that there is a cost to turning off OVS, and it may be higher than the cost of leaving it on. Leaving it on costs money. Turning it off costs mental effort, team time, and the conscious decision to not give back to open source. There could also be public pressures that arise incentivizing companies to continue to give back, especially if it was the default setting and a conscious decision to not give back. 153 | 154 | To the second concern, the rebuttal is that the consumer configuration allows consumers to turn off payments entirely or for individual dependencies. It seems illogical then for a consumer to go through the effort to fork projects to get around OVS when it is much simpler and easier to just turn it off. 155 | 156 | ## Prior Art 157 | 158 | - [npm Supporting Open Source Maintainers](https://blog.npmjs.org/post/187382017885/supporting-open-source-maintainers.html) 159 | - [Brave Rewards](https://brave.com/brave-rewards/) 160 | - [Sustainus](https://github.com/lastmjs/sustainus) 161 | - [Podcrypt](https://medium.com/hackernoon/podcrypt-automatic-fair-peer-to-peer-podcast-donations-with-ether-f0a638111410) 162 | 163 | ## License 164 | 165 | MIT License 166 | 167 | Copyright (c) 2024 Demergent Labs LLC 168 | 169 | Permission is hereby granted, free of charge, to any person obtaining a copy 170 | of this software and associated documentation files (the "Software"), to deal 171 | in the Software without restriction, including without limitation the rights 172 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 173 | copies of the Software, and to permit persons to whom the Software is 174 | furnished to do so, subject to the following conditions: 175 | 176 | The above copyright notice and this permission notice shall be included in all 177 | copies or substantial portions of the Software. 178 | 179 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 180 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 181 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 182 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 183 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 184 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 185 | SOFTWARE. 186 | --------------------------------------------------------------------------------