[U-Boot] changes to U-boot and GPL
We are getting confused when reading the GPL and interpreting how it applies to our situation. We are adding features (not changing existing ones) to U-boot particular to our in-house developed system which we sell as a product to our customers. These changes involve adding a menu command for common tasks particular to our product and adding an in-house developed protocol for transferring files over a proprietary bus. We do not see these changes as being useful to the general U-boot community. We do have some concerns about security and opening our product (which is safety-critical) for malicious hacking by exposing the modifications. This modified U-boot will be deployed on our products. It will not make sense to use on any other platforms. Our question is: Do we need to submit our changes to the U-boot maintainers for inclusion in the mainline distribution code ? We understand the philosophy of GPL to give our customers the source code so they have the ability to inspect, modify and outsource And customization without being dependent on us. In that light we have no problem in either providing our customers with the full source code upon their request OR simply load the full source code in the file system of the box it is shipped with. So if a customer wants the code, they can load it of the box they bought from us. Any suggestions ? Thank you Any files attached to this e-mail will have been checked with virus detection software prior to transmission but you should carry out your own virus check before opening any attachment. Safetran Systems Corp does not accept liability for any damage or loss which may be caused by software viruses. The contents of this e-mail and any attachments are the property of Safetran Systems Corp and are intended for the confidential use by the named recipient only. They may be legally privileged and should not be communicated to, or relied upon, by any other person without written consent. If you are not the addressee, please notify us immediately at the following address: Safetran Systems Corporation, 2400 Nelson Miller Parkway, Louisville, Kentucky 40223. Safetran Systems Corp is a subsidiary of Invensys Plc. Registered office: Portland House, Bressenden Place, London, SW1E 5BF. UK Registered in England and Wales No. 1641421. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] changes to U-boot and GPL
On Friday 28 May 2010 13:50:57 Mangelschots, Jef wrote: We are getting confused when reading the GPL and interpreting how it applies to our situation. then you should hire a lawyer to interpret it for you. legal advice cannot be obtained from mailing lists such as this. the only thing you can get is random people's opinions. so here is mine ;p. Do we need to submit our changes to the U-boot maintainers for inclusion in the mainline distribution code ? this is never a requirement of the GPL for any project out there We understand the philosophy of GPL to give our customers the source code so they have the ability to inspect, modify and outsource And customization without being dependent on us. In that light we have no problem in either providing our customers with the full source code upon their request OR simply load the full source code in the file system of the box it is shipped with. So if a customer wants the code, they can load it of the box they bought from us. and those customers are free to take that source code and release it onto the internet. so your original concerns seem kind of moot. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] changes to U-boot and GPL
Dear Mangelschots, Jef, In message 226bc4afa29fc24789dfd00dff3084c250d3690...@safemail.safetran.railad.com you wrote: We are getting confused when reading the GPL and interpreting how it applies to our situation. You may want to read A Practical Guide to GPL Compliance, see http://www.softwarefreedom.org/resources/2008/compliance-guide.html We are adding features (not changing existing ones) to U-boot particular to our in-house developed system which we sell as a product to our customers. These changes involve adding a menu command for common tasks particular to our product and adding an in-house developed protocol for transferring files over a proprietary bus. We do not see these changes as being useful to the general U-boot community. We do have some concerns about security and opening our What makes you think they would not be useful? Others might get inspired by your menu system and adjust / extend it for their purposes. U-Boot's origin is from a port to some board thatis of no use to you - and still you benefit from a lot of code you can re-use. product (which is safety-critical) for malicious hacking by exposing the modifications. Security by obscurity has never worked, and never will work. Eventually a peer review from the experts in the community might even help to improve the security of your system (and I mean the real one, not the one you think you have). But this is your decision, of course. This modified U-boot will be deployed on our products. It will not make sense to use on any other platforms. This is your opinion. Other people my think differently. Our question is: Do we need to submit our changes to the U-boot maintainers for inclusion in the mainline distribution code ? As Mike already pointed out: no. We understand the philosophy of GPL to give our customers the source code so they have the ability to inspect, modify and outsource And customization without being dependent on us. In that light we have no problem in either providing our customers with the full source code upon their request OR simply load the full source code in the file system of the box it is shipped with. So if a customer wants the code, they can load it of the box they bought from us. Out-of-tree ports have two distinct properties: 1) they are obsolete from day 1 after their release (and often long before that), and 2) they are a never ending maintenance effort. In our experience the most efficient way to optimize product quality while minimizing long-term maintenance efforts is to push all changes into mainline as soon as possible. You get free code reviews from the best experts in the field, the community is maintaining your code for you, and there is free help for you and your customers from the community. See what's happening with all the out-of-tree ports - people come here asking for help for really ancient versions, and we cannot help even if we want because we don't know the code... It's your choice. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Technology is dominated by those who manage what they do not under- stand. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot