Tags

Ecosystem Need

Rapid advances in AI (especially LLMs and coding copilots) pose growing risks to Open Source attributions and value capture. This exploration is intended to be one of various responses to help ecosystems adapt to these shifts and to lay the groundwork for programmatic, protocol-native value flows on the Ethereum network. Decentralized trust systems introduce a new design space: economic arrangements where rules, interfaces, and commitments can be made durable, transparent, and non-discretionary, allowing participants to build with confidence. This initial exploration aims at consolidating and verifying the potential use of revenue-sharing clauses in new licenses which aim to be compatible with existing ones.

Hard Requirements

Proposals must adhere to this template: https://notes.ethereum.org/@s_VsCoN-RHCQdMf6bFLJ8g/H1Tsh8sSWx Proposals Requirements: 1. All applicants must be actively enrolled in a PhD Program from a university or academic institute. 2. Must propose work that directly advances the RFP goal: legal/academic exploration of a minimal revenue-sharing (“profit-left”) clause and its compatibility with widely used OSS licenses (at minimum: MIT, Apache-2.0, GPL). 3. Address at least these three questions: a) Compatibility: under what conditions (if any) can a revenue-sharing clause be compatible with existing OSS licenses? b) Open Source definition impact: what is the effect on the “four freedoms” / Open Source norms, and how would it be classified? c) Building on past and current work on this matter, evaluate how a “profit-left” requirement can be implemented most effectively: (1) as a license condition, (2) as a separate contract, or (3) as a hybrid. If appropriate, evaluate based on the current work of the Prosperous Software movement and the Post-Open-License proposals. Compare legal enforceability and remedies, downstream binding/privity, license compatibility and adoption friction, and practical compliance/ administration tradeoffs. Conclude with a recommendation and the contexts where each approach is preferable. 4. Include a research design: methodology, work plan, milestones, and deliverables. 5. Specify what will be analyzed (e.g., license text analysis, compatibility matrices, case studies, comparative legal analysis across jurisdictions). 6. Include an explicit timeline and resourcing plan. 7. Research output must be open-access with a free and permissive license. 8. Include, at minimum: a) A written report summarizing findings and recommendations. b) A license compatibility assessment for the targeted licenses. c) Draft clause language (or multiple variants) plus commentary on tradeoffs.

Soft Requirements

Preference will be given to proposals that: 1. Ground claims in primary sources; 2. State assumptions, uncertainties, and jurisdictional boundaries rather than implying universality. 3. Name contributors with relevant background (OSS licensing, legal scholarship, policy, or comparable). 4. Include an “Ethereum/public goods relevance” section that explains how outcomes inform licensing choices for public goods teams, and how the work relates to the idea of programmatic, protocol-native value flows (even if only conceptually at this stage).

Resources

Timeline