project license not OS conform and difficult to use

[vbasem]

I am sorry if this is a touchy subject, but I find it difficult to work with the license as it is right now.

1. Github project doesnt have a license
2. Attribution in the "wanted" form requires manual work
3. Tooling will have to work the difference between TEST and others

I assume these are legal requirements from your company, but perhaps we have some room to simplify and set an example

[kreincke]

Dear vbasem;

many thanks for your review. We really appreciate being noticed so early. Please let us add the following remarks: Our test cases shall follow the pattern of test-driven software development. Therefore, they contain the test data (the program sources = input-sources) and the expectable reference results. The tools shall work on the test-data. And their results shall be compared with the reference compliance artifacts to see, what they already can and what is still missed:

1. Inside of 'input-sources' you find the real software. This software is licensed as GNU programs have to be licensed. Moreover, the software contains particular license traps that should be managed by the compliance tools.
2. As mentioned in README, all other compliance artifacts and docs are licensed under the CC-BY-SA. If you think, that we should mention the different licensing statements in a LICENSE file, we could do so. But at the end, there will never be 'the one license' of the GitHub repository, because the test data (= input-sources) cannot be as licensed as the reference data (compliance artifacts)
3. We do not exactly know what do you mean with the 'wanted form'. But in general, we also feel that we still have to do to much work manually. For us, it is not optimal to reduce the complexity of the cases to a level that is servable by the tools work. We want to increase the capabilities of the tools to a level on which to compliance work can completely be done automatically.

We can assure you that the requirements are not specific! If you distribute the software in input-sources - especially if you are only distributing the binaries -, then you must distribute any equivalent of the OSCF.md together with your package. That's not a matter of the viewpoint of a company, but a matter of the license requirements. At the end of our work we need a tool chain that generates such a file automatically.

So, what can we do? We would be happy if you are able to preserve the idea and the structure of our TDOSCA test cases. If you think, that our reference documents could be improved, we would be glad to get your proposals. But if you feel that in general there should be use cases structured in another way, please feel free to clone our material (you may do - as our licensing statements say), modify it in the way you want to have, and create your own repository. It is always good for the community to be able to choose from different approaches.

we are looking forward to your comments KR

[vbasem]

Karsten,

my humble thanks for the very detailed response.

My view is from the software and tooling side. This particular use case is usually seen with AND licenses which can be placed in a license file. A clarification in the README is then cherry on top.

It was never my intention t o dispute the legal requirements regarding the individual binaries. Rather just the license of this project itself.

On the last point File originates from https://github.com/Open-Source-Compliance/tdosca-tc02-plainhw initiated by Deutsche Telekom AG , I understand the reasoning behind this, but I would never want to force my users to include attribution in a wanted format. This kills any automation. A standard copyright attribution from license file(s), helps to deal with this in an automated way.

I understand that some of the license issues are yet to be solved, but this is a good example why it becomes more complex to use something to due custom requirements.

A possible solution would be reuse / spdx to define the license for their packages/folders?

top level --dual license--

• src --permisive license file--
• test --gpl license file--