Genode FPGA graphics project launched
Matthias Alles
Genode FX is a composition of hardware and software that enables the
creation of fully fledged graphical user interfaces as system-on-chip
solutions using commodity FPGAs, e.g., Xilinx' low-cost Spartan3 series.
The integrated solution complements the Microblaze soft core with custom
hardware for interconnecting display and input devices. On the software
side, the heart of the project is a complete GUI software stack
especially tailored to resource-constrained embedded systems. In
addition to leveraging the Microblaze architecture, support for the PPC
core as featured in high-end Virtex5 FPGAs is on the way. This prospect
makes Genode FX a solution that scales with the demands of current and
future applications. The release features a complete demonstration
project ready to use with widely popular Spartan3A Starter Kit boards.
To learn more about Genode FX visit:
http://www.genode-labs.com/products/fpga-graphics
To download Genode FX sourcecode and demo project visit:
https://sourceforge.net/projects/genode-fx/
Matthias
Jon Beniston
Looks interesting. Would the LGPL license be more appropriate though?
For example, can you legally distribute a project based on the GPLed
Genode that also uses MicroBlaze/NIOS, as doing so would presumably
require you to provide the MicroBlaze source as well, which will
obviously be a problem.
Jon
nfeske
> Looks interesting. Would the LGPL license be more appropriate though?
> For example, can you legally distribute a project based on the GPLed
> Genode that also uses MicroBlaze/NIOS, as doing so would presumably
> require you to provide the MicroBlaze source as well, which will
> obviously be a problem.
According to the License text, the terms about the modification and
distribution of GPL'ed source code apply only to derivative work,
which is work that takes GPL source code as a starting point. The
Microblaze is clearly not derived work because it does not depend in
any way on the components Genode FX provides.
Regards
Norman
Jon Beniston
Using GPLed code means that all code in a project must be open source.
No proprietary stuff. Anything that uses Genode is a derived work. If
you want to allow use with proprietary code, then the LGPL should be
used.
See here: http://www.gnu.org/philosophy/why-not-lgpl.html
"The GNU Project has two principal licenses to use for libraries. One
is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice
of license makes a big difference: using the Lesser GPL permits use of
the library in proprietary programs; using the ordinary GPL for a
library makes it available only for free programs."
Jon
Antti
if you claim that then you can equally force Xilinx to release source
code of the microblaze
because the mb gcc is GPL licensed and not LPGL licensed
not always ALL project sources are needed to be made public if GPL
based part are
used in the project
depend how you define project and library
i can say its ALL one projects and microblaze is one VHDL library what
is linked to the
stuff compiled with GPL licensed tools, so microblaze also needs to be
GPL, etc..
i think the Xilinx lawer disagree with that
but in generic the GPLxxx stuff is not really applicable today for
FPGA ip cores and related stuff
Antti
nfeske
> No proprietary stuff. Anything that uses Genode is a derived work. If
> you want to allow use with proprietary code, then the LGPL should be
> used.
>
> See here:http://www.gnu.org/philosophy/why-not-lgpl.html
That discussion is going on for ages, for example about binary
graphics drivers in the Linux kernel. I am with the interpretation by
Linus Torvalds that GPL code that is linked to independent (!)
proprietary code does not infect this proprietary code, which is just
common sense. If however, you build a system that depends on GPL
components and you distribute your system, your additions must be
released as GPL. So it is not as easy as "no proprietary stuff" ;-)
In any case, Genode Labs offers proprietary licensing options in
addition to the GPL version of Genode FX. For using Genode FX in a
proprietary product, I suggest to contact Genode Labs directly.
Regards
Norman
Jon Beniston
> code of the microblaze
> because the mb gcc is GPL licensed and not LPGL licensed
Not at all. GCC is not linked with Microblaze.
> not always ALL project sources are needed to be made public if GPL
> based part are
> used in the project
Correct. Its only if they are linked together.
> depend how you define project and library
> i can say its ALL one projects and microblaze is one VHDL library what
> is linked to the
> stuff compiled with GPL licensed tools, so microblaze also needs to be
> GPL, etc..
I'm not refering the s/w parts of this project - but the VHDL/Verilog
core that gets linked in.
> but in generic the GPLxxx stuff is not really applicable today for
> FPGA ip cores and related stuff
It is if IP cores are being released under the GPL.
Jon
Jon Beniston
> graphics drivers in the Linux kernel. I am with the interpretation by
> Linus Torvalds that GPL code that is linked to independent (!)
> proprietary code does not infect this proprietary code, which is just
> common sense.
Well, that argument is based on the fact that the proprietary code
isn't statically linked. That is not the case in an FPGA or ASIC. Much
easier to just use the LGPL so there is no confusion, IMHO.
Jon
David Brown
It's *not* easier to use the LGPL - it is almost equally unsuitable.
The GPL says (roughly) that any code that is directly linked to the
GPL'ed code must also be GPL'ed. You can't use GPL'ed IP and non-GPL'ed
IP in the same FPGA.
The LGPL is a little lighter - it allows you to link the LGPL'ed code
with non-GPL'ed code as long as anyone with the binary is able to get
the source code to the LGPL part, modify it, re-link it, and use the new
version. This is fine for things like dynamically linked libraries on a
desktop OS (that's what it was designed for), but hardly practical for
FPGA IP!
A better choice of license would be what is known as a "modified GPL" or
"GPL with exception" license (or the very similar Mozilla Public
License). Here the GPL is explicitly modified to apply only to the
source files provided - you are free to link them in any way to any
other modules under any other license. This basically means you can use
the modified GPL files as you like, but if you change them you have to
give these changes back to the community.
See <http://www.freertos.org/a00114.html> for an example of this for an
embedded RTOS.
MikeWhy
news:0d15ddf8-ebfd-4863...@25g2000hsx.googlegroups.com...
Yes, and it seems pretty clear. The code you build on top of Genode is
GPL'ed. The underlying stuff that Genode in turn uses -- Microblaze, or even
the FPGA fabric -- is not. The LGPL would differ by allowing your code,
which uses Genode, to remain proprietary. The situation is clearer to see in
more "traditional" software projects. For example, distributing a GPL'ed
library doesn't infer also distributing the Windows operating system source.
Jon Beniston
> > is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice
> > of license makes a big difference: using the Lesser GPL permits use of
> > the library in proprietary programs; using the ordinary GPL for a
> > library makes it available only for free programs."
>
> Yes, and it seems pretty clear. The code you build on top of Genode is
> GPL'ed. The underlying stuff that Genode in turn uses -- Microblaze, or even
> the FPGA fabric -- is not.
If MicroBlaze was a hard-core, then maybe I'd agree. However, as a
soft-core, to me, it's the same as linking with a library.
Can a GPLed program run on a proprietary CPU and O/S? Yes. Can it link
in a proprietary library? No.
I would have thought the logical conclusion would therefore be that a
GPLed FPGA bitstream can run on a proprietary FPGA, but can't link in
proprietary soft IP cores.
Jon
Jon Beniston
> GPL'ed code must also be GPL'ed. You can't use GPL'ed IP and non-GPL'ed
> IP in the same FPGA.
Ok, I think we agree here.
> The LGPL is a little lighter - it allows you to link the LGPL'ed code
> with non-GPL'ed code as long as anyone with the binary is able to get
> the source code to the LGPL part, modify it, re-link it, and use the new
> version. This is fine for things like dynamically linked libraries on a
> desktop OS (that's what it was designed for), but hardly practical for
> FPGA IP!
You don't have to supply the modified code with the FPGA though. I'm
sure a web download would be suitable.
> A better choice of license would be what is known as a "modified GPL" or
> "GPL with exception" license (or the very similar Mozilla Public
> License). Here the GPL is explicitly modified to apply only to the
> source files provided
What happens if someone modifies a file to use a function that is in a
new file though? Do they have to provide this?
Jon
MikeWhy
>> > "The GNU Project has two principal licenses to use for libraries. One
>> > is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice
>> > of license makes a big difference: using the Lesser GPL permits use of
>> > the library in proprietary programs; using the ordinary GPL for a
>> > library makes it available only for free programs."
>>
>> Yes, and it seems pretty clear. The code you build on top of Genode is
>> GPL'ed. The underlying stuff that Genode in turn uses -- Microblaze, or
>> even
>> the FPGA fabric -- is not.
>
> If MicroBlaze was a hard-core, then maybe I'd agree. However, as a
> soft-core, to me, it's the same as linking with a library.
If that were so, Genode would be required to GPL Microblaze, and our
troubles would already be solved. We would just refer everyone else to
Genode for the Microblaze code.
>
> Can a GPLed program run on a proprietary CPU and O/S? Yes. Can it link
> in a proprietary library? No.
>
> I would have thought the logical conclusion would therefore be that a
> GPLed FPGA bitstream can run on a proprietary FPGA, but can't link in
> proprietary soft IP cores.
Is the intent of the GPL to prohibit physical distribution on the same media
as proprietary components? I think not. I can store GPL components on the
same hard disk as I store unrelated components, proprietary or otherwise.
Their presence in the same bitstream ... is complicated by the difference
between general computing and embedded systems. I'm tending to agree with
you that (my superficial understanding of) the license terms leaves it gray
and muddy.
If a proprietary component puts a signal on a wire, and I arranged for a
GPL'ed component to read that signal, am I in violation of the GPL? Does
that constitute "linking with"?
If my GPL'ed component reads signals from disparate sources, proprietary or
otherwise, would I be in violation of the GPL by generating signals
specifically targetted for the GPL'ed GUI?
If I sell a proprietary solution that generated signals compatible with a
GPL component, would the end user be in violation of the GPL by "linking"
the two into a single bitstream?
For the same proprietary system, is it a violation of the GPL if it came
already "linked" with the GPL component in a single bitstream?
Kolja Sulimma
wrote:
> The LGPL is a little lighter - it allows you to link the LGPL'ed code
> with non-GPL'ed code as long as anyone with the binary is able to get
> the source code to the LGPL part, modify it, re-link it, and use the new
> version. This is fine for things like dynamically linked libraries on a
> desktop OS (that's what it was designed for), but hardly practical for
> FPGA IP!
Why not? There is no need to be able to do this dynamically. If you
can do it with the usual FPGA toolflow everything is in order.
In the software world there has been a long discussion about what
linking
means. For the hardware world this is completely in the open. When
using
GPLed IP, must other FPGA IP in the same project be under GPL? (Very
likely.)
But how about the board layout? (Maybe) How about software running on
a GPLed
processor (following the dynamic linking debate this probably is a yes
for software
stored in the bitstream and a no for software loaded later).
I think that anyone who uses a software license for hardware should
clarify what
this means when applied to hardware. Just write an appendix to the
license.
After all the creator of the work is free to license under any terms
he likes, he is
not bound by the FSFs view of the world.
And yes, if you want to use it together with EDK, the LGPL is the
better starting point
than the GPL.
Kolja Sulimma
> > If MicroBlaze was a hard-core, then maybe I'd agree. However, as a
> > soft-core, to me, it's the same as linking with a library.
>
> If that were so, Genode would be required to GPL Microblaze, and our
> troubles would already be solved. We would just refer everyone else to
> Genode for the Microblaze code.
No. GPL prohibits linking with non GPL code, that is a fact. Compiling
an
FPGA bitstream that contains both Genode and non GPL Xilinx Cores is
therefore a violation of Genodes GPL license.
This does not mean that the Xilinx Cores suddenly fall under the GPL.
It only means that the creators of Genode do not allow you to create
such a
bitstream. (Violators face multiple years in prison in most
countries.)
Norman writes that this is not what he intended, so he probably
should
change the license.
As I interpret the LPGL it provides exactly the desired effects:
Modifications
to Genode must be made publicly available, but all other cores in the
system can have any license including the Vendor license.
Kolja Sulimma
Eric Smith
> No. GPL prohibits linking with non GPL code, that is a fact. Compiling
> an
> FPGA bitstream that contains both Genode and non GPL Xilinx Cores is
> therefore a violation of Genodes GPL license.
Only if the resulting bitstream is distributed. You can do it in the
privacy of your own home all you want.
David Brown
>> The GPL says (roughly) that any code that is directly linked to the
>> GPL'ed code must also be GPL'ed. You can't use GPL'ed IP and non-GPL'ed
>> IP in the same FPGA.
>
> Ok, I think we agree here.
>
>> The LGPL is a little lighter - it allows you to link the LGPL'ed code
>> with non-GPL'ed code as long as anyone with the binary is able to get
>> the source code to the LGPL part, modify it, re-link it, and use the new
>> version. This is fine for things like dynamically linked libraries on a
>> desktop OS (that's what it was designed for), but hardly practical for
>> FPGA IP!
>
> You don't have to supply the modified code with the FPGA though. I'm
> sure a web download would be suitable.
>
Technically, according to the letter of the GPL 2, a web download alone
is not enough (it was considered too unreliable at the time the GPL2 was
written), but the GPL 3 allows it. It's a minor quibble, of course.
But what is important for using the LGPL is that the user (or anyone who
legally acquires the binary) must have access to everything they need to
modify the LGPL'ed code and produce a new binary, or exactly the same
binary as the original. In the software world, this means that the rest
of the program must be available as a linkable object - easy if you have
an OS and the LGPL'ed code is a dynamic library. It must also be
possible for the user to download their binary into the system. It's
okay if the tools to do this cost money, as long as the user is free to
buy them - I don't think you'd have to provide any Microblaize IP, as
that's a standard library with the tools. But you'd have to include
compiled versions of all your own IP, possibly also third party IP, and
things like pin layout files. And if the bitstream is to be encrypted,
you have a new set of issues...
All in all, the LGPL is very impractical for embedded systems.
>> A better choice of license would be what is known as a "modified GPL" or
>> "GPL with exception" license (or the very similar Mozilla Public
>> License). Here the GPL is explicitly modified to apply only to the
>> source files provided
>
> What happens if someone modifies a file to use a function that is in a
> new file though? Do they have to provide this?
>
I don't think so - there is no requirement that your modified m-GPL'ed
code can work without the rest of your system. The aim is to codify the
idea that the package you got under the m-GPL is a community effort -
you can use it as you want, but can't claim you wrote it, and if you
extend or improve it, these changes must be available to others. It has
always struck me as a very fair license giving the best of both worlds
(it can be used freely even in commercial systems, but enforces more
"freeness" than BSD-style licenses).
David Brown
This is very important - publishers should always give a statement of
the aim or "spirit" of their license, as well as the legal stuff.
Sometimes these are contradictory (I've seen software given out with the
GPL "so that anyone can use it in their code"), but mostly it helps. In
particular, especially in the FPGA field, a clear indication of what the
author means by "linking" and "derivative works" is vital.
> And yes, if you want to use it together with EDK, the LGPL is the
> better starting point than the GPL.
>
As you say, there have been plenty of discussions and debates around
linking and derivative works regarding the GPL/LGPL, and there are
plenty of opinions when it comes to the grey areas (such as binary
modules in the Linux kernel) and use outside "ordinary" software (such
as for FPGA IP). The LGPL is certainly a better starting point than the
GPL - but it is still not a good choice of license. With a clear enough
statement of the intent of the license, it might be okay - but otherwise
it's better to pick a license that is clearer to start with.
Of course, the author is free to pick whatever license they want. In
this particular case, the author has chosen a dual license - GPL (which
basically allows free academic, testing and evaluation usage), and a
commercial license with no issues about linking or distribution.
MikeWhy
news:2fc35801-55fe-4fa0...@e39g2000hsf.googlegroups.com...
> On 28 Aug., 18:24, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
>> > If MicroBlaze was a hard-core, then maybe I'd agree. However, as a
>> > soft-core, to me, it's the same as linking with a library.
>>
>> If that were so, Genode would be required to GPL Microblaze, and our
>> troubles would already be solved. We would just refer everyone else to
>> Genode for the Microblaze code.
>
> No. GPL prohibits linking with non GPL code, that is a fact. Compiling
> an
> FPGA bitstream that contains both Genode and non GPL Xilinx Cores is
> therefore a violation of Genodes GPL license.
> This does not mean that the Xilinx Cores suddenly fall under the GPL.
> It only means that the creators of Genode do not allow you to create
> such a
> bitstream. (Violators face multiple years in prison in most
> countries.)
That's pretty messed up. Are you stating it as an authoritative
interpretation of the GPL? Or are you, like me, musing about its possible
meaning?
From GPL3:
[[ The “System Libraries” of an executable work include anything, other than
the work as a whole, that (a) is included in the normal form of packaging a
Major Component, but which is not part of that Major Component, and (b)
serves only to enable use of the work with that Major Component, or to
implement a Standard Interface for which an implementation is available to
the public in source code form. A “Major Component”, in this context, means
a major essential component (kernel, window system, and so on) of the
specific operating system (if any) on which the executable work runs, or a
compiler used to produce the work, or an object code interpreter used to run
it.
The “Corresponding Source” for a work in object code form means all the
source code needed to generate, install, and (for an executable work) run
the object code and to modify the work, including scripts to control those
activities. However, it does not include the work's System Libraries, or
general-purpose tools or generally available free programs which are used
unmodified in performing those activities but which are not part of the
work. For example, Corresponding Source includes interface definition files
associated with source files for the work, and the source code for shared
libraries and dynamically linked subprograms that the work is specifically
designed to require, such as by intimate data communication or control flow
between those subprograms and other parts of the work.
]]
Kolja Sulimma
> "Kolja Sulimma" <ksuli...@googlemail.com> wrote in message
One essential question is what "the work" is in this case. To me it is
pretty clear
that the bitstream is the work. The work can't be only part of the
bitstream, because
the parts can't be seperated easily. The IP inside a bitstream has a
much tighter coupling
than statically linked code has.
It could be more than the bitstream (e.g. including the board
schematics and layout),
because of the "major component" clause that you cite as there
generally is no
publicly available implementation that allows to run your bitstream.
As you cite "[the source] does not include [stuff] which are not part
of the work."
GPL requires available sourcecode for everything that is part of the
work.
The reason for the LGPL to exist ist that sometimes this approach is
not practical
and you need to allow components in the work that are covered by other
licenses.
If that was possible with the GPL the LGPL would be redundant.
Kolja
MikeWhy
> On 29 Aug., 18:37, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>> "Kolja Sulimma" <ksuli...@googlemail.com> wrote in message
>
>
> One essential question is what "the work" is in this case. To me it is
> pretty clear
> that the bitstream is the work. The work can't be only part of the
> bitstream, because
> the parts can't be seperated easily. The IP inside a bitstream has a
> much tighter coupling
> than statically linked code has.
>
> It could be more than the bitstream (e.g. including the board
> schematics and layout),
> because of the "major component" clause that you cite as there
> generally is no
> publicly available implementation that allows to run your bitstream.
Separating "the work" from the bitstream is conceptually no more difficult
than deleting or uninstalling an application from a harddrive. From the
user's point of view, the file's location and representation on a harddrive
is equally opaque as it is inside a bitstream. The work's presence in a
bitstream does not introduce new concepts or difficulties in regards GPL.
I read the GPL to cover no more than the .ELF which includes my custom code,
and the supplied display IP along with my derived enhancements. Their
inclusion in the bitstream is incidental in the same way that a device
driver or application is incidental when present in the boot image of a
general purpose computer. The presence of a proprietary operating system and
other components in the boot image in no way violates the GPL terms for
using or distributing that device driver or application. The presence of
other IPs in the same bitstream does not violate the terms or intent of the
GPL for Genode.
By way of example, suppose I write an application that reads Excel
spreadsheets, and displays its results using a GPL'ed library. I would like
to distribute the application under LGPL terms. However, the additional
permissiveness is meaningless, because the GPL library would not be
available to those wishing to produce a proprietary derived work. Otherwise,
my choices have absolutely no implications for any of the involved
components, including the GPL'ed library, Excel, and Windows.
Similarly, if I build a signal processing system and use GPL'ed Genode for
user interaction, I am bound by Genode's GPL terms, which prohibits
proprietary use. However, GPL has no implications for the proprietary
Ethernet or PCI IP's used elsewhere in the system.
I'll submit that a system consisting only of Genode in its bitstream is of
no practical use to anyone or application. The stated intent of the GPL is
to induce free developemnt and distribution by limiting use of covered works
to only non-proprietary applications. It would be utterly self-defeating to
pre-suppose that eventually someone will build a free board design and
develop free IP around its use, to permit its use.
> As you cite "[the source] does not include [stuff] which are not part
> of the work."
> GPL requires available sourcecode for everything that is part of the
> work.
>
> The reason for the LGPL to exist ist that sometimes this approach is
> not practical
> and you need to allow components in the work that are covered by other
> licenses.
> If that was possible with the GPL the LGPL would be redundant.
The LGPL differs mainly by permitting use and distribution in proprietary
systems, while the GPL does not. Perhaps this is the author's intent;
perhaps it is not. It would be duplicitous to coerce him into this direction
under the guise of reasonable use, when the GPL already sufficiently allows
its use, presuming for the moment that it does and that this is his intent.
Bear in mind my layman status in the opinions above. I too would very much
like to hear authoritative clarification (although the license wording seems
reasonably clear already).
Kolja Sulimma
> "Kolja Sulimma" <ksuli...@googlemail.com> wrote in message
>
> I read the GPL to cover no more than the .ELF which includes my custom code,
> and the supplied display IP along with my derived enhancements. Their
> inclusion in the bitstream is incidental in the same way that a device
> driver or application is incidental when present in the boot image of a
> general purpose computer.
But a propriatary EDK project is no general purpose computer.
I agree, that if you have a pure software project you could probably
treat it as a
seperate work from the hardware design. (That's what it is all about:
What
constitued "the work".) But as the hardwarearchitecture you are
running it on
is proprietrary you also must supply at least the edk system
definition files.
"The “Corresponding Source” for a work in object code form means all
the
source code needed to generate, install, and (for an executable work)
run
the object code." [...]
"However, it does not include the work's System Libraries, or
general-purpose tools or generally available free programs which are
used
unmodified in performing those activities but which are not part of
the
work. "
See the formulation "generally available" which does not hold for your
own
EDK design. The GPL is about anybody beeing able to recreate the work.
Someone who wants to do that might need to spend some money (e.g.
buying EDK) but you can't require them to do reverse engineering on
the
hardware architecture it is running on.
Kolja Sulimma
David Brown
> "Kolja Sulimma" <ksul...@googlemail.com> wrote in message
> news:2fc35801-55fe-4fa0...@e39g2000hsf.googlegroups.com...
>> On 28 Aug., 18:24, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>>
>>> > If MicroBlaze was a hard-core, then maybe I'd agree. However, as a
>>> > soft-core, to me, it's the same as linking with a library.
>>>
>>> If that were so, Genode would be required to GPL Microblaze, and our
>>> troubles would already be solved. We would just refer everyone else to
>>> Genode for the Microblaze code.
>>
>> No. GPL prohibits linking with non GPL code, that is a fact. Compiling
>> an
>> FPGA bitstream that contains both Genode and non GPL Xilinx Cores is
>> therefore a violation of Genodes GPL license.
>> This does not mean that the Xilinx Cores suddenly fall under the GPL.
>> It only means that the creators of Genode do not allow you to create
>> such a
>> bitstream. (Violators face multiple years in prison in most
>> countries.)
>
> That's pretty messed up. Are you stating it as an authoritative
> interpretation of the GPL? Or are you, like me, musing about its
> possible meaning?
>
The GPL is a license based on copyright laws - I don't believe you can
face "multiple years in prison" for breaking it. My understanding
(IANAL) is that you will need to be at the level of serious economic
crime before it becomes a criminal offence, and thereby risk jail. The
normal result of court cases around the GPL is that the violator must
stop violating (i.e., remove the code from their product, or make all
the required GPL'ed code available), promise not to violate the GPL in
the future, and pay some monetary compensation. That's been testing in
courts in a number of countries, although AFAIK that's only been for
complete works (such as busybox) rather than testing the meaning of
"derived works" or "linking" in court.
It's also important to note that the GPL covers distribution only - you
are perfectly within your rights to mix and match GPL'ed code with any
other code you like (assuming the other code's license is okay with
this), as long as it is for your own use or use inside your
organisation. You only have to consider the GPL when distributing the code.
The GPL3 excerpt you quoted is in the GPL3, but not the GPL2 - it's one
of the differences, and that makes it important to know which GPL
version is under consideration (if code uses a standard GPL of any
version, you can "upgrade" it to a newer version if you want). Does the
Microblaize count as a "system library" in an FPGA?
I believe (my own thoughts) that in an FPGA design, generating and
compiling modules is equivalent to compilation in software, and routing
and placing is equivalent to static linking. If there are components
that are isolated and communicate through standard and fixed interfaces,
then it could be argued that these are separate "works" and not part of
a complete "derived work", and the GPL/LGPL will not spread across the
interface. But the opposite could also be argued - the router and
placer software will dig into components on each side of the interface,
and the implementation of these components will depend on each other.
This of course gives you a more efficient bitstream - but it means that
the final bitstream cannot be split into separate parts and is therefore
a single combined "work".
All in all, I would not distribute an FPGA design which includes GPL or
LGPL code without an explicit statement from the copyright owner saying
exactly how they interpret the GPL in this case.
Andreas Ehliar
> I believe (my own thoughts) that in an FPGA design, generating and
> compiling modules is equivalent to compilation in software, and routing
> and placing is equivalent to static linking. If there are components
> that are isolated and communicate through standard and fixed interfaces,
> then it could be argued that these are separate "works" and not part of
> a complete "derived work", and the GPL/LGPL will not spread across the
> interface. But the opposite could also be argued - the router and
> placer software will dig into components on each side of the interface,
> and the implementation of these components will depend on each other.
> This of course gives you a more efficient bitstream - but it means that
> the final bitstream cannot be split into separate parts and is therefore
> a single combined "work".
First of all: Thanks to Genode Labs for releasing this source code under
an open source license! I hope this initiative will bring you lot of
goodwill and customers!
However, I have a few things to say regarding open source and hardware.
The license question for open source hardware is a pretty interesting one.
I feel that there are many questions here such as the one you list above.
My personal belief is that it is not legally possible to distribute a
design which contains both components under GPL and components under a more
restrictive license.
Regarding your comments about standard interfaces: A GPL program which
calls a proprietary library using a standardized calling convention
specified in the ABI can not be legally distributed AFAIK. (Ignoring the
system library exception.)
Some things to think on:
http://www.bitlaw.com/copyright/maskwork.html
Someone has actually gone to the trouble of making a license for hardware:
http://technocrat.net/d/2007/2/5/14355 <-- Some interesting discussion
regarding a draft version of this license.
http://www.tapr.org/ohl.html <-- A page with the complete license (follow
the links on the top)
Unfortunately the hardware license above is not aimed at HDL code according
to the author.
Another hardware license is the one included in Opencores' DDR SDRAM
controller: http://www.opencores.org/projects.cgi/web/ddr_sdr/overview
(Unfortunately I cannot link directly to the license file as Opencores now
requires you to register to look at files in the CVS repository.)
I'm not sure how much thought that went into the creation of this license
and I'm therefore not willing to use it myself without reading the opinion
of a lawyer about it.
My personal belief is that there might be some problems with GPL as a license
for HDL code. On the other hand, Sun has released OpenSparc under the GPL
which I see as a clear indication that the GPL is a viable license for
hardware. See http://www.opensparc.net/faqs/licensing/ for what they think
this means in a hardware design. (They are using GPLv2 at the moment.)
/Andreas
David Brown
> On 2008-09-01, David Brown <da...@westcontrol.removethisbit.com> wrote:
>> I believe (my own thoughts) that in an FPGA design, generating and
>> compiling modules is equivalent to compilation in software, and routing
>> and placing is equivalent to static linking. If there are components
>> that are isolated and communicate through standard and fixed interfaces,
>> then it could be argued that these are separate "works" and not part of
>> a complete "derived work", and the GPL/LGPL will not spread across the
>> interface. But the opposite could also be argued - the router and
>> placer software will dig into components on each side of the interface,
>> and the implementation of these components will depend on each other.
>> This of course gives you a more efficient bitstream - but it means that
>> the final bitstream cannot be split into separate parts and is therefore
>> a single combined "work".
>
> First of all: Thanks to Genode Labs for releasing this source code under
> an open source license! I hope this initiative will bring you lot of
> goodwill and customers!
>
> However, I have a few things to say regarding open source and hardware.
> The license question for open source hardware is a pretty interesting one.
> I feel that there are many questions here such as the one you list above.
> My personal belief is that it is not legally possible to distribute a
> design which contains both components under GPL and components under a more
> restrictive license.
>
In this case, the main aim of Genode Labs is almost certainly that
people can download the IP, examine it, play with it, try it out, and
use it for testing or academic work - but they can't sell products using
it until they buy a commercial license from Genode Labs. You are also
free to modify the code and pass it around - but only under the GPL.
This sort of dual-licensing is popular in the software world - it is
very nice for users, developers and experimenters, with minimal risk to
the company (there will always be some people who download the GPL code
and use it illegally - but they are unlikely to have paid for a
legitimate license if there were no GPL version available).
> Regarding your comments about standard interfaces: A GPL program which
> calls a proprietary library using a standardized calling convention
> specified in the ABI can not be legally distributed AFAIK. (Ignoring the
> system library exception.)
>
That's basically correct, AFAIU (ignoring, as you say, the system
library exception).
>
> Some things to think on:
> http://www.bitlaw.com/copyright/maskwork.html
>
> Someone has actually gone to the trouble of making a license for hardware:
> http://technocrat.net/d/2007/2/5/14355 <-- Some interesting discussion
> regarding a draft version of this license.
> http://www.tapr.org/ohl.html <-- A page with the complete license (follow
> the links on the top)
>
> Unfortunately the hardware license above is not aimed at HDL code according
> to the author.
>
> Another hardware license is the one included in Opencores' DDR SDRAM
> controller: http://www.opencores.org/projects.cgi/web/ddr_sdr/overview
> (Unfortunately I cannot link directly to the license file as Opencores now
> requires you to register to look at files in the CVS repository.)
> I'm not sure how much thought that went into the creation of this license
> and I'm therefore not willing to use it myself without reading the opinion
> of a lawyer about it.
>
>
> My personal belief is that there might be some problems with GPL as a license
> for HDL code. On the other hand, Sun has released OpenSparc under the GPL
> which I see as a clear indication that the GPL is a viable license for
> hardware. See http://www.opensparc.net/faqs/licensing/ for what they think
> this means in a hardware design. (They are using GPLv2 at the moment.)
>
Sun is a company with a long history of love/hate relationships with
open source and licenses, so their choices are never a good indication
of anything. On the one hand they will donate a great deal of code and
resources to open source projects like Open Office - on the other hand,
they released the ZFS code under their own CDL license making it open
source and yet unusable with the Linux kernel. The choice of the GPL
for the OpenSparc is similar - it effectively restricts its use to
evaluation and academic work.
Jon Beniston
> for the OpenSparc is similar - it effectively restricts its use to
> evaluation and academic work
Not if they used the LGPL, it isn't.
Jon
Andreas Ehliar
> Sun is a company with a long history of love/hate relationships with
> open source and licenses, so their choices are never a good indication
> of anything.
What I meant was that Sun's choice is a clear indication that they expect
the GPL to work correctly for hardware even though it is originally
designed as a copyright license for software.
/Andreas
David Brown
They use the GPLv2, not the LGPL.
One other point that I did not mention earlier for both GPL'ed code and
LGPL'ed code is that it is perfectly possible to make and sell devices
that use GPL'ed IP - as long as *all* the IP in the device is GPL'ed.
I think it is very reasonable to say that the bitstream for a single
FPGA device is a single "work", and that the license for that "work" is
not affected by the licenses of any other "work", including other FPGA
designs and software running on the FPGA, at least as long as you are
talking about a complete design with a specific interface.
Thus it is quite possible to use, for example, the OpenSparc
commercially in an FPGA - as long as the rest of your code on the same
device is also GPL'ed. When the GPL'ed IP already forms a major part of
your design, this will make perfect sense. The trouble only comes if
you want most of your design to have a closed source license, with only
parts of it under the (L)GPL.
The main difference between the LGPL and GPL is commonly summarised as
saying that you can dynamically link code of any license with LGPL'ed
code. You can't statically link non-(L)GPL'ed code with LGPL'ed code.
This has been discussed and argued back and forth in the world of
embedded software for years before it was a major topic in FPGA design,
and the conclusion is that very few embedded software developers will
touch LGPL'ed code unless they are happy with a completely open source
program, or their system is large enough to support a more general OS
with dynamic linking (such as an embedded Linux system) - for statically
linked software, the LGPL and GPL are the same. Since placing and
routing in an FPGA is directly equivalent to static linking in software,
I can't see that there is any distinction between them.
Some links showing other people's opinions on the use of the LGPL in
embedded software:
<http://lists.kde.org/?l=kde-policies&m=103813752610289&w=2>
<http://listas.apesol.org/pipermail/sdl-libsdl.org/2006-January/053814.html>
Jon Beniston
> > Not if they used the LGPL, it isn't.
>
> They use the GPLv2, not the LGPL.
Yep - my mistake.
> The main difference between the LGPL and GPL is commonly summarised as
> saying that you can dynamically link code of any license with LGPL'ed
> code. You can't statically link non-(L)GPL'ed code with LGPL'ed code.
> This has been discussed and argued back and forth in the world of
> embedded software for years before it was a major topic in FPGA design,
> and the conclusion is that very few embedded software developers will
> touch LGPL'ed code unless they are happy with a completely open source
> program, or their system is large enough to support a more general OS
> with dynamic linking (such as an embedded Linux system) - for statically
> linked software, the LGPL and GPL are the same. Since placing and
> routing in an FPGA is directly equivalent to static linking in software,
> I can't see that there is any distinction between them.
So partial reconfiguration in an FPGA to load the the LGPLed code
would be ok?
Jon
David Brown
That would be fine, as far as I can tell. The idea is that the end user
should be able to get hold of the source code for the LGPL'ed part,
modify it (or get an updated version), and use that modified version in
the complete system. If you can arrange for that to be possible using
partial reconfiguration, that should be okay.
glen herrmannsfeldt
(snip)
> The work can't be only part of the bitstream,
> because the parts can't be seperated easily.
> The IP inside a bitstream has a much tighter coupling
> than statically linked code has.
I am not so sure. Maybe logically, but not necessarily
legally. With some amount of work, you might be able
to generate a bitstream not containing certain parts
of the logic, and a bitstream that could be combined
with it that would generate the final result.
That might require more details of the bitstream
than are normally available, but that doesn't mean
it can't be done as far as the legal system is
concerned.
-- glen
MikeWhy
news:48bf9105$0$25395$8404...@news.wineasy.se...
> Jon Beniston wrote:
>>> The choice of the GPL
>>> for the OpenSparc is similar - it effectively restricts its use to
>>> evaluation and academic work
>>
>> Not if they used the LGPL, it isn't.
>>
>
> They use the GPLv2, not the LGPL.
>
> One other point that I did not mention earlier for both GPL'ed code and
> LGPL'ed code is that it is perfectly possible to make and sell devices
> that use GPL'ed IP - as long as *all* the IP in the device is GPL'ed.
GPL, or equivalent license. The only requirement is the end user can build
the system without paying someone for licenses.
>
> I think it is very reasonable to say that the bitstream for a single FPGA
> device is a single "work", and that the license for that "work" is not
> affected by the licenses of any other "work", including other FPGA designs
> and software running on the FPGA, at least as long as you are talking
> about a complete design with a specific interface.
The GPL specifically excludes "mere aggregation ... on a volume of a storage
or distribution medium" from consideration. But you don't have to fight that
battle to determine reasonable use. The bitstream is a distribution medium.
However, that alone does not release the conveyor from the GPL's terms.
The real issue is conveying the work if the end user cannot examine the
work, modify it, and build it into a working system. The presence of other
licensed IPs precludes distributing the modified work. He would have to
license the other IPs in order to build and distribute the system. This is
relevant in manufacturing scenarios, where the "work" is typically
incorporated into the ROM of the presumably commercial hardware product. The
issue is not the distribution medium, but licensing terms for the other,
more restrictive IPs.
This has no consequence for the single user. He may freely compile the
GPL'ed source into his own work, if he is otherwise able to do so. (Hmmm.
The EDK is not free. Microblaze and MPMC are licensed for use with the EDK.
Is this an issue for GPL terms? I think not, but that can be a discussion
point.)
Anyway... Genode specifically makes the distinction between open source and
commercial use in their license terms. The bitstream aspect is not a special
case for GPL, and does not introduce new difficulties. Genode's stated
intent was that you may examine the work, extend it as you wish, and convey
the changes if you like as an open source work. They address commercial
licensing terms separately. LGPL is not suitable for their intents. By
releasing under LGPL, they essentially relinquish their commercial rights,
which they expressly wish to hold.
David Brown
> "David Brown" <da...@westcontrol.removethisbit.com> wrote in message
> news:48bf9105$0$25395$8404...@news.wineasy.se...
>> Jon Beniston wrote:
>>>> The choice of the GPL
>>>> for the OpenSparc is similar - it effectively restricts its use to
>>>> evaluation and academic work
>>>
>>> Not if they used the LGPL, it isn't.
>>>
>>
>> They use the GPLv2, not the LGPL.
>>
>> One other point that I did not mention earlier for both GPL'ed code
>> and LGPL'ed code is that it is perfectly possible to make and sell
>> devices that use GPL'ed IP - as long as *all* the IP in the device is
>> GPL'ed.
>
> GPL, or equivalent license. The only requirement is the end user can
> build the system without paying someone for licenses.
>
I don't think the GPL allows for mixing GPL code with "equivalent"
licenses, although it is certainly possible (and not uncommon) to mix it
with code that is dual licensed so that you are allowed to treat the
code as pure GPL (the LGPL, for example, explicitly allows that).
However, that's perhaps nitpicking. The point is, as you said, that the
end user can view, modify, rebuild and distribute the code without other
licenses (although they may have to pay a small handling fee to get the
source code, and may have to pay for the tools).
>>
>> I think it is very reasonable to say that the bitstream for a single
>> FPGA device is a single "work", and that the license for that "work"
>> is not affected by the licenses of any other "work", including other
>> FPGA designs and software running on the FPGA, at least as long as you
>> are talking about a complete design with a specific interface.
>
> The GPL specifically excludes "mere aggregation ... on a volume of a
> storage or distribution medium" from consideration. But you don't have
> to fight that battle to determine reasonable use. The bitstream is a
> distribution medium. However, that alone does not release the conveyor
> from the GPL's terms.
>
The bitstream is not just the "distribution medium" - it is also the
"program". It is the equivalent of the elf or exe file as well. (If
you have code for two or more FPGA's in the same bitstream, then these
are obviously "mere aggregates".) To be aggregates, you must be able to
separate the parts, use them separately, and replace them separately.
> The real issue is conveying the work if the end user cannot examine the
> work, modify it, and build it into a working system. The presence of
> other licensed IPs precludes distributing the modified work. He would
> have to license the other IPs in order to build and distribute the
> system. This is relevant in manufacturing scenarios, where the "work" is
> typically incorporated into the ROM of the presumably commercial
> hardware product. The issue is not the distribution medium, but
> licensing terms for the other, more restrictive IPs.
>
That's certainly a major issue, yes.
> This has no consequence for the single user. He may freely compile the
> GPL'ed source into his own work, if he is otherwise able to do so.
> (Hmmm. The EDK is not free. Microblaze and MPMC are licensed for use
> with the EDK. Is this an issue for GPL terms? I think not, but that can
> be a discussion point.)
>
IP and code that comes with the standard Xilinx tools will count as
"standard system libraries", and can be freely used with GPL'ed code in
the same way as software on Windows uses the windows headers, or
software written in Python uses the Python libraries (which are not
GPL'ed, but have their own open source license). Whether or not the
Microblaze is a "standard system library" could certainly be discussed.
It's that sort of thing that makes it so important to have an informal
but clear "clarification statement" along with a license. For example,
Linux has a statement making it perfectly clear that programs that use
the Linux API are in no way "derived works", and are unaffected by the
GPL in the kernel (there is no such statement surrounding binary
drivers, and thus plenty of discussion there!).
> Anyway... Genode specifically makes the distinction between open source
> and commercial use in their license terms. The bitstream aspect is not a
> special case for GPL, and does not introduce new difficulties. Genode's
> stated intent was that you may examine the work, extend it as you wish,
> and convey the changes if you like as an open source work. They address
> commercial licensing terms separately. LGPL is not suitable for their
> intents. By releasing under LGPL, they essentially relinquish their
> commercial rights, which they expressly wish to hold.
>
Yes, I think the full GPL is the correct choice for Genode in this case,
although as I said before I don't think the LGPL would be any different
legally. However, since the LGPL is in many ways harder to understand
(look at this thread here), the full GPL is a better choice here.
Matthias Alles
Just a short update:
Yesterday I released a new version that supports for the first time the
PPC440 in the Virtex5 FXT. A demo running out of the box on the ML507
board is also included. The GUI runs quite well on the PPC that is
clocked at 300 MHz. The resolution in this demo is 1024x768.
In case somebody is present at the FPL'08 in Heidelberg these days:
My research group presents a demonstrator that is entirely controlled by
Genode FX. The demonstrator shows an application-specific
instruction-set processor (ASIP) for channel coding (convolutional and
turbo coding) running on the ML507.
To learn more about Genode FX visit:
http://www.genode-labs.com/products/fpga-graphics
To download Genode FX sourcecode and demo projects visit:
https://sourceforge.net/projects/genode-fx/
Matthias