Hi Ian,
Ian Lewis wrote:
Thank you for your detailed reply. Of course, I understand that you cannot provide legal advice. But, for now, I need to understand the practicalities of how to comply, more than I need to understand the law of compliance. And, in any case, that will probably be someone else's problem if we reach that point.
Since I wrote to this group, I found another page from SFLC https://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_.... I know that Sam said that SFLC may have issues, but their write up still seems useful.
Cool!
On the issue of notice, I am referring to section 1. of the license.
- 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.
Ah! Thanks for clarifying.
Note that this Section covers "verbatim copies of the Program's source code" and says "on each copy" and "keep intact all the notices that refer to this License".
This seems to me to require some kind of clear notice to the recipient of their GPL rights. A microSD attached to our product may provide the necessary source and license agreements. But, it sure does not satisfy "conspicuously ", at least in my opinion.
I believe that the purpose of this section is to ensure that recipients "after" you have exactly the same freedoms and possibilities with this program as you had.
Thus it is important to communicate to those recipients which copyright and licensing terms apply - conspicuously and appropriately "on each copy" "of the Program's source code."
Not on each copy in object code or executable form (that's Section 3) - but on each verbatim copy of the Program's source code.
In my opinion, a COPYING or LICENSE file in the source code root directory serves as such conspicuous and appropriate notice, and is one reason why this file is sometimes required by legal departments. (See the thread on this list by the codeaurora member, who requested that such a file be added to the root directory of the depthcharge repo (one payload) as the preferd method to satisfy the requirements of Qualcomm's legal department.
You say that it is not possible to absolve our customer from GPL responsibility.
Correct. Your customers are also distributing the (coreboot) Program (in object form, as received from you) and they must of course do so in compliance with the licensing terms.
But, I had the impression that they would have met their obligations if we can keep the source with our product (that is, physically attached to it) and provide each recipient with the notice (as I called it - see above) somehow. Do you read this as incorrect?
I think that's correct.
Their obligations to their customers are the same as your obligations to them. But the important point is that *they* are always responsible for *their* obligations, just as you are responsible for yours. They can't legally depend on you for that. (They would risk non-compliance due to factors out of their control. Bad risk!)
If you want to (and I think you should, to maximize the value of your offer :) you can design your compliance (as permitted by the license) such that your customers can re-use your effort in order to themselves achieve compliance easily, in particular if you choose the option to deliver source code accompanied with the object code.
That is, even if we could get our notice in front of each recipient
The notice is to be "on each copy" "of the Program's source code."
and our product always included the full license and source on microSD, that would not be good enough to cover the obligations of our distributor/customer?
As long as your customer passes the medium along to *their* customer, I would consider them compliant. They have to actually do that however.
It is helpful to state that they are non-compliant and risk a lawsuit should they fail to accompany the object code (in your hardware, which they ship) with the source code that they can acquire or have received from you.
PS. I did not get a direct copy of your message.
Sorry about that. I've Cc:ed you on this reply, I hope that helps.
It's often customary to reply only directly to lists, although some lists (noticeably all Linux kernel-related lists) have an explicit policy to always use reply-all.
Because many email programs group messages by using (invisible) email threading headers regardless of how/where the message arrived, people with such programs usually prefer not to receive two messages. It usually works very well to politely ask for any replies to list messages to also be Cc:ed directly to you, if that is helpful for your workflow. "Please Cc me on replies." is enough. Of course it's no guarantee that people actually do so, but it tends to work well.
Because of that thread grouping it's also customary and much prefered to reply inline with only a minimum of relevant text quoted, and to remove all quoted text not directly replied to, since the full preceding email with complete context is presented immediately before the reply in such thread-grouping mailers.
Threading and list-reply are great features. Unfortunately, especially enterprise mail clients often support neither. :\
Kind regards
//Peter