darin755 commented

Needs and benefits

Currently Forgeio and all sites that use have free JavaScript that isn't recognized by librejs. This is a problem because without the proper licensing tags people don't know there rights to the libre code.

Feature Description

Librejs reads the licenses of JavaScript and blocks those that don't have finable licenses. It finds licenses though licenses embedded in JavaScript or a separate file. Adding this to Forgejo shouldn't be to complex and I am willing to look into doing it.

This issue is mostly to get the options of the community.

Screenshots

No response

### Needs and benefits Currently Forgeio and all sites that use have free JavaScript that isn't recognized by librejs. This is a problem because without the proper licensing tags people don't know there rights to the libre code. ### Feature Description Librejs reads the licenses of JavaScript and blocks those that don't have finable licenses. It finds licenses though licenses embedded in JavaScript or a separate file. Adding this to Forgejo shouldn't be to complex and I am willing to look into doing it. This issue is mostly to get the options of the community. ### Screenshots _No response_

👍 2 👀 3

darin755 added the

enhancement/feature

label

2023-10-22 22:58:46 +02:00

Gusted commented

2023-10-22 23:07:47 +02:00

Owner

There's https://codeberg.org/assets/js/licenses.txt, which is present in the footer. It contains the license of all javascript & Go dependencies.

darin755 commented

2023-10-23 05:08:56 +02:00

Author

I'll see if I can figure out why it isn't being detected

banaanihillo commented

2023-11-04 12:54:17 +01:00

Contributor

Did anyone pick this up yet? I tried looking for how the license tags work but couldn't figure out if it is not detected due to being minified code or if it was another issue altogether

Gusted commented

2023-11-04 13:53:39 +01:00

Owner

Maybe a issue over on LibreJS should be made, but for what's worth it seems like it once worked with LibreJS but because it's not a format that can be generated it was removed.

Maybe a issue over on LibreJS should be made, but for what's worth it seems like it once worked with LibreJS but because it's not a format that can be generated it [was removed](https://github.com/go-gitea/gitea/issues/11630).

delgh1 commented

2023-12-03 06:38:44 +01:00

Is anyone working on this? I'm not good at these things but would like to see it implemented.

wolftune commented

2023-12-29 23:52:16 +01:00

Note: I and some others are working to evaluate Codeberg for listing at https://www.gnu.org/software/repo-criteria-evaluation.html

Functioning with LibreJS is criterion B0, and resolving this issue will give a passing grade there. I have not investigated whether the best fix involves some work on the LibreJS side, I'm just doing the evaluation of the status quo.

Note: I and some others are working to evaluate Codeberg for listing at https://www.gnu.org/software/repo-criteria-evaluation.html Functioning with LibreJS is criterion B0, and resolving this issue will give a passing grade there. I have not investigated whether the best fix involves some work on the LibreJS side, I'm just doing the evaluation of the status quo.

wolftune referenced this issue from Codeberg/Community

2023-12-30 06:53:43 +01:00

GNU LibreJS detects some unlicensed JS #64

n0toose commented

2023-12-30 14:56:38 +01:00

Member

Functioning with LibreJS is criterion B0, and resolving this issue will give a passing grade there.

I've taken a look at the page before and noticed the absence of Codeberg there, I felt like looking into that LibreJS stuff but it seems like the support got the plug at the Gitea level.

Would LibreJS deem files containing SPDX headers that declare the use of an FSF-approved license or entire repositories (in this case, the latter is very hard) using https://reuse.software (by the FSFE)? What do you define as a passing grade?

> Functioning with LibreJS is criterion B0, and resolving this issue will give a passing grade there. I've taken a look at the page before and noticed the absence of Codeberg there, I felt like looking into that LibreJS stuff but it seems like the support got the plug at the Gitea level. Would LibreJS deem files containing SPDX headers that declare the use of an FSF-approved license or entire repositories (in this case, the latter is very hard) using https://reuse.software (by the FSFE)? What do you define as a passing grade?

👍 1

wolftune commented

2023-12-30 16:35:21 +01:00

Yes, the original GNU repo reviews were done before Codeberg existed I believe, and since then some of the volunteers reviewed SourceHut, and GitLab was updated to failing after passing before (GitLab has gotten worse, more invasive third-party requests, more proprietary, etc). This effort now is the first time for GNU reviewing Codeberg.

For LibreJS to work, the JS needs to be marked as described at https://www.gnu.org/software/librejs/manual/html_node/Setting-Your-JavaScript-Free.html#License-tags

The current file at https://codeberg.org/assets/js/index.js has no appropriate tagging. Somewhere in the file, there is a mention of license with a link to a GitHub repo which happens to show MIT license, but that is only able to be determined by going to the link. I don't understand how that index.js gets to be there for the Codeberg deployment from the Forgejo code.

In order to support LibreJS, any deployed Forgejo instance needs to automatically have the necessary license tags be correct regardless of JS minification or whatever. I know that at one point having a separate file that declared JS licenses worked. LibreJS has been updated though, and I'm really not clear on the details myself, I'm just doing my best to facilitate. I tested Codeberg with LibreJS and found that the JS was blocked because license was not recognized.

Btw, there is an upstream Gitea ticket (though no insights there): https://github.com/go-gitea/gitea/issues/13393

Yes, the original GNU repo reviews were done before Codeberg existed I believe, and since then some of the volunteers reviewed SourceHut, and GitLab was updated to failing after passing before (GitLab has gotten worse, more invasive third-party requests, more proprietary, etc). This effort now is the first time for GNU reviewing Codeberg. For LibreJS to work, the JS needs to be marked as described at https://www.gnu.org/software/librejs/manual/html_node/Setting-Your-JavaScript-Free.html#License-tags The current file at https://codeberg.org/assets/js/index.js has no appropriate tagging. Somewhere in the file, there is a mention of license with a link to a GitHub repo which happens to show MIT license, but that is only able to be determined by going to the link. I don't understand how that index.js gets to be there for the Codeberg deployment from the Forgejo code. In order to support LibreJS, any deployed Forgejo instance needs to automatically have the necessary license tags be correct regardless of JS minification or whatever. I know that at one point having a separate file that declared JS licenses worked. LibreJS has been updated though, and I'm really not clear on the details myself, I'm just doing my best to facilitate. I tested Codeberg with LibreJS and found that the JS was blocked because license was not recognized. Btw, there is an upstream Gitea ticket (though no insights there): https://github.com/go-gitea/gitea/issues/13393

Gusted commented

2023-12-30 17:12:13 +01:00

Owner

There's a generated list of licenses at https://codeberg.org/assets/licenses.txt, that includes all javascript and Go licenses of the used dependencies. I understand from https://www.gnu.org/software/librejs/free-your-javascript.html#step3 that it needs to be formatted in this special HTML format in order to be recognized (with the appropriate linking rel="jslicense" on every page), at one point there was this list but has been removed as it wasn't possible to generate this trough current tooling https://github.com/go-gitea/gitea/issues/11630 and it still seems to be the case.

There's a generated list of licenses at https://codeberg.org/assets/licenses.txt, that includes all javascript and Go licenses of the used dependencies. I understand from https://www.gnu.org/software/librejs/free-your-javascript.html#step3 that it needs to be formatted in this special HTML format in order to be recognized (with the appropriate linking `rel="jslicense"` on every page), at one point there was this list but has been removed as it wasn't possible to generate this trough current tooling https://github.com/go-gitea/gitea/issues/11630 and it still seems to be the case.

wolftune commented

2024-01-23 20:26:44 +01:00

The other practical issue (whether LibreJS specifically recognizes it or not) is facilitating access to the non-minified original source files. It's not enough to have the licenses, the links to the source code is the other piece of the puzzle. Having that would be a big step even if LibreJS still doesn't work.

fnetX added the

Gain

Undefined

label

2025-01-24 03:38:34 +01:00

fnetX commented

2025-01-24 03:39:35 +01:00

Owner

For the record, since this issue was last updated, a non-free dependency has been discovered in Forgejo which was removed. Changes to the licensing tooling have been made, and I believe it might make sense to check if the situation also improved w.r.t. librejs. https://forgejo.org/2024-07-non-free-dependency-found/

👍 1

fnetX commented

2025-06-07 12:48:14 +02:00

Owner

I'm closing this issue, because it has been labelled with Gain/Undefined for a while. It looks like there is little interest to keep the discussion going at the moment.

😕 1

fnetX closed this issue

2025-06-07 12:48:18 +02:00

wolftune commented

2025-06-08 23:26:57 +02:00

I think it much more appropriate to get enough Forgejo leaders to clarify a decision not to do this (such as that it is just too burdensome) and consider what alternatives could be done at least.

I don't know about "little interest to keep discussion going". The whole GNU project perspective remains that having Forgejo instances work with LibreJS is essential. I don't care personally as much as GNU does formally, but I care to help GNU and other software-freedom projects work well together.

I didn't lose interest in my last comment, it just got no reply, this point is still a concern:

The other practical issue (whether LibreJS specifically recognizes it or not) is facilitating access to the non-minified original source files. It's not enough to have the licenses, the links to the source code is the other piece of the puzzle. Having that would be a big step even if LibreJS still doesn't work.

I think it much more appropriate to get enough Forgejo leaders to clarify a decision *not* to do this (such as that it is just too burdensome) and consider what alternatives could be done at least. I don't know about "little interest to keep discussion going". The whole GNU project perspective remains that having Forgejo instances work with LibreJS is essential. I don't care personally as much as GNU does formally, but I care to help GNU and other software-freedom projects work well together. I didn't lose interest in my last comment, it just got no reply, this point is still a concern: > The other practical issue (whether LibreJS specifically recognizes it or not) is facilitating access to the non-minified original source files. It's not enough to have the licenses, the links to the source code is the other piece of the puzzle. Having that would be a big step even if LibreJS still doesn't work.

👍 1

earl-warren commented

2025-06-09 10:43:50 +02:00

Contributor

Let's re-open then.

@wolftune wrote in #1654 (comment):

...to clarify a decision not to do this...

For a decision to be made a consensus is the best way. I suspect there will never be a consensus to not support LibreJS. The only problem is the amount of work to support it in the long run, as for every Forgejo feature really.

It all depends on whether someone steps up.

Let's re-open then. @wolftune wrote in https://codeberg.org/forgejo/forgejo/issues/1654#issuecomment-5050485: > ...to clarify a decision _not_ to do this... For a decision to be made [a consensus is the best way](https://codeberg.org/forgejo/governance/src/branch/main/DECISION-MAKING.md). I suspect there will never be a consensus to not support LibreJS. The only problem is the amount of work to support it in the long run, as for every Forgejo feature really. It all depends on whether someone steps up.

❤️ 1

earl-warren reopened this issue

2025-06-09 10:43:54 +02:00

cregox commented

2025-07-14 16:14:54 +02:00

@earl-warren wrote in #1654 (comment):

someone steps up

i would like mentorship or co-holding from another community member, as to help me decide if i can step up for this.

as i just stumbled here, i feel like i might enjoy to support this right now and "in the long run".

warning/disclaimer: for sure i ain't an "easy case" for whoever might find enough courage to try and help!

@earl-warren wrote in https://codeberg.org/forgejo/forgejo/issues/1654#issuecomment-5055567: > someone steps up i would like mentorship or co-holding from another community member, as to help me decide if i can step up for this. as i just stumbled here, i feel like i might enjoy to support this right now and "in the long run". warning/disclaimer: for sure i ain't an "easy case" for whoever might find enough courage to try and help!

fnetX commented

2025-07-15 02:16:27 +02:00

Owner

I honesetly dont know if anyone from the Forgejo team could mentor here. The frontend libraries are assembled to bundles using webpack, a common tool for this job.

I believe this rather needs guidance from the LibreJS community on how to configure this toolchain accordingly. If this is not possible, the LibreJS and webpack communities should likely patch the tooling accordingly.

After all, Forgejo is just "one of many" projects, the data is available in form of packages. Asking every project like Forgejo to spend significant time and effort to become librejs-compatible is unreasonable in my eyes. I see this as a task for the librejs ecosystem to ensure that free/libre projects generate a compliant frontend build by default or with a minimal configuration change.

I honesetly dont know if anyone from the Forgejo team could mentor here. The frontend libraries are assembled to bundles using webpack, a common tool for this job. I believe this rather needs guidance from the LibreJS community on how to configure this toolchain accordingly. If this is not possible, the LibreJS and webpack communities should likely patch the tooling accordingly. After all, Forgejo is just "one of many" projects, the data is available in form of packages. Asking every project like Forgejo to spend significant time and effort to become librejs-compatible is unreasonable in my eyes. I see this as a task for the librejs ecosystem to ensure that free/libre projects generate a compliant frontend build by default or with a minimal configuration change.

😕 1

cregox commented

2025-07-15 11:53:17 +02:00

currently, i do not know enough about forgejo or librejs codease, and how they relate to webpack myself, but i can see 2 issues here, both about finding the best way to declare licenses in "web scripts" and choices.

librejs responsibility

librejs basically only requires that all scripts have a clear machine-readable license format claiming to use a copyleft license from the accepted list. very reasonable requirement. i tested it in my own website (ahoxus.org /fupl), and it mostly worked indeed like that (except for service workers, for some reason).

indeed, it will fail to detect the license in many cases, so librejs team gave a suggestion on how to make it more standard. from the link already provided by @wolftune up there: http://gnu.org/software/librejs/manual/html_node/Setting-Your-JavaScript-Free.html#License-tags

LibreJS will allow non-trivial scripts to run as long as they use a free license.

In order for the license of a script to be recognized by LibreJS, it must be declared using a machine-readable license format.

This format is the same for both remote in-line scripts.

"// @license [magnet link] [identifier]" [Script here] "// @license-end"

could librejs make a bigger effort to identify the license in more "standard ways"? probably. and perhaps this would indeed "fix this issue" for codeberg.

should librejs adhere to standards such as whatever github/microsoft invented? nope. do forgejo relies on that at all? i dunno. i can only see it does try to replicate a lot of behavior (even a bit too much, in my opinion) from github.

forgejo responsibility

regardless of how to better make this standard declaration, i feel that if adding a few comments to declare the license used in the way proposed by librejs to forgejo will make codeberg work with librejs without issues, that will be a big win to codeberg. so why not?

we only need someone to step up? well, perhaps i can do that and, if i can, i will happily do it.

also, on a little side note, i see no reason why forgejo NEEDS js. it could do something more like sourcehut and work entirely without it, no? of course that would require a huge effort and i would bet nobody using forgejo right now would care for this. but personally i would, very much. although i could not take on this task today.

too long; didn't read / didn't dig up

i will still feel honored if i manage to take on this.

if you feel like talking, i will be available on http://t.me/acauema or [email protected] (delta chat) while looking for a better way to connect with people mobile-first on my years-long quest to software that respects my freedom

ps: sadly, never managed to find a good matrix, irc, or fediverse client for my android, nor a good gnu/linux phone, and don't get me started on computer issues i have with all kinds of "desktops".

currently, i do not know enough about forgejo or librejs codease, and how they relate to webpack myself, but i can see 2 issues here, both about finding the best way to declare licenses in "web scripts" and choices. # librejs responsibility librejs basically only requires that all scripts have a clear machine-readable license format claiming to use a copyleft license from the accepted list. very reasonable requirement. i tested it in my own website (`ahoxus.org /fupl`), and it mostly worked indeed like that (except for service workers, for some reason). indeed, it will fail to detect the license in many cases, so librejs team gave a suggestion on how to make it more standard. from the link already provided by @wolftune up there: http://gnu.org/software/librejs/manual/html_node/Setting-Your-JavaScript-Free.html#License-tags > LibreJS will allow non-trivial scripts to run as long as they use a free license. > > In order for the license of a script to be recognized by LibreJS, it must be declared using a machine-readable license format. > > This format is the same for both remote in-line scripts. > > "// @license [magnet link] [identifier]" [Script here] "// @license-end" could librejs make a bigger effort to identify the license in more "standard ways"? probably. and perhaps this would indeed "fix this issue" for codeberg. should librejs adhere to standards such as whatever github/microsoft invented? nope. do forgejo relies on that at all? i dunno. i can only see it does try to replicate a lot of behavior (even a bit too much, in my opinion) from github. # forgejo responsibility regardless of how to better make this standard declaration, i feel that if adding a few comments to declare the license used in the way proposed by librejs to forgejo will make codeberg work with librejs without issues, that will be a big win to codeberg. so why not? we only need someone to step up? well, perhaps i can do that and, if i can, i will happily do it. also, on a little side note, i see no reason why forgejo NEEDS js. it could do something more like sourcehut and work entirely without it, no? of course that would require a huge effort and i would bet nobody using forgejo right now would care for this. but personally i would, very much. although i could not take on this task today. # too long; didn't read / didn't dig up i will still feel honored if i manage to take on this. if you feel like talking, i will be available on http://t.me/acauema or [email protected] (delta chat) while looking for a better way to connect with people mobile-first on my years-long quest to software that respects my freedom ps: sadly, never managed to find a good matrix, irc, or fediverse client for my android, nor a good gnu/linux phone, and don't get me started on computer issues i have with all kinds of "desktops".

n0toose commented

2025-07-15 12:41:56 +02:00

Member

should librejs adhere to standards such as whatever github/microsoft invented? nope.

we only need someone to step up? well, perhaps i can do that and, if i can, i will happily do it.

of course that would require a huge effort and i would bet nobody using forgejo right now would care for this

you'd be responsible for explicitly investigating whether it's possible and doable to work with other parties so as to maximize your impact by attempting to contribute to upstream instead of offloading maintenance to forgejo (and repeating the need for such large undertakings to many different projects). otto probably suggested the need to ask the librejs folk not because they're against it explicitly, but because we don't have as much experience. ideology is fine, as long as you take a look at the greater picture and the concrete technical requirements so as to not have your solution turn useless after a while: i'd suggest taking a look at the circumstances which led to librejs getting removed from gitea too (after it was originally merged/present).

it's open-source and open-source involves people / trying to get stuff done in the face of multiple, often contradictory "stakeholder requirements" - if you find out that your efforts at upstreaming librejs is e.g. stuck because of microsoft, then that's a valid case to have an explicit, separate effort for forgejo. if you find out that doing this on the forgejo side of things is actually super easy, then that could be another valid case.

> should librejs adhere to standards such as whatever github/microsoft invented? nope. > we only need someone to step up? well, perhaps i can do that and, if i can, i will happily do it. > of course that would require a huge effort and i would bet nobody using forgejo right now would care for this you'd be responsible for explicitly investigating whether it's possible and doable to work with other parties so as to maximize your impact by attempting to contribute to upstream instead of offloading maintenance to forgejo (and repeating the need for such large undertakings to many different projects). otto probably suggested the need to ask the librejs folk *not* because they're against it explicitly, but because we don't have as much experience. ideology is fine, as long as you take a look at the greater picture and the concrete technical requirements so as to not have your solution turn useless after a while: i'd suggest taking a look at the circumstances which led to librejs getting removed from gitea too (after it was originally merged/present). it's open-source and open-source involves people / trying to get stuff done in the face of multiple, often contradictory "stakeholder requirements" - if you find out that your efforts at upstreaming librejs is e.g. stuck because of microsoft, then that's a valid case to have an explicit, separate effort for forgejo. if you find out that doing this on the forgejo side of things is actually super easy, then that could be another valid case.

❤️ 3

n0toose commented

2025-07-15 12:46:50 +02:00

Member

also, on a little side note, i see no reason why forgejo NEEDS js

the onus is on you to find out and look up previous discussions on the subject (both in forgejo and gitea) - forgejo kind of caters to the github crowd - people might not "need a web interface because they can still send patches via email". more generally, people might be able to lead a very happy life without, say, milk products, laptops or bread. they don't need all of that, but they can still prefer.

as a hint, there are many interactive elements (e.g. "Copy to clipboard" buttons, dynamically generated repository lists in the Dashboard, the Dashboard itself). i would be explicitly not opposed to advancing nojs-support (e.g. removing or substituting javascript-only components) on the basis that it helps people on older hardware and can implicitly improve accessibility.

> also, on a little side note, i see no reason why forgejo NEEDS js the onus is on you to find out and look up previous discussions on the subject (both in forgejo and gitea) - forgejo kind of caters to the github crowd - people might not "need a web interface because they can still send patches via email". more generally, people might be able to lead a very happy life without, say, milk products, laptops or bread. they don't *need* all of that, but they can still *prefer*. as a hint, there are many interactive elements (e.g. "Copy to clipboard" buttons, dynamically generated repository lists in the Dashboard, the Dashboard itself). i would be explicitly not opposed to advancing nojs-support (e.g. removing or substituting javascript-only components) on the basis that it helps people on older hardware and can implicitly improve accessibility.

❤️ 2

cregox commented

2025-07-21 13:29:48 +02:00

thanks a lot for the input, @n0toose

after reading a bit further, it looks now to me that gitea didn't even fully gave up on doing it, they just never found a way to make it work. and librejs had some updates that perhaps they didn't even notice, due to the lack of interest.

so yeah, i did feel committed to exploring this issue further.

however...

i found a fundamental mismatch with the technological principles i adhere to in my own work (namely go and node, very long story i may post one day on #fupl or something).

because of this, i need to step back from this issue for now to reconsider my approach.

i appreciate the opportunity and wish you the best with the project.

also, my development environment lacks a lot. i currently work on setting it up properly so i can tackle this kind of activity (in my life). for many related reasons, it became now my immediate priority. right now i doubt i could even clone and compile forgejo on my machine or literally anywhere i have access to.

once i do have a stable environment where i can compile and test forgejo, i might get back to this with a more substantial update.

in short: i will be out of this. for now.

thanks a lot for the input, @n0toose after reading a bit further, it looks now to me that gitea didn't even fully gave up on doing it, they just never found a way to make it work. and librejs had some updates that perhaps they didn't even notice, due to the lack of interest. so yeah, i did feel committed to exploring this issue further. however... i found a fundamental mismatch with the technological principles i adhere to in my own work (namely go and node, very long story i may post one day on `#fupl` or something). because of this, i need to step back from this issue for now to reconsider my approach. i appreciate the opportunity and wish you the best with the project. also, my development environment lacks a lot. i currently work on setting it up properly so i can tackle this kind of activity (in my life). for many related reasons, it became now my immediate priority. right now i doubt i could even clone and compile forgejo on my machine or literally *anywhere* i have access to. once i do have a stable environment where i can compile and test forgejo, i might get back to this with a more substantial update. in short: i will be out of this. for now.

n0toose commented

2025-10-21 19:38:00 +02:00

Member

Hi, during today's Forgejo upgrade party, we went through a couple of issues marked with Gain/Undefined. In the context of many recent pull requests that aim to improve no-JS compatibility (see here) and given the lack of interest among Forgejo's contributor base over more directly actionable solutions (i.e. reducing our dependency on JavaScript), we will close this for now.

If anybody is interested enough in seeing this through, please do leave a comment. However, I don't think this is planned for the time being.

Hi, during today's [Forgejo upgrade party](https://codeberg.org/forgejo/discussions/issues/402), we went through a couple of issues marked with `Gain/Undefined`. In the context of many recent pull requests that aim to improve no-JS compatibility ([see here](https://codeberg.org/forgejo/forgejo/pulls?q=no-JS&type=all&sort=&state=closed&labels=&milestone=0&project=0&assignee=0&poster=0&archived=false)) and given the lack of interest among Forgejo's contributor base over more directly actionable solutions (i.e. reducing our dependency on JavaScript), we will close this for now. If anybody is interested enough in seeing this through, please do leave a comment. However, I don't think this is planned for the time being.

n0toose closed this issue

2025-10-21 19:38:05 +02:00

Rows
Columns

[FEAT] Add support for librejs #1654

Needs and benefits

Feature Description

Screenshots

librejs responsibility

forgejo responsibility

too long; didn't read / didn't dig up