WEBVTT 00:00.000 --> 00:29.120 I'm muted, where it's good. 00:29.120 --> 00:39.960 Hi, I'm Mattia, I'm going to present something that's potentially controversial. 00:39.960 --> 00:52.560 So I'm very happy that the chairs are actually bolted down, so the thing is, the thing 00:52.560 --> 01:00.120 is, I want to keep the session interactive because what I'm really interested in is the 01:00.120 --> 01:06.000 feedback, because I have a proposal and I want to make it better. 01:06.000 --> 01:08.520 So what's the problem in the first place? 01:08.520 --> 01:16.600 If anybody of you have seen JavaScript and practice before, typically there's no licenses 01:16.600 --> 01:21.960 or notices in the source called already, and if they were, they're usually under distributed 01:21.960 --> 01:26.800 to the end user, so typically to the browser, they're not anymore. 01:26.800 --> 01:31.800 That's a potential copyright problem, right? 01:31.800 --> 01:38.080 And I was trying to fix this finally, so what were my goals? 01:38.080 --> 01:43.720 And I've done a quite bold goal that I tried to achieve is, I tried to push it as far 01:43.720 --> 01:45.080 as I can. 01:45.080 --> 01:51.760 So the pushing as far as I can, idea was, what if I can make it so copyright and 01:51.760 --> 01:58.880 license data in from the source code get preserved even after a minification of JavaScript. 01:58.880 --> 02:03.940 So even in the minified barf, he will still find where it is and exactly from where to 02:03.940 --> 02:07.520 where which license applies. 02:07.520 --> 02:12.120 But also, because we have to keep it real, I wanted to keep it as short and as simple 02:12.120 --> 02:19.520 as possible, and I limited myself to not rely on any new standard specs, so it relies 02:19.560 --> 02:25.560 basically on SPDX ISO standard and on reuse best practices. 02:25.560 --> 02:29.240 And I didn't want to introduce any new tooling or changes to the tooling, so it relies 02:29.240 --> 02:33.680 on tooling, that's already out there. 02:33.680 --> 02:37.280 So here's the proposal. 02:37.280 --> 02:46.480 So as I said, the idea was how far can I push existing stuff and how to keep the code, 02:47.400 --> 02:52.040 the license info in even in minified barf output? 02:52.040 --> 02:54.640 And that's the actual proposal. 02:54.640 --> 03:00.080 Some of you might recognize 99% of it. 03:00.080 --> 03:09.840 So the whole idea is you have code and you have the SPDX tags or reuse tags to the same thing 03:09.840 --> 03:13.800 actually here in the top comment as usual. 03:13.800 --> 03:19.240 But because JavaScript, CSS, et cetera, before you get shipped, typically got to 03:19.240 --> 03:20.480 concatenate it first. 03:20.480 --> 03:23.760 So you don't know where it starts in events, and then you have a problem, you know, 03:23.760 --> 03:27.340 if there's some files that have license info and some files that don't have 03:27.340 --> 03:31.320 license info, you don't know whether it over stretches or not. 03:31.320 --> 03:36.400 So what I thought introduced was that we can then start every file with a snippet 03:36.400 --> 03:39.480 begin and end every file with a snippet end. 03:39.520 --> 03:48.000 So we know exactly to which code this applies and then to keep it and to keep this 03:48.000 --> 03:53.520 markers and the minified code, I just used an exclamation mark here in an exclamation 03:53.520 --> 03:54.520 mark here. 03:54.520 --> 03:55.520 Done. 03:55.520 --> 03:58.720 That is it. 03:58.720 --> 04:00.720 Does it work? 04:00.720 --> 04:05.360 In theory, it's a fucking literally. 04:05.360 --> 04:07.720 I even done some research. 04:07.720 --> 04:15.120 So I took, I'm a lawyer, I'm not a developer, so this took time. 04:15.120 --> 04:24.640 In specific cases, I had to go read the code because in the documentation they were lying. 04:24.640 --> 04:31.600 So from what I understand, and I can be wrong here because not my folder, these are the 04:31.600 --> 04:40.800 most common minifiers, and as we can see that they do support, like since 2013, they 04:40.800 --> 04:49.080 do support to keep important comments, for example, for licenses, or just important 04:49.080 --> 04:57.120 comments, and pretty much everything apart from fun, which is a fairly new one, support, 04:57.160 --> 05:04.440 at least one of them completely, and even here there's a pool request already being discussed 05:04.440 --> 05:05.440 to implement it. 05:05.440 --> 05:09.600 So theoretically still, we're very good. 05:09.600 --> 05:13.720 Okay, but how does it look like in practice for reals? 05:13.720 --> 05:21.680 Again, not a different front end developer, so I have quite a bit of help from friends 05:21.680 --> 05:23.160 and colleagues. 05:23.160 --> 05:30.400 So somebody helped me with Svelta Abda Dunn, which depends on roll up and thercer, and 05:30.400 --> 05:31.400 it was mostly fine. 05:31.400 --> 05:38.320 So the only thing, so everything was perfect, the only thing that was a bit weird was that 05:38.320 --> 05:45.960 one snippet end tag ended up before the snippet begin tag in the minified output. 05:45.960 --> 05:49.160 But in the mapping, in the source map, it was again fine. 05:49.200 --> 05:53.400 So there's something fucking happening here. 05:53.400 --> 06:07.640 I don't know what, then React, I hate React now, it's again, mostly fine, React depends 06:07.640 --> 06:15.440 on webpack and thercer, but it has very opinionated, and so it's very hard to change anything 06:15.440 --> 06:16.440 in thercer. 06:16.440 --> 06:23.840 Therefore, the big problem that it has is that React just removes all the comments and 06:23.840 --> 06:29.560 ignores, ignores, whether it's tagged as a license or an important comment, it just 06:29.560 --> 06:31.520 that it gets rid of everything. 06:31.520 --> 06:36.120 And then it buffs everything that it saw is important into a dot license file. 06:36.120 --> 06:42.680 So, eh, maybe. 06:42.680 --> 06:47.200 And that was all the proofs of concept I could manage to actually get running, because 06:47.200 --> 06:51.200 again, not a front end developer. 06:51.200 --> 06:58.840 I did create the blog post a few months ago about this, and I did ask for feedback, and 06:58.840 --> 07:03.280 the feedback in broad strokes is, people who were into compliance were like, yes, that 07:03.280 --> 07:06.760 totally makes sense, that's the proper way to do it. 07:06.760 --> 07:12.480 How most of the JavaScript does were like, how low is it going to make everything so 07:12.560 --> 07:14.960 big? 07:14.960 --> 07:22.080 And I don't know, I don't have a proof of concept that is large enough to prove or just 07:22.080 --> 07:26.720 prove the how big is this info will make the unified code. 07:26.720 --> 07:33.080 So, if somebody is a front end dev and thinks this is interesting, I would love to 07:33.080 --> 07:41.960 cooperate and find a huge example to see, you know, how many kilobytes or what's the 07:41.960 --> 07:49.640 percentage of extra craft that goes into it if we do it that way? 07:49.640 --> 07:56.560 So I got some more specific feedback, but I don't want to influence you. 07:56.560 --> 08:02.720 So I already opened the floor for any comments and questions. 08:02.720 --> 08:09.360 No, I am a licensed compliance guy, I've only touched the front end developer, and would 08:09.360 --> 08:16.220 I agree that it held, you know, if you want to ship someone, you need to have two 08:16.220 --> 08:20.520 or three or three specific insights, so I'm having the only way, as maybe I'd identify 08:20.520 --> 08:24.120 it is a good game, but it's not perfect. 08:24.120 --> 08:32.320 The question, the comment was by a person who's both a compliance guy and partial front 08:32.320 --> 08:36.760 end developer, that this wouldn't help because you still need the full text of the license 08:36.760 --> 08:46.600 and I am a lawyer, and I am fairly certain that the SPDX ID is enough because it's an 08:46.600 --> 08:53.880 SPDX is an ISO standard, so if you see SPDX license identity for MIT, you know exactly 08:53.880 --> 09:02.320 which totalisers we're talking about. 09:02.320 --> 09:15.040 You have the SPDX license identifier, yep, I mean there's some templating there, but you are 09:15.040 --> 09:21.380 a legal person, so do we need to provide the corresponding license text or some license 09:21.380 --> 09:22.380 text? 09:22.380 --> 09:39.260 Ah, that's, this is not legal advice, no but I have to be precise this, but would it help 09:39.260 --> 09:45.060 to shoot, but would we be able to do some things for the JavaScript developers to have that 09:45.060 --> 09:46.060 code? 09:46.060 --> 09:48.060 A tiny bit larger, hardly. 09:48.620 --> 09:54.460 No, no, I could really agree, but that was that, I mean, could we convince, there was 09:54.460 --> 10:00.180 also a discussion whether SPDX ID is enough and it's something we would need to discuss 10:00.180 --> 10:08.740 in a longer session, but then there was a comment, would we be able to convince all the 10:08.740 --> 10:16.020 JavaScript developers to make the code slightly longer, and yeah, probably not, but that 10:16.020 --> 10:21.420 would still be easier than convince them to do something more crazy, and what else are 10:21.420 --> 10:23.420 you going to do? 10:23.420 --> 10:37.740 There was a question in the back first, and then shellio and then. 10:37.740 --> 10:49.460 So that's the thought to be provided by the license, the question is, so one of the questions 10:49.460 --> 11:01.620 was, I can go over here, one of the questions that was here was, do we even need license 11:01.620 --> 11:05.780 information in the magnified code, or even if we need it in the front end code? 11:05.780 --> 11:09.460 Absolutely, we need it in the front end code, do we need it in the magnified code? 11:09.460 --> 11:10.460 That's a good question. 11:10.460 --> 11:15.500 I don't know, as I said, I tried to push it as hard as I can, you know, what's the maximum 11:15.500 --> 11:19.380 I can squeeze out of existing tools and existing specs? 11:19.380 --> 11:27.980 Whether there's a more convenient way of doing it, that's a good question, and one option 11:27.980 --> 11:35.380 would be we could use source maps, but when I spoke to some of our in-house JavaScript 11:35.380 --> 11:41.180 developers, they were also like source maps, not even reliable, really, when you're debugging 11:41.180 --> 11:45.740 stuff, and now you want to rely on it for legal stuff. 11:45.740 --> 11:54.940 The other thing that kind of goes into your place is I had a feedback from one of the big 11:54.940 --> 12:01.980 companies that have really big JavaScript packages, and there is she who was exactly 12:01.980 --> 12:04.660 that this could be quite big, but they don't know. 12:04.700 --> 12:06.300 That was just the assumption. 12:06.300 --> 12:16.700 So what they do is they create an ASBOM, depending on package manager data, which I am not 12:16.700 --> 12:21.260 sure whether it's very reliable or not, but since they're dealing with a lot of code, 12:21.260 --> 12:27.420 I suspect that, you know, doing it more proper would be a lot more work, and then they 12:27.500 --> 12:40.780 ship the ASBOM, in, for example, like a well-licensed HTML anchor, but even that guy said, 12:40.780 --> 12:44.060 you know, the proposal sounds like the proper way to go, but this is how they currently 12:44.060 --> 12:45.460 manage it. 12:45.460 --> 12:50.740 So follow up question or a new question? 12:51.700 --> 12:52.700 OK. 13:01.180 --> 13:08.420 No, no, I'm saying it matters, because if you're shipping code, you're distributing code, 13:08.420 --> 13:12.020 you need to distribute the information. 13:12.020 --> 13:15.540 How you're going to distribute the information is a good question. 13:15.540 --> 13:21.820 Is it enough to just have a, as a other suggestion was, to just have a pop-up, and then 13:21.820 --> 13:32.620 you have a link to everything, or have a pop-up with an ASBOM, or have an anchor link 13:32.620 --> 13:38.100 to in the meta file to the ASBOM? 13:38.100 --> 13:44.740 That's a good question, but you definitely need to have to deal with licenses, even in, you 13:44.740 --> 13:47.940 know, clients, JavaScript. 13:47.940 --> 13:52.980 The problem is the question is only how, and the reason why it suggests doing it in the source 13:52.980 --> 14:03.260 code and profile is because that is the most reliable, and it's also when people copy 14:03.260 --> 14:09.540 just whole files instead of relying on whole packages, the information, the meta licensing 14:09.540 --> 14:15.020 metadata goes with the file, because it's in the file already in the first place. 14:15.020 --> 14:16.020 OK. 14:16.020 --> 14:17.020 Helio. 14:17.020 --> 14:21.500 Not just think that it's more feasible, more straight ahead to the people that 14:21.500 --> 14:22.500 do it. 14:22.500 --> 14:28.620 The hashes tree is there and convince them to do a new revision that we need to enforce 14:28.620 --> 14:30.060 this kind of information. 14:30.060 --> 14:36.140 So at some point we have the package registry provided information, instead of making 14:36.140 --> 14:39.940 it completely amount of developers angry. 14:39.940 --> 14:46.740 So you just, the question was, if I'm just directly, would it make more sense to go to 14:46.740 --> 14:55.100 registries and package managers, to ask them to enforce it, that it has to have the right 14:55.100 --> 15:01.380 information, instead of spacing off developers directly, I think what all you're trying 15:01.380 --> 15:05.420 to do is to offload the pissing off people on somebody else. 15:05.420 --> 15:11.180 They're going to tell me the exact same thing. 15:11.180 --> 15:16.180 There was the question here first, and then it was there, and then in the back. 15:16.180 --> 15:17.180 OK. 15:17.180 --> 15:23.420 There's a broader question here, is how useful information is captured in a comment that 15:23.420 --> 15:29.460 is then lost, so you have the same thing when you do it compile, so I'm thinking about 15:29.460 --> 15:31.580 all that, I'm thinking about a general public. 15:31.580 --> 15:35.940 So we talked about this, this was talked last year, and first then when you build a set 15:35.940 --> 15:41.420 of C file, and you lose that, because you have to have the comment in the comment pile 15:41.420 --> 15:43.900 that you lose that reference into the statement. 15:43.900 --> 15:52.260 So I think there's a more general public in trying to solve, and do we need a way of capturing 15:52.260 --> 15:57.180 meaningful information about the license, every license of that, any criteria, it's a number, 15:57.420 --> 16:03.940 it's a simplest thing, do we store the number as part of the header, so it's not going 16:03.940 --> 16:10.540 to grow the file significantly, but it's going to have the information that can be interpreted. 16:10.540 --> 16:14.580 And it's a more general public than just JavaScript. 16:14.580 --> 16:21.300 Right, so if I understood the question correctly, the comment was, why do we try to do this 16:21.380 --> 16:32.540 in the files, if not just in JavaScript, but in any language, the copyright headers, and the 16:32.540 --> 16:38.580 comments might just get disappeared anyway, and my answer to that would be that's why pretty 16:38.580 --> 16:45.980 much everybody in this room is using specialized tooling to scan this thing, and scanning 16:45.980 --> 16:50.900 for this is much more efficient than scanning for arbitrary pieces of text. 16:50.900 --> 16:54.580 And it's also quite shorter than arbitrary pieces of text. 16:54.580 --> 17:00.140 It was a gentleman over there, or with a finish. 17:00.140 --> 17:01.140 That's it. 17:01.140 --> 17:11.900 I'm actually just picking up feedback, so if anybody is interested in the blog post, that's the full 17:11.900 --> 17:19.820 blog post, which is a longer version of what I just presented, and I would be very, very happy 17:19.860 --> 17:26.700 to gather more feedback, because my point is not to be proven right, my aim is to figure 17:26.700 --> 17:34.140 this out and have a proposal that we could actually work on, because if we're just ignoring 17:34.140 --> 17:41.300 the problem with front hand code, it's not going to get away, as just being pushed under 17:41.300 --> 17:42.300 the rug. 17:42.300 --> 17:43.300 That's it. 17:43.300 --> 17:44.300 Thank you.