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" <k...@watsen.net> 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
