identifying software and licenses used in base install

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

identifying software and licenses used in base install

Kent Watsen

I'm throwing together a quick proof-of-concept thingy to give to a
customer and thought it might be  fun to use OpenBSD as the OS for the
VM image.   Unfortunately, the not so fun part of it is that I'm
required to get permission to use/distribute this open source software,
which entails needing to identify all the internal software components
and licenses used.  I thought this was going to be easy, but it's
proving to be anything but...

My system only has the following installed: bsd, bsd.rd, bsd.mp, base62,
etc62, and man62.

Is there, by chance, such a breakdown available for these already? Since
OpenBSD is distributed in binary form, is there a copyright attributions
listing somewhere to satisfy the "must reproduce the above copyright"
clause, or do you just point to the also-distributed source for all that?

In lieu of that, it seems that a script could analyze the source code -
everything is contained in sys.tar.gz (the kernel) and src.tar.gz
(userland), right?

For the kernel, I'd like to think that it's all BSD, but `grep -R
'"GPL"' *` shows 39 files having the "GPL" string.  Looking at these, it
appears that they are all dual-licensed.  I didn't check if there are
any other licenses in the kernel, but is it safe to say that, if there
are, they are all dual-licensed and therefore the net-net is that the
kernel is all BSD?

For the userland, first, is there an easy way to isolate the sub-parts
of src.tar.gz that contribute to base62, etc62, and man62?  Next, is
there an easy way to identify the unique packages/projects that are
included?  - this in hope that it might be easier to identify the
licenses at the project-level than the file-level.  Any thoughts for how
to make this go easy?

I'm beginning to think that this might be more trouble than it's worth,
and that I might be better off having the customer download/install
OpenBSD  themselves, and then run something like an Ansible script to
install/configure the demo...

Thanks,
Kent



Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Nick Holland
On 01/17/18 18:11, Kent Watsen wrote:
>
> I'm throwing together a quick proof-of-concept thingy to give to a
> customer and thought it might be  fun to use OpenBSD as the OS for the
> VM image.   Unfortunately, the not so fun part of it is that I'm
> required to get permission to use/distribute this open source software,
> which entails needing to identify all the internal software components
> and licenses used.  I thought this was going to be easy, but it's
> proving to be anything but...

I'm a little puzzled by this.
You have been granted the permission to use/distribute the software.

No one is going to give you a personal note of permission, unless you
want to chuck a lot of money someone's way.

http://www.openbsd.org/policy.html

This shows the common open source licenses, and the OpenBSD take on
them.  Have your requestor look at those licenses, have them tell you
which are objectionable, and see if the OpenBSD "take" is similar.  For
example, if your requestor says, "I don't accept GPL3", great, OpenBSD
is on the same page.  if they don't like GPL2, you lose the compiler tools.

> My system only has the following installed: bsd, bsd.rd, bsd.mp, base62,
> etc62, and man62.
>
> Is there, by chance, such a breakdown available for these already? Since
> OpenBSD is distributed in binary form, is there a copyright attributions
> listing somewhere to satisfy the "must reproduce the above copyright"
> clause, or do you just point to the also-distributed source for all that?
>
> In lieu of that, it seems that a script could analyze the source code -
> everything is contained in sys.tar.gz (the kernel) and src.tar.gz
> (userland), right?

the source tree pretty well shows you how the utilities are licensed.
Things that are ISC/BSD compatible.  Things that aren't BSD-ish license
are in /usr/src/gnu.  If that's where your problem is, that's what you
want to leave out.

...

> I'm beginning to think that this might be more trouble than it's worth,
> and that I might be better off having the customer download/install
> OpenBSDÂ  themselves, and then run something like an Ansible script to
> install/configure the demo...

naw.  Better than that, walk them through the install over the phone,
configuring the thing and all.  Really, I've done it several times with
people, it is so stupidly easy to do in person, you can easily guide
someone through it over the phone, just having them read to you what is
on the screen, and tell them the appropriate response.  They will be
wowed beyond belief, I suspect.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Theo de Raadt-2
In reply to this post by Kent Watsen
> Is there, by chance, such a breakdown available for these already?

No.  We did our best.

Always interesting that the more one works in the free software
space, the more constraints get added by the public.

Sometimes it is almost like there is a stream of people who want us
to stop trying.

And quit.   Some of you can see it, right?

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Raul Miller
On Thu, Jan 18, 2018 at 12:31 AM, Theo de Raadt <[hidden email]> wrote:
> Sometimes it is almost like there is a stream of people who want us
> to stop trying.
>
> And quit.   Some of you can see it, right?

yes. :(

Worse, i am concerned that i might have been contributing to that
effect - not intentionally, but it's not like that should matter to
anyone.

But you do what you can.

--
Raul

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

chohag
In reply to this post by Theo de Raadt-2
"Theo de Raadt" writes:
> > Is there, by chance, such a breakdown available for these already?
>
> No.  We did our best.

To be fair, these statements are potentially contradictory. If you (plural) only "did your best" (and what more could have been done?) then it is at least in *theory* possible that some mis-licensed piece of code slipped through.

In fact I expect this didn't happen, but regardless ...

> Always interesting that the more one works in the free software
> space, the more constraints get added by the public.
>
> Sometimes it is almost like there is a stream of people who want us
> to stop trying.
>
> And quit.   Some of you can see it, right?

... as more time goes by the more damage and less advantage I see by the existence of software licenses. I signed up to this life to be a programmer not a lawyer and over the years I've spent dealing in various parts of the computer ecosystem I've seen them causing more harm than good in practically every case. https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses describes a sorry state of affairs. So much good technology has been lost, and so much potential for cooperation has been squandered, by schoolyard bickering between the ignorant over irrelevant (and I might add, euro/anglo-centric) ideas of propriety.

Why did BeOS and QNX, among many many others, dwindle into obscurity?

Why are zfs, jails, kvm, pf not integrated into every operating system?

Why are hardware drivers not developed centrally?

Why do we have half a dozen java (the write-once run no^H^Hanywhere language) implementations?

Why did Debian waste some of our limited effort on a useless and disruptive fork of mozilla?

Why does mariadb even exist?

X?

Et cetera.

Such a terrible waste. We have become divided at our own hand and are being slowly conquered, and who does it benefit? The public? Other programmers? The state of the art?

Matthew

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Peter Nicolai Mathias Hansteen
On Thu, Jan 18, 2018 at 09:27:22AM +0200, [hidden email] wrote:
> "Theo de Raadt" writes:
> > > Is there, by chance, such a breakdown available for these already?
> >
> > No.  We did our best.
>
> To be fair, these statements are potentially contradictory. If you (plural) only "did your best" (and what more could have been done?) then it is at least in *theory* possible that some mis-licensed piece of code slipped through.
>
> In fact I expect this didn't happen, but regardless ...

The OpenBSD source tree was in fact license audited at one point, more
less as a direct response to the IPF episode that lead to us no having PF instead.

I think the message Theo wrote to misc@ in early 2003 serves to illustrate the
amount of work that went into this: https://marc.info/?l=openbsd-misc&m=104570938124454&w=2

During the roughly 15 years since then, everybody involved in adding or removing
code in the source tree have been very aware of the licensing issue, and I think we
can state with some confidence that no improperly licensed code or other material
has been added to the OpenBSD source tree during that period.

If you have sufficient time on your hands to read all the OpenBSD source in order
to track down anything that the early noughties licensing audit missed there's nothing
stopping you, of course. But I would think that peeking around the CVS history
of various items referenced in Theo's message would serve to convince most sane
people that a a significant effort was put in to ensure that the tree has no
improperly licensed material.

- Peter

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Anthony J. Bentley-4
In reply to this post by chohag
[hidden email] writes:

> "Theo de Raadt" writes:
> > > Is there, by chance, such a breakdown available for these already?
> >
>
> > No.  We did our best.
>
> To be fair, these statements are potentially contradictory. If you
> (plural) only "did your best" (and what more could have been done?)
> then it is at least in *theory* possible that some mis-licensed piece
> of code slipped through.
>
> In fact I expect this didn't happen, but regardless ...

Of course it's possible. There's no contradiction in saying so.

We also do our best to write bug-free software.
You might be shocked to hear that there are still bugs in OpenBSD.

I suspect that OpenBSD is stricter than the vast majority of comparable
free software projects. OpenBSD has a demonstrated history and culture
of removing or rewriting nonfree code. I personally have confidence both
that we have removed all nonfree code, or very close to it, and that we
haven't introduced more.

But providing a *guarantee* is a tall order, and certainly not one I'm
willing to fulfill.

If the chance of a license error slipping through is unacceptable to
someone like Kent, due to his choice of customer or some other reason,
he needs to audit the source himself until he's confident. Why should
he, or his customer, trust what we *say*? That's what the code is for.

If no person ever audited the source of the software they use, that
would be a sad state of affairs.

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Janne Johansson-3
In reply to this post by chohag
2018-01-18 8:27 GMT+01:00 <[hidden email]>:

> "Theo de Raadt" writes:
> > > Is there, by chance, such a breakdown available for these already?
> >
> > No.  We did our best.
>
> To be fair, these statements are potentially contradictory. If you
> (plural) only "did your best" (and what more could have been done?) then it
> is at least in *theory* possible that some mis-licensed piece of code
> slipped through.
>
> In fact I expect this didn't happen, but regardless ...
>

Well, it could still be a mix of MIT, BSD 2-clause, BSD 3-clause, public
domain and other very similar but not 100% identical licenses spread around
the non-GPL parts, and among those, a list of which parts are what might be
hard to find.

So for "commercial vs free" or "BSD-ish vs GPL" you might be safe to know
all except the gnu stuff has a very permissive license, comparable to
MIT/2-3 BSDL, you might still not be able to get a full list with tables and
checkboxes for each single file because making _that_ list takes time from
real work and may never be finished.

Now, something recent like importing llvm might have accidentally pulled in
a single small file with a wrong license in theory, so of course mistakes
can slip in, but barring that you can be certain that badly licensed code
will not have
deliberately entered the tree.

--
May the most significant bit of your life be positive.
Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Ingo Schwarze
In reply to this post by Kent Watsen
Hi Kent,

Kent Watsen wrote on Wed, Jan 17, 2018 at 11:11:40PM +0000:

> I'm throwing together a quick proof-of-concept thingy to give to a
> customer and thought it might be fun to use OpenBSD as the OS for the
> VM image.  Unfortunately, the not so fun part of it is that I'm
> required to get permission to use/distribute this open source software,

I assume that with "this" you mean "OpenBSD".  In this case, as others
have explained, everybody already has that permission.

> which entails needing to identify all the internal software components
> and licenses used.

Just curious - why do you think that is required?  In general, if all
parts of a compilation allow redistribution, then by definition you have
the right to redistribute the compilation, and i know of no obligation
to provide a list of licences with the redistribution, at least not if
access to the complete source code (containing all the licences) is
readily available, which it is in this case.

That said, i have seen people povide such lists in the past, and i did
provide such lists in the past for projects i'm maintaining, for
example

  http://mandoc.bsd.lv/LICENSE

which is also a (very small) part of OpenBSD.  The reason for doing
so is that it can sometimes clarify the situation and it is a nice
way to give credit for a project of limited size, but there is no
obligation to provide something like that that i'm aware of, and it
is hardly practical for a large project like OpenBSD because setting
up and maintaining the list would consume unreasonable time and the
list would be so long that it would not be worthwhile for anybody to
try and read it.

[...]
> bsd, bsd.rd, bsd.mp, base62, etc62, and man62.
> Is there, by chance, such a breakdown available for these already?

No, and the source tree is not structured in the same way as the
installation sets.

> Since OpenBSD is distributed in binary form, is there a copyright
> attributions listing somewhere to satisfy the "must reproduce the
> above copyright" clause, or do you just point to the also-distributed
> source for all that?

Exactly, the latter, the licenses are published in the source tree,
which is readily available to everybody.

> For the userland, first, is there an easy way to isolate the sub-parts
> of src.tar.gz that contribute to base62, etc62, and man62?

No.

> Next, is there an easy way to identify the unique packages/projects
> that are included?

No.

In contrast to many Linux distributions, which split even the core
of the userland into small packages taken from various third-party
sources, OpenBSD is developed as an integral whole, and there is no
such concept as "packages contained in the base system".  As far as
portable packages of software exist that are also part of OpenBSD,
these portable packages are assembled as collections of files taken
from various parts of the OpenBSD tree, but the OpenBSD tree is *not*
constructed as a union of independent packages.  For example, portable
mandoc contains files from /usr/src/usr.bin/mandoc and /usr/src/share,
but OpenBSD does not contain all files contained in portable mandoc.

The remaining questions were already answered by others.

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Ingo Schwarze
In reply to this post by chohag
Hi,

[hidden email] wrote on Thu, Jan 18, 2018 at 09:27:22AM +0200:

> ... as more time goes by the more damage and less advantage I see
> by the existence of software licenses.

This is imprecise.  The *proliferation* of software licenses is
indeed a problem, in particular the proliferation of complicated
and restrictive ones like GPL, CDDL, and Apache 2.0.

The *existence* of a free license is required as long as Copyright
exists, and realistically, Copyright is not going to go away soon.
Besides, i wouldn't even want Copyright to go away completely.  Some
aspects of it are good, in particular the moral rights, for example
the inalienable right of artists to object to the abuse of their
works for slander and the inalienable right of creators to be known
as such.

You ask many questions about reasons, and almost all of them have
complex answers containing more than one sub-reason, so discussing
these question would probably drift off-topic.  But it is true that
license proliferation and incompatibility play a role in some
of these cases - but not the fact that every free software needs
a free license.  There is nothing wrong with that.

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Ingo Schwarze
In reply to this post by Nick Holland
Hi Nick,

Nick Holland wrote on Wed, Jan 17, 2018 at 09:44:41PM -0500:

> Things that aren't BSD-ish license are in /usr/src/gnu.

Still true, but...

> If that's where your problem is, that's what you want to leave out.

... that part is mildly misleading.
Large parts below /usr/src/gnu/ *are* BSD-ish.  See:

   $ sed -n 3,7p /usr/src/gnu/README  
  This directory contains software that is Gigantic and Nasty but
  Unavoidable.
 
  Some, but not all, of the software in this subtree follows special
  rules, i.e. licences other than BSD.

Besides, GPL is not a problem when *redistributing* OpenBSD.  The
GPL explicitly allows redistribution, and the source code is available
as required.  It only becomes a potential problem if you want to
change a GPL-licensed file and then distribute binaries of the
changed version.  But before starting to edit any file, you look
at the license header in that file in the first place and consider
the implications, don't you?  So you don't need any list for that,
either.

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Janne Johansson-3
In reply to this post by Janne Johansson-3
2018-01-18 9:28 GMT+01:00 Janne Johansson <[hidden email]>:

> 2018-01-18 8:27 GMT+01:00 <[hidden email]>:
>
>> > > Is there, by chance, such a breakdown available for these already?
>>
>>
> So for "commercial vs free" or "BSD-ish vs GPL" you might be safe to know
> all except the gnu stuff has a very permissive license, comparable to
> MIT/2-3 BSDL, you might still not be able to get a full list with tables and
> checkboxes for each single file because making _that_ list takes time from
> real work and may never be finished.
>

Oh, and even if you do the work to complete a list of (C) holders like
NetBSD does,
ftp://ftp.netbsd.org/pub/NetBSD-archive/NetBSD-5.1.3/evbarm/INSTALL.html#Legal
Mumbo-Jumbo
it still doesn't say which file has 2,3 clause BSD and so on.

--
May the most significant bit of your life be positive.
Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Kent Watsen
In reply to this post by Kent Watsen

FWIW, the permission I seek is from my Legal department.  They want to
ensure that 1) we don't use software having unacceptable licenses or in
unacceptable ways, and 2) that the terms of all the copyrights are
adhered to (e.g., reproducing attribution statements, etc.).

At this point, it appears that I'm going to need to use a script to
analyze the entire source tree in order to generate a report.
Fortunately, a colleague has such a script for FreeBSD that I hope to
adapt.  I'll see if I can send the result here as well.

While I'm installing just a subset of src.tar.gz (base62, etc62, and
man62), it appears from the responses here that it's not possible to
isolate the source code for those parts.  I guess I'll run the script
over the entire this and see what happens.

Thanks again,
Kent

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Theo de Raadt-2
In reply to this post by Kent Watsen
>FWIW, the permission I seek is from my Legal department.

That maybe your job but it isn't the project's job.

We could write the document you need.  Then the next comment would
probably we that we didn't publish our procedure and have a lawyer
sign off on what we did.

It is a neverending battle.  We do more to advance things, and
we get told we need to do more.

Enough is enough.  That sentence above makes it clear who is getting
paid for satisfying those requirements:  You.

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

chohag
In reply to this post by chohag
"Jake D. Parsons" writes:
> You seem to be railing against some perceived notion of injustice in

Injustice? No. Irrelevence.

> some perceived notion utopia. What is the point and agenda here? Why do

Utopia? Have you ever even *run* a computer system? My point is that I'm tired of the excessive waste and shere incompetence caused by bickering between people unwilling to humble themselves enough to admit to their shared experiences and common goals. How did we *ever* let the emperor's new server come to pass?

Although it does pay well.

> different technologies? Because it is their choice and considerations of
> what would work best for them. I' am glad there is so many choices. It

This sentence no verb. If I assume 'exist' it can only imply that you misunderstand. Quelle surprise.

The problem is not different technologies; competition builds strength. The problem is identical bikesheds painted different colours; competition can also end in a premature death of misdirected talent.

Ingo, although I disagree with the finer points of his argument, is the only person in this thread yet to talk sense. There's _so much_ posturing. And to what purpose?

> means the riff raff can float their raft over there and I can float my

Always it is "they" who are the riff-raff. Such arrogance.

> raft over here.

And yet they're still rafts, while we fool ourselves that we man a battleship.

Enjoy your lawyer-enriching disaster while you are ground into irrelevance beneath a mountain of impotence and wasted effort.

Matthew

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Anders Arnholm
In reply to this post by Kent Watsen

>
> FWIW, the permission I seek is from my Legal department.  They want to ensure that 1) we don't use software having unacceptable licenses or in unacceptable ways, and 2) that the terms of all the copyrights are adhered to (e.g., reproducing attribution statements, etc.).
>

In my personal opinion this is the time to ask what and how much they need that promise. The budget they have and what risk contra costs that might be needed. It also the time to look at products like BlackDuck to run that against you code. There is always a line between risk and cost, imho moving the cost into the openbsd project for this doesn’t see fair.


Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Lari Rasku
In reply to this post by Theo de Raadt-2
On 01/19/18 01:12, Theo de Raadt wrote:
>> FWIW, the permission I seek is from my Legal department.
>
> That maybe your job but it isn't the project's job.
 
> Enough is enough.  That sentence above makes it clear who is getting
> paid for satisfying those requirements:  You.

Huh, where did he imply otherwise?  I don't think I saw Kent make a
single claim about what the project _ought_ to do, or have done.

Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Theo de Raadt-2
> On 01/19/18 01:12, Theo de Raadt wrote:
> >> FWIW, the permission I seek is from my Legal department.
> >
> > That maybe your job but it isn't the project's job.
>  
> > Enough is enough.  That sentence above makes it clear who is getting
> > paid for satisfying those requirements:  You.
>
> Huh, where did he imply otherwise?  I don't think I saw Kent make a
> single claim about what the project _ought_ to do, or have done.

Oh, cut your crap.

There is no question who would be capable of doing that work and
having it count.  His legal isn't going to sign off on someone like
Lari doing the work, so the implication is he wanted *US TO DO IT*

And we don't.  And he should know better

(1) due to the gigantic NO WARRANTY on 99% of the files.

(2) the realizion that we provide a vast body for code for free

His expectation is balony.  This isn't a corporation.

Your disagreement isn't worth a penny.  You have no stake in the work.
It is obvious you just want to be a yappy mouth.


Reply | Threaded
Open this post in threaded view
|

Re: identifying software and licenses used in base install

Gareth Nelson
In reply to this post by Kent Watsen
If your customer is not satisfied by simply pointing to the terms that
cover the whole of OpenBSD, and if they insist on some kind of audit of the
whole tree.....

Well then, offer it - but charge more.

Point out that what they're asking for would be unreasonably complex and
expensive no matter what third-party code is being used.

If they're worried about some kind of liability for using OpenBSD, offer to
idemnify them.

Personally, any contract for development work I ever sign has clauses
stating that all code is either 100% my own work (often with the copyright
assigned as work under hire) or licensed under a free software license
acceptable to the client (client specifies what licenses they're happy
with).

I generally find that technically knowledgeable  clients are happy for me
to use BSD and MIT type licenses without asking, and GPLv2 if there's no
decent alternative.

Clients who are not technically knowledgeable will usually be happy to
trust my judgement and settle on the same policy after a few minutes of
explanation.

If your client is being paranoid about licensing and copyright issues to
the point you're seriously considering what's basically an audit of the
OpenBSD tree, I'd question if they're going to be unreasonable on other
matters too.

It may be the case that your client's lawyer is being paranoid about
liability, so ask them to draft an idemnification clause in the contract
and if they're not happy with that, charge them for the large and expensive
task of auditing OpenBSD.

Ultimately, if they're unwilling to accept the reasonable path and don't
want to pay for the extra work, drop them. It's not worth it.


On Jan 17, 2018 11:30 PM, "Kent Watsen" <[hidden email]> wrote:


I'm throwing together a quick proof-of-concept thingy to give to a customer
and thought it might be  fun to use OpenBSD as the OS for the VM image.
Unfortunately, the not so fun part of it is that I'm required to get
permission to use/distribute this open source software, which entails
needing to identify all the internal software components and licenses
used.  I thought this was going to be easy, but it's proving to be anything
but...

My system only has the following installed: bsd, bsd.rd, bsd.mp, base62,
etc62, and man62.

Is there, by chance, such a breakdown available for these already? Since
OpenBSD is distributed in binary form, is there a copyright attributions
listing somewhere to satisfy the "must reproduce the above copyright"
clause, or do you just point to the also-distributed source for all that?

In lieu of that, it seems that a script could analyze the source code -
everything is contained in sys.tar.gz (the kernel) and src.tar.gz
(userland), right?

For the kernel, I'd like to think that it's all BSD, but `grep -R '"GPL"'
*` shows 39 files having the "GPL" string.  Looking at these, it appears
that they are all dual-licensed.  I didn't check if there are any other
licenses in the kernel, but is it safe to say that, if there are, they are
all dual-licensed and therefore the net-net is that the kernel is all BSD?

For the userland, first, is there an easy way to isolate the sub-parts of
src.tar.gz that contribute to base62, etc62, and man62?  Next, is there an
easy way to identify the unique packages/projects that are included?  -
this in hope that it might be easier to identify the licenses at the
project-level than the file-level.  Any thoughts for how to make this go
easy?

I'm beginning to think that this might be more trouble than it's worth, and
that I might be better off having the customer download/install OpenBSD
themselves, and then run something like an Ansible script to
install/configure the demo...

Thanks,
Kent