I'm muted, where it's good.
Hi, I'm Mattia, I'm going to present something that's potentially controversial.
So I'm very happy that the chairs are actually bolted down, so the thing is, the thing
is, I want to keep the session interactive because what I'm really interested in is the
feedback, because I have a proposal and I want to make it better.
So what's the problem in the first place?
If anybody of you have seen JavaScript and practice before, typically there's no licenses
or notices in the source called already, and if they were, they're usually under distributed
to the end user, so typically to the browser, they're not anymore.
That's a potential copyright problem, right?
And I was trying to fix this finally, so what were my goals?
And I've done a quite bold goal that I tried to achieve is, I tried to push it as far
as I can.
So the pushing as far as I can, idea was, what if I can make it so copyright and
license data in from the source code get preserved even after a minification of JavaScript.
So even in the minified barf, he will still find where it is and exactly from where to
where which license applies.
But also, because we have to keep it real, I wanted to keep it as short and as simple
as possible, and I limited myself to not rely on any new standard specs, so it relies
basically on SPDX ISO standard and on reuse best practices.
And I didn't want to introduce any new tooling or changes to the tooling, so it relies
on tooling, that's already out there.
So here's the proposal.
So as I said, the idea was how far can I push existing stuff and how to keep the code,
the license info in even in minified barf output?
And that's the actual proposal.
Some of you might recognize 99% of it.
So the whole idea is you have code and you have the SPDX tags or reuse tags to the same thing
actually here in the top comment as usual.
But because JavaScript, CSS, et cetera, before you get shipped, typically got to
concatenate it first.
So you don't know where it starts in events, and then you have a problem, you know,
if there's some files that have license info and some files that don't have
license info, you don't know whether it over stretches or not.
So what I thought introduced was that we can then start every file with a snippet
begin and end every file with a snippet end.
So we know exactly to which code this applies and then to keep it and to keep this
markers and the minified code, I just used an exclamation mark here in an exclamation
mark here.
Done.
That is it.
Does it work?
In theory, it's a fucking literally.
I even done some research.
So I took, I'm a lawyer, I'm not a developer, so this took time.
In specific cases, I had to go read the code because in the documentation they were lying.
So from what I understand, and I can be wrong here because not my folder, these are the
most common minifiers, and as we can see that they do support, like since 2013, they
do support to keep important comments, for example, for licenses, or just important
comments, and pretty much everything apart from fun, which is a fairly new one, support,
at least one of them completely, and even here there's a pool request already being discussed
to implement it.
So theoretically still, we're very good.
Okay, but how does it look like in practice for reals?
Again, not a different front end developer, so I have quite a bit of help from friends
and colleagues.
So somebody helped me with Svelta Abda Dunn, which depends on roll up and thercer, and
it was mostly fine.
So the only thing, so everything was perfect, the only thing that was a bit weird was that
one snippet end tag ended up before the snippet begin tag in the minified output.
But in the mapping, in the source map, it was again fine.
So there's something fucking happening here.
I don't know what, then React, I hate React now, it's again, mostly fine, React depends
on webpack and thercer, but it has very opinionated, and so it's very hard to change anything
in thercer.
Therefore, the big problem that it has is that React just removes all the comments and
ignores, ignores, whether it's tagged as a license or an important comment, it just
that it gets rid of everything.
And then it buffs everything that it saw is important into a dot license file.
So, eh, maybe.
And that was all the proofs of concept I could manage to actually get running, because
again, not a front end developer.
I did create the blog post a few months ago about this, and I did ask for feedback, and
the feedback in broad strokes is, people who were into compliance were like, yes, that
totally makes sense, that's the proper way to do it.
How most of the JavaScript does were like, how low is it going to make everything so
big?
And I don't know, I don't have a proof of concept that is large enough to prove or just
prove the how big is this info will make the unified code.
So, if somebody is a front end dev and thinks this is interesting, I would love to
cooperate and find a huge example to see, you know, how many kilobytes or what's the
percentage of extra craft that goes into it if we do it that way?
So I got some more specific feedback, but I don't want to influence you.
So I already opened the floor for any comments and questions.
No, I am a licensed compliance guy, I've only touched the front end developer, and would
I agree that it held, you know, if you want to ship someone, you need to have two
or three or three specific insights, so I'm having the only way, as maybe I'd identify
it is a good game, but it's not perfect.
The question, the comment was by a person who's both a compliance guy and partial front
end developer, that this wouldn't help because you still need the full text of the license
and I am a lawyer, and I am fairly certain that the SPDX ID is enough because it's an
SPDX is an ISO standard, so if you see SPDX license identity for MIT, you know exactly
which totalisers we're talking about.
You have the SPDX license identifier, yep, I mean there's some templating there, but you are
a legal person, so do we need to provide the corresponding license text or some license
text?
Ah, that's, this is not legal advice, no but I have to be precise this, but would it help
to shoot, but would we be able to do some things for the JavaScript developers to have that
code?
A tiny bit larger, hardly.
No, no, I could really agree, but that was that, I mean, could we convince, there was
also a discussion whether SPDX ID is enough and it's something we would need to discuss
in a longer session, but then there was a comment, would we be able to convince all the
JavaScript developers to make the code slightly longer, and yeah, probably not, but that
would still be easier than convince them to do something more crazy, and what else are
you going to do?
There was a question in the back first, and then shellio and then.
So that's the thought to be provided by the license, the question is, so one of the questions
was, I can go over here, one of the questions that was here was, do we even need license
information in the magnified code, or even if we need it in the front end code?
Absolutely, we need it in the front end code, do we need it in the magnified code?
That's a good question.
I don't know, as I said, I tried to push it as hard as I can, you know, what's the maximum
I can squeeze out of existing tools and existing specs?
Whether there's a more convenient way of doing it, that's a good question, and one option
would be we could use source maps, but when I spoke to some of our in-house JavaScript
developers, they were also like source maps, not even reliable, really, when you're debugging
stuff, and now you want to rely on it for legal stuff.
The other thing that kind of goes into your place is I had a feedback from one of the big
companies that have really big JavaScript packages, and there is she who was exactly
that this could be quite big, but they don't know.
That was just the assumption.
So what they do is they create an ASBOM, depending on package manager data, which I am not
sure whether it's very reliable or not, but since they're dealing with a lot of code,
I suspect that, you know, doing it more proper would be a lot more work, and then they
ship the ASBOM, in, for example, like a well-licensed HTML anchor, but even that guy said,
you know, the proposal sounds like the proper way to go, but this is how they currently
manage it.
So follow up question or a new question?
OK.
No, no, I'm saying it matters, because if you're shipping code, you're distributing code,
you need to distribute the information.
How you're going to distribute the information is a good question.
Is it enough to just have a, as a other suggestion was, to just have a pop-up, and then
you have a link to everything, or have a pop-up with an ASBOM, or have an anchor link
to in the meta file to the ASBOM?
That's a good question, but you definitely need to have to deal with licenses, even in, you
know, clients, JavaScript.
The problem is the question is only how, and the reason why it suggests doing it in the source
code and profile is because that is the most reliable, and it's also when people copy
just whole files instead of relying on whole packages, the information, the meta licensing
metadata goes with the file, because it's in the file already in the first place.
OK.
Helio.
Not just think that it's more feasible, more straight ahead to the people that
do it.
The hashes tree is there and convince them to do a new revision that we need to enforce
this kind of information.
So at some point we have the package registry provided information, instead of making
it completely amount of developers angry.
So you just, the question was, if I'm just directly, would it make more sense to go to
registries and package managers, to ask them to enforce it, that it has to have the right
information, instead of spacing off developers directly, I think what all you're trying
to do is to offload the pissing off people on somebody else.
They're going to tell me the exact same thing.
There was the question here first, and then it was there, and then in the back.
OK.
There's a broader question here, is how useful information is captured in a comment that
is then lost, so you have the same thing when you do it compile, so I'm thinking about
all that, I'm thinking about a general public.
So we talked about this, this was talked last year, and first then when you build a set
of C file, and you lose that, because you have to have the comment in the comment pile
that you lose that reference into the statement.
So I think there's a more general public in trying to solve, and do we need a way of capturing
meaningful information about the license, every license of that, any criteria, it's a number,
it's a simplest thing, do we store the number as part of the header, so it's not going
to grow the file significantly, but it's going to have the information that can be interpreted.
And it's a more general public than just JavaScript.
Right, so if I understood the question correctly, the comment was, why do we try to do this
in the files, if not just in JavaScript, but in any language, the copyright headers, and the
comments might just get disappeared anyway, and my answer to that would be that's why pretty
much everybody in this room is using specialized tooling to scan this thing, and scanning
for this is much more efficient than scanning for arbitrary pieces of text.
And it's also quite shorter than arbitrary pieces of text.
It was a gentleman over there, or with a finish.
That's it.
I'm actually just picking up feedback, so if anybody is interested in the blog post, that's the full
blog post, which is a longer version of what I just presented, and I would be very, very happy
to gather more feedback, because my point is not to be proven right, my aim is to figure
this out and have a proposal that we could actually work on, because if we're just ignoring
the problem with front hand code, it's not going to get away, as just being pushed under
the rug.
That's it.
Thank you.