4

Disclaimer: I'm not entirely sure if this is the correct stack-exchange for this matter.

We're a small to medium company in the EU (about 70 employees). We develop and sell equipment and accompanying software for a very niche market segment. We also try to be very "agile" about it, as in "phone rings, customers ask for xyz, we make xyz happen asap", regardless of whether its a one off hack.

This high velocity neglects proper open source licensing handling. For context, out of these 70 employees, only two are software engineers. So this particular topic is not on the very top of the management's priority list.

Here is the rough situation:

Customers receive a device and some software sold together as one product. The software is running on-premise.

  • a web app running Django and the usual assortment of CSS/JS libraries

    The web app is supplied open-sourced, but that is not stated anywhere and is also not by design, rather out of convenience. The only open source related thing it does, it has an about page which states and links to the core components being used, i.e. Django, Python, Lodash and the likes. It is certainly missing to disclose some of these, especially if you'd consider transitive dependencies.

  • a WPF (.net/c#) desktop app

    This one is closed source. It states the full license text and links to the homepage of two major components within the app itself in an about page/section. But again, probably not all used (nuget) packages. For example, it does not state the usage of log4net.

  • within the device, touch panels running Raspbian and a QML (Qt5) interface

    This is, I guess, the tricky part. It is supplied as open source, but again, not stated anywhere. But you could just take a screwdriver and grab the SD-card from one of the raspberries inside. The whole usage of Raspbian is not stated anywhere, neither is the usage of Qt5 (LGPL in this case) and various python libraries (most notably PySide2 and Raspbian itself which is afaik GPL)

What I would like to do now (rather late than never) is basically do our due diligence in terms of fulfilling the licence requirements. I recently had a lengthy talk with a software compliance expert which essentially boiled down to "if someone really wants to mess with you", there is the potential danger of an prohibition of sale via temporary injunction. Which could be devastating to a smaller company.

While I am aware of the basics of how I would comply with i.e. a MIT or LGPL licensed part, what's a good approach for this particular scenario, where these parts, all the software and the device itself form one product. I am assuming this is not an uncommon scenario, so there are probably some established ways or best practices' around?

Possible solutions I could think of:

  • state all the parts and licenses somewhere centrally, i.e. on our homepage or a dedicated product page?
  • similar idea, state all the licenses in a (pdf) manual?
  • bite the bullet and list all parts and licenses where they are used? Especially on the touch screen we (as in our sales and markets folks) would very much like to avoid having some 'About' button cluttering the constrained interface space

So tl;dr, the question is how to comply with all the (licenses of) used 3rd party open source components in a manageable way, i.e. not putting hundreds of man-hours on it nor involving an expensive external advisor. That is, not how do I comply with license xyz (i can look that up, although tedious), but where would I ideally supply all that information, links, potential source code.

To make matters worse, searching this stack-exchange also indicates I would have to include every transitive dependency as well. Although it's good enough, if I understood correctly, if one of the first-order dependencies that I link to in turn links to its dependencies.

7
  • Do you have all the source code on the SD card for all the executables that run on the RasPi? There are tools that can scan that source and deliver a complete report. Still this will not be sufficient, because you will have difficulties to determine which of the libraries are linked together (in terms of copyleft implications) and which of the parts are 'mere aggregation'. For your own code you can probably create a proper licenses.txt including all transitive dependencies, but for 3rd party components you need to ask your supplier to provide that as an SBOM. Commented Jul 21, 2023 at 16:52
  • @Martin_in_AUT I don't know to be honest, it's the default Raspbian distribution slightly stripped down, so the full source should be somewhere. Unless i forgot to remove some closed source junk that is included by default. Our one part is just Python. But how would a license.txt on the SD Card be helpful if it is hidden behind screws and glue? That was basically my initial question, if i could provide that someplace else, i.e. in a manual bit or something else.
    – flipflop
    Commented Jul 22, 2023 at 16:45
  • 2
    You could easily print a URL in the manual (or put it on the serial number sticker on the device), where the URL points to your home page and you provide the information in a similar way like this. If you have enough space you can print the SBOM and the language of the licenses in your manual, but this is not so common any more (save the trees). Commented Jul 22, 2023 at 17:13
  • @Martin_in_AUT So in short, link at some prominent place (in any of the three parts of the product) to some easily accessible SBOM/List of things with licenses and that should cover most/all of our open source related obligations? Even if IANAL might apply here, that is probably still way better than what we have right now.
    – flipflop
    Commented Jul 24, 2023 at 8:48
  • So, something like this docs.oracle.com/cd/E79446_01/html/E62005/licenses.html would do the job, spanning all components?
    – flipflop
    Commented Jul 25, 2023 at 7:47

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.