SPDX and reuse.software

https://reuse.software/dev/ describes approaches to generate a SPDX file and how to apply license headers. Today this is not combinded with the efforts from the todogroup and it's repolinter but I think it would be worth to use those approaches to simplify license compliance for bacstack.

@bufferoverflow

Hi @bufferoverflow

Thanks for the proposal.

However, I personally think this project is already extremely good in shape regarding license compliance. The project has a proper license definition (MIT, see package.json and LICENSE.md) which applies for the whole project. Furthermore, each commit is scanned regarding license compliance (see here).

My personal opinion on this is, that SPDX files only add complexity to license compliance topics instead of solving the root cause (mixed licenses in projects due to wrong modularisation) while license headers also add further complexity and are a thing of the past and almost never used for newer style projects. I think that NPM is in that regards a role model for other eco systems: the majority of packages have a single, permissive license (MIT) and use proper SPDX license identifier for the whole project. We should invest more time for identifying non-compliant packages and correct them instead of building complex workarounds.

Your thought on this?

Cheers

@fh1ch

@fh1ch yes, the project is already in a very good shape in regard of license compliance. However, there are a few aspects that can be improved and I will prepare a PR so you can see what I think we should do to make this project a best in class in regard of the license topic as well.

here another topic worth to look at https://bestpractices.coreinfrastructure.org/

@bufferoverflow

@bufferoverflow thanks for providing an MR!

However, I strongly oppose the idea of copyright/license headers and try to prevent the introduction of such antiquated patterns whenever possible.

The Apache Foundation discourages the use of copyright headers for very good reasons: https://opensource.com/law/14/2/copyright-statements-source-files
Copyright headers are redundant, since every file/work is inherently protected by the copyright law. E.g. see: http://geotoolsnews.blogspot.de/2016/07/copyright-headers-in-source-code-files.html
Copyright header create extensive maintenance efforts for keeping them up-to-date (e.g. updating copyright years)
Copyright header create a lot of noise (commit and file)
This project just reached 100% in the FLOSS license chapter of https://bestpractices.coreinfrastructure.org/ without copyright/license headers
There is a single point to look at (package.json) to see all the licenses, without the need to scan each file

I therefore consider this project already as in a good shape and see the introduction of copyright/license header as quality reduction.

I agree partial on copyright handling within individual files, especially the year is something to remove. As you know reuse is also done file level and people do copy individual files to other projects, that's why a license within each file makes sense.

I'm also a strong believer in headerless source code. I'd say there are way more arguments against copyright / license headers than there are pros.

The strongest argument for still having the headers when using an already permissive license is to make it clear that there is no default copyright. But I'd argue that this is not really a valid argument: As soon as a code snippet or file has been copied and put out of context (which the license allows), the question becomes immediately obsolete, Why still keeping a copy-OK statement in the file which would anyway not do mutch if it would have been copied only partially.

I'd say a friendly programmer would add a link to the original project/file in such a case. So it would probably make more sense to put a self referencing link in the header, that would make it much more trackable anyway. However, I also think this is not necessary and is up to the user.

Please provide me some examples of well established open source projects using that headerless source code approach.

@kfenner

@kfenner thank you very much for representing your view on this topic. Those aspects, which I honestly forgot about, empower even more, that headerless source code is the way to go.

@bufferoverflow see following list of established Open Source projects which use this approach:

Bootstrap is not fully true, still using license headers in js files:

/**
 * --------------------------------------------------------------------------
 * Bootstrap (v4.0.0-beta.3): tab.js
 * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
 * --------------------------------------------------------------------------
 */

But Vue is a beautiful example 👍

A two liner simplifies things a lot, especially for the users and the involved license compliance processes. That's why I believe it is worth to add the minimum with the relevant facts here as well.

First of all, I would like to thank all participant of this discussion. It was fascinating talk and we brought together an amazing list of arguments. However, based on GitHub's OSS best practise, including the fact that this discussion switched from an exchange of hard facts to an exchange of personal opinions, we shall close this issue and focus on producing value by fixing issues and adding features. Following outcome has been extracted from the discussion:

2 out of 3 maintainer voted against the introduction of license and copyright headers, so the majority is against it and we shall honour that.

Some other statements I would like to make:

As this project complies with the Headerless.org initiative criteria, I prepared PR [WIP] docs(readme): add Headerless.org badge #88 to state the fact even clearer ().
While this project was good in shape in regards of license compliance, some far more essentials OSS best practises have been missing (e.g. CONTRIBUTING.md, CODE_OF_CONDUCT.md, ...), which have been added as part of PR Chore/community templates #86.
The changes of PR Chore/community templates #86 bumped the rating of this project in GitHub's Community Analysis to 100% and let all checks of repolinter (except the copyright-header warnings) pass.
As repolinter almost exclusively checks the existence/inexistence of files in a repository on a extremely high level, I don't see any value of adding it to the CI change, compared to run it once locally.
The Core Infrastructure Project has a far more detailed checks and goes way beyond what repolinter does, while covering all of its checks as well. Furthermore, it doesn't require anything to be added as a dependency, since it's a independent service.
I've created issue Check compliance with Core Infrastructure best practises #91 to add this project to the Core Infrastructure Project and check if we comply with it's guidelines.

I hope this summary and outcome is satisfying for all participants. Feel free to re-open this issue if you feel certain aspects haven't been touched at all, but I would like to invite you otherwise to push this project further and reach feature completeness.

Navigation Menu

Repository navigation

SPDX and reuse.software #83

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

SPDX and reuse.software #83

Description

Activity

fh1ch commented on Dec 27, 2017

bufferoverflow commented on Dec 27, 2017

bufferoverflow commented on Dec 27, 2017

fh1ch commented on Dec 27, 2017

bufferoverflow commented on Dec 27, 2017

kfenner commented on Dec 29, 2017

bufferoverflow commented on Dec 29, 2017

fh1ch commented on Dec 29, 2017

kfenner commented on Dec 29, 2017

bufferoverflow commented on Dec 29, 2017

fh1ch commented on Dec 31, 2017

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions