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