This is an automatically created page. Please do not edit this page.
NOMAD software and source code release
This page tracks the progress of all relevant NOMAD software projects
towards public source code release as Open Source and
APACHE 2.0 licensed software.
Purpose of the source code release
We as the NOMAD CoE want to make our work available for 3rd parties to use.
This means that 3rd parties need to access, understand, and are legally allowed
to use our work in the broadest possible context. This means we have to
make our source code publicly available, clean it up, and license the use of it.
ALLOW OTHERS TO USE YOUR HARD WORK, LET IT LIVE ON, DON'T LET IT DIE IN VAIN.
What source code is going to be released
The basic assumption is that all NOMAD code is on this GITLab (gitlab.rzg.mpg.de).
The list at the bottom list all GITLab projects of the NOMAD organisation.
Not all projects are necessary for 3rd parties to make use of NOMAD
(hackatons, forks, coordination projects, etc.). We will remove
unnecessary projects when they are identified.
Who is responsible
Short answer: You should know if you are responsible for a source code project.
Its hard for us to point fingers to specific people due to the ad-hoc nature
of the GITLab use. The list below shows the owners, masters, developers of
each project, if this information was available. The list also shows the
main authors of recent commits. So if you find yourself in this list, please
When must this be done
We already have request from people that want to use NOMAD software. This is
also relevant to proof NOMAD's success for the next proposal. These are
simple steps there is not reason for postponing them.
Do them as soon as possible and within the next weeks.
How to release your source code
This is much simpler than it sounds.
There are 5 simple steps that you have to take
Identify relevant projects
Apply a license to your code
Clean up your code
Document your code
Make your code publicly available
There will be (or already is) an issue called "Source code release" in each GITLab project.
You can use this for the following things
Comment to ask questions that are specific to your project
Comment to state that this project should not be made public, since it
is not a vital part of the overall NOMAD software
Comment to state that you have to use a different license than Apache 2.0
Close the issue to state that the process has been completed.
Add the license
You MUST add a LICENSE file at the top level of each of your GITLab projects.
To apply the Apache 2.0 license (the default NOMAD has chosen) use this file:
Licenses outside that list should be used only with a very good reason.
Please comment your projects source release issue if you have to
diverge from the Apache 2.0 license.
You SHOULD claim your copyright.
All source code files should have the following header (python example)
as the very first thing in them. Replace the  accordingly. Only legal names
of individual authors or institutions are allowed. Please do not use
NOMAD developer group as it was suggested before.
# Copyright 2016-2018 [A comma separated list of full author names without the brackets] # # 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 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License.
You can adapt this for the comment format of other source code languages.
clean up you code
You SHOULD clean up your code and make it something you are proud to show.
For Python, flake8 (or pylint) can help standardising the code.
We do not require all things they check, in particular I would definitely relax the maximum line length limit, and probably also the variable naming.
If someone is interested in tuning them and making them automatic would be welcome.
You MUST remove all private items (e.g. tokens, keys, other cryptographic information).
Document your code
You SHOULD document your code where appropriate.
You MUST write a brief README file. Markdown (README.md) is the canonical format choice.
The README should explain the purpose of your code, the context it is supposed
to be used in, any requirements for using it, and how it can be used.
Make your code publicly available
You MUST make your code publicly available. The gitlab.rzg.mpg.de is a public
source code hosting service. You just have to make your project public (instead of private or internal).
There are some issues with GITLab that might prohibit you from changing the
visibility of your project(s). Please leave a comment in
you project's issue that states if this project should be part of NOMAD's
public source base. You can try the following, although it might not work:
Use the settings section of your project on GITLab to achieve this (settings / general / permissions / public visibility).
The list of all projects in the GITLab organisation NOMAD
The user row shows GITLab users associated with the project. It shows
either owner, masters, or developers depending of whats there.
Not all projects actually have members.
The committer row shows the top 3 authors of the last 100 commits.
These are not GITLab users, but the names used during commit git. These
names depend on how you setup your local git command.
The rows on READMEs and LICENSEs show if there are respective files
(with no, ".md", or ".txt" ending) in the master branch.
The numbers behind READMEs and LICENSEs are the size of the respective file
The commits row refers to the total number of commits in the repository.
The issue row gives a link to the tracking issue and its current state.