coreboot December 2017

coreboot@coreboot.org

68 participants
177 discussions

Re: [coreboot] Coreboot Purism BIOS is free? open?
by Nico Huber 24 Dec '17

24 Dec '17

On 23.12.2017 22:08, Ivan Ivanov wrote: > Sadly the ARM processor also have the ME-like backdoor (called "TrustZone). Some have. Some not. Some have it and it's owner-controllable. It's not about the ISA and some optional architectural feature, it's about the chip you buy. > And even MIPS is going this road soon (check out the "MIPS OmniShield" news). > > Could it be the requirement of US Government - for all the consumer > CPU to have backdoors ? > My last hopes are on POWER 9 and RISC V now ; meanwhile sticking to > the AMD pre-PSP tech Forget it. RISC-V already has SMM like tech in the architecture. But that doesn't matter as long as you can buy chip's that are owner con- trollable. Such features make it harder to keep everything secure but they don't force the silicon vendor to lock you out (as long as you don't ask to be able to watch Netflix in high resolution or something like that). Nico

6 10

Re: [coreboot] Coreboot Purism BIOS is free? open?
by Todd Weaver 24 Dec '17

24 Dec '17

On Fri, 2017-12-22 at 22:06 -0500, Youness Alaoui wrote: > On Tue, Dec 19, 2017 at 3:54 PM, Timothy Pearson > <tpearson(a)raptorengineering.com> wrote: > > > > Thank you for the detailed explanation. I guess this is an area in > > which experience matters; it is absolutely unacceptable (and not > > unexpected) that Intel misled your CEO, but this is sadly not an > > uncommon tactic in the industry. Intel has not misled anything. We knew the ME/FSP/vBIOS were the issues (from my first questions to this coreboot mailing list and the replies from the community), but there was no perfect alternative, so we chose Intel to get hardware (more) people wanted and work and invest toward liberating it. I can say, without much doubt, that if we chose any other platform we would have struggled in volume and not advanced any faster or farther than we have already. To liberate hardware, there are three larger paths: 1) use existing liberated hardware (gets older and older) 2) design using freed chips (low performance) 3) use products people want that are not yet fully liberated, invest in liberating. For laptops: #1 is already being done by many #2 is also being done #3 is the path we are doing for laptops. For a phone: #1 doesn't exist #2 is the path we are doing #3 others are trying We can then cross-polinate our investment efforts into the phone motherboard into a laptop with #2. I have a published business vision page here: https://puri.sm/about/business-model-and-vision/ > > One item I would like to call out though is the following: > > > > > if old or non-x86 architectures were so appealing, you would have > > > seen that become the norm rather than the exception) This statement is accurate. The volume of sales would be significantly less if we tried non-x86. And then our growth would be smaller; and our investment toward freeing future hardware would not happen; and then there would be no advancement toward convenient ethical products, which is our goal. > > Trying to switch architectures may be hard, but it is only > > going to get harder day after day as people continue to cling to > > false hope that the x86 platform may ever be brought under their > > control. It's pretty simple. With leverage we can change businesses. This is not a short-term game, but a long-term... grow-gain leverage-influence change-repeat. And this is what we are doing at Purism, and will continue. We are not griping about the state of affairs, we have a plan to change the future, and are executing on it. > > I wonder, though, if given this information if possibly Raptor and > > Purism might have some common business ground here? Purism has > > experience with laptop mechanicals and related concerns, and we > > have experience with truly blob-free, powerful hardware -- > > combining those two could yield an interesting machine... Ping me off list to discuss. We are always looking for aligned- partnerships or collaboration. > > > The main question I have, and this is an honest question, is why > > > Purism chose to use the x86 platform as a base for libre > > > hardware, when it has been known for some time that said hardware > > > could never be made fully blob-free? See above, I think I laid out and answered this clearly. It's not just technical, there is a strong business model behind our approach. > > > There were (and are) other good ways to make a system that could > > > be fully blob-free, for instance ARM, and given the engineering > > > effort that is said to have been put into the Purism machines I > > > wonder what we could have had if said effort had been put into an > > > aarch64 system instead of an x86 system? Sure, that would sell a small fraction of the quantity, and fail to impact the future of computing in a way we model out. > > > > The second reason is that Todd (CEO) was in talks with Intel > > > > and was unfortunately lead to believe that they were open to > > > > release an ME-less design CPU for his needs, it ended up not > > > > being the case. Intel did not mislead, we told them, and continue to, that we _want_ an ME-less design (which is their term for what we asked for). And as we grow our leverage will grow, and our influence will grow. This is a long-term strategy and is playing out as planned. They will not adjust based on small quantities, but quantity = leverage, and our influence changes as volumes grow. (e.g. $ = influence) > > > > Todd thought that it would be possible to get a binary blob > > > > free coreboot/CPU with a few months of work. Not binary-blob free. It was always known this will be a large investment of both time and money. But coreboot ported to hardware within a few months is an accurate assessment of what I heard, and that turned out to be much longer, not in technical nature, but finding the right people/developers to do it properly. Now all our (x86) products are running coreboot, and will continue to. > > > > A good summary is that we want to "bring > > > > blob-free to the hardware that people want", rather than "bring > > > > blob-free hardware to the people who want it". This is great; and I may quote you on that :) Todd.

5 5

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Sam Kuper 24 Dec '17

24 Dec '17

Hi Ian, On 24/12/2017, Lewis, Ian (Microstar Laboratories) <ilewis(a)mstarlabs.com> wrote: > I have read this page > https://www.softwarefreedom.org/resources/2008/compliance-guide.html > several times, a number of other sites, as well as reading the GPLv2 > itself. I want to echo Peter Stuge on these points... On 24/12/2017, Peter Stuge <peter(a)stuge.se> wrote: > Thank you for reaching out to the community with your very valid concerns! > > You are asking exactly the right questions. > > In the end, the community can't provide you with legal advice ... and to add a caveat to these points from Peter: >> If this is the wrong forum for this kind of question, I apologies. And, >> I would appreciate if someone could point me to an appropriate forum. > > I think SFLC is a good point of contact, and FSF Europe also have a > strong focus on applied use of free software code. > > http://fsfe.org/activities/ftf/documentation.en.html > http://fsfe.org/activities/ftf/services.html > http://gpl-violations.org/faq/vendor-faq/ > > And if you are interested to connect your legal counsel with experts on > the field of free software licensing, then this may be relevant: > > http://fsfe.org/activities/ftf/ln.en.html The caveat is that this is all good advice *except* that instead of contacting the SFLC (i.e. the Software Freedom Law Centre, run by Eben Moglen et al), it might be better for you to contact the SFC (the Software Freedom Conservancy, run by Bradley Kuhn, Karen Sandler, et al). In my opinion, the SFLC was still giving decent advice in 2008, which is when it published the post you linked to. But it has, sadly, behaved rather confusingly of late. By contrast, the SFC has always, as far as I know, taken a reasonable and consistent stance in its work. For more about the SFLC's recent, unfortunate behaviour, see: - https://mjg59.dreamwidth.org/49370.html - http://www.rants.org/2017/11/conservancy_sflc_dispute/ - https://lwn.net/Articles/738046/ Wishing you a successful and GPL-compliant product! Sam

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Peter Stuge 24 Dec '17

24 Dec '17

Hi Ian, Thank you for reaching out to the community with your very valid concerns! You are asking exactly the right questions. In the end, the community can't provide you with legal advice, but what we can do is help with pointers to successful uses of GPL code, and we can of course discuss personal understanding of the license text. I'm a developer, not legal counsel. :) Lewis, Ian (Microstar Laboratories) wrote: > We have never used GPL licensed code in our products before. And, I > am having a hard time seeing how we can do so and comply with GPLv2, > or GPLv3 for that matter. In the end it may be that you actually can't, if you have non-technical requirements which are incompatible with the GPL. But several companies have done it, so it is in no way impossible per se! > I have read this page > https://www.softwarefreedom.org/resources/2008/compliance-guide.html > several times, a number of other sites, as well as reading the GPLv2 > itself. Thanks for the link, I hadn't seen that, and I think it's a good commentary to read along the license text itself. > I do not want to impose a GPLv2 requirement on our customers if they use > our product. I want GPLv2 compliance to be fully our responsibility. The license applies to the software wherever the software ends up, whoever the distributors and recipients are. This is very different from a proprietary license, where conditions usually end with the first recipient, and usually amount to "do not ever distribute" or "you paid us once, so distribute as much as you like", or anything in between. Think about what the GPL strives to achieve. The conditions in the license want to ensure that every single recipient of the software has the same possibilities that you, the initial recipient, have. This in turn means that GPL compliance is per definition required from every single distributor, not only from you. > If we do have to impose a GPLv2 requirement on our customers to use a > Coreboot/SeaBIOS initialized platform, we probably cannot use such a > platform in any product, which would be quite unfortunate from my point > of view. That's your decision to make. It is certainly possible, many companies do so very successfully already, and I would argue that some of their success can actually be attributed to the very fact that they have decided to reuse (and perhaps contribute to!) existing GPL projects, at the very small compliance cost. > A large fraction of our customers are OEMs or VARs and they make > products of their own that use our products as a part. Unless they pull > the system apart, the end-use customer often does not even know one of > our products is part of the system they buy, though our licensing to our > customer (OEM) does require that the reseller maintain our copyright > notice in their system documentation or software copyright notice or > they do not have a right to distribute our software. The copyright for > the hardware is printed on the hardware itself, as is customary. The OEM > who uses our product configures our product before it ships to the > end-use customer, and they often build additional hardware of their own > as part of the system. The OEM (our customer) almost always includes a > PC and custom software of their own as part of the end-use system. The > end use customer may later re-sell their system to yet another end-use > customer or even pull our product out of the system and resell that > separately (on eBay, say). Cool. None of that is per se incompatible with the GPL, IMHO. > If I have understood correctly, all of these owners of our product must > have access to exactly the Coreboot/SeaBIOS source used to produce the > binary in the copy of our product they own. Yes, that is my understanding too. > Based on my understanding so far (highly limited), the only way that > looks like it might be possible to avoid propagating a GPLv2 requirement > to our customers - and thus making the compliance fully our responsibility No, absolving someone else of GPL requirements is simply not possible, unless you are the sole copyright holder and you use a dual-licensing scheme. (Enabling that is one purpose of copyright assignment.) Every single distributor of GPL code must comply with the license, as is the case with every other license. The conditions of the GPL mean that distributors do have to spend some effort on compliance. Instead, quite some NRE effort can be saved! In the case of coreboot, I think the monetary advantage to GPL is super obvious, but of course that doesn't help if you have strict requirements to not require your customers to understand and implement GPL compliance. So far that may sound quite scary, but: GPLv2 compliance is not really difficult, just different from engineering, but maybe more importantly it is very different from the adversarial compliance that lawyers have trained for decades to deal with. It's common for legal departments to need some time to climb the learning curve for free and open source. > - would be if we distribute a copy of the exact source > code used to build the module's Coreboot/SeaBIOS configuration as an > integral part of our product. This is one way to comply; the "Source Alongside Binary" option. > If there is any way to do it, we would actually rather not develop > the expertise to set up such a build, but I see no way around being > able to build our own version of the system image if we are to > comply with GPLv2. GPL requirements aside, being able to build yourself what you deliver to customers is never a bad thing. It takes some R&D yes, but nothing comparable to full R&D for an inhouse replacement, and in my experience quite many open source and free software projects are far simpler to use than proprietary products. > My understanding is that we have to know exactly how to build the > exact binary we distribute I don't think the GPL requires this explicitly, but I think you should do this regardless, if you distribute anything at all. Let's look at my layman understanding of the GPLv2 sections: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. This section gives you the freedom to distribute the source code, and sets out the conditions for compliance should you want or need to do so. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program ... This section gives you the freedom to modify the code. It doesn't seem that you want to do so. Your case is a typical one where you would benefit the most from getting your shipped configuration included into the upstream repository, and as long as you take ownership of that configuration (in the end probably just a few files) then that is also very much welcomed and desired by the project! 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: So this is an important section, becase you want to distribute object code. Let's look at a) and b). (c) we'll ignore, because it's only for noncommercial distribution. a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, Something like the memory card you described could be used to achieve compliance with the above section. It is important to note, that every downstream distributor must also comply with the license. But you can make it easy for them. If all they need to do is ship that memory card along to their customers, then that's not a high cost for compliance, and on the flip side they of course save cost through your competitive pricing that was enabled by you reusing coreboot and SeaBIOS. b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, Because paper costs less than storage medium this mini-book or booklet method is used by many consumer electronics vendors. I've personally received such a "compliance booklet" from Philips with a TV set, from Samsung with a TV set and with a phone, and from several wireless router vendors. Personally I am less fond of this method. Yes, the cost at time of shipment is less per unit, but on the other hand you must set up a process to fulfill the offer, and you must keep it running for a minimum of three years after your distribute the very last unit! This is fairly risky; because this process will not be exercised very frequently it is also much more prone to fail, and fail silently, and then you are suddenly no longer compliant without being aware, so if a request then comes in but the offer is not fulfilled then the (usually simple) operational issue immediately becomes a legal liability. Most importantly, if the process breaks you are unable to satisfy your customer's request for the source code. > and we have to be able to tell a technically competent recipient of > the binary how to do that build themselves, as well as how to > incorporate the new build into our product. Neither of those are in GPLv2, but indeed in GPLv3. Certainly the GPLv3 has more requirements, and that may be a reason to use coreboot, but not SeaBIOS. Other bootloaders exist, such as FILO. Since you are booting your own OS anyway, that may even be preferable over hanging on to obsolete BIOS services and data structures. > We do not have to support any changes whatsoever, but we do have to > support the initial process of re-configuring our product with a > newly built binary that came from the sources we supply as long as > there are no changes made to those sources. For GPLv3, yes. > One idea I had is to put the source on a microSD drive .. > So, an owner of our product (and so a recipient of > the binary distribution of Coreboot/SeaBIOS) would have the code on the > microSD, but we have no easy way to provide them access to its content. > But, they could remove the microSD from the product and read it from any > machine that can read a microSD. That means almost any machine. It could be argued that a memory card qualifies as "a medium customarily used for software interchange". > That seems to me like it might cover the source distribution requirement > of GPLv2, though I am not quite certain it is good enough. I think it is one feasible way for *you* to comply. But as part of your product, maybe in some documentation or training, you should probably also make sure that your customers understand why they must *also* ensure that *they* comply, and that part of the value of your particular product is that you have already prepared this medium to assist them with that. For GPLv2 I think the rest is a matter of documentation that they supply with their products. (Like a booklet.) > However, so far, it looks impossible to me to meet the GPLv2 > notification requirements. Sorry, what are you refering to here? Neither "notification", "Notification", "notify" nor "Notify" appears in my copy of the GPLv2 license text. > And, I do not understand at all how the likes of network routers > that use GPL licensed code can possibly comply either. Many ship a compliance booklet which refers to a distribution service where recipients of a binary copy can obtain the source code in compliance with the license requirements. Once set up, and firmly established within a company, that is probably by far the most cost-effective. It's a longer commitment than shipping a physical storage medium - that's a one-time thing for you. GPLv3 is explicit about who can operate network servers, but: "Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements." > I can imagine fitting a URL, such as www.mstarlabs.com/GPL (not a real > URL) on to the product to point any owner of the product to an > explanation of where to find the license text and source for > Coreboot/SeaBIOS. The microSD would have everything needed to > comply on it, but I do not think that comes close to meeting the > notice requirements of GPL. Maybe you refer to the 3b) "written offer" option for Section 3 of GPLv2? Whether a mere URL constitues "a written offer ..." I don't know. Personally I find that a very weak offer. A booklet or even a single sheet of peper is significantly more obvious. Note that Section 3 requires only "one of the following" options, not all. > Do you have any written guidelines that explain how to properly - > and legally - distribute a commercial hardware product that incorporates > Coreboot/SeaBIOS? In particular, how can we meet the notification > requirements when the user never even physically handles the product, > sees any output from the device, or installs any software on it? I am > having a hard time figuring out how to do this, if it is possible at > all. I personally find GPLv2 Section 3a) and 3b) to be pretty clear and comprehensible. 3a) says accompanying object code with complete corresponding machine-readable source code on a medium. 3b) says accompanying object code with a written offer. Note that however source code is distributed, Sections 1 and 2 must also be complied with. > If this is the wrong forum for this kind of question, I apologies. And, > I would appreciate if someone could point me to an appropriate forum. I think SFLC is a good point of contact, and FSF Europe also have a strong focus on applied use of free software code. http://fsfe.org/activities/ftf/documentation.en.html http://fsfe.org/activities/ftf/services.html http://gpl-violations.org/faq/vendor-faq/ And if you are interested to connect your legal counsel with experts on the field of free software licensing, then this may be relevant: http://fsfe.org/activities/ftf/ln.en.html Hope this helps, and happy holidays to everyone! :) //Peter

1 0

Re: [coreboot] Depthcharge License
by Ivan Ivanov 24 Dec '17

24 Dec '17

This commit got merged and the Depthcharge now should have the requested license files at its root directory. Dear friend, please let us learn about your device once it is released, maybe some of the coreboot developers would want to get your device - to use, and possibly help Best regards, Ivan Ivanov 2017-12-21 21:34 GMT+03:00 Aaron Durbin via coreboot <coreboot(a)coreboot.org>: > https://chromium-review.googlesource.com/c/chromiumos/platform/depthcharge/… > > On Thu, Dec 21, 2017 at 11:14 AM, <tturne(a)codeaurora.org> wrote: >> >> On 2017-12-19 09:53, David Hendricks wrote: >>> >>> To be fair, it appears that many source files refer to a non-existent >>> LICENSE file. Someone on the CrOS team should probably just add the >>> LICENSE file for depthcharge and/or contact mal@ to see how the >>> license info is being collected these days (e.g. for >>> chrome://os-credits [3]). >>> >> >> Thanks for the input on the DC licensing, and because lawyers are involved >> I need to ask a direct question. >> Can a Depthcharge maintainer (anybody who has +2 gerrit authority would >> suffice) state on this thread >> that the Depthcharge project license is GPLv2 (or later)? >> >> I know this feels redundant and that the question has been asked and >> answered, I'm just trying >> to satisfy our internal legal group. >> >> Per David's point above, this direct question would not be required to >> satisfy the lawyers >> if a top-level COPYING or LICENSE file is added to Depthcharge. Which I >> will be happy to >> add once I'm able to start contributing to the project. >> Cheers, >> T.mike >> >>> On Tue, Dec 19, 2017 at 9:19 AM, ron minnich <rminnich(a)gmail.com> >>> wrote: >>> >>>> Is there even a question? Looks like aaron just answered the >>>> original question, which boils down to Read The Source? >>>> >>>> On Tue, Dec 19, 2017 at 7:58 AM Aaron Durbin via coreboot >>>> <coreboot(a)coreboot.org> wrote: >>>> >>>> On Tue, Dec 19, 2017 at 8:03 AM, <tturne(a)codeaurora.org> wrote: >>>> On 2017-12-15 13:39, tturne(a)codeaurora.org wrote: >>>> Preparing to mirror the coreboot.org [1] requires us to vet the >>>> various >>>> licenses, etc. >>>> >>>> There doesn't appear to be a LICENSE or COPYING file in the >>>> Depthcharge tree. >>>> >>>> My understanding is that Depthcharge is licensed GPLv2 (or later). >>>> >>>> How would I confirm this with an online source? >>>> >>>> Cheers, >>>> T.mike >>>> >>>> Should this query be posted on Chromium list rather than Coreboot >>>> list? >>> >>> >>> Probably. The files in the depthcharge repository have licenses at >>> the top of each file. They are GPLv2. >>> >>>> Cheers, >>>> T.mike >>>> >>>> -- >>>> coreboot mailing list: coreboot(a)coreboot.org >>>> https://mail.coreboot.org/mailman/listinfo/coreboot [2] >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://mail.coreboot.org/mailman/listinfo/coreboot [2] >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://mail.coreboot.org/mailman/listinfo/coreboot [2] >>> >>> >>> >>> Links: >>> ------ >>> [1] http://coreboot.org >>> [2] https://mail.coreboot.org/mailman/listinfo/coreboot >>> [3] https://www.chromium.org/chromium-os/licenses > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Ivan Ivanov 24 Dec '17

24 Dec '17

Good day, Ian! Perhaps it is a good idea to look what another responsible company did at the same situation The TP-Link company is using the GPLv2-licensed source code for the firmware of their routers, and they include a small paper printed mini-book ---> which contains two major things: 1) the complete text of GNU GPLv2 license 2) an explanation that the complete firmware source code could be obtained from TP-Link website: http://www.tp-link.com/us/support/gpl-code-center But it seems that in your situation you could not include such a mini-book, because it could be lost before it reaches the eventual user of your device and also - these are additional expenses to print such mini-books However there are two excellent alternative solutions : 1ST SOLUTION : 1) Modify the SeaBIOS source code, so that - while booting - it will print a two-line message at the bottom of screen, something like "The source code of this BIOS is GNU GPLv2 licensed, for more info - press "ESC" and then a letter corresponding to "FreeDOS with GNU GPLv2 texts" boot entry 2) Download a FreeDOS floppy, remove an installer from it (not needed!) and add two text files to this image: *) your "mini-book" in txt format with GNU GPLv2 license text and a link to your sources *) similar "mini-book" but for FreeDOS - with a license for FreeDOS and a link to its sources 3) Add this virtual floppy to the completed coreboot+SeaBIOS build while using the LZMA compression using a simple command like this: ./coreboot/build/cbfstool ./coreboot/build/coreboot.rom add -f ./FreeDOS.img -n floppyimg/FreeDOS_with_GNU_GPLv2_texts.lzma -t raw -c lzma and then it will be shown as "FreeDOS with GNU GPLv2 texts" boot entry at SeaBIOS boot menu. Good thing is that even if the user makes some edits to license using a text editor - these changes will be temporary and will disappear after a user reboots your device When LZMA compression is used, FreeDOS floppy takes about 714 KB - twice less than its original 1440 KB size However, if thats still too large for you, instead of FreeDOS you could use any other floppy based OS which meets these two requirements: *) Contains a text editor / text displayer as the means to show the license texts to the user. *) That OS is licensed by GNU GPLv2 or less restrictive license So, if you don't like FreeDOS you could use something like MikeOS: *) this floppy MikeOS is licensed by BSD-like license *) it compresses significantly better than FreeDOS: to just 54 KB, and even better if you remove some games/demos from it 2ND SOLUTION: Similar to 1ST, but - instead of using a floppy based OS - you could directly modify the SeaBIOS source code to include a fake boot entry - which, when selected, instead of booting any device will start showing your mini-book page by page and its possible to scroll pages or move back/forward between them I wrote a patch to SeaBIOS which sadly didn't got accepted, you could obtain it here: https://mail.coreboot.org/pipermail/seabios/2017-June/011416.html [SeaBIOS] [PATCH] boot: boot menu up to 35 devices with letters and possible pages Without this patch the SeaBIOS supports just 9 or 10 boot entries, but with this patch - 35 boot entries, and its possible to switch the pages between the first 18 entries and last 17 entries You can borrow this paging code and modify it to display the pages of your mini-book with license texts and explanation that sources are easily available from your website Actually it would be much better if you will be able to contribute the sources for your device to the official coreboot repositories: 1) it will be more convenient both for you and your users to have the latest coreboot updates 2) other coreboot users will clearly see that your device is supported and would want to get it Please ask if any questions, we could come up with a lot of good ideas of how it could be done. Also it will be great to learn about your product once its released, maybe some of coreboot developers would want to get your device - and this could probably give some additional support from community Best regards, Ivan Ivanov<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /> <table style="border-top: 1px solid #D3D4DE;"> <tr> <td style="width: 55px; padding-top: 18px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-anima…" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td> <td style="width: 470px; padding-top: 17px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Без вирусов. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…" target="_blank" style="color: #4453ea;">www.avast.ru</a> </td> </tr> </table> <a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div> 2017-12-24 9:46 GMT+03:00 Lewis, Ian (Microstar Laboratories) <ilewis(a)mstarlabs.com>: > I am looking at using a processor module that initializes using Coreboot and > SeaBIOS to make an embedded hardware product. Assuming we move forward, > Coreboot/SeaBIOS will load our (proprietary) OS. Our OS contains no GPL > licensed code. > > > > We have never used GPL licensed code in our products before. And, I am > having a hard time seeing how we can do so and comply with GPLv2, or GPLv3 > for that matter. > > > > I have read this page > https://www.softwarefreedom.org/resources/2008/compliance-guide.html several > times, a number of other sites, as well as reading the GPLv2 itself. > > > > I do not want to impose a GPLv2 requirement on our customers if they use our > product. I want GPLv2 compliance to be fully our responsibility. If we do > have to impose a GPLv2 requirement on our customers to use a > Coreboot/SeaBIOS initialized platform, we probably cannot use such a > platform in any product, which would be quite unfortunate from my point of > view. > > > > A large fraction of our customers are OEMs or VARs and they make products of > their own that use our products as a part. Unless they pull the system > apart, the end-use customer often does not even know one of our products is > part of the system they buy, though our licensing to our customer (OEM) does > require that the reseller maintain our copyright notice in their system > documentation or software copyright notice or they do not have a right to > distribute our software. The copyright for the hardware is printed on the > hardware itself, as is customary. The OEM who uses our product configures > our product before it ships to the end-use customer, and they often build > additional hardware of their own as part of the system. The OEM (our > customer) almost always includes a PC and custom software of their own as > part of the end-use system. The end use customer may later re-sell their > system to yet another end-use customer or even pull our product out of the > system and resell that separately (on eBay, say). > > > > If I have understood correctly, all of these owners of our product must have > access to exactly the Coreboot/SeaBIOS source used to produce the binary in > the copy of our product they own. > > > > Based on my understanding so far (highly limited), the only way that looks > like it might be possible to avoid propagating a GPLv2 requirement to our > customers – and thus making the compliance fully our responsibility - would > be if we distribute a copy of the exact source code used to build the > module’s Coreboot/SeaBIOS configuration as an integral part of our product. > If there is any way to do it, we would actually rather not develop the > expertise to set up such a build, but I see no way around being able to > build our own version of the system image if we are to comply with GPLv2. My > understanding is that we have to know exactly how to build the exact binary > we distribute and we have to be able to tell a technically competent > recipient of the binary how to do that build themselves, as well as how to > incorporate the new build into our product. We do not have to support any > changes whatsoever, but we do have to support the initial process of > re-configuring our product with a newly built binary that came from the > sources we supply as long as there are no changes made to those sources. > > > > One idea I had is to put the source on a microSD drive and semi-permanently > attach that drive to the product. That way the Coreboot/SeaBIOS code would > go along for the ride any time our product changed hands (as long as no one > lost it). The microSD would not be part of our product. So, an owner of our > product (and so a recipient of the binary distribution of Coreboot/SeaBIOS) > would have the code on the microSD, but we have no easy way to provide them > access to its content. But, they could remove the microSD from the product > and read it from any machine that can read a microSD. That means almost any > machine. > > > > That seems to me like it might cover the source distribution requirement of > GPLv2, though I am not quite certain it is good enough. > > > > However, so far, it looks impossible to me to meet the GPLv2 notification > requirements. And, I do not understand at all how the likes of network > routers that use GPL licensed code can possibly comply either. > > > > I can imagine fitting a URL, such as www.mstarlabs.com/GPL (not a real URL) > on to the product to point any owner of the product to an explanation of > where to find the license text and source for Coreboot/SeaBIOS. The microSD > would have everything needed to comply on it, but I do not think that comes > close to meeting the notice requirements of GPL. > > > > Under Windows, where we sell the vast majority of our systems, we do have a > control panel application that every user could potentially get to. And, it > could include a screen that explains the owner’s GPL rights and where to > find the source microSD on the product. But, we have no means to force the > user to look at the control panel application, and most users would never > have any reason to do so. > > > > Do you have any written guidelines that explain how to properly – and > legally - distribute a commercial hardware product that incorporates > Coreboot/SeaBIOS? In particular, how can we meet the notification > requirements when the user never even physically handles the product, sees > any output from the device, or installs any software on it? I am having a > hard time figuring out how to do this, if it is possible at all. > > > > If this is the wrong forum for this kind of question, I apologies. And, I > would appreciate if someone could point me to an appropriate forum. > > > > Ian Lewis > > www.mstarlabs.com > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Intel ME vs. fascist regimes
by Enrico Weigelt, metux IT consult 24 Dec '17

24 Dec '17

Hi folks, JFYI: @Germany, the secretery of state de Maizière of dictator Merkel openly plans to obligate industrie to wiretap all computer products, personal computers, smartphones, cards, digital kitchen tools, etc, etc. A german article on the topic: http://www.watergate.tv/2017/12/05/merkel-regierung-neuer-frontalangriff-au… Considering Intel ME - does it ring any bells ? :o --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info(a)metux.net -- +49-151-27565287

2 1

How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Lewis, Ian (Microstar Laboratories) 24 Dec '17

24 Dec '17

I am looking at using a processor module that initializes using Coreboot and SeaBIOS to make an embedded hardware product. Assuming we move forward, Coreboot/SeaBIOS will load our (proprietary) OS. Our OS contains no GPL licensed code. We have never used GPL licensed code in our products before. And, I am having a hard time seeing how we can do so and comply with GPLv2, or GPLv3 for that matter. I have read this page https://www.softwarefreedom.org/resources/2008/compliance-guide.html several times, a number of other sites, as well as reading the GPLv2 itself. I do not want to impose a GPLv2 requirement on our customers if they use our product. I want GPLv2 compliance to be fully our responsibility. If we do have to impose a GPLv2 requirement on our customers to use a Coreboot/SeaBIOS initialized platform, we probably cannot use such a platform in any product, which would be quite unfortunate from my point of view. A large fraction of our customers are OEMs or VARs and they make products of their own that use our products as a part. Unless they pull the system apart, the end-use customer often does not even know one of our products is part of the system they buy, though our licensing to our customer (OEM) does require that the reseller maintain our copyright notice in their system documentation or software copyright notice or they do not have a right to distribute our software. The copyright for the hardware is printed on the hardware itself, as is customary. The OEM who uses our product configures our product before it ships to the end-use customer, and they often build additional hardware of their own as part of the system. The OEM (our customer) almost always includes a PC and custom software of their own as part of the end-use system. The end use customer may later re-sell their system to yet another end-use customer or even pull our product out of the system and resell that separately (on eBay, say). If I have understood correctly, all of these owners of our product must have access to exactly the Coreboot/SeaBIOS source used to produce the binary in the copy of our product they own. Based on my understanding so far (highly limited), the only way that looks like it might be possible to avoid propagating a GPLv2 requirement to our customers - and thus making the compliance fully our responsibility - would be if we distribute a copy of the exact source code used to build the module's Coreboot/SeaBIOS configuration as an integral part of our product. If there is any way to do it, we would actually rather not develop the expertise to set up such a build, but I see no way around being able to build our own version of the system image if we are to comply with GPLv2. My understanding is that we have to know exactly how to build the exact binary we distribute and we have to be able to tell a technically competent recipient of the binary how to do that build themselves, as well as how to incorporate the new build into our product. We do not have to support any changes whatsoever, but we do have to support the initial process of re-configuring our product with a newly built binary that came from the sources we supply as long as there are no changes made to those sources. One idea I had is to put the source on a microSD drive and semi-permanently attach that drive to the product. That way the Coreboot/SeaBIOS code would go along for the ride any time our product changed hands (as long as no one lost it). The microSD would not be part of our product. So, an owner of our product (and so a recipient of the binary distribution of Coreboot/SeaBIOS) would have the code on the microSD, but we have no easy way to provide them access to its content. But, they could remove the microSD from the product and read it from any machine that can read a microSD. That means almost any machine. That seems to me like it might cover the source distribution requirement of GPLv2, though I am not quite certain it is good enough. However, so far, it looks impossible to me to meet the GPLv2 notification requirements. And, I do not understand at all how the likes of network routers that use GPL licensed code can possibly comply either. I can imagine fitting a URL, such as www.mstarlabs.com/GPL (not a real URL) on to the product to point any owner of the product to an explanation of where to find the license text and source for Coreboot/SeaBIOS. The microSD would have everything needed to comply on it, but I do not think that comes close to meeting the notice requirements of GPL. Under Windows, where we sell the vast majority of our systems, we do have a control panel application that every user could potentially get to. And, it could include a screen that explains the owner's GPL rights and where to find the source microSD on the product. But, we have no means to force the user to look at the control panel application, and most users would never have any reason to do so. Do you have any written guidelines that explain how to properly - and legally - distribute a commercial hardware product that incorporates Coreboot/SeaBIOS? In particular, how can we meet the notification requirements when the user never even physically handles the product, sees any output from the device, or installs any software on it? I am having a hard time figuring out how to do this, if it is possible at all. If this is the wrong forum for this kind of question, I apologies. And, I would appreciate if someone could point me to an appropriate forum. Ian Lewis www.mstarlabs.com

1 0

Re: [coreboot] Coreboot Purism BIOS is free? open?
by Taiidan＠gmx.com 24 Dec '17

24 Dec '17

On 12/23/2017 04:08 PM, Ivan Ivanov wrote: > Sadly the ARM processor also have the ME-like backdoor (called "TrustZone). > And even MIPS is going this road soon (check out the "MIPS OmniShield" news). > > Could it be the requirement of US Government - for all the consumer > CPU to have backdoors ? > My last hopes are on POWER 9 and RISC V now ; meanwhile sticking to > the AMD pre-PSP tech I believe that "the No Such Agency did it" is too easy - I doubt they would be able to keep something that big under wraps for long considering how incompetent they are when it comes to security. My bets are on some type of private actor who wants industrial espionage on steroids - blackmailing or bribing key people who work for intel/amd to make it seem like ME/PSP is a good idea. Imagine all the money you could make with that kind of access!

1 0

Re: [coreboot] Coreboot Purism BIOS is free? open?
by Nico Huber 24 Dec '17

24 Dec '17

Hey Youness, hey Todd, On 23.12.2017 04:06, Youness Alaoui wrote: > I think there is a plan to move librems to non-x86 architecture > eventually (considering that RYF is our long term plan, there is no > choice in moving out of x86 eventually), that would be great. > I think the efforts on the > risc-v front are the most promising and I think that's where the true > competition to x86 will be, but to be honest, I don't really follow, > understand or know much of anything that happens in the hardware space > since I'm a software guy at heart (i.e: all I know is that x86, ARM, > PPC and Risc-V use different instruction sets). RISC-V is just a different ISA. Ok, it's free, but as it's BSD licen- sed, silicon vendors can build around it whatever they want. Delivering an owner-controllable platform is not in the scope of an ISA anyway. So RISC-V can't magically change the game by definition. > I hear a lot about PPC > (with Talos for example), but I don't think PPC is as open as Risc-v > (ISA or something). All I know about PPC really is that it was fun to > reverse engineer during my PS3 days :) > Anyways, as far as I know, for risc-v, it's not there yet, so we're > waiting for that to be ready for the masses before moving to it. I > have absolutely no idea if it's "close" or if it's really a long term > plan for risc-v to be able to compete with x86 in terms of > performance/power usage/features/etc... It doesn't matter how close somebody else is. If I understand Purism correctly, the idea is not to jump into a market of owner-controllable devices once it exists, but to pioneer that market. The only thing that matters is what you buy *today*. The choice of i.MX for the Librem 5 is a move into the right direction. i.MX6 was the best thing you can get for mobile devices, IMHO (controllable and publicly documented). If you get the i.MX8 for it (and it turns out to be as good documented), all you have to do is to ask for a board with the most powerful version that physically fits a Librem 13 [1]. Then you can offer trustworthy hardware vs. performance and let your customers chose. There are ofc alternatives to i.MX. Most use a graphics core where free drivers are a problem. Though, a proprietary driver in the OS is far less troublesome than blobs in your firmware (or the ME). And you might find something that is already available and delivers higher performance than the announced i.MX8 versions. Once you buy a reasonable quantity of an SoC, you can ask if they can make the next generation with RISC-V instead of ARM. Unlikely to get that soon, but way more likely than Intel changing their silicon for you. Nico [1] I'm convinced that this is easily doable. At least compared to the effort you already put in liberating the unliberatable. If the i.MX8 turns out to be as controllable and well documented as the i.MX6, you'd be catapulted towards the end of your freedom roadmap.

3 3

← Newer
1
2
3
4
5
6
7
8
9
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2017