doc CHANGE add project documentation files
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..b150904
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,228 @@
+# Contributing to libyang
+
+First of all, thanks for thinking about contribution to libyang! Not all of us
+are C guru, but believe that helping us with docs, tests, helping other users to
+solve their issues / answer ther questions or even letting us to know via
+[issue tracker](https://github.com/CESNET/libyang/issues) that something
+can be done in a better or just different way is really appreciated.
+
+If you are willing to contribute, you will definitely have to build and install
+libyang first. To do it, please check dependencies and follow build and install
+instructions provided in [README](README.md).
+
+If you have something what you believe should be part of the libyang repository,
+add it via [Github Pull Request mechanism](https://help.github.com/articles/about-pull-requests/).
+Remember to explain what you wish to add and why. The best approach is to start
+with creating an issue and discuss possible approaches there. Pull requests can be
+then connected with such issues.
+
+## Branches
+
+There are 2 main branches in libyang project. The default branch is named `master`. It is the
+most stable and tested code which you get by default when cloning the Git repository. The
+`devel` branch introduces new features, API changes or even bugfixes in case `master` and
+`devel` differs significantly at that moment and the fix affects the changed code. There are
+some more branches for work-in-progress features and special `coverity` branch for submitting
+code for the [analysis in the Coverity tool](https://scan.coverity.com/projects/5259) usign
+[Travis CI build](https://travis-ci.org/CESNET/libyang/branches).
+
+When you create pull request, think carefully about the branch where the patch belongs to.
+In most cases (if not all), it is the `devel` branch.
+
+## Issue Ticketing
+
+All the communication with the developers is done via [issue tracker](https://github.com/CESNET/libyang/issues).
+You can send us an email, but in case you will ask a question we would think that someone else
+could ask in future, our answer will be just **use the issue tracker**. Private emails are not visible
+for others and we don't want to answer the same questions.
+
+So when you are goingto submit a new issue, **please:**
+* check that the issue you are having is not already solved in the devel branch,
+* go through the present issues (in case of question, it can be already a closed issue) in the tracker,
+* give it as descriptive title as possible,
+* separate topics - solving multiple issues in one ticket hides the issues from others,
+* provide as much relevant information as possible (versions, logs, input data, etc.).
+
+## libyang Coding Style
+
+When you are going to contribute C code, please follow these coding style guidelines.
+
+### Basics
+
+- Use space instead of tabs for indentations.
+- There is no strict limit for the line length, However, try to keep lines in a
+ reasonable length (120 characters).
+- Avoid trailing spaces on lines.
+- Put one blank line between function definitions.
+- Don't mix declarations and code within a block. Similarly, don't use
+ declarations in iteration statements.
+
+### Naming
+
+Use underscores to separate words in an identifier: `multi_word_name`.
+
+Use lowercase for most names. Use uppercase for macros, macro parameters and
+members of enumerations.
+
+Do not use names that begin with `_`. If you need a name for "internal use
+only", use `__` as a suffix instead of a prefix.
+
+### Comments
+
+Avoid `//` comments. Use `/* ... */` comments, write block comments with the
+leading asterisk on each line. You may put the `/*` and `*/` on the same line as
+comment text if you prefer.
+
+```c
+/*
+ * comment text
+ */
+```
+
+### Functions
+
+Put the return type, function name, and the braces that surround the function's
+code on separate lines, all starting in column 0.
+
+```c
+static int
+foo(int arg)
+{
+ ...
+}
+```
+
+When you need to put the function parameters on multiple lines, start new line
+at column after the opening parenthesis from the initial line.
+
+```c
+static int
+my_function(struct my_struct *p1, struct another_struct *p2,
+ int size)
+{
+ ...
+}
+```
+
+In the absence of good reasons for another order, the following parameter order
+is preferred. One notable exception is that data parameters and their
+corresponding size parameters should be paired.
+
+1. The primary object being manipulated, if any (equivalent to the "this"
+ pointer in C++).
+2. Input-only parameters.
+3. Input/output parameters.
+4. Output-only parameters.
+5. Status parameter.
+
+Functions that destroy an instance of a dynamically-allocated type should accept
+and ignore a null pointer argument. Code that calls such a function (including
+the C standard library function `free()`) should omit a null-pointer check. We
+find that this usually makes code easier to read.
+
+#### Function Prototypes
+
+Put the return type and function name on the same line in a function prototype:
+
+```c
+static const struct int foo(int arg);
+```
+
+### Statements
+
+- Indent each level of code with 4 spaces.
+- Put single space between `if`, `while`, `for`, etc. statements and the
+ expression that follow them. On the other hand, function calls has no space
+ between the function name and opening parenthesis.
+- Opening code block brace is kept at the same line with the `if`, `while`,
+ `for` or `switch` statements.
+
+```c
+if (a) {
+ x = exp(a);
+} else {
+ return 1;
+}
+```
+
+- Start switch's cases at the same column as the switch.
+
+```c
+switch (conn->state) {
+case 0:
+ return "data found";
+case 1:
+ return "data not found";
+default:
+ return "unknown error";
+}
+```
+
+- Do not put gratuitous parentheses around the expression in a return statement,
+that is, write `return 0;` and not `return(0);`
+
+### Types
+
+Use typedefs sparingly. Code is clearer if the actual type is visible at the
+point of declaration. Do not, in general, declare a typedef for a struct, union,
+or enum. Do not declare a typedef for a pointer type, because this can be very
+confusing to the reader.
+
+Use the `int<N>_t` and `uint<N>_t` types from `<stdint.h>` for exact-width
+integer types. Use the `PRId<N>`, `PRIu<N>`, and `PRIx<N>` macros from
+`<inttypes.h>` for formatting them with `printf()` and related functions.
+
+Pointer declarators bind to the variable name, not the type name. Write
+`int *x`, not `int* x` and definitely not `int * x`.
+
+### Expresions
+
+Put one space on each side of infix binary and ternary operators:
+
+```c
+* / % + - << >> < <= > >= == != & ^ | && || ?: = += -= *= /= %= &= ^= |= <<= >>=
+```
+
+Do not put any white space around postfix, prefix, or grouping operators with
+one exception - `sizeof`, see the note below.
+
+```c
+() [] -> . ! ~ ++ -- + - * &
+```
+
+The "sizeof" operator is unique among C operators in that it accepts two very
+different kinds of operands: an expression or a type. In general, prefer to
+specify an expression
+```c
+int *x = calloc(1, sizeof *x);
+```
+When the operand of sizeof is an expression, there is no need to parenthesize
+that operand, and please don't. There is an exception to this rule when you need
+to work with partially compatible structures:
+
+```c
+struct a_s {
+ uint8_t type;
+}
+
+struct b_s {
+ uint8_t type;
+ char *str;
+}
+
+struct c_s {
+ uint8_t type;
+ uint8_t *u8;
+}
+...
+struct a_s *a;
+
+switch (type) {
+case 1:
+ a = (struct a_s *)calloc(1, sizeof(struct b_s));
+ break;
+case 2:
+ a = (struct a_s *)calloc(1, sizeof(struct c_s));
+ break;
+ ...
+```
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000..f7cafac
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,28 @@
+Copyright (c) 2015-2016, CESNET
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+* Redistributions of source code must retain the above copyright notice, this
+ list of conditions and the following disclaimer.
+
+* Redistributions in binary form must reproduce the above copyright notice,
+ this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+
+* Neither the name of libyang nor the names of its
+ contributors may be used to endorse or promote products derived from
+ this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..62e2e6e
--- /dev/null
+++ b/README.md
@@ -0,0 +1,245 @@
+# libyang
+
+[](https://opensource.org/licenses/BSD-3-Clause)
+[](http://travis-ci.org/CESNET/libyang/branches)
+[](https://codecov.io/github/CESNET/libyang?branch=master)
+[](https://scan.coverity.com/projects/5259)
+[](https://www.openhub.net/p/libyang)
+
+libyang is a YANG data modelling language parser and toolkit written (and
+providing API) in C. The library is used e.g. in [libnetconf2](https://github.com/CESNET/libnetconf2),
+[Netopeer2](https://github.com/CESNET/Netopeer2) or [sysrepo](https://github.com/sysrepo/sysrepo) projects.
+
+## Provided Features
+
+* Parsing (and validating) schemas in YANG format.
+* Parsing (and validating) schemas in YIN format.
+* Parsing, validating and printing instance data in XML format.
+* Parsing, validating and printing instance data in JSON format
+ ([RFC 7951](https://tools.ietf.org/html/rfc7951)).
+* Manipulation with the instance data.
+* Support for default values in the instance data ([RFC 6243](https://tools.ietf.org/html/rfc6243)).
+* Support for YANG extensions.
+* Support for YANG Metadata ([RFC 7952](https://tools.ietf.org/html/rfc6243)).
+* [yanglint](#yanglint) - feature-rich YANG tool.
+
+Current implementation covers YANG 1.0 ([RFC 6020](https://tools.ietf.org/html/rfc6020))
+as well as YANG 1.1 ([RFC 7950](https://tools.ietf.org/html/rfc7950)).
+
+## Packages
+
+We are using openSUSE Build Service to automaticaly prepare binary packages for number of GNU/Linux distros. Check
+[this](https://software.opensuse.org//download.html?project=home%3Aliberouter&package=libyang) page and follow the
+instructions for your distro to install `libyang` package. The `libyang` package is built once a day from the
+master branch. If you want the latest code from the devel branch, install `libyang-experimental` package.
+
+## Requirements
+
+### Build Requirements
+
+* C compiler
+* cmake >= 2.8.12
+* libpcre (devel package)
+ * note, that PCRE is supposed to be compiled with unicode support (configure's options
+ `--enable-utf` and `--enable-unicode-properties`)
+* cmocka >= 1.0.0 (for tests only, see [Tests](#Tests))
+
+#### Optional
+
+* doxygen (for generating documentation)
+* valgrind (for enhanced testing)
+
+### Runtime Requirements
+
+* libpcre
+
+## Building
+
+```
+$ mkdir build; cd build
+$ cmake ..
+$ make
+# make install
+```
+
+### Documentation
+
+The library documentation can be generated directly from the source codes using
+Doxygen tool:
+```
+$ make doc
+$ google-chrome ../doc/html/index.html
+```
+
+The documentation is also built hourly and available at
+[netopeer.liberouter.org](https://netopeer.liberouter.org/doc/libyang/master/).
+
+### Useful CMake Options
+
+#### Changing Compiler
+
+Set `CC` variable:
+
+```
+$ CC=/usr/bin/clang cmake ..
+```
+
+#### Changing Install Path
+
+To change the prefix where the library, headers and any other files are installed,
+set `CMAKE_INSTALL_PREFIX` variable:
+```
+$ cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..
+```
+
+Default prefix is `/usr/local`.
+
+#### Build Modes
+
+There are two build modes:
+* Release.
+ This generates library for the production use without any debug information.
+* Debug.
+ This generates library with the debug information and disables optimization
+ of the code.
+
+The `Debug` mode is currently used as the default one. to switch to the
+`Release` mode, enter at the command line:
+```
+$ cmake -D CMAKE_BUILD_TYPE:String="Release" ..
+```
+
+#### Changing Extensions Plugins Directory
+
+As for YANG extensions, libyang allows loading extension plugins. By default, the
+directory to store the plugins is LIBDIR/libyang. To change it, use the following
+cmake option with the value specifying the desired directory:
+
+```
+$ cmake -DPLUGINS_DIR:PATH=`pwd`"/src/extensions/" ..
+```
+
+The directory path can be also changed runtime via environment variable, e.g.:
+
+```
+$ LIBYANG_EXTENSIONS_PLUGINS_DIR=`pwd`/my/relative/path yanglint
+```
+
+#### Optimizations
+
+Whenever the latest revision of a schema is supposed to be loaded (import without specific revision),
+it is performed in the standard way, the first time. By default, every other time when the latest
+revision of the same schema is needed, the one initially loaded is reused. If you know this can cause
+problems meaning the latest available revision of a schema can change during operation, you can force
+libyang to always search for the schema anew by:
+
+```
+$ cmake -DENABLE_LATEST_REVISIONS=OFF ..
+```
+
+Also, it can be efficient to store certain information about schemas that is generated during parsing
+so that it does not need to be generated every time the schema is used, but it will consume some
+additional space. You can enable this cache with:
+
+```
+$ cmake -DENABLE_CACHE=ON ..
+```
+
+### CMake Notes
+
+Note that, with CMake, if you want to change the compiler or its options after
+you already ran CMake, you need to clear its cache first - the most simple way
+to do it is to remove all content from the 'build' directory.
+
+## Usage
+
+All libyang functions are available via the main header:
+```
+#include <libyang/libyang.h>
+```
+
+To compile your program with libyang, it is necessary to link it with libyang using the
+following linker parameters:
+```
+-lyang
+```
+
+Note, that it may be necessary to call `ldconfig(8)` after library installation and if the
+library was installed into a non-standard path, the path to libyang must be specified to the
+linker. To help with setting all the compiler's options, there is `libyang.pc` file for
+`pkg-config(1)` available in the source tree. The file is installed with the library.
+
+If you are using `cmake` in you project, it is also possible to use the provided
+`FindLibYANG.cmake` file to detect presence of the libyang library in the system.
+
+## yanglint
+
+libyang project includes a feature-rich tool called `yanglint(1)` for validation
+and conversion of the schemas and YANG modeled data. The source codes are
+located at [`/tools/lint`](./tools/lint) and can be used to explore how an
+application is supposed to use the libyang library. `yanglint(1)` binary as
+well as its man page are installed together with the library itself.
+
+There is also [README](./tools/lint/examples/README.md) describing some examples of
+using `yanglint`.
+
+libyang supports YANG extensions via a plugin mechanism. Some of the plugins (for
+NACM or Metadata) are available out of the box and installed together with libyang.
+However, when libyang is not installed and `yanglint(1)` is used from the build
+directory, the plugins are not available. There are two options:
+
+1. Install libyang.
+```
+# make install
+```
+
+2. Set environment variable `LIBYANG_EXTENSIONS_PLUGINS_DIR` to contain path to the
+ built extensions plugin (`./src/extensions` from the build directory).
+```
+$ LIBYANG_EXTENSIONS_PLUGINS_DIR="`pwd`/src/extensions" ./yanglint
+```
+
+## Tests
+
+libyang includes several tests built with [cmocka](https://cmocka.org/). The tests
+can be found in `tests` subdirectory and they are designed for checking library
+functionality after code changes.
+
+The tests are by default built in the `Debug` build mode by running
+```
+$ make
+```
+
+In case of the `Release` mode, the tests are not built by default (it requires
+additional dependency), but they can be enabled via cmake option:
+```
+$ cmake -DENABLE_BUILD_TESTS=ON ..
+```
+
+Note that if the necessary [cmocka](https://cmocka.org/) headers are not present
+in the system include paths, tests are not available despite the build mode or
+cmake's options.
+
+Tests can be run by the make's `test` target:
+```
+$ make test
+```
+
+## Bindings
+
+We provide bindings for high-level languages using [SWIG](http://www.swig.org/)
+generator. The bindings are optional and to enable building of the specific
+binding, the appropriate cmake option must be enabled, for example:
+```
+$ cmake -DJAVASCRIPT_BINDING=ON ..
+```
+
+More information about the specific binding can be found in their README files.
+
+Currently supported bindings are:
+
+* JavaScript
+ * cmake option: `JAVASCRIPT_BINDING`
+ * [README](./swig/javascript/README.md)
+
+