License tags

[ghost]

The jquery javascript files that users run should be tagged as free software so that people who want to run only free software on the web could do so. jQuery is free software might be free software but since it is not tagged as such you have to either allow all proprietary javascript as well or just not run jQuery.

LibreJS is a project by GNU to make it possible for those who want to run only free software on their browsers to only allow files that are free software.

http://www.gnu.org/software/librejs/
http://www.gnu.org/software/librejs/free-your-javascript.html

PS. The license file on jquery.org (and rest of the page for that matter) is completely unaccessible from Tor.

[dmethvin]

Since you're requesting this can you suggest what you mean specifically by "should be tagged"? What is it that needs to be changed? Note that the repo has a LICENSE file.

[ghost]

@dmethvin This page: http://www.gnu.org/software/librejs/free-your-javascript.html has all the info about how to make librejs understand the license for scripts.

I tried to edit the original post to clarify that but the editing function doesn't seem to work for me currently.

It is not really sensible for a browser or browser plugin to try to find the LICENSE for each javascript library because that would be ungodly amount of work to get working. Instead us humans can tag our javascript so that it's easy to parse and to automatically recognize what license scripts have.

[dmethvin]

We're not embedding an entire license into our distribution file. The header, even on the compressed file, references the license. Can you suggest a way to do what you want without embedding a full license? If so can you submit a PR?

[ghost]

@dmethvin You misunderstood. You don't have to embed a whole license.

All you would need is this at the top:
// @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&dn=expat.txt

And this at the bottom:
// @license-end

That won't be too many bytes more than what the current license notice is but has a lot more functionality.

[mgol]

Do I understand that we'd have to make the license available via BitTorrent or is the magnet link used in a different way here?

Also, I worry about introducing code to handle cases that are not officially standardized; could you name some popular JavaScript libraries that include such license comments?

[ghost]

@mgol librejs recognizes the magnet link as being that of a proper Expat license and if user wants to get the license they can download it via the magnet link. jQuery doesn't have to make any new magnet urls or anything, just include the one of a proper Expat (the current license that's in use).

So in order you to help users only use free software other people have to have done it before you? Do you realize that if everyone thought like you the world would only have proprietary software? This is an effort to put some kind of standard in place, even if it's an ad hoc one. Currently there is no other way of automatically parsing licensing information for javascript files.

[dmethvin]

@TsuTsuKaKushi I don't think we're opposed to it necessarily, having some good way to specify the license seems like a good thing. That document is rather preachy and dogmatic, rather than just approaching the problem as one of how to automate the issue of license recognition. Perhaps it would help to separate the two issues and make a page that is focused on the technical details.

[ghost]

@dmethvin I agree with a page with more technical details would be and I will ask about that on the mailing list. However I don't think that LibreJS has more than a couple of guys working on it so it might not get the top priority. Maybe some experienced Javascript developers could help wink wink.

[ghost]

I totally messed up that first sentence. Let's try again.

I agree that a page with more technical details would be good and I will ask about that on the mailing list.

[markelog]

Not sure what would need to be updated there, it seems just adding -

// @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&dn=expat.txt
...
// @license-end

And libre would parse it, the other question if we would want to do it... does anyone?

[markelog]

@TsuTsuKaKushi do you have any examples of libraries that already use such tags?

[ghost]

@markelog

And libre would parse it, the other question if we would want to do it... does anyone?

Do you want people to run only freesoftware on the net or do you also want them to run all of that fingerprinting javascript and other malicious stuff? I don't want people to run fingerprinting javascript and currently the user can to either both jQuery and all of the malicious stuff or neither.

do you have any examples of libraries that already use such tags?

I'd like to quote myself from an earlier message as an answer.

So in order you to help users only use free software other people have to have done it before you? Do you realize that if everyone thought like you the world would only have proprietary software?

[mgol]

@TsuTsuKaKushi

@mgol librejs recognizes the magnet link as being that of a proper Expat license and if user wants to get the license they can download it via the magnet link. jQuery doesn't have to make any new magnet urls or anything, just include the one of a proper Expat (the current license that's in use).

Good, I was worried about that.

So in order you to help users only use free software other people have to have done it before you? Do you realize that if everyone thought like you the world would only have proprietary software?

I didn't mean to sound in that way, I'm sorry if I gave that impression.

Experience with jQuery & other projects has taught me that there are established standards and "standards" that may become the former but not necessarily. Catering too much to the latter often leads to maintaning non-needed obsolete code later on. One example are package managers - we've added support for npm & bower, people were asking for more of them but, after some discussions, we decided to punt on that. Every such package manager is an additional release burden for us and they come & go; in retrospect we might have been better of just publishing to npm and leaving the rest of the packages to community.

This is my main concern here. I was asking about other libraries to see how established it is (or may be). There's always a possibility that this @license spec has critical faults, that there are better solutions out there, that this may be automated without making any changes etc. Note that being cautious about doing it as the only library doesn't mean nothing can be done as someone has to be the first - you may e.g. open similar issues in other popular libraries' bug trackers and if some of them agree this might be something worth doing we'd know we won't be the only ones.

There's no hurry in that; existing jQuery versions on the web won't get it anyway so this won't change much if we do it for 3.0.0, 3.0.1 or only for 3.1.0. I'd rather wait a little, hear what other projects have to say and make a well-thought decision than to rush it.

To sum up, I don't object to doing that; if other maintainers of popular OSS libraries also don't object & don't present better solutions, we may do it. I just want jQuery to not be the only library ever used doing that.

[markelog]

Point of my question was about borrowing someone else experience not to create our own, but not to get in into the philosophical debate, like if there a grunt task for this or configuration that we could use or anything else that could help us.

[ghost]

@mgol

Experience with jQuery & other projects has taught me that there are established standards and "standards" that may become the former but not necessarily.

Ad hoc standard is better than nothing.

Catering too much to the latter often leads to maintaning non-needed obsolete code later on.

There is no need for any code in jQuery's part, only two comment lines per js file that will be run on user's browsers.

One example are package managers - we've added support for npm & bower, people were asking for more of them but, after some discussions, we decided to punt on that.

Package managing is a world which has a lot of different tools. License verification has just one.

Every such package manager is an additional release burden for us and they come & go; in retrospect we might have been better of just publishing to npm and leaving the rest of the packages to community.

Again. This only requires two comments, no code.

There's no hurry in that; existing jQuery versions on the web won't get it anyway so this won't change much if we do it for 3.0.0, 3.0.1 or only for 3.1.0.

Yeah, javascript library and framework field is a trainwreck. This is why LibreJS has some versions jQuery whitelisted but there are just TOO MANY.

I'd rather wait a little, hear what other projects have to say and make a well-thought decision than to rush it.

That is reasonable

To sum up, I don't object to doing that; if other maintainers of popular OSS libraries also don't object & don't present better solutions, we may do it. I just want jQuery to not be the only library ever used doing that.

Javascript libraries are very neglegent about such issues and none of them is willing to take the first step.

@markelog

Point of my question was about borrowing someone else experience not to create our own, but not to get in into the philosophical debate, like if there a grunt task for this or configuration that we could use or anything else that could help us.

I doubt there is a tool that can navigate the differences in the structure to determine what needs the tag and what doesn't. You will only have to add it to the existing files once and every time you add new files that run on the user's browser you add the tags. To me it doesn't even seem like a task that would require a separate tool.

[mgol]

@TsuTsuKaKushi

To sum up, I don't object to doing that; if other maintainers of popular OSS libraries also don't object & don't present better solutions, we may do it. I just want jQuery to not be the only library ever used doing that.

Javascript libraries are very neglegent about such issues and none of them is willing to take the first step.

Would you be willing to create issues about that anyway? I'd like to hear their voices, regardless of what they say. I'm not saying we'll necessarily follow what they decide or wait for their final decisions but at least hearing them would be worthwhile IMO.

[ghost]

Would you be willing to create issues about that anyway?

I will. I'm not just sure which libraries I should target at first.

[markelog]

I doubt there is a tool that can navigate the differences in the structure to determine what needs the tag and what doesn't. You will only have to add it to the existing files once and every time you add new files that run on the user's browser you add the tags. To me it doesn't even seem like a task that would require a separate tool.

Cool, sounds very easy, could you provide a pr then?

[ghost]

@markelog I am not any more familiar with the structure of jQuery than a stupid script. I don't know which files would require the tags and which wouldn't. I did clone the repo to see if I could figure it out but there seems to be a lot of scripts that build other scripts and whatnot. It would be trivial for someone who is already familiar with the project.

[markelog]

So it is not that easy? Then i guess it would be better to check out someone else experience in that matter

[ghost]

@markelog It's easy for someone who knows the project. It's not easy for someone who doesn't. Writing patches for a project without knowing about how it works can be hard.

[markelog]

It's easy for someone who knows the project.

I "know" the project, but i don't know who to write it, it seems no one in this thread either.

[ghost]

@markelog you are a "jQuery Foundation member" and you aren't familiar with the build process?

[mgol]

Since this is static information it can just be added to the intro.js file for the unminified file and to Gruntfile.js for the minified version, that's not a problem (unless @markelog wanted to have an automated way to generate these magnet links from license URLs/names but that would be overkill IMO).

Would you be willing to create issues about that anyway?

I will. I'm not just sure which libraries I should target at first.

If you need ideas, off the top of my head: lodash, Bootstrap, Backbone, Angular, Ember, three.js, Modernizr, pdf.js, less.js.

If you create some issues, please link them to this bug so that we can see them. Thanks!

[markelog]

@mgol libre asks to add end comment too, so you would have to update outro.js for unminified file, which already look like a hack.

For minified file we would need to use uglify to prepend it, it can add a banner, but not the footer (to my knowledge), we can again workaround that. But it seems we would need to make already two hacks to make it work.

@TsuTsuKaKushi

@markelog you are a "jQuery Foundation member" and you aren't familiar with the build process?

I'm familiar with the process, i just don't know how to do what you asking us to do. Whereas you don't want to help us with your issue, i guess it is always fun to debate about the philosophy of things, but when push comes to shove people start quickly disappear.

[dmethvin]

I'm going to close this issue, not because we're opposed to it but because it seems like it is probably something that could be addressed elsewhere to prove its viability and utility before we have to adopt it and carry it around as potential future baggage.

For example, a proxy could identify the versions of jQuery that have acceptable licenses (e.g., using a SHA hash) and inject the appropriate license tag. This would have the advantage of working with past versions of jQuery and thus allowing many existing web sites to run. Any solution that involves our build system would only be beneficial to users once popular sites upgrade, and that would take years.