puppet 2.6.18 → 2.7.1

data/CONTRIBUTING.md

@@ -1,299 +0,0 @@
-Checklist (and a short version for the impatient)
-=================================================
-
-  * Commits:
-
-    - Make commits of logical units.
-
-    - Check for unnecessary whitespace with "git diff --check" before
-      committing.
-
-    - Commit using Unix line endings (check the settings around "crlf" in
-      git-config(1)).
-
-    - Do not check in commented out code or unneeded files.
-
-    - The first line of the commit message should be a short
-      description (50 characters is the soft limit, excluding ticket
-      number(s)), and should skip the full stop.
-
-    - If there is an associated Redmine ticket then the first line
-      should include the ticket number in the form "(#XXXX) Rest of
-      message".
-
-    - The body should provide a meaningful commit message, which:
-
-      - uses the imperative, present tense: "change", not "changed" or
-        "changes".
-
-      - includes motivation for the change, and contrasts its
-        implementation with the previous behavior.
-
-    - Make sure that you have tests for the bug you are fixing, or
-      feature you are adding.
-
-    - Make sure the test suite passes after your commit (rake spec unit).
-
-  * Submission:
-
-    * Pre-requisites:
-
-      - Make sure you have a [Redmine account](http://projects.puppetlabs.com)
-
-      - Sign the [Contributor License Agreement](https://projects.puppetlabs.com/contributor_licenses/sign)
-
-    * Preferred method:
-
-      - Fork the repository on GitHub.
-
-      - Push your changes to a topic branch in your fork of the
-        repository.
-
-      - Submit a pull request to the repository in the puppetlabs
-        organization.
-
-    * Alternate methods:
-
-      - Mail patches to puppet-dev mailing list using `rake mail_patches`,
-        or `git-format-patch(1)` & `git-send-email(1)`.
-
-      - Attach patches to Redmine ticket.
-
-The long version
-================
-
-  0.  Decide what to base your work on.
-
-      In general, you should always base your work on the oldest
-      branch that your change is relevant to.
-
-      - A bug fix should be based on the current stable series. If the
-        bug is not present in the current stable release, then base it on
-        `master`.
-
-      - A new feature should be based on `master`.
-
-      - Security fixes should be based on the current maintenance series
-        (that is, the previous stable series).  If the security issue
-        was not present in the maintenance series, then it should be
-        based on the current stable series if it was introduced there,
-        or on `master` if it is not yet present in a stable release.
-
-      The current stable series is 2.7.x, and the current maintenance
-      series is 2.6.x.
-
-  1.  Make separate commits for logically separate changes.
-
-      Please break your commits down into logically consistent units
-      which include new or changed tests relevent to the rest of the
-      change.  The goal of doing this is to make the diff easier to
-      read for whoever is reviewing your code.  In general, the easier
-      your diff is to read, the more likely someone will be happy to
-      review it and get it into the code base.
-
-      If you're going to refactor a piece of code, please do so as a
-      separate commit from your feature or bug fix changes.
-
-      We also really appreciate changes that include tests to make
-      sure the bug isn't re-introduced, and that the feature isn't
-      accidentally broken.
-
-      Describe the technical detail of the change(s).  If your
-      description starts to get too long, that's a good sign that you
-      probably need to split up your commit into more finely grained
-      pieces.
-
-      Commits which plainly describe the the things which help
-      reviewers check the patch and future developers understand the
-      code are much more likely to be merged in with a minimum of
-      bike-shedding or requested changes.  Ideally, the commit message
-      would include information, and be in a form suitable for
-      inclusion in the release notes for the version of Puppet that
-      includes them.
-
-      Please also check that you are not introducing any trailing
-      whitespaces or other "whitespace errors".  You can do this by
-      running "git diff --check" on your changes before you commit.
-
-  2.  Sign the Contributor License Agreement
-
-      Before we can accept your changes, we do need a signed Puppet
-      Labs Contributor License Agreement (CLA).
-
-      You can access the CLA via the
-      [Contributor License Agreement link](https://projects.puppetlabs.com/contributor_licenses/sign)
-      in the top menu bar of our Redmine instance.  Once you've signed
-      the CLA, a badge will show up next to your name on the
-      [Puppet Project Overview Page](http://projects.puppetlabs.com/projects/puppet?jump=welcome),
-      and your name will be listed under "Contributor License Signers"
-      section.
-
-      If you have any questions about the CLA, please feel free to
-      contact Puppet Labs via email at cla-submissions@puppetlabs.com.
-
-  3.  Sending your patches
-
-      We accept multiple ways of submitting your changes for
-      inclusion.  They are listed below in order of preference.
-
-      Please keep in mind that any method that involves sending email
-      to the mailing list directly requires you to be subscribed to
-      the mailing list, and that your first post to the list will be
-      held in a moderation queue.
-
-      * GitHub Pull Requests
-
-        To submit your changes via a GitHub pull request, we _highly_
-        recommend that you have them on a topic branch, instead of
-        directly on "master" or one of the release, or RC branches.
-        It makes things much easier to keep track of, especially if
-        you decide to work on another thing before your first change
-        is merged in.
-
-        GitHub has some pretty good
-        [general documentation](http://help.github.com/) on using
-        their site.  They also have documentation on
-        [creating pull requests](http://help.github.com/send-pull-requests/).
-
-        In general, after pushing your topic branch up to your
-        repository on GitHub, you'll switch to the branch in the
-        GitHub UI and click "Pull Request" towards the top of the page
-        in order to open a pull request.
-
-        You'll want to make sure that you have the appropriate
-        destination branch in the repository under the puppetlabs
-        organization.  This should be the same branch that you based
-        your changes off of.
-
-      * Other pull requests
-
-        If you already have a publicly accessible version of the
-        repository hosted elsewhere, and don't wish to or cannot use
-        GitHub, you can submit your change by requesting that we pull
-        the changes from your repository by sending an email to the
-        puppet-dev Google Groups mailing list.
-
-        `git-request-pull(1)` provides a handy way to generate the text
-        for the email requesting that we pull your changes (and does
-        some helpful sanity checks in the process).
-
-      * Mailing patches to the mailing list
-
-        If neither of the previous methods works for you, then you can
-        also mail the patches inline to the puppet-dev Google Group
-        using either `rake mail_patches`, or by using
-        `git-format-patch(1)`, and `git-send-email(1)` directly.
-
-        `rake mail_patches` handles setting the appropriate flags to
-        `git-format-patch(1)` and `git-send-email(1)` for you, but
-        doesn't allow adding any commentary between the '---', and the
-        diffstat in the resulting email.  It also requires that you
-        have created your topic branch in the form
-        `<type>/<parent>/<name>`.
-
-        If you decide to use `git-format-patch(1)` and
-        `git-send-email(1)` directly, please be sure to use the
-        following flags for `git-format-patch(1)`: -C -M -s -n
-        --subject-prefix='PATCH/puppet'
-
-      * Attaching patches to Redmine
-
-        As a method of last resort you can also directly attach the
-        output of `git-format-patch(1)`, or `git-diff(1)` to a Redmine
-        ticket.
-
-        If you are generating the diff outside of Git, please be sure
-        to generate a unified diff.
-
-  4.  Update the related Redmine ticket.
-
-      If there's a Redmine ticket associated with the change you
-      submitted, then you should update the ticket to include the
-      location of your branch, and change the status to "In Topic
-      Branch Pending Merge", along with any other commentary you may
-      wish to make.
-
-How to track the status of your change after it's been submitted
-================================================================
-
-Shortly after opening a pull request on GitHub, there should be an
-automatic message sent to the puppet-dev Google Groups mailing list
-notifying people of this.  This notification is used to let the Puppet
-development community know about your requested change to give them a
-chance to review, test, and comment on the change(s).
-
-If you submitted your change via manually sending a pull request or
-mailing the patches, then we keep track of these using
-[patchwork](https://patchwork.puppetlabs.com).  When code is merged
-into the project it is automatically removed from patchwork, and the
-Redmine ticket is manually updated with the commit SHA1.  In addition,
-the ticket status must be updated by the person who merges the topic
-branch to a status of "Merged - Pending Release"
-
-We do our best to comment on or merge submitted changes within a week.
-However, if there hasn't been any commentary on the pull request or
-mailed patches, and it hasn't been merged in after a week, then feel
-free to ask for an update by replying on the mailing list to the
-automatic notification or mailed patches. It probably wasn't
-intentional, and probably just slipped through the cracks.
-
-Additional Resources
-====================
-
-* [Getting additional help](http://projects.puppetlabs.com/projects/puppet/wiki/Getting_Help)
-
-* [Writing tests](http://projects.puppetlabs.com/projects/puppet/wiki/Development_Writing_Tests)
-
-* [Bug tracker (Redmine)](http://projects.puppetlabs.com)
-
-* [Patchwork](https://patchwork.puppetlabs.com)
-
-* [Contributor License Agreement](https://projects.puppetlabs.com/contributor_licenses/sign)
-
-* [General GitHub documentation](http://help.github.com/)
-
-* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)
-
-If you have commit access to the repository
-===========================================
-
-Even if you have commit access to the repository, you'll still need to
-go through the process above, and have someone else review and merge
-in your changes.  The rule is that all changes must be reviewed by a
-developer on the project (that didn't write the code) to ensure that
-all changes go through a code review process.
-
-Having someone other than the author of the topic branch recorded as
-performing the merge is the record that they performed the code
-review.
-
-  * Merging topic branches
-
-    When merging code from a topic branch into the integration branch
-    (Ex: master, 2.7.x, 1.6.x, etc.), there should always be a merge
-    commit.  You can accomplish this by always providing the `--no-ff`
-    flag to `git merge`.
-
-        git merge --no-ff --log tickets/master/1234-fix-something-broken
-
-    The reason for always forcing this merge commit is that it
-    provides a consistent way to look up what changes & commits were
-    in a topic branch, whether that topic branch had one, or 500
-    commits.  For example, if the merge commit had an abbreviated
-    SHA-1 of `coffeebad`, then you could use the following `git log`
-    invocation to show you which commits it brought in:
-
-        git log coffeebad^1..coffeebad^2
-
-    The following would show you which changes were made on the topic
-    branch:
-
-        git diff coffeebad^1...coffeebad^2
-
-    Because we _always_ merge the topic branch into the integration
-    branch the first parent (`^1`) of a merge commit will be the most
-    recent commit on the integration branch from just before we merged
-    in the topic, and the second parent (`^2`) will always be the most
-    recent commit that was made in the topic branch.  This also serves
-    as the record of who performed the code review, as mentioned
-    above.

data/COPYING

@@ -1,340 +0,0 @@
-		    GNU GENERAL PUBLIC LICENSE
-		       Version 2, June 1991
-
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
-                       51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-			    Preamble
-
-  The licenses for most software are designed to take away your
-freedom to share and change it.  By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users.  This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it.  (Some other Free Software Foundation software is covered by
-the GNU Library General Public License instead.)  You can apply it to
-your programs, too.
-
-  When we speak of free software, we are referring to freedom, not
-price.  Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
-
-  To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
-  For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have.  You must make sure that they, too, receive or can get the
-source code.  And you must show them these terms so they know their
-rights.
-
-  We protect your rights with two steps: (1) copyright the software, and
-(2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
-  Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software.  If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
-  Finally, any free program is threatened constantly by software
-patents.  We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary.  To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
-  The precise terms and conditions for copying, distribution and
-modification follow.
-
-		    GNU GENERAL PUBLIC LICENSE
-   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
-  0. This License applies to any program or other work which contains
-a notice placed by the copyright holder saying it may be distributed
-under the terms of this General Public License.  The "Program", below,
-refers to any such program or work, and a "work based on the Program"
-means either the Program or any derivative work under copyright law:
-that is to say, a work containing the Program or a portion of it,
-either verbatim or with modifications and/or translated into another
-language.  (Hereinafter, translation is included without limitation in
-the term "modification".)  Each licensee is addressed as "you".
-
-Activities other than copying, distribution and modification are not
-covered by this License; they are outside its scope.  The act of
-running the Program is not restricted, and the output from the Program
-is covered only if its contents constitute a work based on the
-Program (independent of having been made by running the Program).
-Whether that is true depends on what the Program does.
-
-  1. You may copy and distribute verbatim copies of the Program's
-source code as you receive it, in any medium, provided that you
-conspicuously and appropriately publish on each copy an appropriate
-copyright notice and disclaimer of warranty; keep intact all the
-notices that refer to this License and to the absence of any warranty;
-and give any other recipients of the Program a copy of this License
-along with the Program.
-
-You may charge a fee for the physical act of transferring a copy, and
-you may at your option offer warranty protection in exchange for a fee.
-
-  2. You may modify your copy or copies of the Program or any portion
-of it, thus forming a work based on the Program, and copy and
-distribute such modifications or work under the terms of Section 1
-above, provided that you also meet all of these conditions:
-
-    a) You must cause the modified files to carry prominent notices
-    stating that you changed the files and the date of any change.
-
-    b) You must cause any work that you distribute or publish, that in
-    whole or in part contains or is derived from the Program or any
-    part thereof, to be licensed as a whole at no charge to all third
-    parties under the terms of this License.
-
-    c) If the modified program normally reads commands interactively
-    when run, you must cause it, when started running for such
-    interactive use in the most ordinary way, to print or display an
-    announcement including an appropriate copyright notice and a
-    notice that there is no warranty (or else, saying that you provide
-    a warranty) and that users may redistribute the program under
-    these conditions, and telling the user how to view a copy of this
-    License.  (Exception: if the Program itself is interactive but
-    does not normally print such an announcement, your work based on
-    the Program is not required to print an announcement.)
-
-These requirements apply to the modified work as a whole.  If
-identifiable sections of that work are not derived from the Program,
-and can be reasonably considered independent and separate works in
-themselves, then this License, and its terms, do not apply to those
-sections when you distribute them as separate works.  But when you
-distribute the same sections as part of a whole which is a work based
-on the Program, the distribution of the whole must be on the terms of
-this License, whose permissions for other licensees extend to the
-entire whole, and thus to each and every part regardless of who wrote it.
-
-Thus, it is not the intent of this section to claim rights or contest
-your rights to work written entirely by you; rather, the intent is to
-exercise the right to control the distribution of derivative or
-collective works based on the Program.
-
-In addition, mere aggregation of another work not based on the Program
-with the Program (or with a work based on the Program) on a volume of
-a storage or distribution medium does not bring the other work under
-the scope of this License.
-
-  3. You may copy and distribute the Program (or a work based on it,
-under Section 2) in object code or executable form under the terms of
-Sections 1 and 2 above provided that you also do one of the following:
-
-    a) Accompany it with the complete corresponding machine-readable
-    source code, which must be distributed under the terms of Sections
-    1 and 2 above on a medium customarily used for software interchange; or,
-
-    b) Accompany it with a written offer, valid for at least three
-    years, to give any third party, for a charge no more than your
-    cost of physically performing source distribution, a complete
-    machine-readable copy of the corresponding source code, to be
-    distributed under the terms of Sections 1 and 2 above on a medium
-    customarily used for software interchange; or,
-
-    c) Accompany it with the information you received as to the offer
-    to distribute corresponding source code.  (This alternative is
-    allowed only for noncommercial distribution and only if you
-    received the program in object code or executable form with such
-    an offer, in accord with Subsection b above.)
-
-The source code for a work means the preferred form of the work for
-making modifications to it.  For an executable work, complete source
-code means all the source code for all modules it contains, plus any
-associated interface definition files, plus the scripts used to
-control compilation and installation of the executable.  However, as a
-special exception, the source code distributed need not include
-anything that is normally distributed (in either source or binary
-form) with the major components (compiler, kernel, and so on) of the
-operating system on which the executable runs, unless that component
-itself accompanies the executable.
-
-If distribution of executable or object code is made by offering
-access to copy from a designated place, then offering equivalent
-access to copy the source code from the same place counts as
-distribution of the source code, even though third parties are not
-compelled to copy the source along with the object code.
-
-  4. You may not copy, modify, sublicense, or distribute the Program
-except as expressly provided under this License.  Any attempt
-otherwise to copy, modify, sublicense or distribute the Program is
-void, and will automatically terminate your rights under this License.
-However, parties who have received copies, or rights, from you under
-this License will not have their licenses terminated so long as such
-parties remain in full compliance.
-
-  5. You are not required to accept this License, since you have not
-signed it.  However, nothing else grants you permission to modify or
-distribute the Program or its derivative works.  These actions are
-prohibited by law if you do not accept this License.  Therefore, by
-modifying or distributing the Program (or any work based on the
-Program), you indicate your acceptance of this License to do so, and
-all its terms and conditions for copying, distributing or modifying
-the Program or works based on it.
-
-  6. Each time you redistribute the Program (or any work based on the
-Program), the recipient automatically receives a license from the
-original licensor to copy, distribute or modify the Program subject to
-these terms and conditions.  You may not impose any further
-restrictions on the recipients' exercise of the rights granted herein.
-You are not responsible for enforcing compliance by third parties to
-this License.
-
-  7. If, as a consequence of a court judgment or allegation of patent
-infringement or for any other reason (not limited to patent issues),
-conditions are imposed on you (whether by court order, agreement or
-otherwise) that contradict the conditions of this License, they do not
-excuse you from the conditions of this License.  If you cannot
-distribute so as to satisfy simultaneously your obligations under this
-License and any other pertinent obligations, then as a consequence you
-may not distribute the Program at all.  For example, if a patent
-license would not permit royalty-free redistribution of the Program by
-all those who receive copies directly or indirectly through you, then
-the only way you could satisfy both it and this License would be to
-refrain entirely from distribution of the Program.
-
-If any portion of this section is held invalid or unenforceable under
-any particular circumstance, the balance of the section is intended to
-apply and the section as a whole is intended to apply in other
-circumstances.
-
-It is not the purpose of this section to induce you to infringe any
-patents or other property right claims or to contest validity of any
-such claims; this section has the sole purpose of protecting the
-integrity of the free software distribution system, which is
-implemented by public license practices.  Many people have made
-generous contributions to the wide range of software distributed
-through that system in reliance on consistent application of that
-system; it is up to the author/donor to decide if he or she is willing
-to distribute software through any other system and a licensee cannot
-impose that choice.
-
-This section is intended to make thoroughly clear what is believed to
-be a consequence of the rest of this License.
-
-  8. If the distribution and/or use of the Program is restricted in
-certain countries either by patents or by copyrighted interfaces, the
-original copyright holder who places the Program under this License
-may add an explicit geographical distribution limitation excluding
-those countries, so that distribution is permitted only in or among
-countries not thus excluded.  In such case, this License incorporates
-the limitation as if written in the body of this License.
-
-  9. The Free Software Foundation may publish revised and/or new versions
-of the General Public License from time to time.  Such new versions will
-be similar in spirit to the present version, but may differ in detail to
-address new problems or concerns.
-
-Each version is given a distinguishing version number.  If the Program
-specifies a version number of this License which applies to it and "any
-later version", you have the option of following the terms and conditions
-either of that version or of any later version published by the Free
-Software Foundation.  If the Program does not specify a version number of
-this License, you may choose any version ever published by the Free Software
-Foundation.
-
-  10. If you wish to incorporate parts of the Program into other free
-programs whose distribution conditions are different, write to the author
-to ask for permission.  For software which is copyrighted by the Free
-Software Foundation, write to the Free Software Foundation; we sometimes
-make exceptions for this.  Our decision will be guided by the two goals
-of preserving the free status of all derivatives of our free software and
-of promoting the sharing and reuse of software generally.
-
-			    NO WARRANTY
-
-  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
-FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
-OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
-PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
-OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
-TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
-PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
-REPAIR OR CORRECTION.
-
-  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
-WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
-REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
-INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
-OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
-TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
-YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
-PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES.
-
-		     END OF TERMS AND CONDITIONS
-
-	    How to Apply These Terms to Your New Programs
-
-  If you develop a new program, and you want it to be of the greatest
-possible use to the public, the best way to achieve this is to make it
-free software which everyone can redistribute and change under these terms.
-
-  To do so, attach the following notices to the program.  It is safest
-to attach them to the start of each source file to most effectively
-convey the exclusion of warranty; and each file should have at least
-the "copyright" line and a pointer to where the full notice is found.
-
-    <one line to give the program's name and a brief idea of what it does.>
-    Copyright (C) <year>  <name of author>
-
-    This program is free software; you can redistribute it and/or modify
-    it under the terms of the GNU General Public License as published by
-    the Free Software Foundation; either version 2 of the License, or
-    (at your option) any later version.
-
-    This program is distributed in the hope that it will be useful,
-    but WITHOUT ANY WARRANTY; without even the implied warranty of
-    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-    GNU General Public License for more details.
-
-    You should have received a copy of the GNU General Public License
-    along with this program; if not, write to the Free Software
-    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
-
-
-Also add information on how to contact you by electronic and paper mail.
-
-If the program is interactive, make it output a short notice like this
-when it starts in an interactive mode:
-
-    Gnomovision version 69, Copyright (C) year name of author
-    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
-    This is free software, and you are welcome to redistribute it
-    under certain conditions; type `show c' for details.
-
-The hypothetical commands `show w' and `show c' should show the appropriate
-parts of the General Public License.  Of course, the commands you use may
-be called something other than `show w' and `show c'; they could even be
-mouse-clicks or menu items--whatever suits your program.
-
-You should also get your employer (if you work as a programmer) or your
-school, if any, to sign a "copyright disclaimer" for the program, if
-necessary.  Here is a sample; alter the names:
-
-  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
-  `Gnomovision' (which makes passes at compilers) written by James Hacker.
-
-  <signature of Ty Coon>, 1 April 1989
-  Ty Coon, President of Vice
-
-This General Public License does not permit incorporating your program into
-proprietary programs.  If your program is a subroutine library, you may
-consider it more useful to permit linking proprietary applications with the
-library.  If this is what you want to do, use the GNU Library General
-Public License instead of this License.