1/1 
|
licensing - design vs documentation
by amigabill on Sep 2, 2010 |
amigabill
Posts: 9 Joined: Dec 14, 2008 Last seen: Jan 11, 2012 |
||
|
I'm trying to learn a bit more about various licenses, and wonder about using different licenses for different parts of a project. I'd like to use LGPL 2.1 "or later" for the design, and maybe Gnu Free Documentation 1.2 for the specification and testplan etc. docs.
Has anyone used different licenses for different parts of a single project? Are LGPL 2.1+ and GFDL compatible in a single project repository/distribution? Any other benefits, problems, or misc comments? |
|||
|
RE: licensing - design vs documentation
by jeremybennett on Sep 3, 2010 |
jeremybennett
Posts: 689 Joined: May 29, 2008 Last seen: Feb 9, 2012 |
||
|
I'm trying to learn a bit more about various licenses, and wonder about using different licenses for different parts of a project. I'd like to use LGPL 2.1 "or later" for the design, and maybe Gnu Free Documentation 1.2 for the specification and testplan etc. docs.
Has anyone used different licenses for different parts of a single project? Are LGPL 2.1+ and GFDL compatible in a single project repository/distribution? Any other benefits, problems, or misc comments? Hi amigabill This probably isn't the best forum for such questions. You might get a richer response from something like the Open Source Initiative's license-discuss mailing list. However, with the caveat IANAL, here are some thoughts. There is no problems with using different licenses for different components of a project, so long as you make clear which license applies to which bit. It's quite normal to use GPL/LGPL for the code base and GFDL for the user guide. The only issue comes with things like machine generated documentation (using tools like Doxygen). That is a derivative work of the code (so covered by GPL/LGPL), so must be covered by the same license. So you can't then include that within a GFDL licensed user guide. This has been exercising the GCC guys considerably as they move towards embedded documentation. You may have a similar issue if you generate one part of the code in one way, and others in another way. For example if your RTL is LGPL, then presumably any schematics that come out at the end must be LGPL. If it's your own project, it's not a problem, since you own all the rights and you can choose to license any part, or your own derivative as you wish. You could probably make it work generally by incorporating a GFDL as well as LGPL in your code, although then you would lose some of the benefits of the LGPL, because people could reuse the code under the terms of the GFDL. At this point you really need to consult a specialist lawyer. Bear in mind that the GPL/LGPL were not intended for hardware use (the FSF FAQ is explicit about that), although it is often used for Verilog/VHDL designs. You may want to consder the merits of the TAPR OHL by John Ackermann as an alternative. HTH Jeremy
-- |
|||
|
RE: licensing - design vs documentation
by amigabill on Sep 3, 2010 |
amigabill
Posts: 9 Joined: Dec 14, 2008 Last seen: Jan 11, 2012 |
||
|
I wasn't expecting much in the way of deriving documentation from RTL. I'm first beginning a specification document, and if I'm good a testplan document, before writing any RTL. I've not used Doxygen before, but your point is good to know about that kind of thing.
I've tried asking questions to FSF, and got answer to one, but not the rest. As to whether they think GPL/LGPL are suitable for Verilog code, their reply:
While the LGPL and the GPL talk about things like object files and
linking, they are also general enough so that they are successfully applied to all kinds of other languages. Very few languages need customized versions of these licenses. What we usually find is that the particularly unusual languages can get away with using the generic LGPL/GPL with the addition of an extra permission. But most of the time when the concept of "source" (as in "source code") makes sense, we find the LGPL/GPL suitable. Do you have a specific problem in mind that would prevent these licenses from working with verilog programs? I'll ask at OSI licensing discussion as well as you suggested. |
|||
|
RE: licensing - design vs documentation
by jeremybennett on Sep 4, 2010 |
jeremybennett
Posts: 689 Joined: May 29, 2008 Last seen: Feb 9, 2012 |
||
|
Hi Bill, I saw your question on the OSI mailing list. I think they will give you a wider range of views than the FSF, which has limited resources for this sort of thing. The problem is not Verilog, but that you are producing hardware. All the GNU licenses are based on the law of copyright, and the concept of publishing, which is well established, and reasonably consistent between jurisdictions. The problem is when a chip is manufactured. Making a chip from your Verilog and distributing it is probably not publication, so there would be no obligation to supply source code, nor distribute any changes. Of course if the manufacturer also supplied a simulation model built from your RTL, then the GPL/LGPL would work just fine. That's why the GPL FAQ says it is not suitable for hardware. HTH Jeremy |
|||
|
RE: licensing - design vs documentation
by nussgipfel on Sep 17, 2010 |
nussgipfel
Posts: 12 Joined: Apr 12, 2007 Last seen: Jun 9, 2011 |
||
|
The problem is not Verilog, but that you are producing hardware. All the GNU licenses are based on the law of copyright, and the concept of publishing, which is well established, and reasonably consistent between jurisdictions. The problem is when a chip is manufactured. Making a chip from your Verilog and distributing it is probably not publication, so there would be no obligation to supply source code, nor distribute any changes. Of course if the manufacturer also supplied a simulation model built from your RTL, then the GPL/LGPL would work just fine. That's why the GPL FAQ says it is not suitable for hardware. Two or three years ago I started a similar discussion here on opencores when we where in the process to decide how to license our GECKO3 project which contains all sorts of work (c code, vhdl code, schematics, pcb files, documentation incl. images etc.). my view at this time was that the GPL 3 was written with a wider scope, not only software, but in the discussion this view was not shared. as jeremy writes, the problem is mainly the implementation into a chip and also, not mentiont yet, patents. the patent part was, as i understood, a main concern for the "open hardware license" (TAPR OHL). for our project in the end, we choose the creative commons licensing system (CC) as it covers all sorts of work. but still chip implementation and patents is out of scope but i still think that you have some benefits compared to the gpl. first you have one license for your design and documentation, so the problem with automatic created documentation parts does not exist. further and more important is that, as i understand, the creative commons "attribution" license part means that every time and for everything where you use the licensed work or parts of it you have to show the name/source of the work you used. so in my opinion, when you build a chip with CC licensed parts you have to clearly show what you used (in the public available datasheet for example). still i'm not a lawyer and we are more or less the first ones who used CC for a hardware project, as i know, so not much experience exists. |
|||
1/1