some updates to contributing file.

Author: jacobwilliams

CONTRIBUTING.md

@@ -36,12 +36,16 @@ git rebase upstream
 - Create a branch in your fork with a descriptive name that also includes the [issue number](https://github.com/jacobwilliams/json-fortran/issues), if applicable. For example, after forking the repo, you can run something like `git checkout -b Unicode-support-issue-35` before starting work on [issue #35 : Unicode support](https://github.com/jacobwilliams/json-fortran/issues/35)
 - When you're content with your changes, your commits are clean, self contained, with concise descriptive messages, and your changes compile and pass the tests, submit a pull request. We will review your changes, and may ask for certain modifications to be made.
 - Pull requests are tested by our [travis-ci](https://travis-ci.org/jacobwilliams/json-fortran) continuous integration system, and any errors uncovered will need to be fixed before the pull request can be merged into master.
+- The json-fortran library and associated documentation is released under a BSD style [license](https://github.com/jacobwilliams/json-fortran/blob/master/LICENSE).  By submitting a pull request, you are agreeing to release your code under the same license.  Note that code with GPL or other "copyleft" style licenses will not be accepted.
 
 ## Coding Standards
 
 - Each commit should address a single logical change and code base transformation.
 - Each commit **must** compile.
 - Each commit should pass the tests unless the feature being implemented or bug being fixed requires extensive changes that would result in a commit with too many different changes.
 - No extraneous white spaces are allowed to be introduced at line endings and all non binary files should end with a single new line. Run `git config core.whitespace trailing-space,space-before-tab,blank-at-eol,blank-at-eof` to setup the whitespace rules from within your fork, and then check for white space errors with `git diff --check` to see if you have accidentally introduced white space errors before committing. (You can also enable the sample `pre-commit` hook that ships with git, to prevent you from committing changes that introduce white space errors. See [this stackoverflow question](http://stackoverflow.com/questions/591923/make-git-automatically-remove-trailing-whitespace-before-committing/28446440)) for some tips on preventing the introduction of whitespace errors.
-- Please adhere to the code indentation and formatting as it currently exists, aligning common elements vertically, etc.
+- Please adhere to the code indentation and formatting as it currently exists, aligning common elements vertically, etc. Tab characters are not allowed. Indentations should be done with *4* space characters.
 - *Do NOT* allow your editor to make a bunch of indentation or white space changes, that will introduce non-substantive changes on lines that you have not actually edited.
+- The coding style is modern free-form Fortran, consistent with the Fortran 2008 standard.  Note that the two supported compilers (ifort and gfortran) do not currently include the entire Fortran 2008 standard. Therefore, only those language features supported by Gfortran 4.9 and Intel 13.1.0 are currently allowed.  This also means that previous versions of these compilers are not supported, and major changes to the code to support earlier compilers (or Fortran 95) will not be accepted.  At some point in the future (when compiler support has improved), all Fortran 2008 features will be allowed.
+- All subroutines and functions *must* be properly documented.  This includes useful inline comments as well as comment blocks using the [ROBODoc](http://rfsber.home.xs4all.nl/Robo/manual.html) syntax.
+- For simplicity, json-fortran currently consists of one module file. It is not envisioned that it will ever need to expand to include multiple files (if it does, there would need to be a very good reason).