Hi Ian, Did you actually need to change coreboot or SeaBIOS? If so, how extensive were the changes? I am guessing that the boot firmware isn't considered to be part of the high-value IP of the product - that is presumably in your OS. If you can publish the coreboot and SeaBIOS code on your website (it could be a zip file or something) then things should be reasonably simple. Even better would be to add the mainboard support to upstream coreboot or fork upstream coreboot on github and then add your patches on top. Then downstream customers can then easily download the code and, if needed, modify and commit their patches to the same codebase as to be in compliance in the same manner as you. Your idea about using the "About" tab to inform the user about the licenses and where to find the code is good. It should cover your company even if the customer never reads it. You shouldn't need a clickthrough license or anything (gnu.org has a FAQ that covers that topic: https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html). Also, the "conspicuous" requirement should already be met with the license information that exists in the header of each source code file and/or a LICENSE or COPYING file. As Peter mentioned that is exactly how the requirement is met for large companies who work with open source software. Like you say, the goal here should be to make it so that downstream customers don't need to think about this stuff. The nice thing is that if you act consistently with the spirit of the open-source licenses then this should all be simple for them and for your company as well, and you get to spend more time engineering and collaborating and less time worrying. Just my $0.02. Please make sure to consult your company's legal department before acting on anything you read in this thread (or elsewhere) :-) On Fri, Dec 29, 2017 at 6:21 PM, Lewis, Ian (Microstar Laboratories) < ilewis@mstarlabs.com> wrote:

ron minnich wrote

...

how are you different in this case from Motorola, who had to put their linux source on a web site? companies resold motorola phones. Or the many switch vendors who sell network switches that run coreboot/linuxbios? or irobot, who use it still on the packbot? Or how are you different from just about every vendor that sells embedded ARM boards that run u-boot? We are, because of the nature of our customers, very different from all of your example use cases, except perhaps the people who sell embedded ARM boards.

Motorola phone: They sell their product to people (well, companies) who set out to make GPL licensed products, typically for a large market. The customer of Motorola makes no modifications to the Motorola phone, or at least no significant modifications. There is no difficulty for such a prospective reseller of such a product to comply with GPL. There are lots of sales to cover the initial costs. But, most importantly, the Motorola reseller is typically not making a new product. They are reselling the Motorola product, perhaps as a private label, to an end user who will receive Motorola's packaging and notifications (at first boot, perhaps - I do not actually know how).

As far as I can see (well, guess), network switch purchasers are almost always end users (corporate or personal). And, it is my guess - after spending the past week and a half trying to understand GPL's implications - that there are many, many small resellers of network switches in complete systems that are out of compliance with GPL because they do not even think about the issue. As a side note, our customers are a bit like this kind of reseller of a complete system that happens to contain a network switch, though the analogy is not great because the network switch is in some sense a complete system, while what we make is not. Still, if I sell a network installation to a small shop, and I fail to give the recipient of my system that includes that switch the GPL license and a place to get the source code, I am in violation of GPL. I do not want this to happen to my customers.

iRobot is making an end use product, not a product that someone else is going to take and build into something very different from the iRobot product. Again, a lot like Motorola and their phone. If NewEgg sells an iRobot product, they just pass through the iRobot package - with everything in it - so (I think, though I am not quite sure) they are in compliance as long as iRobot was. I suspect that NewEgg just assumes that iRobot got their licensing right. My reading of GPL is that NewEgg actually has their own obligation under GPL separate from iRobot's, but I would guess they do not worry about it much. They are not making anything. They are just reselling.

ARM boards that run u-boot: The target customer base is aiming to take advantage of the ARM board to make a product at a low cost (typically), and most of them are well aware of GPL and its implications. This is somewhat like us. Some of the uses have very small markets - as most of our customers do. But, we do not have a customer base that is aware of GPL and intend to use it from the beginning.

A typical customer of ours might sell 50 systems in a year and consider that a very good year. They sell each system for a lot of money (typically) and they are not spending a lot of time thinking about licensing. Most (a guess) probably do not even have an in-house counsel, let alone a license management department.

Asking them to take on new licensing obligations is an impediment to adoption of our product. How many of our customers already easily deal with GPL, I do not know, but I doubt it is a big fraction. You may not see that as a big issue, and if you were our customer it would not be a big issue for you. But, many of our customers hardly even formally license their own products to their customers; they go install them. My point is that our market is not an end use market where the licensing almost does not matter once the end user has the product in hand. And, it is not a big OEM market where the licensing is a triviality. And, our market is not Makers, say, who know - and want to be - buying GPL licensed products so that they can hack around in them.

Our market is for small OEMs - or OEMs who work inside big companies, but with small customer bases, which is even worse because here there is a legal department, but our customer has next to no chance of getting their attention - who make low volume specialized products - an industrial turbine monitoring system, say - that typically sell infrequently for relatively high prices and they want our part of the system to just work with as little thought as possible. Their focus is on their application area. If we can help them without getting in their way, they may use us. If we look like a nuisance, they will go elsewhere (maybe to an ARM board and building their own hardware for measurement - but then it is not my job to see that they properly handle GPL).

Unlike someone selling an ARM board, that part of our code happens to be GPL is of no interest to these customers at all (that is, it is not a reason to adopt us, as it might be if we made ARM boards). And, licensing is not something a typical customer of ours wants to think about (not that the ARM board customer wants to either). The ARM board manufacturer, based on a lot of experience on my part, only worries about their own compliance. They do not worry about their customer's compliance as we do.

If we can make it so that our customers do not have to think about it, then there is likely not much of a problem. But, so far, it is not at all clear to me that we can reach that level of transparency.

To try to clarify: I do not want to just comply with GPL. I easily see how to do that by now. I want to make it so that my customer does not have to think about it when they sell their system. If I try to make them think about it, I am about certain that will be a reason to not use our product. You might not believe that, but I do. The issue is one of marketing and selling, not of engineering or even law.

...

Also, why do you mention GPL V3? Coreboot is 2 or later. What about the many systems that run all kinds of GPL V2 embedded software? What's different between you and them? The module we are using uses both Coreboot (GPLv2) and SeaBIOS (GPLv3).

...

What I'm trying to say is that problem seems to have been solved. I get the feeling you are new to dealing with this question, and are trying to solve it yourself, without talking to people who have already solved it? I am not trying to solve the problem by myself. I did not just read the GPL license and try to determine its implications.

I have been, for the past week and a half, reading materials produced by people who do understand GPL and have successfully used it. I have looked for products like ours where such licensing has been employed where the customer base was developers who are not open source developers. I have yet to find a good match, by which I do not mean to imply there is not one around.

I am on this group exactly to learn what our obligations are and what we need to do to make a product that would work for our customer base using GPL licensing.

-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot