OpenCores

OpenCores

Core Licenses Questions

First

Prev

2/3

Next

Last

Core Licenses Questions by Unknown on Jan 6, 2005			Not available!
Aloha! Quoting Richard Herveille <<A HREF="http://www.opencores.org/mailman/listinfo/cores">richard at herveille.net</A>>: [q] 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.[/q] And we have even had a visit on this maillist from Richard M Stallman himself who asked questions about how to verify that a core on a chip is the same as the one in the source RTL (or something to that effect, unless I misunderstood him). [q] 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 .........[/q] And I have to side with you and Rudi on this - and it's not only because I'm generally a BSD-dude (FreeBSD to be precise). I think that a license that legally describes the way IP-cores are used and somehow integrates the interests of the developer, protects the code from being ripped off, while still allow for a good usage, would be the thing to have. My hope was that LGPL would be that license. But, when I read it, I get stuck at too much things that does not grok with the nature of IP-cores. I would like to point out that (note: IANAL) GPL does not stop anyone from making business using technology based on GPL. You could/should be able to build, for example an FPGA-based application where some cores are GPL. If asked, you can always provide the source for those cores. BUT: If I as a core provider want to be nice and provide freedom in utility and just limit my own liability - as well as the other legal hairy stuff you get with (L)GPL then a version of MIT/BSD-license is probably just the thing. And since im not a lawyer and generally like BSD that's what I'll use. I can agree with the "keep the code open and free" that Linus usually talks about, and do appreciate the hard-line freedom aspects that RMS talks about, but practicality makes BSD look easier (to me). But the one Rudi published at least to me does not fit the bill either since (as pointed out) talks about software etc. BSD based, but still to much SW. Just my thoughts. -- Med vÃ¤nlig hÃ¤lsning, Yours Joachim StrÃ¶mbergson - Alltid i harmonisk svÃ¤ngning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÃ–TEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: <A HREF="http://www.opencores.org/mailman/listinfo/cores">joachim.strombergson at informasic.com</A> Home: www.informasic.com ---------------------------------------------------------------------- Aloha! Quoting Richard Herveille richard at herveille.net>: 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. And we have even had a visit on this maillist from Richard M Stallman himself who asked questions about how to verify that a core on a chip is the same as the one in the source RTL (or something to that effect, unless I misunderstood him). 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 ......... And I have to side with you and Rudi on this - and it's not only because I'm generally a BSD-dude (FreeBSD to be precise). I think that a license that legally describes the way IP-cores are used and somehow integrates the interests of the developer, protects the code from being ripped off, while still allow for a good usage, would be the thing to have. My hope was that LGPL would be that license. But, when I read it, I get stuck at too much things that does not grok with the nature of IP-cores. I would like to point out that (note: IANAL) GPL does not stop anyone from making business using technology based on GPL. You could/should be able to build, for example an FPGA-based application where some cores are GPL. If asked, you can always provide the source for those cores. BUT: If I as a core provider want to be nice and provide freedom in utility and just limit my own liability - as well as the other legal hairy stuff you get with (L)GPL then a version of MIT/BSD-license is probably just the thing. And since im not a lawyer and generally like BSD that's what I'll use. I can agree with the "keep the code open and free" that Linus usually talks about, and do appreciate the hard-line freedom aspects that RMS talks about, but practicality makes BSD look easier (to me). But the one Rudi published at least to me does not fit the bill either since (as pointed out) talks about software etc. BSD based, but still to much SW. Just my thoughts. -- Med vÃ¤nlig hÃ¤lsning, Yours Joachim StrÃ¶mbergson - Alltid i harmonisk svÃ¤ngning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÃ–TEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: joachim.strombergson at informasic.com Home: www.informasic.com ----------------------------------------------------------------------

Core Licenses Questions by jcastillo on Jan 6, 2005			jcastillo Posts: 32 Joined: Jun 29, 2004 Last seen: Dec 21, 2021
Hi, I think it is clear that licenses derived from software ones, does not fit with a hardware design license requirements. From the discussion we can assume that a BSD license seems to be more adequate to hardware designs than a GPL one but it is not as good as it might be. IMHO it is time to write a new license to distribute open hardware designs, we could call it, HGPL (Hardware General Public License). We can post in this forum our proposals and discuss them. Javier Castillo <A HREF="http://www.opencores.org/mailman/listinfo/cores">jcastillo at opensocdesign.com</A> www.opensocdesign.com -----Mensaje original----- De: <A HREF="http://www.opencores.org/mailman/listinfo/cores">cores-bounces at opencores.org</A> [mailto:<A HREF="http://www.opencores.org/mailman/listinfo/cores">cores-bounces at opencores.org</A>] En nombre de VÃctor LÃ³pez Enviado el: miÃ©rcoles, 05 de enero de 2005 21:42 Para: <A HREF="http://www.opencores.org/mailman/listinfo/cores">cores at opencores.org</A> Asunto: [oc] Core Licenses Questions 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 _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A> Hi, I think it is clear that licenses derived from software ones, does not fit with a hardware design license requirements. From the discussion we can assume that a BSD license seems to be more adequate to hardware designs than a GPL one but it is not as good as it might be. IMHO it is time to write a new license to distribute open hardware designs, we could call it, HGPL (Hardware General Public License). We can post in this forum our proposals and discuss them. Javier Castillo jcastillo at opensocdesign.com www.opensocdesign.com -----Mensaje original----- De: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] En nombre de VÃctor LÃ³pez Enviado el: miÃ©rcoles, 05 de enero de 2005 21:42 Para: cores at opencores.org Asunto: [oc] Core Licenses Questions 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 _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Core Licenses Questions by Unknown on Jan 6, 2005			Not available!
On Thu, 2005-01-06 at 06:48, jcastillo wrote: [q] Hi, I think it is clear that licenses derived from software ones, does not fit with a hardware design license requirements. From the discussion we can assume that a BSD license seems to be more adequate to hardware designs than a GPL one but it is not as good as it might be. IMHO it is time to write a new license to distribute open hardware designs, we could call it, HGPL (Hardware General Public License). We can post in this forum our proposals and discuss them. Javier Castillo[/q] Perhaps we should start a lit of items we feel are important to have in a HGPL. Than we could hire an attorney to convert it in to legalese ... For example my list would start of with: 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever Perhaps we can take that as a start and add items till everybody (who is interested in a modified BSD style license) is happy ? I think we will see a big division on my #1 item. So we might have to create 2 flavors of the license. One that is totally permissive (BSD style) and perhaps a second one that is closer to L/GPL. 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 Thu, 2005-01-06 at 06:48, jcastillo wrote: Hi, I think it is clear that licenses derived from software ones, does not fit with a hardware design license requirements. From the discussion we can assume that a BSD license seems to be more adequate to hardware designs than a GPL one but it is not as good as it might be. IMHO it is time to write a new license to distribute open hardware designs, we could call it, HGPL (Hardware General Public License). We can post in this forum our proposals and discuss them. Javier Castillo Perhaps we should start a lit of items we feel are important to have in a HGPL. Than we could hire an attorney to convert it in to legalese ... For example my list would start of with: 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever Perhaps we can take that as a start and add items till everybody (who is interested in a modified BSD style license) is happy ? I think we will see a big division on my #1 item. So we might have to create 2 flavors of the license. One that is totally permissive (BSD style) and perhaps a second one that is closer to L/GPL. 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 6, 2005			Not available!
On Thu, 6 Jan 2005, Rudolf Usselmann wrote: [q] For example my list would start of with: 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements[/q] There is an intermediate possibility; would you consider this? With no requirement to publish enhancements, it is possible that the original designer may not even be able to USE the modified device. Would a requirement to publish the details of the INTERFACE to any enhanced version be acceptable or practical? All it needs to mean is that a url pointing to this information is made public. Without even this minimal condition, I can imagine a future where open cores are wildly successful and still no one apart from the chip manufacturer can write device drivers for them... Best Graham [q] 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever Perhaps we can take that as a start and add items till everybody (who is interested in a modified BSD style license) is happy ? I think we will see a big division on my #1 item. So we might have to create 2 flavors of the license. One that is totally permissive (BSD style) and perhaps a second one that is closer to L/GPL. 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 _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A> [/q] On Thu, 6 Jan 2005, Rudolf Usselmann wrote: For example my list would start of with: 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements There is an intermediate possibility; would you consider this? With no requirement to publish enhancements, it is possible that the original designer may not even be able to USE the modified device. Would a requirement to publish the details of the INTERFACE to any enhanced version be acceptable or practical? All it needs to mean is that a url pointing to this information is made public. Without even this minimal condition, I can imagine a future where open cores are wildly successful and still no one apart from the chip manufacturer can write device drivers for them... Best Graham 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever Perhaps we can take that as a start and add items till everybody (who is interested in a modified BSD style license) is happy ? I think we will see a big division on my #1 item. So we might have to create 2 flavors of the license. One that is totally permissive (BSD style) and perhaps a second one that is closer to L/GPL. Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and Synthesis _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Core Licenses Questions by jcastillo on Jan 6, 2005			jcastillo Posts: 32 Joined: Jun 29, 2004 Last seen: Dec 21, 2021
Hello: I think we should begin by setting the bases. The GPL license is based on the four freedoms enunciated by Richard Stallman. -The freedom to run the program, for any purpose. -The freedom to study how the program works, and adapt it to your needs. -The freedom to redistribute copies. -The freedom to improve the program, and release your improvements to the public, so that the whole community benefits The freedoms for a hardware design should be similar. -The freedom to implement the design, for any purpose. -The freedom to study how the design works, and adapt it to your needs. -The freedom to redistribute copies. -The freedom to improve the design, and release your improvements to the public, so that the whole community benefits Maybe it is necessary to add some others specifics for hardware designs. [q]From this base we can begin to write the license. [/q] [q]1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements[/q] [q]2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever[/q] I am agree with point 2, the license must be published in the cd when you use a open core. About the first point, I have an objection. I thought about it applied to OpenRISC 1200 and my conclusion was: a) You have to publish enhancements if those enhancements are described in the OR1000 architectural manual. For example, if someone takes the OR1200 and add to it the performance counters unit as described in the manual he should contribute back it. b) You don't have to contribute back if you add a new unit don't described in the manual or you enhance the core for your purposes. Best Regards Javier Castillo <A HREF="http://www.opencores.org/mailman/listinfo/cores">jcastillo at opensocdesign.com</A> www.opensocdesign.com -----Mensaje original----- De: <A HREF="http://www.opencores.org/mailman/listinfo/cores">cores-bounces at opencores.org</A> [mailto:<A HREF="http://www.opencores.org/mailman/listinfo/cores">cores-bounces at opencores.org</A>] En nombre de Rudolf Usselmann Enviado el: jueves, 06 de enero de 2005 10:35 Para: Discussion list about free open source IP cores Asunto: RE: [oc] Core Licenses Questions On Thu, 2005-01-06 at 06:48, jcastillo wrote: [q] Hi, I think it is clear that licenses derived from software ones, does not[/q] fit [q] with a hardware design license requirements. From the discussion we can assume that a BSD license seems to be more adequate to hardware designs[/q] than [q] a GPL one but it is not as good as it might be. IMHO it is time to write a new license to distribute open hardware[/q] designs, [q] we could call it, HGPL (Hardware General Public License). We can post in this forum our proposals and discuss them. Javier Castillo[/q] Perhaps we should start a lit of items we feel are important to have in a HGPL. Than we could hire an attorney to convert it in to legalese ... For example my list would start of with: 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever Perhaps we can take that as a start and add items till everybody (who is interested in a modified BSD style license) is happy ? I think we will see a big division on my #1 item. So we might have to create 2 flavors of the license. One that is totally permissive (BSD style) and perhaps a second one that is closer to L/GPL. 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 _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A> Hello: I think we should begin by setting the bases. The GPL license is based on the four freedoms enunciated by Richard Stallman. -The freedom to run the program, for any purpose. -The freedom to study how the program works, and adapt it to your needs. -The freedom to redistribute copies. -The freedom to improve the program, and release your improvements to the public, so that the whole community benefits The freedoms for a hardware design should be similar. -The freedom to implement the design, for any purpose. -The freedom to study how the design works, and adapt it to your needs. -The freedom to redistribute copies. -The freedom to improve the design, and release your improvements to the public, so that the whole community benefits Maybe it is necessary to add some others specifics for hardware designs. From this base we can begin to write the license. 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever I am agree with point 2, the license must be published in the cd when you use a open core. About the first point, I have an objection. I thought about it applied to OpenRISC 1200 and my conclusion was: a) You have to publish enhancements if those enhancements are described in the OR1000 architectural manual. For example, if someone takes the OR1200 and add to it the performance counters unit as described in the manual he should contribute back it. b) You don't have to contribute back if you add a new unit don't described in the manual or you enhance the core for your purposes. Best Regards Javier Castillo jcastillo at opensocdesign.com www.opensocdesign.com -----Mensaje original----- De: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] En nombre de Rudolf Usselmann Enviado el: jueves, 06 de enero de 2005 10:35 Para: Discussion list about free open source IP cores Asunto: RE: [oc] Core Licenses Questions On Thu, 2005-01-06 at 06:48, jcastillo wrote: Hi, I think it is clear that licenses derived from software ones, does not fit with a hardware design license requirements. From the discussion we can assume that a BSD license seems to be more adequate to hardware designs than a GPL one but it is not as good as it might be. IMHO it is time to write a new license to distribute open hardware designs, we could call it, HGPL (Hardware General Public License). We can post in this forum our proposals and discuss them. Javier Castillo Perhaps we should start a lit of items we feel are important to have in a HGPL. Than we could hire an attorney to convert it in to legalese ... For example my list would start of with: 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever Perhaps we can take that as a start and add items till everybody (who is interested in a modified BSD style license) is happy ? I think we will see a big division on my #1 item. So we might have to create 2 flavors of the license. One that is totally permissive (BSD style) and perhaps a second one that is closer to L/GPL. Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and Synthesis _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Core Licenses Questions by Unknown on Jan 6, 2005			Not available!
Rudolf Usselmann schrieb: [q] Perhaps we should start a lit of items we feel are important to have in a HGPL. Than we could hire an attorney to convert it in to legalese ... For example my list would start of with: 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever [/q] 3) GPL compability Philipp Rudolf Usselmann schrieb: Perhaps we should start a lit of items we feel are important to have in a HGPL. Than we could hire an attorney to convert it in to legalese ... For example my list would start of with: 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever 3) GPL compability Philipp

Core Licenses Questions by Unknown on Jan 6, 2005			Not available!
Philipp Klaus Krause wrote: [q] Rudolf Usselmann schrieb: [q] Perhaps we should start a lit of items we feel are important to have in a HGPL. Than we could hire an attorney to convert it in to legalese ... For example my list would start of with: 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever [/q] [/q] isn't 3 inconsistant with 1 and 2 here? [q] 3) GPL compability Philipp _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A>[/q] Philipp Klaus Krause wrote: Rudolf Usselmann schrieb: Perhaps we should start a lit of items we feel are important to have in a HGPL. Than we could hire an attorney to convert it in to legalese ... For example my list would start of with: 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever isn't 3 inconsistant with 1 and 2 here? 3) GPL compability Philipp _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Core Licenses Questions by Unknown on Jan 6, 2005			Not available!
[q]> > Perhaps we should start a lit of items we feel are [/q] important to have [q]> in a HGPL. Than we could hire an attorney to convert it in to > legalese ... > > For example my list would start of with: > > 1) Unrestricted use > a) No requirement to contribute back > b) No requirement to publish enhancements > > 2) Give Credit where credit is due > e.g. Duplicate This License in the user manual/cd/whatever >[/q] > [/q] isn't 3 inconsistant with 1 and 2 here?[/q] It is, but apparantly some people simply don't get it. I am guessing the point Philipp wants to make is that the HPL has to allow linking with other free licenses. So IF somebody wants to combine a core with an HPL and a GPL license, it should be possible without violating any of the used licenses. Everybody please, please keep in mind we're developing hardware, not software. So stop talking in software terms. As an addition to Rudi's points, we need to define a derivative work. In my opinion the final derivative work is a finished chip. The documentation of the chip should clearly provide credits and the disclaimer. So if anybody uses a chip containing open source IP on a board, the board's documentation does not need to provide credits and the disclaimer. Cheers, Richard [q] [q]> 3) GPL compability > > Philipp > _______________________________________________ > <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A>[/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A> [/q] > > Perhaps we should start a lit of items we feel are important to have > in a HGPL. Than we could hire an attorney to convert it in to > legalese ... > > For example my list would start of with: > > 1) Unrestricted use > a) No requirement to contribute back > b) No requirement to publish enhancements > > 2) Give Credit where credit is due > e.g. Duplicate This License in the user manual/cd/whatever > > isn't 3 inconsistant with 1 and 2 here? It is, but apparantly some people simply don't get it. I am guessing the point Philipp wants to make is that the HPL has to allow linking with other free licenses. So IF somebody wants to combine a core with an HPL and a GPL license, it should be possible without violating any of the used licenses. Everybody please, please keep in mind we're developing hardware, not software. So stop talking in software terms. As an addition to Rudi's points, we need to define a derivative work. In my opinion the final derivative work is a finished chip. The documentation of the chip should clearly provide credits and the disclaimer. So if anybody uses a chip containing open source IP on a board, the board's documentation does not need to provide credits and the disclaimer. Cheers, Richard > 3) GPL compability > > Philipp > _______________________________________________ > http://www.opencores.org/mailman/listinfo/cores _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Core Licenses Questions by Unknown on Jan 6, 2005			Not available!
On Thu, 2005-01-06 at 18:07, John Sheahan wrote: [q] Philipp Klaus Krause wrote: [q]> Rudolf Usselmann schrieb: > [q]> > Perhaps we should start a lit of items we feel are important > to have in a HGPL. Than we could hire an attorney to convert > it in to legalese ... > > For example my list would start of with: > > 1) Unrestricted use > a) No requirement to contribute back > b) No requirement to publish enhancements > > 2) Give Credit where credit is due > e.g. Duplicate This License in the user manual/cd/whatever >[/q] > [/q] isn't 3 inconsistant with 1 and 2 here? [q]> 3) GPL compability > > Philipp > _______________________________________________[/q] Yes, indeed, #3 is in direct contradiction with #1. Don't know about #2. 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 Thu, 2005-01-06 at 18:07, John Sheahan wrote: Philipp Klaus Krause wrote: > Rudolf Usselmann schrieb: > > > Perhaps we should start a lit of items we feel are important > to have in a HGPL. Than we could hire an attorney to convert > it in to legalese ... > > For example my list would start of with: > > 1) Unrestricted use > a) No requirement to contribute back > b) No requirement to publish enhancements > > 2) Give Credit where credit is due > e.g. Duplicate This License in the user manual/cd/whatever > > isn't 3 inconsistant with 1 and 2 here? > 3) GPL compability > > Philipp > _______________________________________________ Yes, indeed, #3 is in direct contradiction with #1. Don't know about #2. Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and Synthesis

Core Licenses Questions by RT on Jan 6, 2005			RT Posts: 10 Joined: Sep 2, 2009 Last seen: Sep 27, 2011
jcastillo wrote: [q] The freedoms for a hardware design should be similar. -The freedom to implement the design, for any purpose. -The freedom to study how the design works, and adapt it to your needs. -The freedom to redistribute copies. -The freedom to improve the design, and release your improvements to the public, so that the whole community benefits[/q] These principles are pretty much meaningless. You would have exactly the same effect if you simply released source code which was not copyrighted. The real issue with the various licences is what 'adapt it to your needs' actually means: 1) What constitutes 'adapting'? Does, for example, a bug fix constitute 'adapting'? Is the entire modified source file you own adaption, or is just the bug fix itself your own adaption? 2) Can you keep the adapted code secret? Can you keep the unadapted code secret as well, on the grounds that it is now simply a part of the adapted code? 3) If you incorporate unadapted code in your own design, are you obliged to release your own original work under the same licence? 4) If you incorporate adapted code in your own design, are you obliged to release your own original work under the same licence? The other significant issue is: 5) Does 'for any purpose' include 'for commercial gain'? However, this is missing the point. The problem is not freedoms, it's obligations: what obligations do you take on by accepting the licence? Instead of starting with freedoms, I'd suggest taking as a base point having no licence, and releasing code which is not copyrighted. This act itself specifies the allowed freedoms far more eloquently than any statement of principles. You could then, if you really wanted to (and I can personally see no real reason to do this), progressively add two classes of obligations: a) Your obligations if you 'use' the unmodified code b) Your obligations if you 'use' 'modified' code. However, if you want to start adding obligations, you need to start by stating exactly why you wish to place obligations on the user. Can anyone tell me why it is that they want to do this? Richard jcastillo wrote: The freedoms for a hardware design should be similar. -The freedom to implement the design, for any purpose. -The freedom to study how the design works, and adapt it to your needs. -The freedom to redistribute copies. -The freedom to improve the design, and release your improvements to the public, so that the whole community benefits These principles are pretty much meaningless. You would have exactly the same effect if you simply released source code which was not copyrighted. The real issue with the various licences is what 'adapt it to your needs' actually means: 1) What constitutes 'adapting'? Does, for example, a bug fix constitute 'adapting'? Is the entire modified source file you own adaption, or is just the bug fix itself your own adaption? 2) Can you keep the adapted code secret? Can you keep the unadapted code secret as well, on the grounds that it is now simply a part of the adapted code? 3) If you incorporate unadapted code in your own design, are you obliged to release your own original work under the same licence? 4) If you incorporate adapted code in your own design, are you obliged to release your own original work under the same licence? The other significant issue is: 5) Does 'for any purpose' include 'for commercial gain'? However, this is missing the point. The problem is not freedoms, it's obligations: what obligations do you take on by accepting the licence? Instead of starting with freedoms, I'd suggest taking as a base point having no licence, and releasing code which is not copyrighted. This act itself specifies the allowed freedoms far more eloquently than any statement of principles. You could then, if you really wanted to (and I can personally see no real reason to do this), progressively add two classes of obligations: a) Your obligations if you 'use' the unmodified code b) Your obligations if you 'use' 'modified' code. However, if you want to start adding obligations, you need to start by stating exactly why you wish to place obligations on the user. Can anyone tell me why it is that they want to do this? Richard

Core Licenses Questions by Unknown on Jan 6, 2005			Not available!
On Thu, 6 Jan 2005, John Sheahan wrote: [q] Philipp Klaus Krause wrote: [q]> Rudolf Usselmann schrieb: > [/q] B> >> 1) Unrestricted use [q]> a) No requirement to contribute back > b) No requirement to publish enhancements > > 2) Give Credit where credit is due > e.g. Duplicate This License in the user manual/cd/whatever >[/q] > [/q] isn't 3 inconsistant with 1 and 2 here? [q]> 3) GPL compability > [/q] [/q] No. A license can be quite different from the GPL, and still be either compatible or incompatible with it. See <A HREF="http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses">http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses</A> For example, the modified (normal, current) BSD license is compatible with the GPL, while the original BSD license was not since it had a clause insisting that you had to advertise the University of Berkeley if you used it. Avoiding incompatibility is important, whether or not you want a gpl-style license, as it allows someone using gpl-licensed cores to use yours as well. Graham [q]> Philipp [q]> _______________________________________________ > <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A>[/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A> [/q] On Thu, 6 Jan 2005, John Sheahan wrote: Philipp Klaus Krause wrote: > Rudolf Usselmann schrieb: > B> >> 1) Unrestricted use > a) No requirement to contribute back > b) No requirement to publish enhancements > > 2) Give Credit where credit is due > e.g. Duplicate This License in the user manual/cd/whatever > > isn't 3 inconsistant with 1 and 2 here? > 3) GPL compability > No. A license can be quite different from the GPL, and still be either compatible or incompatible with it. See http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses For example, the modified (normal, current) BSD license is compatible with the GPL, while the original BSD license was not since it had a clause insisting that you had to advertise the University of Berkeley if you used it. Avoiding incompatibility is important, whether or not you want a gpl-style license, as it allows someone using gpl-licensed cores to use yours as well. Graham > Philipp > _______________________________________________ > http://www.opencores.org/mailman/listinfo/cores _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Core Licenses Questions by Unknown on Jan 6, 2005			Not available!
John Sheahan schrieb: [q] Philipp Klaus Krause wrote: [q] Rudolf Usselmann schrieb: [q] Perhaps we should start a lit of items we feel are important to have in a HGPL. Than we could hire an attorney to convert it in to legalese ... For example my list would start of with: 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever [/q] [/q] isn't 3 inconsistant with 1 and 2 here? [q] 3) GPL compability Philipp[/q] It is inconsistent with 2. But since you aim to duplicate the BSD license, which is GPL compatible it shouldn't be hard to make this new license GPL compatible. If the license states no requirement to contribute back that doesn't mean that it has to prohibit relicensing under a license which requires to contribute back. Philipp John Sheahan schrieb: Philipp Klaus Krause wrote: Rudolf Usselmann schrieb: Perhaps we should start a lit of items we feel are important to have in a HGPL. Than we could hire an attorney to convert it in to legalese ... For example my list would start of with: 1) Unrestricted use a) No requirement to contribute back b) No requirement to publish enhancements 2) Give Credit where credit is due e.g. Duplicate This License in the user manual/cd/whatever isn't 3 inconsistant with 1 and 2 here? 3) GPL compability Philipp It is inconsistent with 2. But since you aim to duplicate the BSD license, which is GPL compatible it shouldn't be hard to make this new license GPL compatible. If the license states no requirement to contribute back that doesn't mean that it has to prohibit relicensing under a license which requires to contribute back. Philipp

Core Licenses Questions by Unknown on Jan 6, 2005			Not available!
Very good points indeed. [q] However, if you want to start adding obligations, you need to start by stating exactly why you wish to place obligations on the user. Can anyone tell me why it is that they want to do this?[/q] I see 2 reasons: 1. To protect the author from any claims. I do not want to go to court just because somebody took one of my cores, didn't check it, put in 10M$ to make some kind of chip, just to find out that I made a mistake somewhere (bug). Therefore my BSD style license is in fact a big disclaimer. 2. To get the author's name out. That's the only benefit an author can get from providing open source IP cores. Cheers, The other Richard :-) [q] Richard _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A> [/q] Very good points indeed. However, if you want to start adding obligations, you need to start by stating exactly why you wish to place obligations on the user. Can anyone tell me why it is that they want to do this? I see 2 reasons: 1. To protect the author from any claims. I do not want to go to court just because somebody took one of my cores, didn't check it, put in 10M$ to make some kind of chip, just to find out that I made a mistake somewhere (bug). Therefore my BSD style license is in fact a big disclaimer. 2. To get the author's name out. That's the only benefit an author can get from providing open source IP cores. Cheers, The other Richard :-) Richard _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Core Licenses Questions by Unknown on Jan 6, 2005			Not available!
[q] I am guessing the point Philipp wants to make is that the HPL has to allow linking with other free licenses. So IF somebody wants to combine a core with an HPL and a GPL license, it should be possible without violating any of the used licenses. [/q] Yes. Not everyone that published a core under the GPL or LGPL will relicense it under your new license. It would be strange to lock out the users of the GPL-licenses free cores from the use of cores under the new license, while users on nonfree cores my use them. Philipp I am guessing the point Philipp wants to make is that the HPL has to allow linking with other free licenses. So IF somebody wants to combine a core with an HPL and a GPL license, it should be possible without violating any of the used licenses. Yes. Not everyone that published a core under the GPL or LGPL will relicense it under your new license. It would be strange to lock out the users of the GPL-licenses free cores from the use of cores under the new license, while users on nonfree cores my use them. Philipp

Core Licenses Questions by nico on Jan 6, 2005			nico Posts: 21 Joined: Jun 21, 2008 Last seen: May 11, 2009
[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] Derivative work is defined in copyright law. "Linking concept" used in LGPL are more problematic because there is no such thing in hardware. Linus and RMS interprete the things differently. Linux is pure GPL but accept non-free module. Why ? because such module are not "derivative work" a work based on linux (nividia windows driver, fs form other OS,...) [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] [q]From the legal point of view, YOUR constomers are very well defined...[/q] [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] Look at Linux closed module. [q] [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. [/q] I have study a lot GPL/LGPL to find the best licence for the f-cpu project. Notice also that the european space agency have chose LGPL for LEON. I don't like so much LGPL. I prefer GPL with clearly defined API (wishbone bus, pins, amba bus,...). 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. Derivative work is defined in copyright law. "Linking concept" used in LGPL are more problematic because there is no such thing in hardware. Linus and RMS interprete the things differently. Linux is pure GPL but accept non-free module. Why ? because such module are not "derivative work" a work based on linux (nividia windows driver, fs form other OS,...) 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. From the legal point of view, YOUR constomers are very well defined... > 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". Look at Linux closed module. 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. I have study a lot GPL/LGPL to find the best licence for the f-cpu project. Notice also that the european space agency have chose LGPL for LEON. I don't like so much LGPL. I prefer GPL with clearly defined API (wishbone bus, pins, amba bus,...).

First

Prev

2/3

Next

Last

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