Please include weblabels for javascript #6236

New Issue

GiteaMirror · 2025-11-02T06:49:22-06:00

GiteaMirror commented

2025-11-02 06:49:22 -06:00

Originally created by @gnusupport on GitHub (Nov 1, 2020).

This is follow up of the issue wrongly filed here:
https://gitea.com/gitea/website/issues/99#issuecomment-119899

Solution on how to do it is here:
https://www.gnu.org/software/librejs/free-your-javascript.html

Many users of FSf endorsed distributions use LibreJS and many other GNU/Linux users. It is desirable for new users coming to the website to know that javascript is also free software. Those users may not be able to find licenses or crawl the site to find details, browser may warn them or give a green light.

It would be very nice if you include that as that may influence thousands of people in future and other projects as well. Thank you.

Originally created by @gnusupport on GitHub (Nov 1, 2020). This is follow up of the issue wrongly filed here: https://gitea.com/gitea/website/issues/99#issuecomment-119899 Solution on how to do it is here: https://www.gnu.org/software/librejs/free-your-javascript.html Many users of FSf endorsed distributions use LibreJS and many other GNU/Linux users. It is desirable for new users coming to the website to know that javascript is also free software. Those users may not be able to find licenses or crawl the site to find details, browser may warn them or give a green light. It would be very nice if you include that as that may influence thousands of people in future and other projects as well. Thank you.

GiteaMirror added the type/proposal issue/needs-feedback labels 2025-11-02 06:49:22 -06:00

GiteaMirror closed this issue

2025-11-02 06:49:22 -06:00

GiteaMirror commented

2025-11-02 06:49:23 -06:00

@lafriks commented on GitHub (Nov 1, 2020):

Problem is that imho there is no way we can generate it with webpack automatically and keeping it updated manually for each javascript library we use takes too much work. If you can suggest any way to do that automatically we are open to PR on that

@lafriks commented on GitHub (Nov 1, 2020): Problem is that imho there is no way we can generate it with webpack automatically and keeping it updated manually for each javascript library we use takes too much work. If you can suggest any way to do that automatically we are open to PR on that

GiteaMirror commented

2025-11-02 06:49:23 -06:00

@6543 commented on GitHub (Dec 3, 2020):

ref https://forge.softwareheritage.org/source/swh-web/browse/master/swh/web/assets/config/webpack-plugins/generate-weblabels-webpack-plugin/

@6543 commented on GitHub (Dec 3, 2020): ref https://forge.softwareheritage.org/source/swh-web/browse/master/swh/web/assets/config/webpack-plugins/generate-weblabels-webpack-plugin/

GiteaMirror commented

2025-11-02 06:49:23 -06:00

@realaravinth commented on GitHub (Feb 8, 2022):

I use a hack-ish script in one of my projects and it seems to do the job. I could adapt it to Gitea, thoughts?

aside: the page @6543 linked to no longer exists, here's an old archive.org snapshot of the same.

@realaravinth commented on GitHub (Feb 8, 2022): I use a [hack-ish script](https://github.com/mCaptcha/mCaptcha/blob/master/scripts/librejs.sh) in one of my projects and it seems to do the job. I could adapt it to Gitea, thoughts? aside: the page @6543 linked to no longer exists, here's an old [archive.org snapshot](https://web.archive.org/web/20190922024604/https://forge.softwareheritage.org/source/swh-web/browse/master/swh/web/assets/config/webpack-plugins/generate-weblabels-webpack-plugin/) of the same.

GiteaMirror commented

2025-11-02 06:49:23 -06:00

@iambeingtracked commented on GitHub (Jul 16, 2022):

Is there any progress on that? I really want gitea to be LibreJS compatible

@iambeingtracked commented on GitHub (Jul 16, 2022): Is there any progress on that? I really want gitea to be LibreJS compatible

GiteaMirror commented

2025-11-02 06:49:24 -06:00

@wolftune commented on GitHub (Jan 23, 2024):

Even if complete LibreJS support isn't done, can some workaround be made to do something to make it easier for curious people to find the corresponding source code to the minified JS that Gitea serves?

Basically, some direction to the relevant source projects that facilitates this so that people don't have to struggle to search around to find obscure links…

@wolftune commented on GitHub (Jan 23, 2024): Even if complete LibreJS support isn't done, can some workaround be made to do *something* to make it easier for curious people to find the corresponding source code to the minified JS that Gitea serves? Basically, some direction to the relevant source projects that facilitates this so that people don't have to struggle to search around to find obscure links…

GiteaMirror commented

2025-11-02 06:49:24 -06:00

@lunny commented on GitHub (Jan 24, 2024):

I think we already have https://gitea.com/assets/licenses.txt , and a link has been displayed under footer of every Gitea instance. So we just need a tool do convert it the suitable format?

@lunny commented on GitHub (Jan 24, 2024): I think we already have https://gitea.com/assets/licenses.txt , and a link has been displayed under footer of every Gitea instance. So we just need a tool do convert it the suitable format?

GiteaMirror commented

2025-11-02 06:49:24 -06:00

@wolftune commented on GitHub (Jan 24, 2024):

I think we already have https://gitea.com/assets/licenses.txt , and a link has been displayed under footer of every Gitea instance. So we just need a tool do convert it the suitable format?

I have a hard time reading that and knowing: does it contain (or is it generated by something that has) all the info not just about license but about the source files? What I'm most obviously missing in licenses.txt is a way to find the associated non-minified source code. I only see stuff like brace-expansion@2.0.1 with a license, and that doesn't tell me where to find the source code for that.

@wolftune commented on GitHub (Jan 24, 2024): > I think we already have https://gitea.com/assets/licenses.txt , and a link has been displayed under footer of every Gitea instance. So we just need a tool do convert it the suitable format? I have a hard time reading that and knowing: does it contain (or is it generated by something that has) all the info not just about license but about the source files? What I'm most obviously missing in licenses.txt is a way to find the associated non-minified source code. I only see stuff like `brace-expansion@2.0.1` with a license, and that doesn't *tell* me where to find the source code for that.

GiteaMirror commented

2025-11-02 06:49:25 -06:00

@lunny commented on GitHub (Jan 24, 2024):

All js package could be searched on npmjs.org, all go package can be visited directly with the package url. I know it's not convinent like a html and links. But we need a suitable tool to generate that format.

@lunny commented on GitHub (Jan 24, 2024): All js package could be searched on npmjs.org, all go package can be visited directly with the package url. I know it's not convinent like a html and links. But we need a suitable tool to generate that format.

GiteaMirror commented

2025-11-02 06:49:25 -06:00

@wolftune commented on GitHub (Jan 25, 2024):

Would it be easy enough for the licenses.txt file to have a note added to it that says that the source files are available on npmjs.org?

What about maybe changing the generated file so that brace-expansion@2.0.1 has a link to https://www.npmjs.com/package/brace-expansion/v/2.0.1 ?

Anyway, it seems indeed the full weblabels support would work with just a tool to convert licenses.txt appropriately. I guess it does have all the necessary information, yeah?

@wolftune commented on GitHub (Jan 25, 2024): Would it be easy enough for the licenses.txt file to have a note added to it that says that the source files are available on npmjs.org? What about maybe changing the generated file so that `brace-expansion@2.0.1` has a link to `https://www.npmjs.com/package/brace-expansion/v/2.0.1` ? Anyway, it seems indeed the *full* weblabels support would work with just a tool to convert licenses.txt appropriately. I guess it does have all the necessary information, yeah?

GiteaMirror commented

2025-11-02 06:49:25 -06:00

@wxiaoguang commented on GitHub (Feb 6, 2025):

The licenses are also packed into https://gitea.com/assets/js/index.js.xxxxxxxx.map, and also here https://gitea.com/assets/licenses.txt

IMO as in the modern world, JS tools (like LibreJS) should be able to use the map file to detect the license, but not force developers to keep filling the licenses into JS code (it causes unnecessary bandwidth traffic for most users)

And the licenses are also checked by :

943cc4f989/webpack.config.js (L255)

@wxiaoguang commented on GitHub (Feb 6, 2025): The licenses are also packed into `https://gitea.com/assets/js/index.js.xxxxxxxx.map`, and also here `https://gitea.com/assets/licenses.txt` IMO as in the modern world, JS tools (like LibreJS) should be able to use the map file to detect the license, but not force developers to keep filling the licenses into JS code (it causes unnecessary bandwidth traffic for most users) ---- And the licenses are also checked by : https://github.com/go-gitea/gitea/blob/943cc4f98952431c4e95a62301d56bcc7b708338/webpack.config.js#L255

GiteaMirror commented

2025-11-02 06:49:25 -06:00

@lunny commented on GitHub (Feb 6, 2025):

One possible solution is to create a licenses.html file instead of licenses.txt. This file could include links to relevant sources such as the NPM and Golang package sites, as well as a license definition website. However, since all JavaScript files have been bundled, none of these links can point directly to Gitea itself.

That said, I’m unsure how to implement this using the current LicenseCheckerWebpackPlugin Webpack plugin. Any insights or suggestions would be appreciated.

Update: maybe we need this one https://forge.softwareheritage.org/source/swh-web/browse/master/swh/web/assets/config/webpack-plugins/generate-weblabels-webpack-plugin/

@lunny commented on GitHub (Feb 6, 2025): One possible solution is to create a licenses.html file instead of licenses.txt. This file could include links to relevant sources such as the NPM and Golang package sites, as well as a license definition website. However, since all JavaScript files have been bundled, none of these links can point directly to Gitea itself. That said, I’m unsure how to implement this using the current `LicenseCheckerWebpackPlugin` Webpack plugin. Any insights or suggestions would be appreciated. Update: maybe we need this one https://forge.softwareheritage.org/source/swh-web/browse/master/swh/web/assets/config/webpack-plugins/generate-weblabels-webpack-plugin/

GiteaMirror commented

2025-11-02 06:49:25 -06:00

@GiteaBot commented on GitHub (Mar 8, 2025):

We close issues that need feedback from the author if there were no new comments for a month. 🍵

@GiteaBot commented on GitHub (Mar 8, 2025): We close issues that need feedback from the author if there were no new comments for a month. :tea:

GiteaMirror commented

2025-11-02 06:49:26 -06:00

@wolftune commented on GitHub (Mar 9, 2025):

Seems really weird to call an issue "completed" as the type of closure when what actually happened was a no-activity-bot just closed it. Can't there be a reason like "inactive" or something more accurate?

Anyway, this is still something people want done, and it isn't completed

@wolftune commented on GitHub (Mar 9, 2025): Seems really weird to call an issue "completed" as the type of closure when what actually happened was a no-activity-bot just closed it. Can't there be a reason like "inactive" or something more accurate? Anyway, this is still something people want done, and it isn't completed

GiteaMirror commented

2025-11-02 06:49:26 -06:00

@wxiaoguang commented on GitHub (Mar 9, 2025):

It is auto closed by the bot. I changed the closed type to "not planned" now.

Feel free to reopen if there are some feasible methods for it. Keeping stale issues without feasible approaches don't seem useful.

@wxiaoguang commented on GitHub (Mar 9, 2025): It is auto closed by the bot. I changed the closed type to "not planned" now. Feel free to reopen if there are some feasible methods for it. Keeping stale issues without feasible approaches don't seem useful.

GiteaMirror commented

2025-11-02 06:49:26 -06:00

@gnusupport commented on GitHub (Mar 10, 2025):

Solution how to do it was given in the original post.

@gnusupport commented on GitHub (Mar 10, 2025): Solution how to do it was given in the original post.

GiteaMirror commented

2025-11-02 06:49:27 -06:00

@gnusupport commented on GitHub (Mar 10, 2025):

Of course there are freedom issues related to accessing Gitea.

@gnusupport commented on GitHub (Mar 10, 2025): ![Image](https://github.com/user-attachments/assets/92b73756-d42a-46df-9f6b-5a25626a00ce) Of course there are freedom issues related to accessing Gitea.

GiteaMirror commented

2025-11-02 06:49:27 -06:00

@gnusupport commented on GitHub (Mar 10, 2025):

It is indeed up to the authors of software to decide whether they want to ensure their software is all free software and whether they wish to signal this to users. If they choose not to use weblabels, it may indicate a lack of priority or interest in this aspect, as suggested by the fact that addressing this issue took around five years.

As for why someone might care, the presence of weblabels can be crucial for users who rely on software freedom indicators to make informed decisions about using and supporting software projects. Without weblabels, Gitea might not be promoted as truly free software, which could be a consideration for users or developers who prioritize software freedom. However, the decision ultimately rests with the developers of Gitea, who may choose to prioritize other features or developments over weblabel implementation.

@gnusupport commented on GitHub (Mar 10, 2025): It is indeed up to the authors of software to decide whether they want to ensure their software is all free software and whether they wish to signal this to users. If they choose not to use weblabels, it may indicate a lack of priority or interest in this aspect, as suggested by the fact that addressing this issue took around five years. As for why someone might care, the presence of weblabels can be crucial for users who rely on software freedom indicators to make informed decisions about using and supporting software projects. Without weblabels, Gitea might not be promoted as truly free software, which could be a consideration for users or developers who prioritize software freedom. However, the decision ultimately rests with the developers of Gitea, who may choose to prioritize other features or developments over weblabel implementation.

GiteaMirror commented

2025-11-02 06:49:27 -06:00

@wxiaoguang commented on GitHub (Mar 10, 2025):

Disclaimer: I am just one maintainer who occasionally maintains stale issues/PRs, my opinion doesn't stand for the community's (community could disagree with me). Gitea is heavily crowd-contributed, so if there are feasible improvements and people like them, it's always welcome.

Solution how to do it was given in the original post.

The problem is: does it really work for a modern web application? I have briefly read that solution, it overall means to embed licenses into web page's source.

Take Gitea as an example, it has huge amount of dependencies, the license file public/assets/licenses.txt is about 1.3M (frontend + backend).

How to "include" these licenses to web pages?

Really appreciated if you could help to figure out a feasible approach to make weblables work properly. Thank you very much.

A simple demo based on Gitea's code would be quite helpful.

@wxiaoguang commented on GitHub (Mar 10, 2025): Disclaimer: I am just one maintainer who occasionally maintains stale issues/PRs, my opinion doesn't stand for the community's (community could disagree with me). Gitea is heavily crowd-contributed, so if there are feasible improvements and people like them, it's always welcome. ---- > Solution how to do it was given in the original post. The problem is: does it really work for a modern web application? I have briefly read that solution, it overall means to embed licenses into web page's source. Take Gitea as an example, it has huge amount of dependencies, the license file `public/assets/licenses.txt` is about 1.3M (frontend + backend). How to "include" these licenses to web pages? Really appreciated if you could help to figure out a feasible approach to make weblables work properly. Thank you very much. A simple demo based on Gitea's code would be quite helpful.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#6236