Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | 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! |
---|---|
Downloads: | Tarball | ZIP archive | SQL archive |
Timelines: | family | ancestors | descendants | both | bsd-vs-gpl |
Files: | files | file ages | folders |
SHA3-256: |
75e93e35b104ca81b4c45d0687964b19 |
User & Date: | wyoung 2019-07-14 12:11:26 |
Context
2019-07-14
| ||
12:12 | Renamed named anchor for "Accepting Contributions" in fossil-v-git from "license" to "contrib". check-in: 074b896e user: wyoung tags: bsd-vs-gpl | |
12:11 | 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! check-in: 75e93e35 user: wyoung tags: bsd-vs-gpl | |
11:37 | Another bit of prose polishing in fossil-v-git check-in: fcdefd97 user: wyoung tags: bsd-vs-gpl | |
Changes
Changes to www/fossil-v-git.wiki.
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 ... 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 ... 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 |
<tr><td>File versioning only</td> <td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr> <tr><td>Ad-hoc pile-of-files key/value database</td> <td>Relational SQL database</td></tr> <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> <tr><td>Designed for Linux kernel development</td> <td>Designed for SQLite development</td></tr> <tr><td>GPLv2</td> <td>2-clause BSD + CLA</td></tr> <tr><td>Focus on individual branches</td> <td>Focus on the entire tree of changes</td></tr> <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> <tr><td>One check-out per repository</td> <td>Many check-outs per repository</td></tr> <tr><td>Remembers what you should have done</td> <td>Remembers what you actually did</td></tr> ................................................................................ software configuration management problems or D. Richard Hipp scale problems when choosing your DVCS. An [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is not the best way to hang a picture on the living room wall. <h4 id="license">2.3.3 License</h4> Git is covered by [https://en.wikipedia.org/wiki/GNU_General_Public_License#Version_2|the GPLv2]. Fossil is covered by [https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD style license]. Neither license affects the managed repository contents, and it is not our purpose here to try to persuade you to make the same choice of license that we did. However, we do believe the choice of license affects the way each tool was developed, which may affect your choice of which one to use. The GPL allows a project to do without a [https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor license agreement] (CLA) because by the very act of distributing binaries produced from GPL'd source code, you are bound by the license to also distribute that source code under a compatible license. Some GPL-based projects do require a CLA, but usually only to further ................................................................................ [https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L306|an implicit CLA], but contributors agree to both passively. [http://fossil-scm.org/home/doc/trunk/www/contribute.wiki|The Fossil project's contribution process] requires active steps and processing time: the printing, signing, mailing, reception, and processing of the CLA. We think there's an upside to this difference, in Fossil's favor: it improves contributor community cohesion, because everyone who pushed past that legal friction made an affirmative, active step to get commit capability on the Fossil project repository. We think it makes for a better, more carefully-designed, simpler DVCS. <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> Both Fossil and Git store history as a directed acyclic graph (DAG) of changes, but Git tends to focus more on individual branches of the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| | | | | | > | | > | > > > > > > > > > > > |
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 ... 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 ... 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 |
<tr><td>File versioning only</td> <td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr> <tr><td>Ad-hoc pile-of-files key/value database</td> <td>Relational SQL database</td></tr> <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> <tr><td>Designed for Linux kernel development</td> <td>Designed for SQLite development</td></tr> <tr><td>Many contributors</td> <td>Select contributors</td></tr> <tr><td>Focus on individual branches</td> <td>Focus on the entire tree of changes</td></tr> <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> <tr><td>One check-out per repository</td> <td>Many check-outs per repository</td></tr> <tr><td>Remembers what you should have done</td> <td>Remembers what you actually did</td></tr> ................................................................................ software configuration management problems or D. Richard Hipp scale problems when choosing your DVCS. An [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is not the best way to hang a picture on the living room wall. <h4 id="license">2.3.3 Accepting Contributions</h4> Git is covered by [https://en.wikipedia.org/wiki/GNU_General_Public_License#Version_2|the GPLv2]. Fossil is covered by [https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD style license]. Neither license affects the managed repository contents, and it is not our purpose here to try to persuade you to make the same choice of license that we did, but we believe the choice of license has an effect on the actual use of each DVCS. If you don't want to read about licensing, you can skip to [#whylicmat|our point at the end]. The GPL allows a project to do without a [https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor license agreement] (CLA) because by the very act of distributing binaries produced from GPL'd source code, you are bound by the license to also distribute that source code under a compatible license. Some GPL-based projects do require a CLA, but usually only to further ................................................................................ [https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L306|an implicit CLA], but contributors agree to both passively. [http://fossil-scm.org/home/doc/trunk/www/contribute.wiki|The Fossil project's contribution process] requires active steps and processing time: the printing, signing, mailing, reception, and processing of the CLA. <a name="whylicmat"></a> We think there's an upside to this difference in licensing, in Fossil's favor: it improves contributor community cohesion, because everyone who pushed past that legal friction made an affirmative, active step to get commit capability on the Fossil project repository. We believe discouraging [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by contributions] makes for a better, more carefully-designed, simpler DVCS. It's so easy to add features to Git that its command interface has become truly arcane. Masters of the arcane are able to do wizardly things, but only by studying their art deeply for years. This does not strike us as a good use of the user's time. We believe it's better to have a simpler tool with a more easily internalized behavior set, which you can use quickly then set aside in order to get back to your main task of producing the content that you manage in the DVCS. We achieve that by carefully choosing which users to give commit bits to, and which of their feature branches get merged down to trunk. <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> Both Fossil and Git store history as a directed acyclic graph (DAG) of changes, but Git tends to focus more on individual branches of the DAG, whereas Fossil puts more emphasis on the entire DAG. |