 All right. Good morning, everybody. I'm not sure that I've ever seen 9 a.m. at Fostem, so thank you all for coming to talk about every developer's favorite topic I know, licensing. And I have never been able to participate in the JavaScript room here before, so I want to thank the organizers for having me and giving me the opportunity to talk about it. And I didn't know that the opening keynote in advance was going to start this topic going, but that's, as the introduction said, set things up for us to talk here today. I'm the executive director at the Free Software Foundation. I've actually worked at the foundation since 2003 in different capacities. I've been the executive director there since 2011. And as part of that, I work with all the different teams at the FSF, including the technical team with our students' administrators and web developer and our licensing staff as well. So try to help them work together to advance the FSF's interests and freedom for the web and elsewhere. So I've talked about this topic in licensing focus settings before. I've never talked about it in the JavaScript developer focus setting before, so definitely a big part of what I'm here for today is to hear back from you at the end about whether what I'm presenting here makes any sense at all from your perspective. And then if you know possibly other ways where we could accomplish the same goals besides the system that I'm going to present here. So try to save some time at the end for that. And if we don't get to your ideas, then please do follow up with me after we're either by email or I'll be around the conference the rest of the day, of course. So at the Free Software Foundation, our goal is to not just make Free Software better, but to make all Free Software Free Software. So in our perfect world, there's no proprietary software. That's all free. So of course, we have the problem right now that was mentioned in the keynote yesterday. We have now laptops and desktop workstations that run all free software, require no proprietary drivers or proprietary blobs. Even the boot firmware on this laptop is free software. And the FSF has certified machines that meet those criteria under our respects for freedom program. But despite the fact that we might run one of these systems, we're asked to run non-free software. And in fact, our running non-free software still every day. And the main way that happens is by proprietary JavaScript being delivered to the user in the web browser. And so Richard Stallman called this the JavaScript Trap in an article that he published in 2009, which was referring to his 2004 article back when Java was proprietary and it was the Java trap. I don't think I have to tell you all that JavaScript is basically an assumption on the web now. You can't do much of anything if you turn it off or block it. Mozilla in 2013 removed the option that had been there for a long time for users to disable JavaScript. And I wasn't happy about that, but I understood why they did it because users were unchecking that box and then reporting all sorts of bugs that were happening when sites weren't working properly, not realizing that they had disabled JavaScript. But it's just an indication of how required in this theorem JavaScript on the web is. Now, at the FSTF, we don't want to avoid all JavaScript, of course. We only want to avoid proprietary JavaScript. So this isn't necessarily a problem for freedom reasons. People might object to it for accessibility or other reasons, but for freedom reasons, not necessarily a problem as long as the JavaScript that's required is actually free. Unfortunately, JavaScript programs are generally not free. And in particular, they're not free as they're typically distributed to the user. So we know there's all kinds of very popular free software JavaScript frameworks out there where the site operator or the web developer can get a copy of jQuery, it's free software. But the way that these programs are then served to the user in their browser doesn't meet the requirements of free software even if that software is available elsewhere under a free license. So what do I mean by that? The two basic requirements for something to be free software. You have to tell the user it's free software in some fashion because otherwise, around the world, the default copyright is all rights reserved. And so it's proprietary by default if there's no notice to the contrary. And then you also have to provide the complete and corresponding source code. So we know that permissive licenses, like the expat license, allow, commonly called the MIT license, allow people to redistribute that software in binary form if they want to. They're allowed to do that under the license, but if that's how they do it, then that's not free software. It's free software if the source code still comes with it. So the failure to do these two things are the reasons why most JavaScript is non-free. So we know minified JavaScript is not really source code. It's not the preferred form for modification. It's not quite as difficult to work with as a true binary, but it's essentially the same thing. If you are debugging something or trying to make a modification, minified JavaScript is not going to do you any favors. So because people serve JavaScript minified and for all the performance reasons that they typically do, that means they're not normally giving users the source form, which means it's not free software. This hurts users. We shouldn't wait for proprietary software. So we're talking about two different cases here. There should be clear about that. One, I would call kind of the unintentionally non-free case, and these are the cases where people are trying to use a free software JavaScript framework or a free software JavaScript, but they're just not giving users the source and they're not providing clear license notice. That's one category. The other category is JavaScript that's deliberately proprietary. So things like Google Analytics or the JavaScript for Gmail or Google Docs. That JavaScript is intentionally not free. So it's important to keep these two different cases in mind. In the second case, we know from the history of free software versus proprietary software, all the terrible things that can happen to people as a result of proprietary software. The same things can happen as a result of proprietary JavaScript that happened as a result of proprietary C or Python or anything else. We have an unfortunately expanding collection on ganu.org and slash philosophy, slash proprietary of all these examples, not just JavaScript, but other things as well. So if you're ever trying to explain to somebody why proprietary software is harmful, that's a good resource. Run through these quickly because I know you're all familiar with the fact that JavaScript can do these things, we know that JavaScript can modify the copy-paste buffer so the user might think they're copying something and then they paste it into their terminal and it's rm-rf and there you go. Block browser functions like saving images, sort of the poor person's DRM. Record your keystrokes. This is one that a lot of people don't realize. It's gotten a little bit of press. There's kind of a story about how Facebook was recording what users were typing, even if they didn't post it in the end. Also another story recently about how customer service online chat typically actually shows your keystrokes to the representative on the other side without telling you that. And then we know that JavaScript can be used, of course, to deliver malware within the browser and there was one example some years ago that was used to exploit Tor. But it's also the other side, it's not just about avoiding attacks or mistreatment of malware, it's about enabling the power of free software on the web just as we have that power and that dynamic and that culture before JavaScript was such a popular thing on the web on your own system. I know there's, this all kind of started with grease monkey, I think, and then it turned into several different sites repositories where people are sharing JavaScript that can modify the behavior of different popular sites or do different cool things in the browser OpenUserJS is one that I know of and they're actually making like a pretty strong effort to license the job, because all the JavaScript there is actually freely licensed, which was nice to see. But the point is we're trying to not just stop the negative effects of proprietary JavaScript but also trying to sort of move to a new model of the web that embraces user freedom to modify the behavior of how a site acts in their browser with the cooperation of the site operator and everybody involved. So if we're going to do that, we have to meet the basic requirements that we have to provide source. This is the system that the FZF has developed called, we call it JavaScript Web Labels and I'm going to walk through the different components of that. The first is a stylized comment to include in your JavaScript files to point to the source URL. And it's our, we've stated publicly that we believe doing the following things will be in compliance with your GPL's requirement to distribute source code. So we've had a particular challenge with copy left in GPL covered JavaScript because if you read the requirements in a certain way, you might think that you have to distribute a full copy of the GPL with every JavaScript file that you serve to your user. And that can be possibly pretty burdensome. And also how do you properly serve or offer the source code to the user in order to meet the GPL's requirements? So these source code, source comment formats work for that. And then after that, indicate the license of the JavaScript code. And we have a couple of two different ways of doing that. The first way is actually embedding the, or putting the license notice in the file using a comment of that format. Of course, if you're the copyright holder of the JavaScript, you can actually use a license exception to make this even easier for other people. So using GPL v3's additional permission feature, you can distribute non-source. You can add an additional permission worded like this. You may distribute non-source, e.g. minimize or compacted forms of this code without the copy of the GNU GPL normally required by Section 4, provided you include this license notice and a URL through which recipients can access the corresponding source. So if you're the copyright holder of JavaScript that you wrote, then you have the power to add an additional permission to the license. You, of course, can't do that if you're modifying somebody else's JavaScript under a free license because you have to have that permission in order to change the license terms. But this is a clean way to hear the copyright holder because it leaves no doubt about the GPL requirements for providing the copy of the license and the corresponding source. It lets people know that they can... it's okay for them to not distribute the copy of the license as long as they provide a link to the source code. But you're probably not the copyright holder for most of the JavaScript that you're working with. This format was actually announced all the way back in 2012. We're going to talk about how it's doing since then. The full description of it is in slash licenses, JavaScript-labels on gnu.org. The goal of the system is two-fold. First of all, it's to be machine-readable so that it can be read. Licensing information can be read and processed by browser extensions or server tools. But the second thing is it really does need to be human-readable. If you think to the GPL's basic requirement or most free software licenses, the basic requirement that you need to tell the person what they're receiving is free software. You need to inform them of the rights they have over the software. This isn't strictly a machine-readable format. It's something that humans are supposed to be able to read and understand as well. It starts with adding a link somewhere on the site, typically in the photo with other copyright information. This is fsef.org. Link called JavaScript licenses. When you follow that link, sorry, you mark that link with an attribute, REL equals JS license. That's part of the machine-readable automated tool portion. This is part of the approach because it means that any page of the user loads, there's a standard place, a standard link that should lead to the licensing information. That link leads to something that looks like this. It's a simple HTML table in a specific format. You have the file that's being served to the user. For example, the minified version. In the center, you have the license, and at the end, you have the source, the corresponding source. This shows you the format of the table. The table columns are given specific IDs. Again, they facilitate the processing by tooling. I showed you fsef to start with, of course, but it has been adopted by some other organizations and some other sites. We're going to talk more about how that adoption is going in a minute, but just to show an example from Electronic Frontier Foundation. It's pretty cool that they picked it up and started doing it. Free software, obviously, generally for their work, but they went out of their way to make sure that they adopted this as well for the JavaScript that they were using. I think this is a screenshot of their old site, but I confirmed last night that it's still there after they went through their site redesign. They still have it, and in fact, they have a lot of their JavaScript license under the AGPL, which I thought was excellent. Automation, based on this format, you could imagine a number of tools that did interesting things with it, but the one that we focused on is called GnuLiberJS, it's a Gnu project. It's a browser plugin for Mozilla-based browsers that looks for this format and licensing information on sites when you visit them, and if it doesn't find it, it blocks the proprietary JavaScript on the page. It looks for that web-label's information and for any JavaScript that has a corresponding source link and a corresponding license that's free and has a system for recognizing licenses, it will allow that JavaScript through anything else that will block. People don't know a script, right, to generally block all JavaScript, but this is a different, more targeted approach. So, like I said, it happened in 2012 that we started pushing for this. How's it going? I would have to say, not that good. Well, some of the reasons are a bit mundane, so GnuLiberJS as a piece of software for a long period of time was not working very well, and it was hard for us to persuade people to adopt a particular format that has the aims of being machine-readable and useful without any corresponding high-functioning tool to actually use that format, and people that are operating and taking care of big sites with a lot of JavaScript and a lot of pages, you know, you can't give them a tool to go through and test the site, and it becomes quite a bit of work for them to go through and make sure that everything is done properly and according with the format by hand. Then there were the updates to the Mozilla extension system, which broke GnuLiberJS further. So, it took us too long to react to this and catch up to it. The good news is that it was rewritten, and from all reports it's now working pretty well. There were also some performance issues with it. You know, it's trying to go through every JavaScript file and see what the license is, and so it would have to do that for every file before letting the page proceed. There's been a lot of performance improvements. I encourage you to try it out and give us some feedback on it. And there are still further challenges coming. The changes that Google was talking about making to the Chrome extension system, the API will basically make plugins like this almost impossible, maybe impossible, because they're taking away the ability for plugins to modify the content on the page. It's also going to cause problems for NoScript and a lot of other plugins that people have come to rely on. So, I imagine people might be wondering, why didn't you do it some other way? And I'm hoping to hear some of your ideas for how licensing information can be presented that satisfies those two goals, the machine-readable and human-readable. We do not claim this to be the one true method. We didn't go through a big public comment or kind of standards development process in order to come up with this. We wanted to get something out there to start with because this problem even in 2012 was so bad for free software and it's only gotten worse since then. But, you know, plugins like LaborJS could easily support multiple systems, and there's no reason why you can't have multiple systems. There's no reason why we can't experiment with some different ones and settle on another one. I know there's been some proposals using RDF, some using HTTP headers or getting attributes like for licensing tags added to the script elements itself or using custom attributes or I think there's a potential maybe with JavaScript source maps. I saw the great news the other day that Ruby on Rails is going to be turning apps on by default. So, I think there's some potential there. But, you know, we're not going to wait for the perfect system to keep pushing forward ways to help people sort of JavaScript in a free way and help users receive it in a free way. So, let's point to some next steps. LaborJS improvements. I mentioned that a lot of them have happened. It was Georgia, the author of NoScript to help us get that done. But there are more things that need to be done. We all have more wishlist and future requests for it. Mobile devices. You know, the primary way people browse the web now. The good news about this is I'm hoping, you know, fingers crossed that we will have an Android version available within the next few months that it will work with Firefox or iSCAD or any Mozilla-based browser on Android. It won't be on the iPhone because the App Store is not very friendly to resolve for. Then the next step after that for us is to have a command line or automated testing version of LaborJS. So, even for us at the FSF, it's kind of a problem. We work really hard to maintain clear licensing information for our JavaScript, but we also use, you know, upstream platforms. We use Drupal. We use CPCRM. We use MediaWiki. And anytime there's a change or an upgrade, sometimes the web-label system breaks. There's a new JavaScript or something changes. And, you know, we don't necessarily find out about that unless we manually check it or somebody reports a problem to us. But something that people realistically need in order to actually adopt this is an automated way to test it in an easy way without browsing to every individual page on your site. That's the next priority after the mobile version. Something that I'm hoping people in this room might have ideas about or be able to help with is how to modify or make, you know, the right sensible defaults or features in the tool chains and the tooling that are popularly used in the JavaScript community to make a format like this for a minified JavaScript to kind of just happen automatically or, you know, other ways that the tooling could be modified in order to do better at providing licensing information than links to corresponding source code. And then, you know, we can't just demand that upstream projects make changes in order to, you know, fix licensing information. If we want that, we want to help them. And that's something that we have done at the FSF. We've sent some patches upstream to, I think, Etherpad and some other projects to help the LibreJS or, sorry, Rails and JavaScript licensing information get upstream. You know, you can imagine there's a lot of projects that if they started doing that, they're in such wide use that it would make just a huge difference on so many different sites where those frameworks or those platforms are being used, they would be properly free right out of the box. And then we need on the user side, we need awareness campaigns, you know, on both sides, user and the site operator side. We need awareness campaigns in a friendly way, especially because when I mentioned those two problem areas, the, you know, but also the unintentionally non-free, especially in that case with unintentional, we need to take a very friendly approach and a constructive approach, but emphasize the importance of this, that this is software that's running on our local machine and needs to be free just like any other software that we run locally. So I would love to hear your feedback, your ideas, your comments about this. Has anybody in the room tried adding web labels to their site before? We got one. Yeah. A lot of people think about that method of providing license information. So what a link to the standard license suffice instead of putting a lot of text and a comment. The only text that we're recommending, so two things, you don't need the comment in the file if you're using the web label system. So if you have that separate table that provides the correspondence between the file, the license, and the source code, then you don't need to add anything else to the file. You only need to comment in the file if you're not doing the full web label system. But even if you're putting the comment in the file, what we're encouraging people to do is just to put that basic statement about the license in the file, the short version of the GPL boilerplate, for example, that you typically see in a source file because link to the license isn't really doing a great job of telling the user at least the summary that this is free software and you can freely copy it and share it and modify it. So that's nice to have there. But you don't need to worry about it all if you do the web labels.