Unsourced/undocumented libraries; missing license files; and other issues #637

@MTecknology commented on GitHub (Apr 18, 2017):

Beyond just complete documentation, this actually represents a license violation in it's current state... as do many vendor/ dependencies, but the latter has been resolved in downstreams.

@MTecknology commented on GitHub (Apr 18, 2017): Beyond just complete documentation, this actually represents a license violation in it's current state... as do many vendor/ dependencies, but the latter has been resolved in downstreams.

GiteaMirror commented

@MTecknology commented on GitHub (Apr 18, 2017):

Clicked the wrong comment button...

@MTecknology commented on GitHub (Apr 18, 2017): Clicked the wrong comment button...

GiteaMirror commented

@lofidevops commented on GitHub (Apr 21, 2017):

Report from LibreJS (Firefox extension) on try.gitea.io running v1.1.0:

List of accepted JavaScript in https://try.gitea.io/

This script is detected as free
https://try.gitea.io/js/libs/jquery.are-you-sure.js
This script is detected as free
https://try.gitea.io/js/libs/emojify-1.1.0.min.js
This script is detected as free
https://try.gitea.io/js/libs/clipboard-1.5.9.min.js

List of blocked JavaScript in https://try.gitea.io/

This script is detected as nonfree, external, and as defining functions or methods
https://try.gitea.io/js/libs/autolink.js
NONTRIVIAL: eval has been found in code
https://try.gitea.io/js/index.js?v=1ed9cef4e7846494bd7df1cc16ae65fc
NONTRIVIAL: Creates an xhr object
https://try.gitea.io/js/jquery-1.11.3.min.js
NONTRIVIAL: Creates an xhr object
https://try.gitea.io/js/semantic-2.2.1.min.js

Web Labels pages being used for this session

https://try.gitea.io/assets/librejs/librejs.html

@lofidevops commented on GitHub (Apr 21, 2017): Report from LibreJS (Firefox extension) on try.gitea.io running v1.1.0: List of accepted JavaScript in https://try.gitea.io/ This script is detected as free https://try.gitea.io/js/libs/jquery.are-you-sure.js This script is detected as free https://try.gitea.io/js/libs/emojify-1.1.0.min.js This script is detected as free https://try.gitea.io/js/libs/clipboard-1.5.9.min.js List of blocked JavaScript in https://try.gitea.io/ This script is detected as nonfree, external, and as defining functions or methods https://try.gitea.io/js/libs/autolink.js NONTRIVIAL: eval has been found in code https://try.gitea.io/js/index.js?v=1ed9cef4e7846494bd7df1cc16ae65fc NONTRIVIAL: Creates an xhr object https://try.gitea.io/js/jquery-1.11.3.min.js NONTRIVIAL: Creates an xhr object https://try.gitea.io/js/semantic-2.2.1.min.js Web Labels pages being used for this session https://try.gitea.io/assets/librejs/librejs.html

GiteaMirror commented

@bkcsoft commented on GitHub (Apr 25, 2017):

@MTecknology Sorry for the late response 🙂

WRT Logos

Slack: https://slack.com/brand-guidelines

You're entitled to say that your website or application is integrated with Slack (we like people integrating with Slack!), but please don't use the Slack marks as part of the name of your company, application, product, or service, or in any logo you create.

OpenID: http://openid.net/add-openid/logos/

for use in presentations, articles, blog posts, etc.

(It'd say this falls under "etc.")

GitHub: https://github.com/logos

Do these awesome things:

Use the Octocat or GitHub logo to advertise that your product has built-in GitHub integration

WRT sources

Ideally, I'd like some script that could be used without requiring network access that can reproduce the images in public/img/.

Not really possible without polluting the repo with providers tar-balls (not always available either...)
We can however add public/img/gitlab.png.LICENSE and friends if that would make it better.

The emoji/ directory also seems to have a large number of images that probably have sources that I missed.

EmojiOne, we move it to public/plugins/emojione-{{ .Version }} and add their LICENSE-file in there...

the packaging process would strip public/ and rebuild everything in it

This would requires internet-access and is not an option. There's a reason why we have vendor/ 😉

@bkcsoft commented on GitHub (Apr 25, 2017): @MTecknology Sorry for the late response 🙂 ### WRT Logos #### Slack: https://slack.com/brand-guidelines > You're entitled to say that your website or application is **integrated with Slack** (we like people integrating with Slack!), but please don't use the Slack marks as part of the name of your company, application, product, or service, or in any logo you create. #### OpenID: http://openid.net/add-openid/logos/ > for use in presentations, articles, blog posts, etc. (It'd say this falls under "etc.") #### GitHub: https://github.com/logos > #### Do these awesome things: > Use the Octocat or GitHub logo to advertise that your product has built-in **GitHub integration** ### WRT sources > Ideally, I'd like some script that could be used without requiring network access that can reproduce the images in public/img/. Not really possible without polluting the repo with providers tar-balls (not always available either...) We can however add `public/img/gitlab.png.LICENSE` and friends if that would make it better. > The emoji/ directory also seems to have a large number of images that probably have sources that I missed. EmojiOne, we move it to `public/plugins/emojione-{{ .Version }}` and add their LICENSE-file in there... > the packaging process would strip public/ and rebuild everything in it This would requires internet-access and is not an option. There's a reason why we have `vendor/` 😉

GiteaMirror commented

@lunny commented on GitHub (May 31, 2017):

It seems some PR fix this issue?

@lunny commented on GitHub (May 31, 2017): It seems some PR fix this issue?

GiteaMirror commented

@bkcsoft commented on GitHub (Jun 1, 2017):

@lunny No, #1728 is something completely different.

@bkcsoft commented on GitHub (Jun 1, 2017): @lunny No, #1728 is something completely different.

GiteaMirror commented

@MTecknology commented on GitHub (Jul 4, 2017):

I'm only just now hopping back into this issue (Debian 9 released)

The problem I see with the slack logo's Brand Guidelines is this:

By using the Slack marks you agree to follow these guidelines as well as our Terms of Service and all our rules and policies.

This seems pretty unambiguous to me... by using the logo, you agree to their Brand Guidelines, their Terms of Service, and whatever "rules and policies" means. I'd prefer see the logo swapped out for '#' until that wording is changed. The rest of their guidelines seem perfectly reasonable, but this seems very wrong.

As for the javascript stuff, I get the impression @kwill is more capable than me at digging into how we can correctly get only foss javascript libraries in place and correctly documented. Digging through js stuff like this is quite difficult for me, but I do have a few thoughts (finally)...

Stick all javascript in the public/js/ directory
Drop the public/js/libs/ sub-directory
Drop the version number from the filenames (big deal for off-line rebuild)
Build a "proper" file documenting sources and version numbers
[proper] don't know what that looks like, but machine/human readable would be excellent
Remove everything that can't be attributed (git logs show some stuff is original... let's say what is)
Same thing with assets, css, ... -pretty much- everything under public/

Not really possible without polluting the repo with providers tar-balls (not always available either...)
This would requires internet-access and is not an option. There's a reason why we have vendor/

I recall discussing w/ @bkcsoft, on IRC, what it means to build gitea without a network connection and without having vendor/ available. (Everything needs to come from a package already available in Debian.) At first, it meant ~100 golang libs needed to be added to the Debian repos (in the correct reverse dependency order...), now it means about 20 more javascript packages.

I'd like to get what's best and most correct figured out so I can beg someone to work on that while I learn how to package javascript libraries and then learn how correctly utilize those packages.

@MTecknology commented on GitHub (Jul 4, 2017): I'm only just now hopping back into this issue (Debian 9 released) The problem I see with the slack logo's [Brand Guidelines](https://slack.com/brand-guidelines?nojsmode=1) is this: > By using the Slack marks you agree to follow these guidelines as well as our Terms of Service and all our rules and policies. This seems pretty unambiguous to me... by using the logo, you agree to their Brand Guidelines, their [Terms of Service](https://slack.com/terms-of-service?nojsmode=1), and whatever "rules and policies" means. I'd prefer see the logo swapped out for '#' until that wording is changed. The rest of their guidelines seem perfectly reasonable, but this seems very wrong. As for the javascript stuff, I get the impression @kwill is more capable than me at digging into how we can correctly get only foss javascript libraries in place and correctly documented. Digging through js stuff like this is quite difficult for me, but I do have a few thoughts (finally)... - Stick all javascript in the public/js/ directory - Drop the public/js/libs/ sub-directory - Drop the version number from the filenames (big deal for off-line rebuild) - Build a "proper" file documenting sources and version numbers - [proper] don't know what that looks like, but machine/human readable would be excellent - Remove everything that can't be attributed (git logs show some stuff is original... let's say what is) - Same thing with assets, css, ... -pretty much- everything under public/ > Not really possible without polluting the repo with providers tar-balls (not always available either...) > This would requires internet-access and is not an option. There's a reason why we have vendor/ I recall discussing w/ @bkcsoft, on IRC, what it means to build gitea without a network connection and without having vendor/ available. (Everything needs to come from a package already available in Debian.) At first, it meant ~100 golang libs needed to be added to the Debian repos (in the correct reverse dependency order...), now it means about 20 more javascript packages. I'd like to get what's best and most correct figured out so I can beg someone to work on that while I learn how to package javascript libraries and then learn how correctly utilize those packages.

GiteaMirror commented

@lofidevops commented on GitHub (Jul 4, 2017):

I don't actually know how, I just installed LibreJS in Firefox and recorded the results when visiting https://try.gitea.io :) I'll check if the listed libraries/files are already known to be free (I'm guessing they are).

@lofidevops commented on GitHub (Jul 4, 2017): I don't actually know how, I just installed LibreJS in Firefox and recorded the results when visiting https://try.gitea.io :) I'll check if the listed libraries/files are already known to be free (I'm guessing they are).

GiteaMirror commented

@bkcsoft commented on GitHub (Jul 4, 2017):

At first, it meant ~100 golang libs needed to be added to the Debian repos (in the correct reverse dependency order...), now it means about 20 more javascript packages.

Unless these have a separate package for each version that don't conflict with eachother you're gonna have a bad time.

Drop the version number from the filenames (big deal for off-line rebuild)

Build a "proper" file documenting sources and version numbers

machine/human readable

Remove everything that can't be attributed (git logs show some stuff is original... let's say what is)

Same thing with assets, css, ... -pretty much- everything under public/

This can mostly be addressed by using npm/yarn (just like we use govendor for go deps). The only thing we might have issues with is figuring out what we're actually using, and which version of it we're using.

As for the Slack-logo, I think we can just replace all mentions of "Slack" with "Mattermost" TBH, since the API for Mattermost is a superset of Slacks API.

@bkcsoft commented on GitHub (Jul 4, 2017): > At first, it meant ~100 golang libs needed to be added to the Debian repos (in the correct reverse dependency order...), now it means about 20 more javascript packages. Unless these have a separate package for each version that don't conflict with eachother you're gonna have a bad time. > - Drop the version number from the filenames (big deal for off-line rebuild) > - Build a "proper" file documenting sources and version numbers > - machine/human readable > - Remove everything that can't be attributed (git logs show some stuff is original... let's say what is) > - Same thing with assets, css, ... -pretty much- everything under public/ This can mostly be addressed by using npm/yarn (just like we use govendor for go deps). The only thing we might have issues with is figuring out what we're actually using, and which version of it we're using. As for the Slack-logo, I think we can just replace all mentions of "Slack" with "Mattermost" TBH, since the API for Mattermost is a superset of Slacks API.

GiteaMirror commented

@bkcsoft commented on GitHub (Jul 4, 2017):

Drop the public/js/libs/ sub-directory

This is generally a bad idea, since now you have to manually figure out what is vendored and what is original content. From a PMs point-of-view I'd prefer to have js/libs since then I could just rm -rf public/js/libs and go with that.

Packaging JS-libs separately is going to break though ~~unless you create symlinks all over the place...~~ that's gonna break too since the webserver isn't going to allow following symlinks 😒

@bkcsoft commented on GitHub (Jul 4, 2017): > Drop the public/js/libs/ sub-directory This is generally a bad idea, since now you have to manually figure out what is vendored and what is original content. From a PMs point-of-view I'd prefer to have `js/libs` since then I could just `rm -rf public/js/libs` and go with that. Packaging JS-libs separately is going to break though ~~unless you create symlinks all over the place...~~ that's gonna break too since the webserver isn't going to allow following symlinks 😒

GiteaMirror commented

@MTecknology commented on GitHub (Jul 30, 2017):

How about ...?

public/
  css/
  js/
  img/
  ^-- custom stuff covered under 
vendor/
  vendor.json
  ^- upstream location, packaged version (or date + git tag)
  less/
  img/
    emoji/
  js/
    autolink.js
    clipboard.min.js
    emojify.min.js
    semantic.min.js
    ^- no version numbers in file names
  plugins/

Then I get to exclude only public/vendor/ and rebuild it during the build process, which lets me make sure the package meets DFSG. If I can check off that box, then #1524 can get a push in the right direction, and we'd be that much closer to closing #31 and #122.

@MTecknology commented on GitHub (Jul 30, 2017): How about ...? ``` public/ css/ js/ img/ ^-- custom stuff covered under vendor/ vendor.json ^- upstream location, packaged version (or date + git tag) less/ img/ emoji/ js/ autolink.js clipboard.min.js emojify.min.js semantic.min.js ^- no version numbers in file names plugins/ ``` Then I get to exclude only ```public/vendor/``` and rebuild it during the build process, which lets me make sure the package meets [DFSG](https://www.debian.org/social_contract). If I can check off that box, then #1524 can get a push in the right direction, and we'd be that much closer to closing #31 and #122.

GiteaMirror commented

@MTecknology commented on GitHub (Aug 1, 2017):

@kwill I did a bit of a rework, as earlier described. I'm struggling to figure out why librejs isn't detecting some scripts like highlight.pack.js and gitgraph aren't being detected as free despite being in librejs.html. I have my copy currently hosted at http://tempgit.lustfield.net:3000/mike/test/graph. Beyond that, it seems like the new structure and update of public/ manages to resolve this issue as well as C0.0 of #1534.

@MTecknology commented on GitHub (Aug 1, 2017): @kwill I did a bit of a rework, as earlier described. I'm struggling to figure out why librejs isn't detecting some scripts like highlight.pack.js and gitgraph aren't being detected as free despite being in librejs.html. I have my copy currently hosted at http://tempgit.lustfield.net:3000/mike/test/graph. Beyond that, it seems like the new structure and update of public/ manages to resolve this issue as well as C0.0 of #1534.

GiteaMirror commented

@strk commented on GitHub (Aug 23, 2017):

Still to be ported to 1.2 branch (before it is finalized)

@strk commented on GitHub (Aug 23, 2017): Still to be ported to 1.2 branch (before it is finalized)

GiteaMirror commented

@MTecknology commented on GitHub (Aug 23, 2017):

After PR #2374, if there are no other issues from PR #2375, I will create a PR to cherry-pick these changes.

@MTecknology commented on GitHub (Aug 23, 2017): After PR #2374, if there are no other issues from PR #2375, I will create a PR to cherry-pick these changes.

GiteaMirror commented