Created
May 21, 2015 04:30
-
-
Save cvrebert/c8575aced21ff59901f6 to your computer and use it in GitHub Desktop.
misspellings.diff
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Index: appe.xml | |
| =================================================================== | |
| --- appe.xml (revision 2813) | |
| +++ appe.xml (working copy) | |
| @@ -8,7 +8,7 @@ | |
| bugs. They're still good instructions, and are referenced from <xref | |
| linkend="users-to-volunteers"/><phrase output="printed"> in <xref | |
| linkend="managing-volunteers"/></phrase>. But as they are a living | |
| -document, I felt it didn't make sense to include a frozen snaphot of | |
| +document, I felt it didn't make sense to include a frozen snapshot of | |
| them here, and so no longer maintain a copy in this appendix. You can | |
| view them at <ulink | |
| url="http://subversion.apache.org/reporting-issues.html" | |
| Index: ch01.xml | |
| =================================================================== | |
| --- ch01.xml (revision 2813) | |
| +++ ch01.xml (working copy) | |
| @@ -140,7 +140,7 @@ | |
| individually. Thus the goal of management is mostly to ensure that | |
| they continue to believe this, by setting standards for | |
| communications, by making sure useful developers don't get | |
| -marginalized due to personal idiosyncracies, and in general by making | |
| +marginalized due to personal idiosyncrasies, and in general by making | |
| the project a place developers want to keep coming back to. Specific | |
| techniques for doing this are discussed throughout the rest of this | |
| book.</para> | |
| @@ -447,7 +447,7 @@ | |
| <title>Accidental resistance</title> | |
| <para>There were many other things going on in the nascent free | |
| -software scene, however, and not all were as explictly ideological as | |
| +software scene, however, and not all were as explicitly ideological as | |
| Stallman's GNU Project. One of the most important was | |
| the <firstterm>Berkeley Software Distribution</firstterm> | |
| (<firstterm>BSD</firstterm>), a gradual re-implementation of the Unix | |
| @@ -785,7 +785,7 @@ | |
| to their technical contributions, has the potential to harm the | |
| project. That's reasonable: their behavior is relevant because in the | |
| long run it will have a negative effect on the project. The varieties | |
| -of human culture being what they are, I can give no single, succint | |
| +of human culture being what they are, I can give no single, succinct | |
| rule to cover all such cases, except to say that you should try to be | |
| welcoming to all potential contributors and, if you must discriminate, | |
| do so only on the basis of actual behavior, not on the basis of a | |
| Index: ch02.xml | |
| =================================================================== | |
| --- ch02.xml (revision 2813) | |
| +++ ch02.xml (working copy) | |
| @@ -268,7 +268,7 @@ | |
| around the fact that English has become the default | |
| language of the Internet: "easy to remember" usually means | |
| "easy for someone who can read English to remember." Names that | |
| - are puns dependent on native-speaker pronounciation, for | |
| + are puns dependent on native-speaker pronunciation, for | |
| example, will be opaque to the many non-native English | |
| readers out there. If the pun is particularly compelling | |
| and memorable, it may still be worth it; just keep in mind | |
| @@ -618,7 +618,7 @@ | |
| software is to either become the official release, assuming no bugs | |
| are found, or provide detailed feedback to the developers so they | |
| can reach the official release quickly. The difference between | |
| - alpha and beta is very much a matter of judgement.</para> | |
| + alpha and beta is very much a matter of judgment.</para> | |
| </sidebar> | |
| </sect3> | |
| @@ -630,13 +630,13 @@ | |
| <title>Downloads</title> | |
| <!-- This section probably needs to be rewritten, because there's so | |
| - much software, especially Javascript, that is distributed | |
| + much software, especially JavaScript, that is distributed | |
| straight from GitHub. To a first approximation, source packaging | |
| is important for something you expect an OS packager to | |
| repackage; otherwise, it may be a luxury. Not sure whether this | |
| footnote for JS can be used or not: | |
| - <footnote><para>This is still true even for Javascript packages | |
| + <footnote><para>This is still true even for JavaScript packages | |
| that are deployed as minified, continuously available downloads | |
| from a canonical URL. Minified JS downloads are equivalent to an | |
| executable form. They're not what a developer would hack on to | |
| @@ -783,7 +783,7 @@ | |
| the other authors of the project are subscribed to these mailing | |
| lists, so people see there's a way to give feedback that will reach | |
| the developers. Your presence on the lists does not imply a | |
| -committment to answer all questions or implement all feature requests. | |
| +commitment to answer all questions or implement all feature requests. | |
| In the long run, probably only a fraction users will use the forums | |
| anyway, but the others will be comforted to know that they | |
| <emphasis>could</emphasis> if they ever needed to.</para> | |
| @@ -1952,7 +1952,7 @@ | |
| who knew the software more or less equally well, who all received the | |
| same pressures from the same management, and who all know each others' | |
| strengths and weaknesses. Now you're asking them to expose their code | |
| -to the scrutiny of random strangers, who will form judgements based | |
| +to the scrutiny of random strangers, who will form judgments based | |
| only on the code, with no awareness of what business pressures may | |
| have forced certain decisions. These strangers will ask lots of | |
| questions, questions that jolt the existing developers into realizing | |
| @@ -2039,7 +2039,7 @@ | |
| page. While it's good news for your project if you can get mentioned | |
| in a place like that, I hesitate to contribute to the marketing arms | |
| race by suggesting any concrete steps to accomplish this. Use your | |
| -judgement and try not to spam.)</para> | |
| +judgment and try not to spam.)</para> | |
| <para>The topic-specific forums are probably where you'll get the most | |
| interest. Think about mailing lists or web forums where an | |
| Index: ch03.xml | |
| =================================================================== | |
| --- ch03.xml (revision 2813) | |
| +++ ch03.xml (working copy) | |
| @@ -113,7 +113,7 @@ | |
| happening to projects whose workflows were developed before the rise | |
| of GitHub PRs (see <xref linkend="pull-requests"/>) as the canonical | |
| way to package proposed contributions. Many infrastructure questions | |
| -are matters of judgement, involving tradeoffs between the convenience | |
| +are matters of judgment, involving tradeoffs between the convenience | |
| of those producing information and the convenience of those consuming | |
| it, or between the time required to configure information management | |
| software and the benefit it brings to the project.</para> | |
| @@ -456,7 +456,7 @@ | |
| hosting site. Your project itself should never require participants | |
| to run proprietary collaboration software on their own | |
| machines.<footnote><para>The exception to this is proprietary | |
| -Javascript code that is received from the hosting site and run | |
| +JavaScript code that is received from the hosting site and run | |
| confined or "sandboxed" in one tab in the user's browser. The | |
| question of whether such code is conceptually an extension of the | |
| server, or should be thought of as running on the client machine even | |
| @@ -1060,7 +1060,7 @@ | |
| such a person posts to a mailing list that he's not subscribed to, his | |
| setting of Reply-to becomes essential information. If the list | |
| software overwrites it<footnote><para>In theory, the list software | |
| -could <emphasis>add</emphasis> the lists's address to whatever | |
| +could <emphasis>add</emphasis> the list's address to whatever | |
| Reply-to destination were already present, if any, instead of | |
| overwriting. In practice, for reasons I don't know, most list | |
| software overwrites instead of appending.</para></footnote>, he may | |
| @@ -2499,7 +2499,7 @@ | |
| <para>Most ticket databases eventually suffer from the same problem: a | |
| crushing load of duplicate or invalid tickets filed by well-meaning but | |
| -inexperienced or ill-informed users. The first step in combatting | |
| +inexperienced or ill-informed users. The first step in combating | |
| this trend is usually to put a prominent notice on the front page of | |
| the bug tracker, explaining how to tell if a bug is really a bug, how | |
| to search to see if it's already been reported, and finally, how to | |
| @@ -2654,7 +2654,7 @@ | |
| obvious choice is the name of your project—if that's available | |
| at Freenode, then use it. If not, try to choose something as close to | |
| your project's name, and as easy to remember, as possible. Advertise | |
| -the channel's availabity from your project's web site, so a visitor | |
| +the channel's availability from your project's web site, so a visitor | |
| with a quick question will see it right away.<footnote><para>In fact, | |
| you can even offer an IRC chat portal right on your web site. See | |
| <ulink url="https://webchat.freenode.net/" | |
| @@ -2888,7 +2888,7 @@ | |
| <para>All edits in your project's wiki must come from registered | |
| users; if your wiki software doesn't already enforce this by default, | |
| then configure it to enforce that. Even then you may need to keep | |
| -watch for spam edits from users who registered under false pretences | |
| +watch for spam edits from users who registered under false pretenses | |
| for the purpose of spamming.</para> | |
| </sect2> | |
| Index: ch04.xml | |
| =================================================================== | |
| --- ch04.xml (revision 2813) | |
| +++ ch04.xml (working copy) | |
| @@ -775,7 +775,7 @@ | |
| tax benefits available to donors under 501(c)(3) won't apply to | |
| non-U.S. donors anyway.</para> | |
| -<para>If your project joins or creats a non-profit organization, make | |
| +<para>If your project joins or creates a non-profit organization, make | |
| clear the separation between the legal infrastructure and the | |
| day-to-day running of the project. The organization is there to | |
| handle things the developers don't want to handle, not to interfere | |
| Index: ch05.xml | |
| =================================================================== | |
| --- ch05.xml (revision 2813) | |
| +++ ch05.xml (working copy) | |
| @@ -35,7 +35,7 @@ | |
| been formed. The consortium's funding comes from the sysadmins' | |
| salaries, and its office space and network bandwidth are donated, | |
| albeit unknowingly, by the organizations they work for. Those | |
| -organizations benefitted from the investment, of course, although they | |
| +organizations benefited from the investment, of course, although they | |
| may not be institutionally aware of it at first.</para> | |
| <para>Today these efforts tend to be more formalized. Corporations | |
| @@ -620,7 +620,7 @@ | |
| Fixes path inconsistencies on Windows. More generally, actually | |
| makes use of the "style" parameter passed to the path library | |
| - functions to choose the right path delimeter ('/' or '\' at this | |
| + functions to choose the right path delimiter ('/' or '\' at this | |
| time). | |
| * config.hw (SVN_PATH_LOCAL_SEPARATOR): | |
| @@ -824,7 +824,7 @@ | |
| <para>The project's community will always be important to the | |
| long-term success of contract work. Their involvement in the design | |
| -and review process for sizeable changes cannot be an afterthought; It | |
| +and review process for sizable changes cannot be an afterthought; It | |
| must be considered part of the work, and fully embraced by the | |
| contractor. Don't think of community scrutiny as an obstacle to be | |
| overcome—think of it as a free design board and QA department. | |
| @@ -1206,7 +1206,7 @@ | |
| number of developers checking in changes, and other factors, running a | |
| responsive build farm can cost more money than any individual | |
| developer has at their disposal. A good way to help, and gain some | |
| -goodwill in the process, is to donate the server space and bandwith | |
| +goodwill in the process, is to donate the server space and bandwidth | |
| <emphasis>and</emphasis> the technical expertise to set up the | |
| continuous integration and automated testing. If you don't have the | |
| technical expertise available on staff, you could hire someone from | |
| @@ -1411,7 +1411,7 @@ | |
| <sidebar id="commercial-vs-proprietary"> | |
| <title>"Commercial" vs "Proprietary"</title> | |
| -<para><emphasis>possv2 todo: write a sidebar here pointing out ohw | |
| +<para><emphasis>possv2 todo: write a sidebar here pointing out how | |
| many companies publish a proprietary version that they misleadingly | |
| call "commercial" or "enterprise", which they contrast with their | |
| "community" (meaning open source) edition. Then link to this sidebar | |
| Index: ch06.xml | |
| =================================================================== | |
| --- ch06.xml (revision 2813) | |
| +++ ch06.xml (working copy) | |
| @@ -719,7 +719,7 @@ | |
| before now, because it reminds everyone that even those who have been | |
| silent thus far still have a stake in the thread's outcome. It | |
| describes why the thread is going nowhere, but does so without | |
| -pejoratives or judgements—it just dispassionately states | |
| +pejoratives or judgments—it just dispassionately states | |
| some facts. Most importantly, it offers a positive course of action, | |
| so that instead of people feeling like discussion is being closed off | |
| (a restriction against which they can only be tempted to rebel), they | |
| @@ -1177,9 +1177,9 @@ | |
| classic case of abusing project procedures. He wasn't doing something | |
| obvious like trying to filibuster a vote, but he was taking advantage | |
| of the mailing list's policy of relying on self-moderation by its | |
| -members. We left it to each individual's judgement when to post and | |
| +members. We left it to each individual's judgment when to post and | |
| on what topics. Thus, we had no procedural recourse for dealing with | |
| -someone who either did not have, or would not exercise, such judgement. | |
| +someone who either did not have, or would not exercise, such judgment. | |
| There was no rule one could point to and say the fellow was violating | |
| it, yet everyone except him knew that his frequent posting was getting | |
| to be a serious problem.</para> | |
| @@ -1192,8 +1192,8 @@ | |
| to him directly, and asked him to simply stop posting. He never | |
| really did understand the reasons why; if he had been capable | |
| of understanding, he probably would have exercised appropriate | |
| -judgement in the first place. But he agreed to stop posting, and the | |
| -mailing lists became useable again. Part of the reason this strategy | |
| +judgment in the first place. But he agreed to stop posting, and the | |
| +mailing lists became usable again. Part of the reason this strategy | |
| worked was, perhaps, the implicit threat that we could start | |
| restricting his posts via the moderation software normally used for | |
| preventing spam (see | |
| @@ -1241,7 +1241,7 @@ | |
| ominous: the usual open source model of massively parallelized support | |
| simply does not scale to the levels needed for world | |
| domination.<footnote><para>An interesting experiment would be a | |
| -probablistic mailing list, that sends each new thread-originating post | |
| +probabilistic mailing list, that sends each new thread-originating post | |
| to a random subset of subscribers, based on the approximate traffic | |
| level they signed up for, and keeps just that subset subscribed to the | |
| rest of the thread; such a forum could in theory scale without limit. | |
| @@ -1447,7 +1447,7 @@ | |
| additionally indicating that the HTML should be designed for | |
| readability (i.e., you'll want some control over its look and feel), | |
| and should have a table of contents. Point 4 means that each | |
| -individual entry in the FAQ should be directly addresseable via a | |
| +individual entry in the FAQ should be directly addressable via a | |
| direct URL (e.g., using HTML IDs and named anchors, tags that allow | |
| people to reach a particular location on the page). Point 5 means the | |
| source files for the FAQ should be available in a convenient way (see | |
| @@ -1633,7 +1633,7 @@ | |
| canonical referral methods for common entities, and that these | |
| referral methods should be used consistently everywhere, the project | |
| in effect exports certain standards. Those standards enable people to | |
| -write tools that present the project's communications in more useable | |
| +write tools that present the project's communications in more usable | |
| ways—for example, a revision formatted as "r12828" could be | |
| transformed into a live link into the repository browsing system. | |
| This would be harder to do if the revision were written as "revision | |
| @@ -1870,7 +1870,7 @@ | |
| >news.ycombinator.com</ulink>, submit it there. Unlike | |
| Slashdot, Hacker News is audience-curated, so if enough | |
| readers agree with you, your announcement will end up on | |
| - the front page. Please use some judgement: if your | |
| + the front page. Please use some judgment: if your | |
| project is not in wide usage yet and there is not some | |
| specific reason why this announcement would be interesting | |
| to that audience, don't waste their time with it. There's | |
| Index: ch07.xml | |
| =================================================================== | |
| --- ch07.xml (revision 2813) | |
| +++ ch07.xml (working copy) | |
| @@ -29,7 +29,7 @@ | |
| much more time and trouble for the repair crew (now they have to work | |
| with fewer people and less equipment, in cramped conditions, with | |
| flaggers to slow and direct traffic, etc.), but at least the road | |
| -remains useable, albeit not at full capacity.</para> | |
| +remains usable, albeit not at full capacity.</para> | |
| <para>Open source projects tend to work the second way. In fact, for | |
| a mature piece of software with several different release lines being | |
| @@ -101,7 +101,7 @@ | |
| <listitem><para>Incompatible changes may have been introduced, for | |
| example such | |
| that the data formats used by older versions of the | |
| - software are no longer useable without undergoing some | |
| + software are no longer usable without undergoing some | |
| sort of (possibly manual) one-way conversion step.</para> | |
| </listitem> | |
| @@ -512,7 +512,7 @@ | |
| release is covered in <xref linkend="stabilizing-a-release"/><phrase | |
| output="printed"> later in this chapter</phrase>. Here we are | |
| concerned just with the high-level version control actions that relate | |
| -tothe release process. When the release branch is stabilized and | |
| +to the release process. When the release branch is stabilized and | |
| ready, it is time to tag a snapshot from the branch (see <xref | |
| linkend="vc-vocabulary-tag"/><phrase output="printed">in <xref | |
| linkend="technical-infrastructure"/></phrase>) with a name like, e.g., | |
| @@ -578,7 +578,7 @@ | |
| part of the interface and must remain stable). Many projects also | |
| allow certain kinds of low-risk or non-core changes to go in during | |
| stabilization, and may have formal guidelines for measuring risk. But | |
| -no amount of formalization can obviate the need for human judgement. | |
| +no amount of formalization can obviate the need for human judgment. | |
| There will always be cases where the project simply has to make a | |
| decision about whether a given change can go into a release. The | |
| danger is that since each person wants to see their own favorite | |
| @@ -634,7 +634,7 @@ | |
| The skills that make a good development leader are not necessarily the | |
| same as those that make a good release owner. In something as | |
| important as the release process, it may be wise to have someone | |
| -provide a counterbalance to the project leader's judgement. In that | |
| +provide a counterbalance to the project leader's judgment. In that | |
| case, the project leader needs to remember that overriding a decision | |
| by the release owner will undermine the release owner's authority; | |
| that alone may be enough reason, in most situations, to let the | |
| Index: ch08.xml | |
| =================================================================== | |
| --- ch08.xml (revision 2813) | |
| +++ ch08.xml (working copy) | |
| @@ -51,7 +51,7 @@ | |
| <para>Thus it is quite reasonable that one of the considerations | |
| going into each person's decision-making process is the question of | |
| how a given action might affect his own future influence in the | |
| -project. After all, if you trust your own judgement and skills, as | |
| +project. After all, if you trust your own judgment and skills, as | |
| most programmers do, then the potential loss of future influence has | |
| to be considered a technical result, in a sense. Similar reasoning | |
| applies to other behaviors that might seem, on their face, like "pure" | |
| @@ -151,7 +151,7 @@ | |
| volunteer for work that someone else doesn't want or have time to do, | |
| you will gain her good will and respect. Delegation and | |
| substitution are not just about getting individual tasks done; they're | |
| -also about drawing people into a closer committment to the | |
| +also about drawing people into a closer commitment to the | |
| project.</para> | |
| <sect3 id="delegation-assignment"> | |
| @@ -376,7 +376,7 @@ | |
| areas where they are more and less influential, and non-experts | |
| frequently defer to experts in certain domains of the project. But | |
| the key is that this is all voluntary: informal authority is granted | |
| -based on competence and proven judgement, but it should never be | |
| +based on competence and proven judgment, but it should never be | |
| actively | |
| <emphasis>taken</emphasis>. Even if the person desiring the authority | |
| really is competent, it is still crucial that she hold that authority | |
| @@ -471,7 +471,7 @@ | |
| circumstances, it may be preferable to put author names into the | |
| source files, along with precise descriptions of what each author did, | |
| since the majority of potential contributors will expect that style of | |
| -acknowledgement.</para></footnote></para> | |
| +acknowledgment.</para></footnote></para> | |
| <para>If your project decides to ban individual names from source | |
| files, make sure not to go overboard. For instance, many | |
| @@ -774,7 +774,7 @@ | |
| belittling him for not knowing how to report a bug, it tells him how, | |
| and in enough detail to be actually useful—for example, many | |
| users don't realize that "show us the error" means "show us the exact | |
| -text of the error, with no omissions or abridgements." The first time | |
| +text of the error, with no omissions or abridgments." The first time | |
| you work with such a user, you need to be specific about that. | |
| Finally, it offers a pointer to much more detailed and complete | |
| instructions for reporting bugs. If you have successfully engaged | |
| @@ -1310,7 +1310,7 @@ | |
| a while longer, and then there might or might not be another flurry. | |
| But there's rarely an unsolicited formal resignation. To resign | |
| would mean openly acknowledging to himself that his circumstances have | |
| -changed and that his ability to fulfill a committment has been | |
| +changed and that his ability to fulfill a commitment has been | |
| permanently reduced. People are often reluctant to admit that.</para> | |
| <para>Therefore, it's up to you and the others in the project to | |
| @@ -1364,7 +1364,7 @@ | |
| <para>Or, he may agree that there have been problems, but ask for a | |
| little more time (or for one more chance, in the case of discrete-task | |
| -roles like release manager). How you react to that is a judgement | |
| +roles like release manager). How you react to that is a judgment | |
| call, but whatever you do, don't agree to it just because you feel | |
| like you can't refuse such a reasonable request. That would prolong | |
| the agony, not lessen it. There is often a very good reason to refuse | |
| @@ -1507,7 +1507,7 @@ | |
| could succeed without it. Quality control requires, well, control. | |
| There are always many people who feel competent to make changes to a | |
| program, and some smaller number who actually are. The project cannot | |
| -rely on people's own judgement; it must impose standards and grant | |
| +rely on people's own judgment; it must impose standards and grant | |
| commit access only to those who meet them. On the other | |
| hand, having people who can commit changes directly working | |
| side-by-side with people who cannot sets up an obvious power dynamic. | |
| @@ -1528,7 +1528,7 @@ | |
| <para>In the Subversion project, we choose committers primarily on the | |
| Hippocratic Principle: <emphasis>first, do no harm</emphasis>. Our | |
| main criterion is not technical skill or even knowledge of the code, | |
| -but merely that the person show good judgement. Judgement includes | |
| +but merely that the person show good judgment. Judgment includes | |
| knowing what not to take on. Someone might post only small patches, | |
| fixing fairly simple problems in the code, but if her patches apply | |
| cleanly, do not contain bugs, and are mostly in accord with the | |
| @@ -1540,7 +1540,7 @@ | |
| areas of the code base, but that is irrelevant: the person has made it | |
| clear that she is capable of judging her own abilities, and that is | |
| the important thing. Technical skills can be learned (and taught), | |
| -but judgement, for the most part, cannot. Therefore, it is the one | |
| +but judgment, for the most part, cannot. Therefore, it is the one | |
| thing you want to make sure a person has before you give her commit | |
| access.</para> | |
| @@ -1682,12 +1682,12 @@ | |
| <para>First, it may tempt some people into committing acceptable but | |
| unnecessary changes, just to prevent their commit access from | |
| expiring. Second, it doesn't really serve any purpose. If the | |
| -main criterion for granting commit access is good judgement, then why | |
| -assume someone's judgement would deteriorate just because she's been away | |
| +main criterion for granting commit access is good judgment, then why | |
| +assume someone's judgment would deteriorate just because she's been away | |
| from the project for a while? Even if she completely vanishes for | |
| years, not looking at the code or following development discussions, | |
| when she reappears she'll <emphasis>know</emphasis> how out of touch | |
| -she is, and act accordingly. You trusted her judgement before, so | |
| +she is, and act accordingly. You trusted her judgment before, so | |
| why not trust it always? If high school diplomas do not expire, then | |
| commit access certainly shouldn't.</para> | |
| @@ -1917,7 +1917,7 @@ | |
| developers, knowing how to constructively initiate or react to a | |
| social fork of your project is useful — useful even if | |
| a fork never happens, as understanding what leads to social forks, and | |
| -signalling clearly how you will behave in such an event, can sometimes | |
| +signaling clearly how you will behave in such an event, can sometimes | |
| prevent the fork from happening in the first place.</para> | |
| <para>The rest of this section is about social forks, not short forks. | |
| @@ -1992,7 +1992,7 @@ | |
| non-copyable assets: not just trademarks, but perhaps money in the | |
| bank, hardware, that full-color conference banner sitting in a storage | |
| locker somewhere, etc. Sometimes, those questions are resolved | |
| -independently of the project's decision-making procdures, because | |
| +independently of the project's decision-making procedures, because | |
| those assets already had formal owners, and in each case the owner | |
| will decide what happens to the asset. But in cases where the actual | |
| ownership is in dispute, or the asset belongs in some way to the | |
| @@ -2116,7 +2116,7 @@ | |
| the project!"—because everyone is aware that a fork that fails | |
| to attract developers away from the original project is unlikely to | |
| survive long. All observers—not just developers, but users and | |
| -operating system packagers too—will make their own judgement about | |
| +operating system packagers too—will make their own judgment about | |
| which side to choose. You should therefore appear extremely reluctant | |
| to fork, so that if you finally do it, you can credibly claim it was | |
| the only route left.</para> | |
| Index: ch09.xml | |
| =================================================================== | |
| --- ch09.xml (revision 2813) | |
| +++ ch09.xml (working copy) | |
| @@ -176,7 +176,7 @@ | |
| true for decades if not centuries, and they're not going to change. | |
| So if you're a government agency and you want to start a successful | |
| open source project, certain adjustments will be necessary to | |
| -compensate for the structural idiosyncracies above. The advice that | |
| +compensate for the structural idiosyncrasies above. The advice that | |
| follows is most applicable to the U.S. and countries with similar | |
| systems of government and civil service.</para> | |
| Index: ch10.xml | |
| =================================================================== | |
| --- ch10.xml (revision 2813) | |
| +++ ch10.xml (working copy) | |
| @@ -1033,7 +1033,7 @@ | |
| version of the code and the proprietary version. While the | |
| contributor will be comfortable helping the free version, since that's | |
| the norm in open source projects, she may feel less enthusiastic about | |
| -her contributions being useable in a monopolized proprietary product. | |
| +her contributions being usable in a monopolized proprietary product. | |
| That is, unlike a straight non-copyleft license by which anyone has | |
| the right to use the code as part of a proprietary work, here only | |
| <emphasis>one</emphasis> party has that right, and other participants | |
| @@ -1122,7 +1122,7 @@ | |
| truth in labeling and, to some degree, endorsement. A trademarked | |
| name or symbol is a way for an entity — the entity who | |
| owns or controls that trademark — to signal, in an | |
| -easily recognizeable way, that they approve of a particular product. | |
| +easily recognizable way, that they approve of a particular product. | |
| Often they are signaling their approval because they are the source of | |
| the product, and purchases of that product provide a revenue stream | |
| for them. But that is not the only circumstance under which someone | |
| @@ -1328,7 +1328,7 @@ | |
| specifications needed to produce high-performance open source drivers | |
| for their cards, thus making it impossible for free operating systems | |
| to support those cards to their full potential. Why would the | |
| -manufacturers withold these specs? It doesn't make sense for them to | |
| +manufacturers withhold these specs? It doesn't make sense for them to | |
| work <emphasis>against</emphasis> software support; after all, | |
| compatibility with more operating systems can only mean more card | |
| sales. But it turns out that, behind the design room door, these |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment