// doc/legal.dox
  
  // Copyright 2012  Johns Hopkins University (Author: Daniel Povey)
  
  // See ../../COPYING for clarification regarding multiple authors
  //
  // Licensed under the Apache License, Version 2.0 (the "License");
  // you may not use this file except in compliance with the License.
  // You may obtain a copy of the License at
  
  //  http://www.apache.org/licenses/LICENSE-2.0
  
  // THIS CODE IS PROVIDED *AS IS* BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  // KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED
  // WARRANTIES OR CONDITIONS OF TITLE, FITNESS FOR A PARTICULAR PURPOSE,
  // MERCHANTABLITY OR NON-INFRINGEMENT.
  // See the Apache 2 License for the specific language governing permissions and
  // limitations under the License.
  
  /**
   \page legal  Legal stuff
  
   This is not a legal document; see the COPYING file in the distribution
   for that.  In this page we explain what the legal stuff means (as we
   understand it).
  
   The code and other content (e.g. scripts, documentation) in
   Kaldi is released under the Apache license, version 2.0.  The Apache
   license is a popular "BSD-like" license.  This means you can use
   Kaldi for free and redistribute it, even for commercial purposes,
   although you can't take off the license headers (and under some
   circumstances you may have to distribute a license document).  Apache is
   not a ``viral'' license like the GPL, which forces you to release
   your modifications to the source code.  Also note that this project has no
   connection to the Apache Foundation, other than that we use the same
   license terms.
  
   From a legal and copyright point of view, none of the participants in the Kaldi
   project have a special status.  It is a community project, which means
   decisions are not made by any one person, and there is no "legal owner" of the
   Kaldi project.  In a sense this doesn't matter, because the whole project is
   "forkable": that is, if you don't agree with the way the project is being run,
   you can copy the code and create your own Kaldi community, giving it a
   different name if you wish.  If you want you can even claim that you are the
   true carriers of the Kaldi torch, and that the original authors have somehow
   deviated from the true path.  The name itself is not copyrighted by us.
  
   Some fraction of open source projects operate through "copyright assignment".
   That means that when you give your code to the project you assign your
   ownership of the copyright to a third party, who then releases it to the world.
   Kaldi is not set up that way.  If you, Joe Schmo, want to add something to
   Kaldi, the files you contribute are licensed under the Apache terms directly
   from you to the user of Kaldi.  The files that you write will have an Apache
   header on them that says something like:
  \verbatim
    // Copyright 2012  Joe M. Schmo
    //
  // See ../../COPYING for clarification regarding multiple authors
  //
    // Licensed under the Apache License, Version 2.0 (the "License");
    // etc.
  \endverbatim
   However, if Joe Schmo works for Acme Corporation and releases code
   as part of his work, then (depending what country Joe lives in) the header
   would probably look something like this:
  \verbatim
    // Copyright 2012  Acme Corporation
    //
  // See ../../COPYING for clarification regarding multiple authors
  //
    // Licensed under the Apache License, Version 2.0 (the "License");
    // etc.
  \endverbatim
   This would be the case under some circumstances even if he did it
   in his spare time.  For example: the terms of Joe's employment with
   Acme Corporation might dictate that anything he does while working for them
   is owned by them from a copyright point of view ("work for hire"), and
   Acme Corporation might have agreed that he can contribute to the project, but
   that he should put their name as the owner of the copyright.
  
   If Joe Schmo jointly worked with Jane Doe on this, but did so
   while he was working with Acme Corporation, then the header would
   look something like this:
  \verbatim
    // Copyright 2012  Acme Corporation  Jane Doe
    //
  // See ../../COPYING for clarification regarding multiple authors
  //
    // Licensed under the Apache License, Version 2.0 (the "License");
    // etc.
  \endverbatim
   In this case Acme Corporation and Jane Doe (and we're assuming that they
   agreed to this), jointly own the copyright on the code that they wrote.
   The order of names has no legal meaning.
   Joint ownership means that if either party chooses (and they don't have to
   both agree), they can release the code themselves under a different
   license.  However, for Apache-licensed projects, there is
   typically no point in doing this, since Apache already
   allows for commercial use.
  
   There are other cases that work like this: Joe Schmo (working for Acme
   Corporation) creates a file, and releases it under Apache.  Later Jane Doe
   finds a bug and fixes it, or adds new functionality to that file.  Jane Doe
   can't claim "joint ownership" of the copyright on the code, not without getting
   an agreement from Acme Corporation.  This is obvious from common sense, because
   that would allow her to re-release the entire project under a different and
   possibly incompatible license, simply by making a trivial change to each file.
   The way this is normally handled is, Jane Doe
   should add a new Apache header at the top of the file, above the one
   mentioning Acme Corporation, and she should say something to the
   effect that the work is  derived from the original file from Acme
   Corporation, and the whole modified file is being released under Apache.
   We haven't done it this way, because the project is very
   collaborative, and if we did it like this we would have extremely long copyright
   headers.  Instead we use the convention that if Jane makes a change,
   she simply adds her name to the list of authors in the copyright
   header.  We are treating this as
   a kind of shorthand for the whole multiple-header thing (this is
   explained in the COPYING file).  The way you can disambiguate
   between joint copyright ownership and derivative work, is to
   go back in the version history in Git, and see what the original
   release contained.  We guess that most people won't care about
   this distinction, which is why we have not bothered to disambiguate it.
   For shell and perl scripts and other non-C++ content
   (e.g. README files, Makefiles) we have not always been very
   careful to ensure the Apache header is there.  Our intention
   is that everything is being released under Apache.
  
   Note that the use of Kaldi does not protect you against patent claims by any
   third parties.  It doesn't even protect you from patent lawsuits by
   contributors to Kaldi code, as long as the part they are suing you about was
   not contributed by them.  Patent law is completely separate from copyright law.
  
   Also, some of the example scripts download tools from the Web that may have
   a different license from Kaldi itself.  You may want to check the licenses
   on those tools as they aren't always the same as Kaldi (although we try to
   use only tools that have similarly unrestrictive licenses).
  
  */