Please introduce our next speaker, who is Bradley Coon, who will be speaking about, is there
really an espon mandate?
This is the talk that the espon devroom does not want you to hear.
They rejected it saying, well, everybody in the
espon devroom really already wants to work on espon.
So they don't want to hear about how they might not have to work on espon's.
So you should talk in a legal policy, devil instead.
The fact of the matter is the analogy that has been used for way too long to describe
how software works is fundamentally flawed.
We have this idea that there is a software supply chain.
The term supply chain, of course, comes from physical supply chains.
Real hardware things in the world be the electronics or not.
So we first should ask the question, is there really a thing called the software supply
chain?
I don't think there actually is, and the reason why is the things that happen in a supply chain
and the physical activity required by human beings to operate a supply chain is immense.
There are shipping containers.
There are giant cranes that lift those shipping containers.
There are standards that every shipping container has to be exactly the same configuration
all over the world.
So it fits on every barge and fits on every dock and can be unloaded by the same equipment
in every place around the world.
And there is a thing called leakage, both literal and figurative, literal of course,
like things can flood if you travel across an ocean.
And figuratively, the physical item industry talks about employees stealing stuff, which
happens, and dock workers steal stuff, and everyone steals sadly, there are in software,
no phones, no lights, no motor cars, there's not even a single luxury from my point
of view.
The analogy does not fit, and the main reason it doesn't fit is because open source and free
software, fast, has always been designed to reject the idea that software should be treated
like a physical object.
We have always believed that you should have the right and freedom to copy, share, modify,
redistribute, and reinstall software.
That's what philosophy is all about in the first place.
The proprietary software industry has desperately tried for decades to convince the world
that software is a scarce resource, just like physical objects.
They want it to be hard to copy, share, modify, redistribute, and store.
They want it to disappear if your license expires, all those sorts of things.
But we've been rejecting for a very long time, basically since the 1980s, that this notion
should apply to software, because we don't believe digital goods should have the same
scarcity requirements falsely applied from physical goods, the digital goods.
And as such, the supply chain analogy makes absolutely no sense.
So who is it that wants a software supply chain?
Well, people who make proprietary software, they want to make it difficult to
acquire software.
They want you to pay huge amounts of money just to get a copy of that amazing proprietary
software that's so much better than open source, because it's from a firm that developed
it and tailored it so carefully for you, and you can have that one copy, but not another
one.
Well, you could pay us again, have another copy.
We give you a sight license.
That's a couple million, but that one of your employees could have it.
So from my point of view, the entire idea of software supply chain, and therefore
S-bombs as well, is an imposition by the proprietary software industry on the open source
and free software community.
And if it weren't mandate, which I'm going to hopefully show you it is not, it would
be an unfunded mandate on upstream developers to require them to do things that are
not needed to do if your source is 100% false.
There are only needed if you're incorporating proprietary components, something to talk
about that in a few minutes.
This whole idea of the bill of materials, of course, comes from the supply chain analogy.
And the bill of materials is a list of physical things that are in places and in products
as they work their way through the physical supply chain.
So if the analogy doesn't really work for false, there's no way the S-bombs make any
sense for false.
Maybe they do proprietary software.
I don't know.
I don't do proprietary software.
But this has become this cute little marketing term that has convinced people that they
need this thing.
And people are like addicts to like, oh, you have this, bombs, bombs, you want a spombs?
So when you ask somebody, well, what is an S-bomb that is no formal definition?
There are two competing file formats.
But everyone admits that just having a file in that format is not necessarily an S-bomb.
And you're saying, well, what constitutes an S-bomb then?
And they said, we have to have those files in a certain configuration, in a certain order,
in certain requirements, which have not been written down yet by anyone as far as I can
tell.
It's just a thing that people are excited about because marketers told them to be excited
about it.
Now, most S-bomb enthusiasts will tell you that the EU Cybersecurity Act mandates S-bombs.
I have begged people to show me where and how it mandates S-bombs, and no one actually
can.
S-bombs are mentioned.
I'm going to show you a couple of places where it's mentioned in the CRA.
But to me, it is not describing the thing that people in the S-bomb community are talking
about.
So here's the first place that appears.
This is pretty vague.
I think that there is a lot of interpretation that will still come out about this particular
clause.
And it's pretty interesting to note that the S-bombs themselves under the CRA are admitted
to be something that can be proprietary.
And in fact, you can anonymize what your software sources actually are.
So all these folks in the S-bomb community are saying, well, S-bomb will tell you exactly what's
in your software.
Well, no one, because it can be anonymized.
So then you'll be like, well, what software is that?
It has a different name that's some code name that I don't have to beg the company to
tell me what the code name means so I can really figure out who my true upstream is.
This is in the place in the CRA where it says that somebody has to write an S-bomb.
Note that it says they don't have to be public, which means they are by default going to
be proprietary, the least under the CRA, because we know that proprietary offer companies
do not release software unless they're forced to buy a license or require under something
else.
They want to proprietaryize.
So we're going to have lots of proprietary S-bombs that some people will get that will
be anonymized.
So we won't actually know what's in the supply chain, if such a supply chain even exists.
But the best and most interesting part about the CRA is discussion of S-bombs is this
sentence, which says the commission will at some point specify the format and elements
of S-bombs.
To my knowledge, I'm not a CRA expert, there are some in the room and they can jump
up right now and tell me the commission is not so yet defined that.
And as such, even if this were to turn into an S-bomb mandate, we as a community have an
opportunity to decide what the format and elements of S-bombs should be and advocate for it
in a lobbying process to explain to the commission what exactly an S-bomb should look
like for open source and free software.
I will be questions, time for questions at the end.
If you want to sound completely wrong about the CRA, what's that?
And I'm proud of this question.
Yeah.
I appreciate it.
So I hope you'll listen real carefully if I want to say I would love for you to do what
I'm about to say.
So the first thing I'm going to just talk about the U.S. side.
So there was a lot of obsession in the United States about this executive order that President
Biden implemented.
You may have heard we had major regime change in my home land recently and the biggest
thing that's happening right now is executive order being resented and new ones are being
issued every five to ten minutes.
So from my point of view, anything in the Biden executive order, even though it's technically
still an executive order, because it hasn't been resented yet, is very unlikely to be implemented.
And I also don't think any of the NIST documents, which I've read all of, have any requirement
to do anything.
They're just recommendations to study various things, and this is doing a very good job
studying the question, but they have not, to my knowledge, come forward and said, this
is what industry has to do.
So I don't think we should actually ignore us, even though I don't think they really,
even though I think it's a marketing term, but I think there's another way we can
post this in a way that will help free software.
There's a wise lawyer, a colleague of somebody in this room, this lawyer is not retired.
They work for a major software company.
And right when the S-bomb stuff was starting, I had conversation with this person, I don't
know if he wants me to quote this publicly, so I won't, he didn't exactly say it this
way, but he said, well, I've had a really long career as a software industry lawyer,
and he said, sometimes I need colleagues who just want to make lists.
They love making lists, and they make lists, and they make lists of things, and they publish
lists.
And I've seen a lot of lists in my career, but they haven't made any of the software
industry, all that better.
So I've tended not to be a list maker, I've just got to ignore the list makers, my whole
career.
S-bomb is the ultimate and list making.
It's used to make lists sometimes, but it's a tool to get something else done from
my point of view.
Now, I am quite sure you will face the S-bomb problem.
All of you who work in industry as a software developer engineer, at some point a boss
is going to come up to you and say, yeah, so Peter, we have to have a conversation.
We're putting all the S-bombs on the cover sheets of our source code now, and you filed
your last source release with out an S-bombs.
I'm going to make sure you get another copy of the CRA, and then you can put your S-bomb
on the next release that you do there.
And what I'm going to encourage you to say is, say, yeah, so long-berg, I think maybe you
should go ahead and go away, I have been meeting with the bobs in a few minutes, and we're
going to talk about how my build is reproducible, that I have all the complete corresponding
source code.
For copy left license, it will be shipped to the customer, and with a full and complete
copy left release, with a complete corresponding source code, including the scripts used
and control compilation, and installation is executable, and a fully, verifiably reproducible
build.
I argue that this is a better format for an S-bomb than any list, because that entire source
release tells everyone in the so-called supply chain exactly what is in the software, because
it's all there in source code, which is the standard and common operating way that people
communicate about software.
And if the build is verifiably reproducible, it means they can prove that the binaries that
are in the product that we're built from that source code.
In fact, that's where it's good, and all the things that CRA and all the regulations
are trying to address, like, very dangerous things about cybersecurity and so forth, can very
easily be fixed.
And if you really want the list, if you have all of this, I argue that indeed can replace
the S-bomb generation with a very small show script.
So the only people who actually need S-bombs are proprietary software manufacturers, from
my point of view.
I don't know what they need them for, I don't really understand proprietary software, but
if you want a world where all software is free software, which I do, I'm not just
been a lot of time helping people make proprietary software better.
I agree that S-bombs are likely to make proprietary software much better, but I don't want
proprietary software to get better.
I want it to get worse, and I want free software to get better.
So this is why I don't think of the S-bomb mandate, and even if there is, we should advocate
strongly that the S-bomb format should be complete corresponding source code with verifiable
reproducible builds.
Thank you.
Isn't the idea of, you talk about the analogy not being appropriate, because it's not
we're not moving physical stuff, granted, but isn't a lot of the idea of understanding
the origin of a particular piece of software, and where it came from, and particularly for
security type reasons, and things like that, knowing that the famous XKCD comic that
here's all software, and then here's this little thing, the Libna Braska, right?
Understanding, hey, I've got Libna Braska in there, and it goes all the way down to the
free software developer in Nebraska, and it's been repackaged all through this chain.
Isn't that the core of the idea of a software supply chain, and the value that you get
by making the list of an S-bomb?
So if I included Libna Braska in my product, and when I delivered the source code for the
product to you, I gave you entire get history of Libna Braska, which of course includes
all contact information of the original developer in Nebraska, as well as any changes
that I made, and I proved to you that the version I gave you, that get commit, builds
reproducibly into the binary I also gave you.
I cannot imagine what else a list could give you, that isn't already available in that
information that I already gave you.
I agree, maybe you might want to build an automated list from that, it might be helpful,
summary information is useful, but it is in the end just summary information of the complete
corresponding source code.
Now, if I have proprietary Libna Braska, I've said a hot, it's not under a copy of
a license, I want to give you any source code, thank your screw, but you've unscrewed
anyway, because my pride here software is designed to screw you.
So from my point of view, if the pride here software does you need these S-bombs to screw
you a little bit less, they can go play with them if they want to, but I would rather
not screw you at all and give you all the right to deserve.
Then small request, so if you want to ask a question, please keep the hand up, that's
a bit easier for me to see where the people are, I will do my best to somehow do it in
the order and also make sure that I don't have to run all the time, but yeah, I'll try
it.
So in the spirit of S-bombs are they mandatory?
There is one scenario where they are mandatory with a legal construct behind that, and
that's in the US medical device manufacturers, and from a lists perspective, the thing
that they're trying to address is does the creator of the software that is going to somehow
be impacting patient life?
Do they know who supports this and who is maintaining the software, whether it be commercial
software, open source or otherwise?
So it gets very, very complicated quickly, but excellent presentation, I agree completely
that executive orders are not the way to do things.
Well, I think that in the medical devices' contacts, I think patients should have the right
to the complete corresponding source code of their device.
Karen, did you get an S-bombs for your heart device?
They did it well so apparently the man they saw followed, because Karen's got an implied
available high device that has proprietary software, and she didn't get an S-bombs for.
It's a question of when, so it went into effect in October of last year.
Well, again, they shouldn't be making a proprietary anyway, they are harming patients
by making a proprietary, as I already said, if it turns out that the proprietary software
industry wants to trick patients, users, everybody else into thinking, you're safe because
we have an S-bombs, even though you can't examine the source code, that's an unfortunate
outcome, and it's one of the reasons why I'm against S-bombs, right, because they're
designed to trick you into thinking you have something that you don't, which is the ability
to repruce, verify and understand your software.
S-bombs, do not give you that.
Bradley, I apologize if you already mentioned this because I was doing room duty, some
degree.
Have you found, as I have that this obsession with S-bombs has had a deleterious effect
on open source license compliance because increasingly companies seem to have reconceptualized
compliance as making these lists.
I have certainly found that in my work.
Oh, I think that has happened.
I think the most interesting use case of S-bombs, which literally there was a appliance
tools summit yesterday, and multiple people were saying, well, you know, what I really
want is the ability to make sure I don't have any copyrighted software my product because
I don't want to make any free software.
So while I want to consume all the non-copy-lefted stuff into my product, I want to turn
that into proprietary software.
As I have S-bombs, I can find every little copyrighted component throw it away.
So it's actually even worse than what you're saying because not only is it affecting the
compliance industrial complex to turn into an S-bomb generating system, but also the
extent which S-bombs are useful, they're designed to take away software freedom.
Just as a reminder, I will just if hands go down again, they are out of the list because
else it's difficult for me.
I know it's kind of discriminating and exosomely in the minutes later, thank you.
Oh, five.
What's my question?
Yeah, the question really is, is there a better word for supply chain?
Because that seems to be kind of the problem that the supply chain goes between companies
and doesn't reach the end-user and that is why it feels weird.
Yeah, I agree with you.
I mean, I thought as I started my talk, I think the analogy is the wrong analogy.
We used to talk just about upstream and downstream, like the entire software processes of
river, that's a better analogy, I think, than supply chain for sure.
In part, because supply chain is this corporate way of thinking and it ignores consumers.
Consumers never thought about supply chains until the pandemic, basically, and they stopped
thinking about them as soon as they were fixed.
So to apply that to software, in that case, I'm at physical supply chains.
To find out to software, it's like, well, that's you're totally right, it writes the consumer,
writes the end-user out of the picture, they're not important.
And we see that in the CRA, where it's saying, well, consumers in the public have no
right to see these S-bombs.
So it's already kind of baked into the thinking around what they're going to be,
is that they're just for company A to give the company B.
And I don't really care what happens between company A and company B.
I care what happens to the consumer in the end-user.
I'll talk to you later, Michael, close my mind.
Okay, very challenging, because I'm in the S-bombed every month tomorrow.
I'm not allowed to be, so I'm going to kick me out like, why can't you work on that?
So let's look at what S-bombs could be.
S-bombs are a vehicle to help this management to help software be called
more secure and resilient for the consumers.
So therefore, maybe S-bombs on their own might not be sufficient,
but S-bombs are clearly a vehicle to help people become transparent and prove
improve the software to be more secure and resilient.
I agree with everything you said, if you say proprietary software.
There's no question, I don't make a difference between A and R software.
It's all software.
It makes a world of difference, because if you have the complete corresponding source code
and reproducible build, you have a very different situation than a proprietary system.
I agree with you, the S-bombs will probably increase security in proprietary software.
I don't think they will do much for truly open source and free software that's under
a copy left license that has very beautiful build.
Hi, so I am an engineer, wooded of caution, and but also a logistics specialist,
information logistics.
And I understand as an engineer, I don't need S-bombs, I can just go around and
the code and analyze, but the soon I have to place it in rapid to be deployed elsewhere.
I need something to tag along so that people that unfortunately are not engineers can
have a way of saying what's inside without trying to learn count.
S-bombs are not completely evil on that sense, it's a way to tag something.
Could be S-bombs or any other of the different kinds of things.
So my question is more about how can we use this as not as a way to go back and say,
oh, you don't need to be free because we know have all the descriptions, but on the other hand,
as to say, to use the S-bombs as the way to say, this is a proof that what I'm delivering to
you was made completely through open and free licenses, and this has this thing inside it's
actually proprietary, like a firmware blob or something, and so I warning, this is a warning
label saying that there is a toxic component here that we don't know about.
And so, could we think about the S-bombs in that way?
So a part of what you said is actually reproducible builds, not S-bombs, right?
Because I don't think an S-bombs actually gives you that thing you were saying in the middle
there that the verifiable that this software was built from this thing, you can't do that with an
S-bombs. You could do that with a reproducible build, and I would be thrilled if the S-bombs
were inviting the reproducible builds people to come like speak in their
devrim about finding ways to integrate S-bombs with reproducible builds.
That doesn't seem to be very much of interest to the industry, and I also didn't say,
you said, well, I said that S-bombs were evil. I did not say that. What I said was,
S-bombs are lists, and that list making is a useful exercise when it's a tool to another
goal, but just making lists for the sake of making lists, which a lot of the S-bomb rhetoric
is about, in the end, that I've seen, then I don't really think a list for a list sake is that good,
and is there something better you should get? I think there's something better you should get,
is the complete corresponding source code, and that should, if you even want to call it supply chain,
it should travel all the way along the supply chain. It's an entire reproducible build source code,
is not traveling along the security risk is huge, and maybe in S-bombs can mitigate that sometimes,
but it would be much better if you had the complete corresponding source code in a reproducible build.
But in open source packages, you have to code if you have to release that is defined in the S-bomb.
I think I'm out of time, so I just was told, so I don't think, yeah, it's just an
annotation. The thing you criticize was to supply chain, but what we have in open source software,
as well, are dependencies, which are included into software, we write, so there doesn't have to
be a proprietary component in it, we benefit from transparency in our supply chain and our
dependencies and open source as well. And S-bombs is a standardized format, as well as all lockfights,
in all the languages we use. So, S-bombs, I think I should get the last word.
The Ns-bombs is, in fact, not transparent. It's opaque by its nature, specifically because it is
hiding the source code, because we have the source code, the S-bombs is really just a summary
information of the source code that you have.