[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] Inquiry
John Dalton <john.dalton@bigfoot.com> a écrit :
> [This piece has turned out to be lengthy, but hopefully there
> is enough interesting stuff in it, especially the second half,
> to make it worth reading. Given the length of this piece,
> I am explicitly claiming copyright on it and releasing it
> under the terms of the free documentation license with no
> invariant sections. I don't want this copyright claim to affect discussion
> on this list, but if someone distributes this outside the cores list
> I expect the license terms to be explicitly mentioned.
>
> Copyright (c) 2003 John Dalton.
> Permission is granted to copy, distribute and/or modify this document
> under the terms of the GNU Free Documentation License, Version 1.2
> or any later version published by the Free Software Foundation;
> with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
> Texts.
> A copy of the license is available at the URL
> http://www.gnu.org/licenses/fdl.html
> ]
>
> > (from my point of view, GPL with specific API for closed
> > code (like for the linux kernel and it's proprietary
> > modules), is the best licence, ...
>
> I'm not sure exactly what you mean here, but I think you
> are talking about closing the source of a module,
> publishing the API, and linking the closed module
> with GPL'd code. Please correct me if I have misunderstood you.
>
That's the opposite :) Publish the "open cores" in GPL with some restrictions from the original one. Why ? Because there is no OS in hardware world. A simple GPL core imply that the whole design will be under GPL which is a killing for compagnies. You can run proprietary code under linux, so i think you should use proprietary core beside open one.
I say to use GPL with some restriction well describe here :
http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface
I think it's better than LGPL, because LGPL is very weak to say what is in the library or not (what is inside or outside the scope of the licence after a modification, for example)
API in HDL could be very well defined ! So as for linux kernel, you have to specify : "this entities could be connected to proprietary code". That's simple and clean. Scope are well defined.
There isn't any more problem of the definition of linking.
> As a first step to trying to solve this problem, I suggest
> we think of some case studies and try to figure out in
> each case whether linking occurs. **The following are
> purely my opinion.** I WANT people to refute my arguments
> and propose logical alternatives.
>
>
> Example 1 (an easy one):
> I take two modules and use an HDL compiler to produce
> a single executable, which simulates the system when run.
>
> I would argue that the two modules are statically linked,
> in exactly the same way as a computer program (since the
> binary is one). Hence if one of the modules is covered
> by the GPL, I must distribute the HDL for both modules
> with the binary.
>
yep. Too restrictive from my point of view.
>
> Example 2 (a harder one)
> I take two modules and use an HDL compiler to produce
> separate binary libraries of each. I have a simulation
> engine running as a server on another workstation. I get
> the simulation engine to run a simulation, calling each
> module over a network as required.
>
That's a way to plague the licence. Not fair but not very easy to do.
> I would argue that the two modules are probably not linked
> (Note that I'm not 100% certain.), provided the interface
> to the simulation engine is well documented. I would think
> that each module is acting as a self contained program,
> communicating over a network. In this case, if I distribute
> the simulation binaries, I only need to distribute the HDL
> for the GPL'd parts of the system.
>
>
> Example 3:
> I take two modules and use a synthesiser to produce
> a bit stream for a single FPGA.
>
> I would argue that the FPGA bitstream is an example of
> a statically linked program, so if you distribute
> a copy of the bitstream you must also provide the
> HDL for both modules.
>
> Some difficult points in this argument.
>
> Is the bitstream covered by copyright (and so covered by the GPL)?
It's a result of a transformation of the "prefered form of work". So GPL apply like for binaries in SW.
>
>
> Example 4:
> I take two modules and use a synthesiser to produce
> a single design file for an ASIC.
>
> I would argue that if a single design file is
> produced that it is a form of statically linked
> program and source for all modules must be distributed
> with the design file.
>
> Once the design file is turned into an ASIC, I would
> think that it becomes a device and is no longer covered
> by copyright. Hence the GPL does not apply and there
> is no legal obligation to distribute HDL with the ASIC
> (it hurts me to say this!)
GPL don't cover object, BUT those object are a result of copyrigthed material (there are "a derivative of the preferef forme of work"), so GPL apply also (i had ask the question to a lawyer).
> These arguments are leading me to believe that the GPL is a very
> good license for opencores!
>
http://www.gnu.org/licenses/gpl-faq.html#GPLOtherThanSoftware
could help also, to understand where GPL is possible to use.
nicO
> Thoughts on all this please!
>
> Regards
> John
>
>
> --
> To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml
___________________________________
Webmail Nerim, http://www.nerim.net/
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml