Everybody is invited to contribute any material, which will ease and / or reduce the effort of OSS license compliance activities. A contribution can be a Debian copyright file, an SPDX document or any other "machine & human friendly" format of an OSS package analysis file. Further contributions can be:
- A license text found in the internet which is not yet part of any official license text repo like the SPDX(R) license list
- Clarifications with OSS projects
- Collaboration with OSS projects to "ease" OSS license compliance
- Further material, e.g. "OSS disclosure documents"
- Software or tools, such as SPDX comparison or analysis tools
- Export Control and Customs (ECC) classifications, license exception TSU (Technology and Software Unrestricted)
- and any other material which makes life in OSS compliance easier. If you represent a company and you do consider to contribute material, we do not interpret the material which is contributed as an indicator of the maturity of the established processes.
Like any other state of the art OSS project, we need a prove that all information / tools / documents /or any other contributions are contributed with the right and allowance to do so. We need a Certificate of Origin. This does not imply relevant additional efforts; for example, every Linux kernel developer is familiar with this approach. Please understand that we cannot accept and make any contribution available via our sites which are not accompanied by the certificate of origin.
Sharing creates value use a very similar procedure like it is implemented for the Linux kernel development, because we think that this procedure is proven that it functions and that it is not a hurdle which hinders contributions. If you want to check how the Linux Kernel handles it, it is described at "Sign Off" for Linux kernel development section 11) Sign your work - the Developer's Certificate of Origin.
Although we need a certificate of origin, contributors can request that their contributions will be made available in an “anonymous way", i.e.the contributors are not visible anymore. We will keep the certificate private and do not disclose it (we need this only for our records that we have a prove that the contribution was done in a correct legal way). The anonymous contribution way might motivate companies to share any material listed in without being afraid that they are exposed in a matter they do not want to be. In order to "make use of this option" please read option "e" in the certificate of origin. The procedure we have the following procedure defined:
For license hygiene we require all contributions to be licensed under Creative Commons Public Domain Dedication CC0-1.0
Certificate of origin
The sign-off is a simple line at the end of the explanation for the contribution, which certifies that you wrote it or otherwise have the right to pass it on as an open-source contribution. The rules are pretty simple: if you can certify the below:
Contributor's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
then you just add a line saying
Signed-off-by: Random J Developer <random@developer.example.org>
(e) If for some reason you do not want that your name is published please indicate this in your signed-off statement.
Please note although we do not disclose your name we keep your name internally, so that we have a prove that
you had the right to submit the contribution.
for being not disclosed add a line saying
Signed-off-by - no name disclosure: Random J Developer <random@developer.example.org>
A review of the contribution will take place, and when the contribution is accepted it will be integrated into our asset pool and thus made available to the public. If we ask to rework your contribution be persistent and resubmit after making the changes.
If you are still uncertain how and what to conntribute or if you want to make a contribution, without being disclosed as contributor, send me an email
One of the main questions or concerns which might hinder either the use or the contribution of OSS package analysis files is the question whether we or the contributor will be liable if there is a mistake in such a file. In order to answer this fundamental question we asked for legal advice. The following is the summary of the legal advice in our words: Assuming that those files are protected by copyright they need to be licensed so that they can be used. We license the files under CC0 1.0 which is very near to "public domain" to make the use to them as easy as possible. Furthermore, the files can be downloaded and used ‘free of charge’. These documents are so to say a donation. For donations there is liability only in case of willfulness or in a case of gross negligence. The process how the files are generated and which tools are used is described. Therefore, it can be reviewed and the tools can be evaluated. Moreover, the persons who process the tool output do have several years of experience in this area. We think that the risk of being liable is very little. As any other OSS project, we also have implemented the common approach how to improve and to ensure quaility. If you have doubts about the correctness of the content of the OSS package analysis files you simply can file an issue and we will look at it, analyse it, provide feedback and in case there is an error in such a file we will correct it in a timely manner.
This question depends on your point of view, whether you trust this project and whether you think that the way how the files are generated is suited to provide accurate and reliable information. We think that the process is defined in a way that following it will result in high quality information; nevertheless there is always the possibility that a used tool misses information or the person who processes the tool output makes a mistake. If you identify an error we are happy if you file an issue so that we are able to fix it.
You are able to evaluate, reveiw and compare the published results with your own results, if you identifiy differences you can re-check your results or file an issue here. Even if you do not trust in the here published result, this project helps you to do a cross check of the quality of your implemented proceses.
the naming convention is straight forward, it is like this
OSS-Package-Analysis-Files
|
|
--- Vendor
|
|
--- Product
|
|
--- Version_1
--- Version_2
--- Version_n
In case the Vendor is a foundation like the Apache Software Foundation the convention is to write Apache_Software_Foundation. In case the vendor is an individual the convention is to right Name_Surname, e.g. John_Doe
Example:
Apache_Software_Foundation
httpcomponents-client
4.5.1
Michael_Riepe
libelf
0.8.13