Fossil SCM
Re-cast the "BSD vs GPL" section as "Accepting Contributions." In the end, that's what the difference in license amounts to. This makes the section longer, but the change includes a link to skip past the actual licensing discussion for those who don't want to read our attempt at an unbiased discussion of GPL vs BSD, since even if we've succeded, we won't always agree with the user's biases!
Commit
75e93e35b104ca81b4c45d0687964b196ff22131df6dda6ba547689ed6fc50a3
Parent
fcdefd97a74ebb7…
1 file changed
+22
-9
+22
-9
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -34,12 +34,12 @@ | ||
| 34 | 34 | <tr><td>Ad-hoc pile-of-files key/value database</td> |
| 35 | 35 | <td>Relational SQL database</td></tr> |
| 36 | 36 | <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> |
| 37 | 37 | <tr><td>Designed for Linux kernel development</td> |
| 38 | 38 | <td>Designed for SQLite development</td></tr> |
| 39 | -<tr><td>GPLv2</td> | |
| 40 | - <td>2-clause BSD + CLA</td></tr> | |
| 39 | +<tr><td>Many contributors</td> | |
| 40 | + <td>Select contributors</td></tr> | |
| 41 | 41 | <tr><td>Focus on individual branches</td> |
| 42 | 42 | <td>Focus on the entire tree of changes</td></tr> |
| 43 | 43 | <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> |
| 44 | 44 | <tr><td>One check-out per repository</td> |
| 45 | 45 | <td>Many check-outs per repository</td></tr> |
| @@ -263,21 +263,21 @@ | ||
| 263 | 263 | [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact |
| 264 | 264 | wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is |
| 265 | 265 | not the best way to hang a picture on the living room wall. |
| 266 | 266 | |
| 267 | 267 | |
| 268 | -<h4 id="license">2.3.3 License</h4> | |
| 268 | +<h4 id="license">2.3.3 Accepting Contributions</h4> | |
| 269 | 269 | |
| 270 | 270 | Git is covered by |
| 271 | 271 | [https://en.wikipedia.org/wiki/GNU_General_Public_License#Version_2|the |
| 272 | 272 | GPLv2]. Fossil is covered by |
| 273 | 273 | [https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD |
| 274 | 274 | style license]. Neither license affects the managed repository contents, |
| 275 | 275 | and it is not our purpose here to try to persuade you to make the same |
| 276 | -choice of license that we did. However, we do believe the choice of | |
| 277 | -license affects the way each tool was developed, which may affect your | |
| 278 | -choice of which one to use. | |
| 276 | +choice of license that we did, but we believe the choice of license has | |
| 277 | +an effect on the actual use of each DVCS. If you don't want to read | |
| 278 | +about licensing, you can skip to [#whylicmat|our point at the end]. | |
| 279 | 279 | |
| 280 | 280 | The GPL allows a project to do without a |
| 281 | 281 | [https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor |
| 282 | 282 | license agreement] (CLA) because by the very act of distributing |
| 283 | 283 | binaries produced from GPL'd source code, you are bound by the license |
| @@ -303,15 +303,28 @@ | ||
| 303 | 303 | [http://fossil-scm.org/home/doc/trunk/www/contribute.wiki|The Fossil |
| 304 | 304 | project's contribution process] requires active steps and processing |
| 305 | 305 | time: the printing, signing, mailing, reception, and processing of the |
| 306 | 306 | CLA. |
| 307 | 307 | |
| 308 | -We think there's an upside to this difference, in Fossil's favor: it | |
| 308 | +<a name="whylicmat"></a> | |
| 309 | +We think there's an upside to this difference in licensing, in Fossil's favor: it | |
| 309 | 310 | improves contributor community cohesion, because everyone who pushed |
| 310 | 311 | past that legal friction made an affirmative, active step to get commit |
| 311 | -capability on the Fossil project repository. We think it makes for a | |
| 312 | -better, more carefully-designed, simpler DVCS. | |
| 312 | +capability on the Fossil project repository. We believe discouraging | |
| 313 | +[https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by | |
| 314 | +contributions] makes for a better, more carefully-designed, simpler | |
| 315 | +DVCS. | |
| 316 | + | |
| 317 | +It's so easy to add features to Git that its command interface has | |
| 318 | +become truly arcane. Masters of the arcane are able to do wizardly | |
| 319 | +things, but only by studying their art deeply for years. This does not | |
| 320 | +strike us as a good use of the user's time. We believe it's better to | |
| 321 | +have a simpler tool with a more easily internalized behavior set, which | |
| 322 | +you can use quickly then set aside in order to get back to your main | |
| 323 | +task of producing the content that you manage in the DVCS. We achieve | |
| 324 | +that by carefully choosing which users to give commit bits to, and which | |
| 325 | +of their feature branches get merged down to trunk. | |
| 313 | 326 | |
| 314 | 327 | |
| 315 | 328 | <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> |
| 316 | 329 | |
| 317 | 330 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 318 | 331 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -34,12 +34,12 @@ | |
| 34 | <tr><td>Ad-hoc pile-of-files key/value database</td> |
| 35 | <td>Relational SQL database</td></tr> |
| 36 | <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> |
| 37 | <tr><td>Designed for Linux kernel development</td> |
| 38 | <td>Designed for SQLite development</td></tr> |
| 39 | <tr><td>GPLv2</td> |
| 40 | <td>2-clause BSD + CLA</td></tr> |
| 41 | <tr><td>Focus on individual branches</td> |
| 42 | <td>Focus on the entire tree of changes</td></tr> |
| 43 | <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> |
| 44 | <tr><td>One check-out per repository</td> |
| 45 | <td>Many check-outs per repository</td></tr> |
| @@ -263,21 +263,21 @@ | |
| 263 | [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact |
| 264 | wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is |
| 265 | not the best way to hang a picture on the living room wall. |
| 266 | |
| 267 | |
| 268 | <h4 id="license">2.3.3 License</h4> |
| 269 | |
| 270 | Git is covered by |
| 271 | [https://en.wikipedia.org/wiki/GNU_General_Public_License#Version_2|the |
| 272 | GPLv2]. Fossil is covered by |
| 273 | [https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD |
| 274 | style license]. Neither license affects the managed repository contents, |
| 275 | and it is not our purpose here to try to persuade you to make the same |
| 276 | choice of license that we did. However, we do believe the choice of |
| 277 | license affects the way each tool was developed, which may affect your |
| 278 | choice of which one to use. |
| 279 | |
| 280 | The GPL allows a project to do without a |
| 281 | [https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor |
| 282 | license agreement] (CLA) because by the very act of distributing |
| 283 | binaries produced from GPL'd source code, you are bound by the license |
| @@ -303,15 +303,28 @@ | |
| 303 | [http://fossil-scm.org/home/doc/trunk/www/contribute.wiki|The Fossil |
| 304 | project's contribution process] requires active steps and processing |
| 305 | time: the printing, signing, mailing, reception, and processing of the |
| 306 | CLA. |
| 307 | |
| 308 | We think there's an upside to this difference, in Fossil's favor: it |
| 309 | improves contributor community cohesion, because everyone who pushed |
| 310 | past that legal friction made an affirmative, active step to get commit |
| 311 | capability on the Fossil project repository. We think it makes for a |
| 312 | better, more carefully-designed, simpler DVCS. |
| 313 | |
| 314 | |
| 315 | <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> |
| 316 | |
| 317 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 318 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -34,12 +34,12 @@ | |
| 34 | <tr><td>Ad-hoc pile-of-files key/value database</td> |
| 35 | <td>Relational SQL database</td></tr> |
| 36 | <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> |
| 37 | <tr><td>Designed for Linux kernel development</td> |
| 38 | <td>Designed for SQLite development</td></tr> |
| 39 | <tr><td>Many contributors</td> |
| 40 | <td>Select contributors</td></tr> |
| 41 | <tr><td>Focus on individual branches</td> |
| 42 | <td>Focus on the entire tree of changes</td></tr> |
| 43 | <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> |
| 44 | <tr><td>One check-out per repository</td> |
| 45 | <td>Many check-outs per repository</td></tr> |
| @@ -263,21 +263,21 @@ | |
| 263 | [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact |
| 264 | wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is |
| 265 | not the best way to hang a picture on the living room wall. |
| 266 | |
| 267 | |
| 268 | <h4 id="license">2.3.3 Accepting Contributions</h4> |
| 269 | |
| 270 | Git is covered by |
| 271 | [https://en.wikipedia.org/wiki/GNU_General_Public_License#Version_2|the |
| 272 | GPLv2]. Fossil is covered by |
| 273 | [https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD |
| 274 | style license]. Neither license affects the managed repository contents, |
| 275 | and it is not our purpose here to try to persuade you to make the same |
| 276 | choice of license that we did, but we believe the choice of license has |
| 277 | an effect on the actual use of each DVCS. If you don't want to read |
| 278 | about licensing, you can skip to [#whylicmat|our point at the end]. |
| 279 | |
| 280 | The GPL allows a project to do without a |
| 281 | [https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor |
| 282 | license agreement] (CLA) because by the very act of distributing |
| 283 | binaries produced from GPL'd source code, you are bound by the license |
| @@ -303,15 +303,28 @@ | |
| 303 | [http://fossil-scm.org/home/doc/trunk/www/contribute.wiki|The Fossil |
| 304 | project's contribution process] requires active steps and processing |
| 305 | time: the printing, signing, mailing, reception, and processing of the |
| 306 | CLA. |
| 307 | |
| 308 | <a name="whylicmat"></a> |
| 309 | We think there's an upside to this difference in licensing, in Fossil's favor: it |
| 310 | improves contributor community cohesion, because everyone who pushed |
| 311 | past that legal friction made an affirmative, active step to get commit |
| 312 | capability on the Fossil project repository. We believe discouraging |
| 313 | [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by |
| 314 | contributions] makes for a better, more carefully-designed, simpler |
| 315 | DVCS. |
| 316 | |
| 317 | It's so easy to add features to Git that its command interface has |
| 318 | become truly arcane. Masters of the arcane are able to do wizardly |
| 319 | things, but only by studying their art deeply for years. This does not |
| 320 | strike us as a good use of the user's time. We believe it's better to |
| 321 | have a simpler tool with a more easily internalized behavior set, which |
| 322 | you can use quickly then set aside in order to get back to your main |
| 323 | task of producing the content that you manage in the DVCS. We achieve |
| 324 | that by carefully choosing which users to give commit bits to, and which |
| 325 | of their feature branches get merged down to trunk. |
| 326 | |
| 327 | |
| 328 | <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> |
| 329 | |
| 330 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 331 |