Skip to Content
Last modified by Robert Schaub on 2025/12/18 12:03
Show last authors
1 = Open Source Model and Licensing =
2 == 1. Purpose and Relation to Other Documents ==
3 This page explains **how FactHarbor is run from a licensing and enforcement perspective** – as an open, trustworthy, non-profit oriented, but professionally maintained project.
4 It covers in particular:
5 * the **licensing choices** for code, documentation, data, and core specifications,
6 * how contributors grant the project the right to use and enforce those licenses,
7 * how AI-related components (such as AKEL) fit into the licensing picture,
8 * how licence choices support manipulation-resistance and long-term openness,
9 * **organisational transparency commitments**,
10 * **privacy and data protection standards**.
11 Together with the other Organisation pages, it defines **how FactHarbor is run**:
12 * [[Governance>>FactHarbor.Organisation.Governance.WebHome]] – who decides what, and under which principles
13 * [[Finance & Compliance>>FactHarbor.Organisation.Finance-Compliance]] – how funding, transparency, and internal controls work
14 * [[Legal Framework>>FactHarbor.Organisation.Legal-Framework]] – legal forms, contracts, and regulatory aspects
15 The **Specification** (Mission, Requirements, Architecture, Data Model, Workflows, etc.) describes **what FactHarbor does**.
16 This Open Source Model and Licensing page (together with Governance and Finance & Compliance) describes **how FactHarbor is run and protected**.
17 For historical context, earlier drafts used a purely AGPLv3-centric model for the core software.
18 The current licence mix is defined in the sections below and takes precedence over any older drafts.
19 == 2. Overview ==
20 FactHarbor is, and will remain, an **open source project** that:
21 * publishes its work openly whenever legally and ethically possible
22 * makes its reasoning and evidence inspectable
23 * invites contributions under clear, transparent rules
24 * avoids situations where a "FactHarbor-branded" system becomes a black box
25 * maintains exceptional organisational transparency to build trust
26 This page defines:
27 * the **licensing choices** currently used,
28 * the **goals and principles** behind these choices,
29 * how contributors are governed from a licensing/enforcement perspective,
30 * how AI models and third-party components are handled,
31 * the standards that repositories must follow,
32 * **organisational transparency and privacy commitments**.
33 Normative licensing decisions on this page **override** any older variants or drafts.
34 == 3. Licensing (Current Decisions) ==
35 === 3.1 Documentation ===
36 All general **documentation** (organisational and technical) is licensed under:
37 * **Creative Commons Attribution-ShareAlike 4.0 (CC BY-SA 4.0)**
38 This allows:
39 * reuse, adaptation, and translation of documentation,
40 * including commercial reuse,
41 * as long as:
42 * clear attribution to FactHarbor is preserved, and
43 * derivative works are shared under the **same license (CC BY-SA 4.0)**.
44 Exception handling:
45 * In rare cases, **security-sensitive or abuse-enabling documentation** may be:
46 * published only in partial form, or
47 * made available under more restrictive terms, or
48 * kept internal.
49 * Any such exceptions must be **explicitly documented** where they apply.
50 === 3.2 Core Protocol & Data Model ===
51 The **core protocol**, core **data model** (including key ERDs), and other "defining specifications" are licensed under:
52 * **Creative Commons Attribution-ShareAlike 4.0 (CC BY-SA 4.0)**
53 Intent:
54 * enable **collaborative evolution** of the protocol and data model,
55 * allow broad reuse, referencing, and implementation,
56 * ensure derivative specifications remain open (share-alike requirement),
57 * maintain canonical status through **trademark control** rather than license restrictions.
58 Implications:
59 * You may **use, implement, and modify** the protocol/data model in your own systems.
60 * You may **publish derivative or modified specifications** under CC BY-SA 4.0.
61 * Derivative specifications must:
62 * be clearly attributed to FactHarbor,
63 * use different branding/names (trademark protection),
64 * state they are "derived from FactHarbor protocol",
65 * remain under CC BY-SA 4.0 (share-alike).
66 * Changes to the **canonical FactHarbor specification** are governed through FactHarbor's internal review and release processes.
67 **Trademark Protection:**
68 The "FactHarbor" name and associated marks are protected separately from the license. Derivative protocols may not use "FactHarbor" branding without explicit permission, ensuring users can distinguish official from derivative implementations.
69 This approach (license for sharing + trademark for brand protection) follows successful models like Mozilla Firefox and the W3C.
70 === 3.3 Code ===
71 **Default License:** Unless explicitly stated otherwise, **code** produced under the FactHarbor project is licensed under:
72 * **MIT License**
73 This allows:
74 * broad reuse, including in commercial software,
75 * proprietary integrations and extensions,
76 * as long as:
77 * the MIT license text is included, and
78 * attribution to the FactHarbor project is preserved.
79 **Hybrid Licensing for Core Components:**
80 For the **core reasoning engine** and **AKEL components**, we recommend using **AGPL-3.0** to prevent black-box deployments and ensure transparency of modifications.
81 The recommended hybrid approach:
82 * **AGPL-3.0** for: Core verdict engine, AKEL reasoning logic, scenario evaluation engine
83 * **MIT** for: Integrations, utilities, frontend clients, libraries, tools
84 This hybrid model (similar to Wikimedia's use of AGPL for MediaWiki) balances maximum adoption with protection of the transparency mission.
85 **Rationale:**
86 * AGPL-3.0 is **network copyleft** – requires source disclosure for network services
87 * Prevents "FactHarbor-as-a-service" black boxes that contradict transparency mission
88 * MIT for peripheral components maximizes ecosystem growth
89 * Strong protection of **openness of reasoning** is handled via:
90 * open protocol and data model (CC BY-SA),
91 * open documentation (CC BY-SA),
92 * AGPL for core reasoning components,
93 * and explicit transparency rules.
94 The decision to implement this hybrid model should be made explicitly before the first public release.
95 === 3.4 Structured Data & Curation Artefacts ===
96 Structured data, curated knowledge artefacts and derived datasets are licensed under:
97 * **Open Database License (ODbL)**
98 **Note on ODbL:** The Open Database License includes a share-alike requirement, ensuring derivative databases remain open. This aligns with FactHarbor's commitment to openness and prevents proprietary capture of community-curated data.
99 Principles:
100 * data used for public reasoning should be:
101 * reusable and remixable,
102 * properly attributed,
103 * versioned and traceable,
104 * kept open through share-alike.
105 * privacy, safety, and legal constraints may require:
106 * partial publication or anonymity,
107 * stronger access control around certain datasets.
108 Concrete exceptions and more restrictive handling must be **documented at dataset level**.
109 === 3.5 Attribution Guidelines (Non-Mandatory but Recommended) ===
110 FactHarbor encourages, but generally does not require beyond the base licenses, that:
111 * user interfaces show a short line such as:
112 `Powered by FactHarbor (open documentation, open protocol, open data)`
113 Intent:
114 * strengthen **brand recognition** and trust,
115 * keep attribution light-weight and compatible with open licenses,
116 * avoid creating extra legal conditions beyond the existing licenses.
117 == 4. Licensing Goals and Principles ==
118 Earlier "Open Source Model & Licensing" drafts contained valuable reasoning about **why** strong open-source protections might be needed. The core goals remain relevant, even though the exact license mix has evolved.
119 FactHarbor's licensing aims to:
120 * **Protect openness of reasoning**
121 * Users must be able to understand how conclusions were reached.
122 * Code and documentation that materially affect user-visible behaviour should be inspectable or clearly described.
123 * **Discourage hostile or misleading forks**
124 * Avoid "closed clones" that keep the FactHarbor name or appearance while hiding important changes.
125 * Forks that significantly diverge should use their own branding and not pretend to be official FactHarbor instances.
126 * **Make modifications traceable**
127 * Substantial changes to code, specs, or governance documents should be documented and versioned.
128 * Users interacting with a service based on FactHarbor should be able to see **which version or fork** they are using.
129 * **Support long-term sustainability and legal clarity**
130 * Licenses and governance must be enforceable in practice.
131 * The organisation should have clear standing to protect the project if needed.
132 == 5. Contributors, Governance & CLA ==
133 === 5.1 Contributor Journey (from licensing perspective) ===
134 The contributor journey (Visitor → New Contributor → Contributor → Trusted Contributor → Contributor → Moderator → Trusted Contributor) is defined in more detail in the **Contributor Processes** and **Organisation** pages.
135 From a *licensing* perspective, the key points are:
136 * All contributions must be compatible with the chosen licenses (CC, MIT, AGPL, ODbL, etc.).
137 * Contributors confirm that they have the right to contribute the material under these licenses.
138 * Higher-trust roles (Trusted Contributors, Contributors, Moderators) help enforce licensing and attribution rules when reviewing changes.
139 For full role definitions, see the **Organisation / Contributor Processes** documentation.
140 === 5.2 Contributor License Agreement (CLA) ===
141 To keep the legal situation clear and enforceable, FactHarbor uses a **Contributor License Agreement (CLA)**.
142 See [[Contributor License Agreement>>FactHarbor.Organisation.CLA]].
143 ==== 5.2.1 Dual Contributor Model ====
144 FactHarbor distinguishes between two contributor types with different copyright arrangements:
145 **Unpaid Contributors (Volunteers)**:
146 * **Retain copyright** of their contributions
147 * Grant FactHarbor a perpetual, royalty-free license to use and distribute
148 * Enable the project to enforce licenses on their behalf
149 * Maintain attribution in version control and documentation
150 **Paid Contributors (Employees, Contractors)**:
151 * **Transfer copyright** to FactHarbor Organisation
152 * Ensures clear ownership for sponsored work
153 * Simplifies long-term governance
154 * Still receive attribution for their contributions
155 This dual model:
156 * Respects volunteer contributions while preserving their rights
157 * Provides clarity for commercially sponsored work
158 * Ensures FactHarbor can effectively maintain and defend the project
159 * Maintains transparency about contribution sources
160 ==== 5.2.2 Core Intent (All Contributors) ====
161 Regardless of contributor type, the CLA ensures:
162 * Contributors grant the **FactHarbor organisation**:
163 * a **perpetual, worldwide, irrevocable license** to use, modify, and redistribute their contributions under the project's chosen licenses (CC BY-SA, MIT, AGPL, ODbL, etc.), and
164 * the **express right to enforce** those licenses and **pursue legal action** against infringers on their behalf.
165 This ensures that:
166 * the organisation has **clear standing** to defend the project legally,
167 * individual contributors do not have to act alone against infringements,
168 * licensing remains enforceable even if contributors become inactive.
169 ==== 5.2.3 Determining Contributor Type ====
170 * **Default**: Contributors are considered unpaid volunteers unless they have a written agreement specifying paid status.
171 * **Paid Status Indicators**: Employment contract, written contracting agreement, or grant/sponsorship agreement.
172 * **Transparency**: Contributor type should be disclosed where applicable.
173 See [[Contributor License Agreement>>FactHarbor.Organisation.CLA]] for complete terms.
174 == 6. AI Models and Licensing (AKEL) ==
175 AKEL (AI Knowledge Extraction Layer) may rely on different types of models. Licensing and transparency rules are crucial here.
176 === 6.1 Open vs Proprietary Models ===
177 AKEL may use:
178 * **Open-source models (preferred)**:
179 * weights and code are openly available under compatible licenses,
180 * prompts, evaluation logic and integration code are made public where licenses permit.
181 * **Proprietary / hosted models (allowed but constrained)**:
182 * used only when necessary for quality or feasibility,
183 * must be clearly **disclosed to the user** at point of use,
184 * AKEL must label which parts of its output derive from proprietary tools,
185 * surrounding **integration logic remains open** (MIT/AGPL or compatible) and is documented.
186 Rules:
187 * No deployment may suggest "fully open" AI if proprietary models are used without disclosure.
188 * For high-impact reasoning (e.g. health, politics, safety-critical topics), **open, auditable models** are preferred wherever feasible.
189 * Where proprietary models are unavoidable, additional care is taken to:
190 * document limitations,
191 * avoid overstating certainty,
192 * and keep reasoning layers as transparent as possible.
193 === 6.2 Prompts, Pipelines and Integration Code ===
194 * Orchestration code, pipelines and evaluation logic around AKEL are treated as part of the **open FactHarbor codebase** (MIT or AGPL).
195 * Where prompts or model configurations are licensed in a way that restricts publication, this must be documented clearly, and safe abstractions should be used in public documentation.
196 === 6.3 AI Prompts and Orchestration ===
197 * Prompts, system instructions, and orchestration code are considered **Code** and licensed under **MIT** or **AGPL** (depending on component).
198 * They must be visible in the repository to ensure the system is not a 'black box'.
199 * If a proprietary model requires a prompt that cannot be shared (e.g. contractual restriction), that component cannot be part of the open core.
200 == 7. Third-Party Libraries and Components ==
201 FactHarbor depends on third-party libraries under:
202 * permissive licenses (MIT, Apache-2.0, BSD), and/or
203 * other compatible open-source licenses.
204 Requirements:
205 * All dependencies must be **license-compatible** with:
206 * the MIT/AGPL-licensed code,
207 * and the overall FactHarbor licensing strategy.
208 * License information is documented in:
209 * `/LICENSE` and, where applicable, `/NOTICE`,
210 * and a dedicated "Third-Party Licenses" section in project documentation.
211 FactHarbor actively avoids dependencies that:
212 * restrict redistribution in ways incompatible with open-source norms,
213 * prevent network users from accessing the relevant source,
214 * or conflict with the project's transparency and licensing goals.
215 == 8. Repository Standards ==
216 Each official FactHarbor repository must follow a minimum standard.
217 === 8.1 Required Files ===
218 Each repository should contain at least:
219 * `README` – purpose, scope, status, and how to use it.
220 * `LICENSE` – the applicable license(s) for the repository.
221 * `CONTRIBUTING` – how to propose changes; coding/writing guidelines.
222 * `CODEOWNERS` – who is responsible for which parts.
223 * `CHANGELOG` – human-readable log of important changes.
224 * `SECURITY` (or `SECURITY.md`) – how to report vulnerabilities and how they are handled.
225 === 8.2 Prohibited Content ===
226 FactHarbor repositories must **not** contain:
227 * purely ideological advocacy texts unrelated to the project's purpose,
228 * opaque binaries or artefacts that cannot reasonably be inspected or reproduced,
229 * embedded secrets (API keys, passwords, private tokens),
230 * content that materially contradicts the stated licenses or governance rules.
231 == 9. Historical Licensing Option: AGPLv3 for Core Engine (Non-Normative Background) ==
232 Earlier versions of this page explored a **strong copyleft** option for the core software based on **GNU Affero General Public License v3 (AGPLv3)**.
233 Those drafts argued that:
234 * AGPLv3, as a **network-copyleft license**, would:
235 * require modified network services to publish their source to users,
236 * prevent closed forks of the core reasoning engine,
237 * ensure that any public "FactHarbor-like" service stays inspectable.
238 They also defined:
239 * the scope of AGPLv3 coverage (backend services, AKEL logic, frontend),
240 * expectations for forks (must remain AGPLv3, must declare they are forks),
241 * and the same CLA principles now adapted to the current license mix.
242 These AGPLv3 considerations have been **partially adopted** in the hybrid licensing model (section 3.3), where AGPL-3.0 is recommended for core reasoning components.
243 They are preserved here as **design background** and may be revisited for specific components or future arrangements.
244 == 10. Organisational Transparency ==
245 FactHarbor is committed to exceptional transparency in all aspects of its operations, governance, and finances. This commitment is essential to build trust in a system claiming to support well-grounded judgments.
246 === 10.1 Financial Transparency ===
247 We commit to publishing annually:
248 * Complete financial statements (audited where possible)
249 * Swiss tax filings (annual statements per Swiss law)
250 * Income sources in aggregate (grants, donations, sponsorships)
251 * Expense breakdown by category
252 * Compensation ranges for staff roles (not individual salaries)
253 * Major funding relationships and partnerships
254 === 10.2 Governance Transparency ===
255 We commit to publishing:
256 * All governance documents (bylaws, policies, procedures)
257 * Governing Team composition and meeting schedules
258 * Governing Team meeting minutes (with narrow exceptions for privacy, security, or legal matters)
259 * Policy changes with rationale and effective dates
260 * Decision-making process documentation
261 * Conflict of interest policies and disclosures
262 === 10.3 Operational Transparency ===
263 We commit to publishing:
264 * Transparency reports (published twice yearly)
265 * Content moderation statistics and practices
266 * AKEL performance metrics and audit results
267 * Risk tier assignment statistics
268 * Partnership agreements and funding relationships
269 * Incident reports (security, moderation, governance)
270 * System uptime and performance data
271 === 10.4 Privacy Protection ===
272 While maintaining organisational transparency, we protect:
273 * Individual user privacy and personal data
274 * Security vulnerabilities (until patched, typically 30-90 days)
275 * Personnel matters and personal information
276 * Ongoing legal matters (until resolved)
277 * Whistleblower and abuse reports
278 * Authentication credentials and sensitive operational details
279 === 10.5 Review and Oversight ===
280 * Annual review of all information marked "private"
281 * Public reporting on transparency compliance
282 * Community input opportunities on transparency policies
283 * Appeals process for information requests
284 * Independent transparency audits (when feasible)
285 See [[Transparency Policy>>FactHarbor.Organisation.How-We-Work-Together.Transparency-Policy]] for complete details.
286 == 11. Privacy and Data Protection ==
287 FactHarbor is committed to protecting user privacy while maintaining transparency in operations and governance.
288 === 11.1 Data Collection Principles ===
289 * **Data minimization**: Collect only what is necessary for functionality
290 * **Purpose limitation**: Use data only for stated purposes
291 * **Short retention**: Delete data when no longer needed
292 * **User control**: Provide access, correction, and deletion rights
293 === 11.2 User Rights ===
294 Users have the right to:
295 * Access their personal data
296 * Correct inaccurate information
297 * Delete their accounts and associated data
298 * Export their data (portability)
299 * Object to certain processing
300 * Lodge complaints with supervisory authorities
301 === 11.3 What We Collect ===
302 For specific details on data collection practices, retention periods, and processing purposes, see [[Privacy Policy>>FactHarbor.Organisation.How-We-Work-Together.Privacy-Policy]].
303 In general:
304 * **Public contributions**: Permanently public and attributed (essential for transparency)
305 * **Account information**: Email, username (minimal required data)
306 * **Technical data**: IP addresses, user agents (short retention, logged out users)
307 * **Usage data**: Aggregated, anonymized analytics
308 === 11.4 What We Never Do ===
309 * Sell or rent user data
310 * Share personal data with third parties for marketing
311 * Track users across unrelated sites
312 * Use personal data for purposes beyond stated scope
313 * Keep personal data longer than necessary
314 === 11.5 Security Measures ===
315 * Encryption in transit (TLS/HTTPS)
316 * Encryption at rest for sensitive data
317 * Access controls and authentication
318 * Regular security audits
319 * Incident response procedures
320 * Vulnerability disclosure program
321 * **Data Protection Impact Assessments (DPIA)** for high-risk processing (required by FADP Article 22)
322 See [[Privacy Policy>>FactHarbor.Organisation.How-We-Work-Together.Privacy-Policy]] for complete details.
323 === 11.6 Data Protection Officer (DPO) ===
324 **If we serve users in the European Union**, we will appoint a Data Protection Officer (DPO) as required by EU GDPR Article 37.
325 The DPO will:
326 * Advise on data protection compliance
327 * Monitor FADP and GDPR compliance
328 * Serve as contact point for Swiss FDPIC and EU data protection authorities
329 * Conduct privacy audits and DPIAs
330 * Handle data subject requests
331 Contact (if appointed): [DPO contact to be established if needed]
332 **Note:** Swiss law (FADP) does not require a DPO for organizations of our size. However, EU GDPR Article 37 requires a DPO for:
333 * Large-scale systematic monitoring of data subjects
334 * Large-scale processing of sensitive personal data (including political opinions, health information)
335 Given that FactHarbor processes claims containing political opinions and uses AI for systematic evaluation, we commit to appointing a DPO if we process personal data of EU residents.
336 == 12. Exceptions and Appeals ==
337 === 12.1 Requesting Information ===
338 If you believe FactHarbor should disclose specific organisational information:
339 1. Submit a written request to [Transparency contact to be established]
340 2. Specify the information requested and rationale
341 3. Expect initial response promptly
342 === 12.2 Appeals Process ===
343 If a transparency request is denied:
344 1. Appeal to the Transparency Committee (if established)
345 2. Provide additional context or rationale
346 3. Expect appeal decision promptly
347 4. Final appeals may be escalated to the Governing Team
348 === 12.3 Exception Criteria ===
349 Information may be withheld only if disclosure would:
350 * Violate individual privacy rights
351 * Compromise security (vulnerability, credential)
352 * Violate legal obligations (court order, attorney-client privilege)
353 * Enable abuse or harm (expose victim, enable attack)
354 * Breach fiduciary duty (ongoing confidential negotiations)
355 All exceptions are time-limited and reviewed annually.