OpenCores

OpenCores

Core Licenses Questions

no use

no use

1/3

Next

Last

Core Licenses Questions by Unknown on Jan 4, 2005			Not available!
Hello, I have been asked some questions about open hardware and the licenses used by OpenCores (GPL and LGPL are the recommended ones in the FAQ) to make the cores opensource but I haven't been able to provide adequate answers. For instance, after reading the LGPL license, does this license mean that a LGPL'ed core may be put into an ASIC without anybody ever knowing that a core from OpenCores is in there? doesn't this violate the LGPL license as it states that the source code must be made available or at least offered to any user who may want it (and at the same time letting the user know that there is an OpenCore inside the ASIC he is purchasing). Let's put an example: Enterprise A uses the core "AC97 Controller" from OpenCores as part of an ASIC for multimedia applications and Enterprise B decides to integrate this ASIC into a multimedia product, which is then bought in stores by individuals. My main question would be, according to LGPL license, which users (Enterprise B, individuals) shall be made available the possibility of downloading the core code from a web or be supplied thru a companion CD? This would mean letting parts, or all, of the users know that the ASIC contains open cores and which ones. I believe, by reading the Mission Statement in our website, that this is not the intention of OpenCores, but it is what is mentioned in the LGPL! The LGPL serves the open software community as any application that uses an LGPL'ed library can be recognized (the author, and any one who browses the source code that must accompany in some form the app, may immediately know that this library is part of the software), but that is not the case for us, open hardware community, and I seriously doubt that, if any enterprise uses our cores, they will not accompany their ASIC (and the final product in order to not violate the LGPL license) with a CDROM with our code or even mention in the user manual that they can download it from the web. This is not to mention the use of the GPL license in the cores. Doesn't the use of this license forbid the commercial use of the core? Then that is not an open core according to the Mission published in our website, or is it? May somebody be kind enough to help me answer these questions? Thank you very much, Victor Lopez Hello, I have been asked some questions about open hardware and the licenses used by OpenCores (GPL and LGPL are the recommended ones in the FAQ) to make the cores opensource but I haven't been able to provide adequate answers. For instance, after reading the LGPL license, does this license mean that a LGPL'ed core may be put into an ASIC without anybody ever knowing that a core from OpenCores is in there? doesn't this violate the LGPL license as it states that the source code must be made available or at least offered to any user who may want it (and at the same time letting the user know that there is an OpenCore inside the ASIC he is purchasing). Let's put an example: Enterprise A uses the core "AC97 Controller" from OpenCores as part of an ASIC for multimedia applications and Enterprise B decides to integrate this ASIC into a multimedia product, which is then bought in stores by individuals. My main question would be, according to LGPL license, which users (Enterprise B, individuals) shall be made available the possibility of downloading the core code from a web or be supplied thru a companion CD? This would mean letting parts, or all, of the users know that the ASIC contains open cores and which ones. I believe, by reading the Mission Statement in our website, that this is not the intention of OpenCores, but it is what is mentioned in the LGPL! The LGPL serves the open software community as any application that uses an LGPL'ed library can be recognized (the author, and any one who browses the source code that must accompany in some form the app, may immediately know that this library is part of the software), but that is not the case for us, open hardware community, and I seriously doubt that, if any enterprise uses our cores, they will not accompany their ASIC (and the final product in order to not violate the LGPL license) with a CDROM with our code or even mention in the user manual that they can download it from the web. This is not to mention the use of the GPL license in the cores. Doesn't the use of this license forbid the commercial use of the core? Then that is not an open core according to the Mission published in our website, or is it? May somebody be kind enough to help me answer these questions? Thank you very much, Victor Lopez

Core Licenses Questions by Unknown on Jan 4, 2005			Not available!
the users know that the ASIC [q] contains open cores and which ones. I believe, by reading the Mission Statement in our website, that this is not the intention of OpenCores, but it is what is mentioned in the LGPL! The LGPL serves the open software community as any application that uses an LGPL'ed library can be recognized (the author, and any one who browses the source code that must accompany in some form the app, may immediately know that this library is part of the software), but that is not the case for us, open hardware community, and I seriously doubt that, if any enterprise uses our cores, they will not accompany their ASIC (and the final product in order to not violate the LGPL license) with a CDROM with our code or even mention in the user manual that they can download it from the web.[/q] Many products already come with CDs for manual, drivers, etc. The companies could just put the source onto it as well, so the extra effort would be minimal. Philipp the users know that the ASIC contains open cores and which ones. I believe, by reading the Mission Statement in our website, that this is not the intention of OpenCores, but it is what is mentioned in the LGPL! The LGPL serves the open software community as any application that uses an LGPL'ed library can be recognized (the author, and any one who browses the source code that must accompany in some form the app, may immediately know that this library is part of the software), but that is not the case for us, open hardware community, and I seriously doubt that, if any enterprise uses our cores, they will not accompany their ASIC (and the final product in order to not violate the LGPL license) with a CDROM with our code or even mention in the user manual that they can download it from the web. Many products already come with CDs for manual, drivers, etc. The companies could just put the source onto it as well, so the extra effort would be minimal. Philipp

Core Licenses Questions by Unknown on Jan 4, 2005			Not available!
Hi Victor, I would consider this to be the same situation as a product such as a Linksys router, which incorporates open-source software such as Linux in addition to their own commercial (closed-source) additions. They make the GPL'ed source code available for download on their web site, and I believe the user's manual mentions the inclusion of the open-source software in their product. Of course, there is a difference in that a filesystem contains discrete files, each of which may be built from open- or closed-source code. In the case of an FPGA, each FPGA configuration is monolithic. The closest software analog is statically linking an open-source library with your own code. If the open-source code is licensed under the GPL, your software becomes open-source. In the case of the LGPL, there is no issue with the commercial product becoming "infected" by the open-source license. In my opinion, open-source firmware (Verilog, VHDL, ...) authors should consider carefully which license to release their work under, just as open-source software authors must. Those who use the open-source components (whether software or firmware) must also carefully consider the ramifications of using components licensed under the GPL. One could make the argument that "firmware is different", but that's not an argument I would personally want to make in court. ;-) To be completely safe, you might have to partition the open-source stuff into a separate FPGA -- obviously quite inefficient, but legal. - Joe Disclaimer: I am not a lawyer, so don't take this as gospel. I have had prior experience (as a software engineer) with development of products containing a mix of open-source and closed-source software, and in some cases decisions were made based upon licensing ramifications. Hi Victor, I would consider this to be the same situation as a product such as a Linksys router, which incorporates open-source software such as Linux in addition to their own commercial (closed-source) additions. They make the GPL'ed source code available for download on their web site, and I believe the user's manual mentions the inclusion of the open-source software in their product. Of course, there is a difference in that a filesystem contains discrete files, each of which may be built from open- or closed-source code. In the case of an FPGA, each FPGA configuration is monolithic. The closest software analog is statically linking an open-source library with your own code. If the open-source code is licensed under the GPL, your software becomes open-source. In the case of the LGPL, there is no issue with the commercial product becoming "infected" by the open-source license. In my opinion, open-source firmware (Verilog, VHDL, ...) authors should consider carefully which license to release their work under, just as open-source software authors must. Those who use the open-source components (whether software or firmware) must also carefully consider the ramifications of using components licensed under the GPL. One could make the argument that "firmware is different", but that's not an argument I would personally want to make in court. ;-) To be completely safe, you might have to partition the open-source stuff into a separate FPGA -- obviously quite inefficient, but legal. - Joe Disclaimer: I am not a lawyer, so don't take this as gospel. I have had prior experience (as a software engineer) with development of products containing a mix of open-source and closed-source software, and in some cases decisions were made based upon licensing ramifications.

Core Licenses Questions by Unknown on Jan 4, 2005			Not available!
Le mardi 4 Janvier 2005 20:45, Joe Bruce a Ã©crit : [q] Hi Victor, I would consider this to be the same situation as a product such as a Linksys router, which incorporates open-source software such as Linux in addition to their own commercial (closed-source) additions. They make the GPL'ed source code available for download on their web site, and I believe the user's manual mentions the inclusion of the open-source software in their product. Of course, there is a difference in that a filesystem contains discrete files, each of which may be built from open- or closed-source code. In the case of an FPGA, each FPGA configuration is monolithic. The closest software analog is statically linking an open-source library with your own code. If the open-source code is licensed under the GPL, your software becomes open-source. In the case of the LGPL, there is no issue with the commercial product becoming "infected" by the open-source license. In my opinion, open-source firmware (Verilog, VHDL, ...) authors should consider carefully which license to release their work under, just as open-source software authors must. Those who use the open-source components (whether software or firmware) must also carefully consider the ramifications of using components licensed under the GPL. One could make the argument that "firmware is different", but that's not an argument I would personally want to make in court. ;-) To be completely safe, you might have to partition the open-source stuff into a separate FPGA -- obviously quite inefficient, but legal. - Joe [/q] GPL is not a disease :) Like Linux derived work must be in GPL but specific improvement must be GPL. fs from other OS could be closed module or video drivers from the MS world also. But you can't create a specific module targeting linux at the beginning without openning your code. Linus is quite "open" with closed source drivers. You could also used trick like in ecos that define api where you could plug any code you want. Le mardi 4 Janvier 2005 20:45, Joe Bruce a Ã©crit : Hi Victor, I would consider this to be the same situation as a product such as a Linksys router, which incorporates open-source software such as Linux in addition to their own commercial (closed-source) additions. They make the GPL'ed source code available for download on their web site, and I believe the user's manual mentions the inclusion of the open-source software in their product. Of course, there is a difference in that a filesystem contains discrete files, each of which may be built from open- or closed-source code. In the case of an FPGA, each FPGA configuration is monolithic. The closest software analog is statically linking an open-source library with your own code. If the open-source code is licensed under the GPL, your software becomes open-source. In the case of the LGPL, there is no issue with the commercial product becoming "infected" by the open-source license. In my opinion, open-source firmware (Verilog, VHDL, ...) authors should consider carefully which license to release their work under, just as open-source software authors must. Those who use the open-source components (whether software or firmware) must also carefully consider the ramifications of using components licensed under the GPL. One could make the argument that "firmware is different", but that's not an argument I would personally want to make in court. ;-) To be completely safe, you might have to partition the open-source stuff into a separate FPGA -- obviously quite inefficient, but legal. - Joe GPL is not a disease :) Like Linux derived work must be in GPL but specific improvement must be GPL. fs from other OS could be closed module or video drivers from the MS world also. But you can't create a specific module targeting linux at the beginning without openning your code. Linus is quite "open" with closed source drivers. You could also used trick like in ecos that define api where you could plug any code you want.

Core Licenses Questions by Unknown on Jan 4, 2005			Not available!
It may not be a disease, but the GPL presents a number of thorny questions when you try to incorporate it, mostly because it's software license, and so we have to make assumptions about what "linking" means to hardware. For example, someone mentioned that shipping the code along with the documentation would be sufficient. The question is, which documentation? The chip I completed most recently is being designed into multiple different boards within my company, which all go into separate product lines, which are then built by a contract manufacturer, sold to a reseller, who sells them to the customer. Exactly where in this chain am I allowed to stop providing source code? What about cell libraries? If I use a GPLed design, do I have to link to a GPLed cell library? If not, what is the definition of what is a "design" (required to be GPL or LGPL) and what is a "library" (presumably exempt)? Vendors today provide "cells" like SERDES cores and microprocessors, so complexity is not sufficient. Without resolving these, I wouldn't feel safe using GPL or LGPL hardware code in a commercial product. It may not be a disease, but the GPL presents a number of thorny questions when you try to incorporate it, mostly because it's software license, and so we have to make assumptions about what "linking" means to hardware. For example, someone mentioned that shipping the code along with the documentation would be sufficient. The question is, which documentation? The chip I completed most recently is being designed into multiple different boards within my company, which all go into separate product lines, which are then built by a contract manufacturer, sold to a reseller, who sells them to the customer. Exactly where in this chain am I allowed to stop providing source code? What about cell libraries? If I use a GPLed design, do I have to link to a GPLed cell library? If not, what is the definition of what is a "design" (required to be GPL or LGPL) and what is a "library" (presumably exempt)? Vendors today provide "cells" like SERDES cores and microprocessors, so complexity is not sufficient. Without resolving these, I wouldn't feel safe using GPL or LGPL hardware code in a commercial product.

Core Licenses Questions by Unknown on Jan 5, 2005			Not available!
On Tue, 2005-01-04 at 23:42, VÃctor LÃ³pez wrote: [q] Hello, I have been asked some questions about open hardware and the licenses used by OpenCores (GPL and LGPL are the recommended ones in the FAQ) to make the cores opensource but I haven't been able to provide adequate answers. For instance, after reading the LGPL license, does this license mean that a LGPL'ed core may be put into an ASIC without anybody ever knowing that a core from OpenCores is in there? doesn't this violate the LGPL license as it states that the source code must be made available or at least offered to any user who may want it (and at the same time letting the user know that there is an OpenCore inside the ASIC he is purchasing). Let's put an example: Enterprise A uses the core "AC97 Controller" from OpenCores as[/q] Victor, you should check the licenses for ALL IP Cores you want to use very carefully. The AC97 IP Core is provided under a modified BSD style license. Please see my web site "Free IP" for clarification. Best Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, <A HREF="http://www.asics.ws">http://www.asics.ws</A> Your Partner for IP Cores, Design, Verification and Synthesis On Tue, 2005-01-04 at 23:42, VÃctor LÃ³pez wrote: Hello, I have been asked some questions about open hardware and the licenses used by OpenCores (GPL and LGPL are the recommended ones in the FAQ) to make the cores opensource but I haven't been able to provide adequate answers. For instance, after reading the LGPL license, does this license mean that a LGPL'ed core may be put into an ASIC without anybody ever knowing that a core from OpenCores is in there? doesn't this violate the LGPL license as it states that the source code must be made available or at least offered to any user who may want it (and at the same time letting the user know that there is an OpenCore inside the ASIC he is purchasing). Let's put an example: Enterprise A uses the core "AC97 Controller" from OpenCores as Victor, you should check the licenses for ALL IP Cores you want to use very carefully. The AC97 IP Core is provided under a modified BSD style license. Please see my web site "Free IP" for clarification. Best Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and Synthesis

Core Licenses Questions by Unknown on Jan 5, 2005			Not available!
On Wed, 2005-01-05 at 05:01, Guy Hutchison wrote: [q] It may not be a disease, but the GPL presents a number of thorny questions when you try to incorporate it, mostly because it's software license, and so we have to make assumptions about what "linking" means to hardware. For example, someone mentioned that shipping the code along with the documentation would be sufficient. The question is, which documentation? The chip I completed most recently is being designed into multiple different boards within my company, which all go into separate product lines, which are then built by a contract manufacturer, sold to a reseller, who sells them to the customer. Exactly where in this chain am I allowed to stop providing source code? What about cell libraries? If I use a GPLed design, do I have to link to a GPLed cell library? If not, what is the definition of what is a "design" (required to be GPL or LGPL) and what is a "library" (presumably exempt)? Vendors today provide "cells" like SERDES cores and microprocessors, so complexity is not sufficient. Without resolving these, I wouldn't feel safe using GPL or LGPL hardware code in a commercial product.[/q] In my opinion GPL and LGPL are plain out wrong for OpenCores or any other hardware description. GPL and LGPL discourage the usage of IP Cores in real commercial projects. I recommend designers use a modified BSD style license: ================================================================ Copyright (C) 2005, AUTHORS All rights reserved. Redistribution and use in source and binary form, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of the Authors and/or the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ================================================================ Best Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, <A HREF="http://www.asics.ws">http://www.asics.ws</A> Your Partner for IP Cores, Design, Verification and Synthesis On Wed, 2005-01-05 at 05:01, Guy Hutchison wrote: It may not be a disease, but the GPL presents a number of thorny questions when you try to incorporate it, mostly because it's software license, and so we have to make assumptions about what "linking" means to hardware. For example, someone mentioned that shipping the code along with the documentation would be sufficient. The question is, which documentation? The chip I completed most recently is being designed into multiple different boards within my company, which all go into separate product lines, which are then built by a contract manufacturer, sold to a reseller, who sells them to the customer. Exactly where in this chain am I allowed to stop providing source code? What about cell libraries? If I use a GPLed design, do I have to link to a GPLed cell library? If not, what is the definition of what is a "design" (required to be GPL or LGPL) and what is a "library" (presumably exempt)? Vendors today provide "cells" like SERDES cores and microprocessors, so complexity is not sufficient. Without resolving these, I wouldn't feel safe using GPL or LGPL hardware code in a commercial product. In my opinion GPL and LGPL are plain out wrong for OpenCores or any other hardware description. GPL and LGPL discourage the usage of IP Cores in real commercial projects. I recommend designers use a modified BSD style license: ================================================================ Copyright (C) 2005, AUTHORS All rights reserved. Redistribution and use in source and binary form, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of the Authors and/or the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ================================================================ Best Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and Synthesis

Core Licenses Questions by Unknown on Jan 5, 2005			Not available!
[q] I recommend designers use a modified BSD style license: ================================================================ Copyright (C) 2005, AUTHORS All rights reserved. Redistribution and use in source and binary form, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.[/q] I like where this is going. However, I have some questions: * The term "source code" is clear. It means cleartext Verilog or VHDL. However, what does "binary form" mean? Is that the .jed or .bit file? Or is it the actual gates burned into the physical silicon? * If I just ship chips programmed or taped out with a design licenced under your license, what do I need to distribute along with them? Anything? I guess you need to make clear what to do with the three instantiations of a design found in teh chip design flow: 1. VHDL/Verilog (human readable) source, 2. Machine readable programming or manufacturing information, 3. The physical chip. Thanks, Staurt I recommend designers use a modified BSD style license: ================================================================ Copyright (C) 2005, AUTHORS All rights reserved. Redistribution and use in source and binary form, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. I like where this is going. However, I have some questions: * The term "source code" is clear. It means cleartext Verilog or VHDL. However, what does "binary form" mean? Is that the .jed or .bit file? Or is it the actual gates burned into the physical silicon? * If I just ship chips programmed or taped out with a design licenced under your license, what do I need to distribute along with them? Anything? I guess you need to make clear what to do with the three instantiations of a design found in teh chip design flow: 1. VHDL/Verilog (human readable) source, 2. Machine readable programming or manufacturing information, 3. The physical chip. Thanks, Staurt

Core Licenses Questions by Unknown on Jan 5, 2005			Not available!
[q]> > Redistributions in binary form must reproduce the above > copyright notice, this list of conditions and the > following disclaimer in the documentation and/or other > materials provided with the distribution.[/q] I like where this is going. However, I have some questions: * The term "source code" is clear. It means cleartext Verilog or VHDL. However, what does "binary form" mean? Is that the .jed or .bit file? Or is it the actual gates burned into the physical silicon?[/q] I use the same (well similar) BSD style license. The way I intentioned it is as follows; - any HUMAN readable form: source code - any MACHINE readable form: binary format - silicon: neither readable by human, nor machine (does that answer it??) Now the tricky parts: bitstreams. - not readable by human - readably by machines? Taken literally yes, an FPGA is a machine. So to be on the safe side the documentation should list the usage and copyright/disclaimer. The point everybody should understand is that we need a license that: 1. That's clear. (L)GPL leave too many questions to be a usable OpenCores license 2. That informs the user that he's allowed to use the core free of charge at his own risk (no liability for the author of the core) 3. If required by the authors, does oblige the user to return any improvements/modifications on the core. Note that the listed BSD license (and mine neither) request the user to return any modifications, although many do. The reason for this is that this allows the user to modify it to their needs or insert proprietary code. This does not allow them to remove the copyright/license/disclaimer notice. This discussion pops up once in a while or so. Check the opencores archives. I once did a detailed study on this subject and posted this (as emails) on opencores. In those articles I also urgently suggested using BSD style licenses, as the (L)GPL licenses are simply not suited for hardware. But so far most people keep using them ......... Hope this helps. Cheers, Richard > > Redistributions in binary form must reproduce the above > copyright notice, this list of conditions and the > following disclaimer in the documentation and/or other > materials provided with the distribution. I like where this is going. However, I have some questions: * The term "source code" is clear. It means cleartext Verilog or VHDL. However, what does "binary form" mean? Is that the .jed or .bit file? Or is it the actual gates burned into the physical silicon? I use the same (well similar) BSD style license. The way I intentioned it is as follows; - any HUMAN readable form: source code - any MACHINE readable form: binary format - silicon: neither readable by human, nor machine (does that answer it??) Now the tricky parts: bitstreams. - not readable by human - readably by machines? Taken literally yes, an FPGA is a machine. So to be on the safe side the documentation should list the usage and copyright/disclaimer. The point everybody should understand is that we need a license that: 1. That's clear. (L)GPL leave too many questions to be a usable OpenCores license 2. That informs the user that he's allowed to use the core free of charge at his own risk (no liability for the author of the core) 3. If required by the authors, does oblige the user to return any improvements/modifications on the core. Note that the listed BSD license (and mine neither) request the user to return any modifications, although many do. The reason for this is that this allows the user to modify it to their needs or insert proprietary code. This does not allow them to remove the copyright/license/disclaimer notice. This discussion pops up once in a while or so. Check the opencores archives. I once did a detailed study on this subject and posted this (as emails) on opencores. In those articles I also urgently suggested using BSD style licenses, as the (L)GPL licenses are simply not suited for hardware. But so far most people keep using them ......... Hope this helps. Cheers, Richard

Core Licenses Questions by Unknown on Jan 5, 2005			Not available!
[q] GPL is not a disease :)[/q] It is for open source hardware (see my other email). [q] Like Linux derived work must be in GPL but specific improvement must be GPL. fs from other OS could be closed module or video drivers from the MS world also. But you can't create a specific module targeting linux at the beginning without openning your code. Linus is quite "open" with closed source drivers. You could also used trick like in ecos that define api where you could plug any code you want.[/q] Software, software, software, software. We are developing HARDWARE here !!!! GPL is not a disease :) It is for open source hardware (see my other email). Like Linux derived work must be in GPL but specific improvement must be GPL. fs from other OS could be closed module or video drivers from the MS world also. But you can't create a specific module targeting linux at the beginning without openning your code. Linus is quite "open" with closed source drivers. You could also used trick like in ecos that define api where you could plug any code you want. Software, software, software, software. We are developing HARDWARE here !!!!

Core Licenses Questions by Unknown on Jan 5, 2005			Not available!
Hi, even if this issue has been discussed some time ago in the forum, it looks as if it was not solved. After reading the answers to my previous email I must agree with Mr. Usselmann in saying that maybe GPL and LGPL are not suitable for hardware, being these legal issues that we may not fully understand, I think that we should use (and recommend in the FAQ page) some other license other than the LGPL (the one currently recommended) which is not at all applicable to hardware cores. In my experience I think that a license should not give much freedom to misunderstanding if it is to be questioned some day in a court. Modified BSD sounds good, maybe it would be advisable to use and recommend this one (I bet a lot of the published projects use LGPL just because it is advised in the FAQ) or maybe (legal things matter, it is better to prevent now than to have to cure later) we should agree on what we expect from a license for OpenCores and modify one of the existent ones to meet our expectatives. I would like to hear some words from Damjan on this subject. It looks as if each one in the community interprets in a different manner the terms of the licenses. Anyways, what are the implications of modifying the license for an active project? I would say that anybody who downloaded it before the license change are subject to the previous license and the ones who downloaded it later are bound to the new one. Any ideas on this? Thank you, Victor Lopez Hi, even if this issue has been discussed some time ago in the forum, it looks as if it was not solved. After reading the answers to my previous email I must agree with Mr. Usselmann in saying that maybe GPL and LGPL are not suitable for hardware, being these legal issues that we may not fully understand, I think that we should use (and recommend in the FAQ page) some other license other than the LGPL (the one currently recommended) which is not at all applicable to hardware cores. In my experience I think that a license should not give much freedom to misunderstanding if it is to be questioned some day in a court. Modified BSD sounds good, maybe it would be advisable to use and recommend this one (I bet a lot of the published projects use LGPL just because it is advised in the FAQ) or maybe (legal things matter, it is better to prevent now than to have to cure later) we should agree on what we expect from a license for OpenCores and modify one of the existent ones to meet our expectatives. I would like to hear some words from Damjan on this subject. It looks as if each one in the community interprets in a different manner the terms of the licenses. Anyways, what are the implications of modifying the license for an active project? I would say that anybody who downloaded it before the license change are subject to the previous license and the ones who downloaded it later are bound to the new one. Any ideas on this? Thank you, Victor Lopez

Core Licenses Questions by Unknown on Jan 5, 2005			Not available!
Le mardi 4 Janvier 2005 23:01, Guy Hutchison a Ã©crit : [q] It may not be a disease, but the GPL presents a number of thorny questions when you try to incorporate it, mostly because it's software license, and so we have to make assumptions about what "linking" means to hardware.[/q] I don't think that "linking" is a word used in the GPL. The speak about derivative work, prefered form of work, "results". All of this work with hardware. [q] For example, someone mentioned that shipping the code along with the documentation would be sufficient. The question is, which documentation? The chip I completed most recently is being designed[/q] GPL did not speak about documentation. [q] into multiple different boards within my company, which all go into separate product lines, which are then built by a contract manufacturer, sold to a reseller, who sells them to the customer. Exactly where in this chain am I allowed to stop providing source code?[/q] You must give an access to the code to your customers. [q] What about cell libraries? If I use a GPLed design, do I have to link to a GPLed cell library? If not, what is the definition of what is a[/q] You could always used the underlying system library. I don't know the exact term of the GPL. But what ever the licence of system lib of windows, you could create free software on it. You could compare that to cell lib. [q] "design" (required to be GPL or LGPL) and what is a "library" (presumably exempt) ?[/q] That's the problem of the LGPL but i don't think also that the word library is used in the licence IMHO. [q] Vendors today provide "cells" like SERDES cores and microprocessors, so complexity is not sufficient.[/q] That's clearly other "program". Its the same as many program on a computer. [q] Without resolving these, I wouldn't feel safe using GPL or LGPL hardware code in a commercial product.[/q] Sur that's exactly as for software. Some people prefer BSD others GPL. Do what ever you want. Nicolas Boulay Le mardi 4 Janvier 2005 23:01, Guy Hutchison a Ã©crit : It may not be a disease, but the GPL presents a number of thorny questions when you try to incorporate it, mostly because it's software license, and so we have to make assumptions about what "linking" means to hardware. I don't think that "linking" is a word used in the GPL. The speak about derivative work, prefered form of work, "results". All of this work with hardware. For example, someone mentioned that shipping the code along with the documentation would be sufficient. The question is, which documentation? The chip I completed most recently is being designed GPL did not speak about documentation. into multiple different boards within my company, which all go into separate product lines, which are then built by a contract manufacturer, sold to a reseller, who sells them to the customer. Exactly where in this chain am I allowed to stop providing source code? You must give an access to the code to your customers. What about cell libraries? If I use a GPLed design, do I have to link to a GPLed cell library? If not, what is the definition of what is a You could always used the underlying system library. I don't know the exact term of the GPL. But what ever the licence of system lib of windows, you could create free software on it. You could compare that to cell lib. "design" (required to be GPL or LGPL) and what is a "library" (presumably exempt) ? That's the problem of the LGPL but i don't think also that the word library is used in the licence IMHO. Vendors today provide "cells" like SERDES cores and microprocessors, so complexity is not sufficient. That's clearly other "program". Its the same as many program on a computer. Without resolving these, I wouldn't feel safe using GPL or LGPL hardware code in a commercial product. Sur that's exactly as for software. Some people prefer BSD others GPL. Do what ever you want. Nicolas Boulay

Core Licenses Questions by Unknown on Jan 5, 2005			Not available!
Le mercredi 5 Janvier 2005 10:58, Richard Herveille a Ã©crit : [q]> GPL is not a disease :)[/q] It is for open source hardware (see my other email). [q]> Like Linux derived work must be in GPL but specific > improvement must be GPL. > > fs from other OS could be closed module or video drivers from > the MS world also. But you can't create a specific module > targeting linux at the beginning without openning your code. > > Linus is quite "open" with closed source drivers. You could > also used trick like in ecos that define api where you could > plug any code you want.[/q] Software, software, software, software. We are developing HARDWARE here !!!![/q] Sorry, the underlying law is copyright. GPL is a licence on copyright that give a lot of freedom and one obligation (not change the licence). Nothing written in the GPL pose a problem on hardware (from the legal point of view) Le mercredi 5 Janvier 2005 10:58, Richard Herveille a Ã©crit : > GPL is not a disease :) It is for open source hardware (see my other email). > Like Linux derived work must be in GPL but specific > improvement must be GPL. > > fs from other OS could be closed module or video drivers from > the MS world also. But you can't create a specific module > targeting linux at the beginning without openning your code. > > Linus is quite "open" with closed source drivers. You could > also used trick like in ecos that define api where you could > plug any code you want. Software, software, software, software. We are developing HARDWARE here !!!! Sorry, the underlying law is copyright. GPL is a licence on copyright that give a lot of freedom and one obligation (not change the licence). Nothing written in the GPL pose a problem on hardware (from the legal point of view)

Core Licenses Questions by Unknown on Jan 5, 2005			Not available!
[q] I don't think that "linking" is a word used in the GPL. The speak about derivative work, prefered form of work, "results". All of this work with hardware.[/q] True, although one must establish the border of the derivative work. A reasonable interpretation of the GPL is that the border is the chip, and therefore everything inside the chip is subject to the publishing requirements of the GPL. [q] GPL did not speak about documentation.[/q] This point was speaking more to the reporting requirements implicit in the BSD license, which say that the distributed product needs to carry a copyright notice. My point here is simply that figuring out what the distributed product is is not cut-and-dry. [q] [q]> into multiple different boards within my company, which all go into > separate product lines, which are then built by a contract > manufacturer, sold to a reseller, who sells them to the customer. > Exactly where in this chain am I allowed to stop providing source > code?[/q] You must give an access to the code to your customers.[/q] Same point -- who is the customer? I consider my customer to be the board design group. Many people would consider the reseller to be the customer, and some would consider the end customer to be the customer. A few might even consider that customer's customers to be the customer. [q]> Vendors today provide "cells" like SERDES cores > and microprocessors, so complexity is not sufficient.[/q] That's clearly other "program". Its the same as many program on a computer.[/q] It's not clearly another program. In fact the language of the GPL would place it in the same derived work, which would make it clearly part of this "program". [q] Nothing written in the GPL pose a problem on hardware (from the legal point of view)[/q] That is your opinion, and I'm guessing that you're not a lawyer... It is my opinion (who am also not a lawyer) that the GPL and LGPL post significant problems for hardware design, which is why I (and others) have pointed this out. - Guy I don't think that "linking" is a word used in the GPL. The speak about derivative work, prefered form of work, "results". All of this work with hardware. True, although one must establish the border of the derivative work. A reasonable interpretation of the GPL is that the border is the chip, and therefore everything inside the chip is subject to the publishing requirements of the GPL. GPL did not speak about documentation. This point was speaking more to the reporting requirements implicit in the BSD license, which say that the distributed product needs to carry a copyright notice. My point here is simply that figuring out what the distributed product is is not cut-and-dry. > into multiple different boards within my company, which all go into > separate product lines, which are then built by a contract > manufacturer, sold to a reseller, who sells them to the customer. > Exactly where in this chain am I allowed to stop providing source > code? You must give an access to the code to your customers. Same point -- who is the customer? I consider my customer to be the board design group. Many people would consider the reseller to be the customer, and some would consider the end customer to be the customer. A few might even consider that customer's customers to be the customer. > Vendors today provide "cells" like SERDES cores > and microprocessors, so complexity is not sufficient. That's clearly other "program". Its the same as many program on a computer. It's not clearly another program. In fact the language of the GPL would place it in the same derived work, which would make it clearly part of this "program". Nothing written in the GPL pose a problem on hardware (from the legal point of view) That is your opinion, and I'm guessing that you're not a lawyer... It is my opinion (who am also not a lawyer) that the GPL and LGPL post significant problems for hardware design, which is why I (and others) have pointed this out. - Guy

Core Licenses Questions by Unknown on Jan 6, 2005			Not available!
d product is is not cut-and-dry. [q] [q]into multiple different boards within my company, which all go into separate product lines, which are then built by a contract manufacturer, sold to a reseller, who sells them to the customer. Exactly where in this chain am I allowed to stop providing source code?[/q] You must give an access to the code to your customers.[/q] Same point -- who is the customer? I consider my customer to be the board design group. Many people would consider the reseller to be the customer, and some would consider the end customer to be the customer. A few might even consider that customer's customers to be the customer. [/q] This is just the same as with software. You give the code to the one that you give your design to. When they make a chip out of it and give it to someone else it's their responsibility to ship the source they got from you along with it. And so on. Philipp d product is is not cut-and-dry. into multiple different boards within my company, which all go into separate product lines, which are then built by a contract manufacturer, sold to a reseller, who sells them to the customer. Exactly where in this chain am I allowed to stop providing source code? You must give an access to the code to your customers. Same point -- who is the customer? I consider my customer to be the board design group. Many people would consider the reseller to be the customer, and some would consider the end customer to be the customer. A few might even consider that customer's customers to be the customer. This is just the same as with software. You give the code to the one that you give your design to. When they make a chip out of it and give it to someone else it's their responsibility to ship the source they got from you along with it. And so on. Philipp

no use

no use

1/3

Next

Last

© copyright 1999-2025 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.