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.
