fsfe / reuse-website Goto Github PK

https://reuse.software/tutorial/ does not explain how to put multiple copyright holders into a file header, although this is vital information for mature projects should they choose to adopt reuse.

@uniqx and I are currently working on improving translation workflows for Markdown using all free software (po4a and Weblate). We'd like to submit a pull request to make this site translatable using this workflow, and then submit it to free hosting on hosted.weblate.org.

This means:

• Breaking out the menu from site/config.toml to per-language files.
• Adding po4a.conf for managing the conversion to gettext PO format.
• Maintaining a po/ dir for the .po and .pot files which Weblate will work with.
• Adding a website pre-build step that makes po4a generate all the translated .md files

Is this something that you would accept?

There are several throughout the site, but they're most notable on the specification page.

This is a typical example of the link:
https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60

This is certainly an upstream problem--as even SPDX's own links to the v2.1 spec are 404...

However, SPDX is now at v2.3, so perhaps finding updated equivalence would be best.

I ran "reuse spdx" on the website repository (commit 0995165) and among others it reported:

FileName: ./site/static/img/organisations/huawei.png
SPDXID: SPDXRef-7bd68e2cfea7e7f44a6aab23757ccd3f
FileChecksum: SHA1: 41a9e5bd8d858eb86f815380d75ce020b0655cfd
LicenseConcluded: NOASSERTION
LicenseInfoInFile: CC-BY-SA-4.0
FileCopyrightText: <text>2019 Free Software Foundation Europe <https://fsfe.org></text>

I doubt that the FSFE holds copyright for this file and suspect license and copyright information are too unspecific at some place (probably a bug in the website?)

The Siemens logo has a separate .license file and was reported as:

FileName: ./site/static/img/organisations/gray/siemens.png
SPDXID: SPDXRef-1772acb13a58458f96e8bc5860eed12b
FileChecksum: SHA1: 59f1cda9e68a617086d6eb6e248c5de5cf1d5acd
LicenseConcluded: NOASSERTION
LicenseInfoInFile: CC-BY-SA-4.0
LicenseInfoInFile: CC0-1.0
FileCopyrightText: <text>2019 Free Software Foundation Europe <https://fsfe.org>
SPDX-FileCopyrightText: Siemens AG</text>

I guess this might be a bug in the reuse tool?

(I used reuse 1.0.0-1 from Debian testing/unstable.)

See title

From fsfe/reuse-tool#29

You can add a new page- To successfully merge 5 pull requests in https://github.com/fsfe, in 2 months, and get free stickers. This would help in more contributions, exposure, coz let's face it everybody likes free stuff 😃 And this would be a great step, I think.

That could make sense, especially since the REUSE tool is reusing AboutCode's license-expression library.
@mxmehl @carmenbianca Would a PR be fine by you? or do you prefer handling it?

Note also that I help maintain this list of tools https://wiki.debian.org/CopyrightReviewTools

What do you think about showing the logos of organisations, companies and well-known projects which use, comply with and support REUSE in the website's footer?

For instance, this could be done with greyed logos which one can hover over.

Hi folks,
Thank you very much for providing this repo. Please accept my appreciation! I did the following with this repository by now.

cd git/
git clone https://git.fsfe.org/reuse/website.git
cd website/site/
hugo server -D

If follows the response of the last hugo instruction here.

~/git/website/site$ hugo server -D
port 1313 already in use, attempting to use an available port
Total in 46 ms
Error: Error building site: "/home/user/git/website/site/data/organisations.json.license:1:1": unmarshal of format "" is not supported

It looks like hugo is not willing to swallow the *.license file. Had anyone else observed a behavior like this?

Cheers!

#57 seems to be incomplete, the referenced logo file is missing:

Currently, all links in the navbar link to the English version, even if viewing a translation and if there was a translation for that page the link leads to.

Unfortunately, the customised relref shortcode does not work here as it would have to be a partial, and I cannot get it to work.

Alternatively, we could just link to it and depend on the .htaccess rule to link back to the EN page if it's not present. It would work immediately in the deployed and Docker development version, but in local previews (with hugo server) it would not work.

Instead of hosting all versions of the spec on the website, why not simply point people to reuse-docs for prior versions of the spec? This simplifies the building of the website, and people who want prior versions of the spe probably won't be annoyed at having to dig a little deeper into a code repo.

Would you mind adding the OSS Review Toolkit to the Comparison of license compliance projects?

The website currently has quite some flaws and technical quirks which should be resolved in order to make maintenance easier. This is a collection of smaller todos:

• Remove all HTML from .md files in content/
• Create a proper HTML template for index page and single pages
• Put REUSE logo in navbar, and link to home page
• Clean up unused JS, CSS and TTF files
• Fix share buttons (see separate issue) and put in footer
• Fix menu on small screens (currently doesn't open)
• Make default text a bit larger, and more black, not light grey
• Add favicon

The common use-case for people starting with REUSE is to apply the headers to all files in the repository. The tutorial website doesn't currently hint at such a method, resulting in people wondering how to do so (I've had this question twice after pointing to the official docs). As was mentioned in a REUSE github issue already, this can be done by using $ git ls-files | xargs reuse addheader .... Hinting at the piping options would be helpful to people wanting to adopt REUSE.

I propose to mention it in these locations:

• Tutorial in the 2. Add copyright and licensing information to each file section
• Addheader documentation (I know, different repository)

What do you think?

E.g. in Ukrainian, the navbar becomes too long and breaks with the logo. One idea could be to have flexible spaces between the navbar item depending on the available width, e.g. with a flexbox.

The sharing buttons on the left look a bit buggy, and Google+ is also outdated.

We should align this with fsfe.org which uses Mastodon instead of GnuSocial (but may switch to "Fediverse" soon).

Ideally, they would also be present on all pages, e.g. in a floating sidebar like on publiccode.eu or in the footer. Any concrete ideas?

A. Problem / Goal

Since the purchase of GitHub by Microsoft in 2018, a dependence on the BigTech corporation can no longer be denied.

On the one hand, I can understand why GitHub was chosen as the platform for making source code available: "Everyone is here".

On the other hand, I see the danger of a vendor-lockin effect and that open source projects become centrally dependent on Microsoft. In my eyes, this is very dangerous for free and open source software and hardware projects.

In the medium and long term, the goal would be to become independent of GitHub and thus of Microsoft. The Gitea-based Codeberg project of Codeberg e. V. in Berlin would be a good choice here.

There are also (legal) problems with compliance with the licence of GitHub functions, such as the co-pilot.

B. Solution

My considered solution to the problem described in A. would be the following:

1. A user of this open source project creates a user account on https://codeberg.org/
2. If necessary: This user creates an organisation for the project.
3. A "personal access token" is created on the GitHub account, which has appropriate rights to the organisation repositories, using the developer options in the settings.
4. all repositories would be migrated with this access token into the ownership of the organisation created in step two.

Regarding step four, there is an entry in the documentation of Codeberg: https://docs.codeberg.org/advanced/migrating-repos/

C. Alternatives

A possible alternative would be to perform the first three steps as described in B. A possible alternative would be to perform the first three steps as described in B., and modify the fourth step to include a mirror of GitHub. So that all issues and such that would be created in the GitHub repository would be transferred to the Codeberg repository.

D. Responsibilities

I would see the responsibility in the owners of the repository and, if necessary, additional project participants.

E. Other

Basically, a look at the documentation of Codeberg is not unwise: https://docs.codeberg.org

Should it be necessary to manage repositories in organisations, this is also possible under Codeberg, see: https://docs.codeberg.org/collaborating/create-organization/

Regarding licensing there is a page in the documentation of Codeberg:
https://docs.codeberg.org/getting-started/licensing/

It would only be a mirror, which would be migrated to Codeberg. It would affect all GitHub repositories of the FSFE GitHub organisation.

F. Risk

Last but not least, it must be assumed that people could potentially create fewer issues because it is a new platform and it is less known. It remains to be seen how and when the principle of decentralisation or federation will be implemented in Gitea, on which Codeberg, the GitHub alternative, is based, see the following article: https://social.exozy.me/@ta180m/108631221939677386

There are so many projects about license compliance and related topics, e.g. ClearlyDefined, OpenChain, SPDX. What's REUSE's role in all of this?

We should have a page listing some of these projects and explaining why REUSE is unique and so needed, and how it does interact with these other projects.

I remembered there was online linter. I went to https://reuse.software/ and noticed giant "Confirm REUSE compliance"

Sadly, clicking on it did nothing. I expected it to link to https://reuse.software/dev/ or https://api.reuse.software/

Say I am using a Meson subproject with a wrap file gotten from Meson's WrapDB. reuse requires me to add licensing and copyright info about that file.

What isn't clear is how to ascertain that information. Many projects that generate files don't explicitly say the output of the project is licensed and copyrighted in some form or fashion.

Ideally it would be nice to just have a way for reuse to ignore these files since getting the info out of the project maintainers is not always easy nor is it explicit as is the case with the GNU Compiler Collection for instance.

If you clone the repo into a folder that has spaces in its name, then running /sync-docs.sh will fail:

diff: extra operand '/run/user/1000/reuse-docs.pot0e5M'
diff: Try 'diff --help' for more information.
 (278 entries)
Error: 'msgmerge /hdd/home/jayman/VC/Git/Partially
mine/reuse-website/reuse-docs/po/reuse-docs.cs.po
/hdd/home/jayman/VC/Git/Partially
mine/reuse-website/reuse-docs/po/reuse-docs.pot --previous
--add-location=file --no-wrap --backup=none --update' exited with value 1.

This is a tool I built with git hooks: https://github.com/mte90/gh-license

Basically by a user check on github or bitbucket check if all the repositories have a license files. With git hooks does the same but at every commit and let you to download a license and add a badge in the readme.