GNU Lesser Public License and Soft IP

Discussion in 'VHDL' started by moogyd, Oct 9, 2009.

  1. moogyd

    moogyd Guest

    Hi,

    I am looking through the GNU Lesser General Public License (LGPL) and
    trying to understand how it applies to H/W i.e. Using the vhdl or
    verilog IP in one of our products.

    I have seen where it is stated that IP's license under LGPL can be
    used in propriety products, but I don't know how one comes to this
    conclusion from reading the LGPL.

    Specifically, the license talks about linking with a library, deriving
    from a library etc.

    My understanding is (from a simple example):

    There is an soft macro IP named LGPL_IP and an IP named GPL_IP

    - I can use LGPL_IP in my product PRODUCT_A without restriction
    - LGPL_IP will be used in a compiled (synthesized)
    - I *do not* need to make PRODUCT_A available under LGPL
    - If I modify LGPL_IP source code, I need to make the changes
    available under LGPL ?
    - Do I need to include a copyright notice relating to LGPL_IP in the
    documentation for PRODUCT_A (if it relates to LGPL_IP operation?)

    - I can use GPL_IP in my product PRODUCT_B without restriction
    - GPL_IP will be used in a compile form (syntheised)
    - I *do* need to make PRODUCT_B available under GPL (as source if
    someone reqests)
    - If I modify LGPL_IP source code, I need to make the changed
    available under GPL

    - In both cases, there is no warranty or liability

    Can anyone state (or suggest) exactly exactly which section of the
    LGPL is applicable to this case ?

    Thanks,

    Steven
    moogyd, Oct 9, 2009
    #1
    1. Advertising

  2. In comp.lang.verilog moogyd <> wrote:

    < I am looking through the GNU Lesser General Public License (LGPL) and
    < trying to understand how it applies to H/W i.e. Using the vhdl or
    < verilog IP in one of our products.

    < I have seen where it is stated that IP's license under LGPL can be
    < used in propriety products, but I don't know how one comes to this
    < conclusion from reading the LGPL.

    My understanding is that the usual use is for libraries, such
    as the C library. Without the LGPL you couldn't distribute compiled
    C programs (for example) because of the included library routines.
    (Well, you could but you would have to distribute source, too.)

    < Specifically, the license talks about linking with a library,
    < deriving from a library etc.

    I don't know the details, but that is its main use.

    -- glen
    glen herrmannsfeldt, Oct 9, 2009
    #2
    1. Advertising

  3. Hello Steven,

    > I am looking through the GNU Lesser General Public License (LGPL) and
    > trying to understand how it applies to H/W i.e. Using the vhdl or
    > verilog IP in one of our products.
    >
    > I have seen where it is stated that IP's license under LGPL can be
    > used in propriety products, but I don't know how one comes to this
    > conclusion from reading the LGPL.


    You should keep in mind that the (L)GPL licenses were primarily written
    with software designs in mind. As such, not all terminology maps well
    to hardware designs.

    The main difference between the GPL and the LPGL is that embedding GPL
    code within your design requires you to make your entire design available
    under the GPL, while LGPL only requires you to make the LGPL code and any
    changes you make to the LGPL code available under the LGPL. As such, you're
    allowed to embed LGPL code into your proprietary product as long as you keep
    the embedded design and all changes to it available under the LGPL.

    Embedding (L)GPL code into your design is a matter of deciding how the
    cost of building said code by yourself weighs against compliance with
    the (L)GPL license.

    Kind regards,

    Pieter Hulshoff
    Pieter Hulshoff, Oct 12, 2009
    #3
  4. moogyd

    Rich Webb Guest

    On Mon, 12 Oct 2009 09:28:25 +0200, Pieter Hulshoff <>
    wrote:

    >Hello Steven,
    >
    >> I am looking through the GNU Lesser General Public License (LGPL) and
    >> trying to understand how it applies to H/W i.e. Using the vhdl or
    >> verilog IP in one of our products.
    >>
    >> I have seen where it is stated that IP's license under LGPL can be
    >> used in propriety products, but I don't know how one comes to this
    >> conclusion from reading the LGPL.

    >
    >You should keep in mind that the (L)GPL licenses were primarily written
    >with software designs in mind. As such, not all terminology maps well
    >to hardware designs.
    >
    >The main difference between the GPL and the LPGL is that embedding GPL
    >code within your design requires you to make your entire design available
    >under the GPL, while LGPL only requires you to make the LGPL code and any
    >changes you make to the LGPL code available under the LGPL.


    That's correct only if the application can be supplied as an object
    module that dynamically links to the LGPL code. If that's not possible
    (and I'm not sure how it could be in any HDL environment) then
    sufficient source code must be supplied to allow an interested user to
    recreate the application with the current or a modified version of the
    LGPL code. See Section 4.d of the LGPL. As you say, it's aimed at a
    conventional software model.

    --
    Rich Webb Norfolk, VA
    Rich Webb, Oct 12, 2009
    #4
  5. Rich Webb wrote:
    > On Mon, 12 Oct 2009 09:28:25 +0200, Pieter Hulshoff <>
    > wrote:
    >
    >> Hello Steven,
    >>
    >>> I am looking through the GNU Lesser General Public License (LGPL) and
    >>> trying to understand how it applies to H/W i.e. Using the vhdl or
    >>> verilog IP in one of our products.
    >>>
    >>> I have seen where it is stated that IP's license under LGPL can be
    >>> used in propriety products, but I don't know how one comes to this
    >>> conclusion from reading the LGPL.

    >> You should keep in mind that the (L)GPL licenses were primarily written
    >> with software designs in mind. As such, not all terminology maps well
    >> to hardware designs.
    >>
    >> The main difference between the GPL and the LPGL is that embedding GPL
    >> code within your design requires you to make your entire design available
    >> under the GPL, while LGPL only requires you to make the LGPL code and any
    >> changes you make to the LGPL code available under the LGPL.

    >
    > That's correct only if the application can be supplied as an object
    > module that dynamically links to the LGPL code. If that's not possible
    > (and I'm not sure how it could be in any HDL environment) then
    > sufficient source code must be supplied to allow an interested user to
    > recreate the application with the current or a modified version of the
    > LGPL code. See Section 4.d of the LGPL. As you say, it's aimed at a
    > conventional software model.



    An encrypted hierarchical netlist with the LGPL module as separate non-encrypted
    hierarchy combined with the source code may do it. Note that this only needs to
    be supplied to actual users of your chip; not to the public at large. Still, it's
    probably easier to contact the copyright holders of the LGPL module to get a
    separate license or explanation to this part. I doubt a developer puts an LGPL
    license on a module with the idea that it could never be used within a non-GPL
    environment.

    Kind regards,

    Pieter Hulshoff
    Pieter Hulshoff, Oct 12, 2009
    #5
  6. moogyd

    moogyd Guest

    Hi,

    Thanks for all the feedback.

    This is obviously quite complex :-(, and there seems to be no correct
    answer.

    Additional feedback I received was that there is a significant
    difference between H/W and S/W.
    - S/W Can be copyrighted
    - H/W Cannot be copyrighted - it can only be patented.

    The link is

    http://www.febo.com/law/Ackermann_Open_Source_Hardware_Article_2009.pdf

    GPL is based on copyright law, and this doesn't apply to H/W. Since I
    am targeting an ASIC (it's all I deliver), (L)GPL no longer applies,
    so I should be alright.

    (I will also contact the copyright holder and check their
    understanding)

    Anyway, thanks again for the feedback,

    Steven
    moogyd, Oct 16, 2009
    #6
  7. moogyd

    jm l Guest

    On 16 oct, 16:50, moogyd <> wrote:
    > GPL is based on copyright law, and this doesn't apply to H/W. Since

    I
    > am targeting an ASIC (it's all I deliver), (L)GPL no longer applies,
    > so I should be alright.


    I think that's wrong.
    For example, a CD containing software is just a piece of hardware, but
    it's content is copyrighted.
    Your ASIC contains a "copy" of the LGPL software, so you must conform
    to the LGPL license.

    But I'm not a lawyer...
    jm l, Oct 16, 2009
    #7
  8. moogyd wrote:
    > Additional feedback I received was that there is a significant
    > difference between H/W and S/W.
    > - S/W Can be copyrighted
    > - H/W Cannot be copyrighted - it can only be patented.
    >
    > The link is
    >
    > http://www.febo.com/law/Ackermann_Open_Source_Hardware_Article_2009.pdf
    >
    > GPL is based on copyright law, and this doesn't apply to H/W. Since I
    > am targeting an ASIC (it's all I deliver), (L)GPL no longer applies,
    > so I should be alright.


    The (L)GPL is a license delivered with the copyrighted VHDL/Verilog design.
    As such, you can use it within the boundaries of the license, or adhere
    to copyright law. Wether the resulting ASIC is copyrighted/patented/etc. is
    not relevant towards the usage of the copyrighted VHDL/Verilog code. As the
    article you mentioned indicated:
    "There is nothing in the copyright law to stop one from implementing the
    circuit – in other words, the idea – described by a schematic diagram, even
    if that diagram is clearly subject to copyright."
    This implies that copyright still applies to part of the design process even
    if the end-result (the ASIC) does not. The main difficulty however is that
    the (L)GPL terminology doesn't map very well to the hardware so the best thing
    is usually to contact the copyright holders, and ask them what you are and
    are not allowed to do with their code.

    Kind regards,

    Pieter Hulshoff
    Pieter Hulshoff, Oct 19, 2009
    #8
  9. moogyd

    moogyd Guest

    On 19 Oct, 11:20, Pieter Hulshoff <> wrote:
    > moogyd wrote:
    > > Additional feedback I received was that there is a significant
    > > difference between H/W and S/W.
    > > - S/W Can be copyrighted
    > > - H/W Cannot be copyrighted - it can only be patented.

    >
    > > The link is

    >
    > >http://www.febo.com/law/Ackermann_Open_Source_Hardware_Article_2009.pdf

    >
    > > GPL is based on copyright law, and this doesn't apply to H/W. Since I
    > > am targeting an ASIC (it's all I deliver), (L)GPL no longer applies,
    > > so I should be alright.

    >
    > The (L)GPL is a license delivered with the copyrighted VHDL/Verilog design.
    > As such, you can use it within the boundaries of the license, or adhere
    > to copyright law. Wether the resulting ASIC is copyrighted/patented/etc. is
    > not relevant towards the usage of the copyrighted VHDL/Verilog code. As the
    > article you mentioned indicated:
    > "There is nothing in the copyright law to stop one from implementing the
    > circuit – in other words, the idea – described by a schematic diagram, even
    > if that diagram is clearly subject to copyright."
    > This implies that copyright still applies to part of the design process even
    > if the end-result (the ASIC) does not. The main difficulty however is that
    > the (L)GPL terminology doesn't map very well to the hardware so the best thing
    > is usually to contact the copyright holders, and ask them what you are and
    > are not allowed to do with their code.
    >
    > Kind regards,
    >
    > Pieter Hulshoff


    Hi Peter,

    You are correct in that the mapping to H/W (and the H/W design flow)
    is not defined, and therefore we cannot be sure about anything. I
    would therefore have difficulty recommending the use of LGPL IP within
    any products within our company.

    I have contacted the copyright holder, and we are currently in
    discussions about the best way to proceed.

    Thanks for you comments,

    Steven
    moogyd, Oct 19, 2009
    #9
  10. moogyd

    moogyd Guest

    On 16 Oct, 17:08, jm l <> wrote:
    > On 16 oct, 16:50, moogyd <> wrote:
    >  > GPL is based on copyright law, and this doesn't apply to H/W. Since
    > I
    >
    > > am targeting an ASIC (it's all I deliver), (L)GPL no longer applies,
    > > so I should be alright.

    >
    > I think that's wrong.
    > For example, a CD containing software is just a piece of hardware, but
    > it's content is copyrighted.
    > Your ASIC contains a "copy" of the LGPL software, so you must conform
    > to the LGPL license.
    >
    > But I'm not a lawyer...


    Hi,

    The CD analogy is incorrect. The CD containing the S/W contains the
    copyrighted material (in a digital form), and this would also apply to
    the verilog (or VHDL) source, and even the netlist (?).

    In my opinion (and from what I have read), Copyright (and therefore
    GPL) does not apply to H/W.

    e.g. If I design a fantastic new type of Widget, I own the copyright
    of the technical drawings. However, there is *nothing* in law to
    prevent you (or anyone else) taking this drawing and producing this
    new type of Widget.
    I would only have protection if I had patented the design.

    (I am also not a lawyer, and this is my understanding).

    My conclusion from this investigation is that LGPL is probably *not*
    OK if you want to keep your end products and company secrets secret
    (there are too many question marks over interpretation).

    Thanks,

    Steven

    p.s. Please don't take this thread as "big corporation takes community
    effort for profit". As a company, we would probably be happy to return
    improvements we made to the IP back to the community, but we cannot
    afford to take the risk that someone would have access to our
    unrelated IP
    moogyd, Oct 19, 2009
    #10
  11. moogyd wrote:
    > e.g. If I design a fantastic new type of Widget, I own the copyright
    > of the technical drawings. However, there is *nothing* in law to
    > prevent you (or anyone else) taking this drawing and producing this
    > new type of Widget.


    Actually, there is! There is nothing preventing you from making a clean
    room reverse engineering of the drawing (which I admit is relatively easy
    compared to most reverse engineering), but producing by copying is still
    in violation of copyright. It's just harder to deal with in a court of law
    (that's aside from a widget being art, and thus covered by other parts of
    copyright law as well).

    With regards to an ASIC: there's nothing in copyright law preventing you
    from taking my (L)GPL code, and doing a clean room reverse engineering of
    said code, but if you use it as direct input for your design process
    without adhering to the license, you're still in violation of copyright
    law. Not by distributing the chip, but simply as part of your design process.

    In general though, you should also consider what's more costly to your company:
    designing the (L)GPL code by yourself or using it and adhere to the license. If
    it's 90% of your design effort, then you should wonder how much you're protecting
    anyway, and if it's 10% of your design effort, then you should seriously consider
    writing your own implementation.

    Kind regards,

    Pieter Hulshoff
    Pieter Hulshoff, Oct 19, 2009
    #11
  12. In comp.lang.verilog moogyd <> wrote:
    (snip, someone wrote)
    >> > am targeting an ASIC (it's all I deliver), (L)GPL no longer applies,
    >> > so I should be alright.


    >> I think that's wrong.
    >> For example, a CD containing software is just a piece of hardware, but
    >> it's content is copyrighted.
    >> Your ASIC contains a "copy" of the LGPL software, so you must conform
    >> to the LGPL license.


    >> But I'm not a lawyer...


    I am also not a lawyer.

    The one I remember is that patent protects the idea, copyright
    protects the expression of the idea.

    > The CD analogy is incorrect. The CD containing the S/W contains the
    > copyrighted material (in a digital form), and this would also apply to
    > the verilog (or VHDL) source, and even the netlist (?).


    > In my opinion (and from what I have read), Copyright (and therefore
    > GPL) does not apply to H/W.


    I don't see any problem with copyrighting hardware, but the protection
    is weak. Someone can generate a new expression of the same idea
    and get around it. Considering the "look and feel" discussed some
    years ago, one might, for example, copyright a front panel design
    for some hardware. Moving the controls around and changing the
    color might get around that, but it would protect against exact
    copies of the original.

    > e.g. If I design a fantastic new type of Widget, I own the copyright
    > of the technical drawings. However, there is *nothing* in law to
    > prevent you (or anyone else) taking this drawing and producing this
    > new type of Widget.


    In copyright sense, that would be a new expression of the idea.
    Well, I think you have to be a little careful. One couldn't copy
    the drawings while building the new widget, but if they bought
    a copy then they could create all the widgets from it that
    they wanted to.

    > I would only have protection if I had patented the design.


    Consider the case that someone patented the murder mystery.
    (I have no idea if that has or hasn't been done.) That would
    restrict story writing for years to come. Copyrighting one
    protects that specific mystery but allows others to write
    different ones.

    > (I am also not a lawyer, and this is my understanding).


    > My conclusion from this investigation is that LGPL is probably *not*
    > OK if you want to keep your end products and company secrets secret
    > (there are too many question marks over interpretation).


    It might work in some situations. It would be a little more
    restrictive that public domain, for example.

    -- glen
    glen herrmannsfeldt, Oct 19, 2009
    #12
  13. In comp.lang.verilog Pieter Hulshoff <> wrote:
    > moogyd wrote:
    >> e.g. If I design a fantastic new type of Widget, I own the copyright
    >> of the technical drawings. However, there is *nothing* in law to
    >> prevent you (or anyone else) taking this drawing and producing this
    >> new type of Widget.


    > Actually, there is! There is nothing preventing you from making a clean
    > room reverse engineering of the drawing (which I admit is relatively easy
    > compared to most reverse engineering), but producing by copying is still
    > in violation of copyright. It's just harder to deal with in a court of law
    > (that's aside from a widget being art, and thus covered by other parts of
    > copyright law as well).


    As usual, I am not a lawyer. It seems to me that you could buy a
    copy of the copyrighted drawings and create widgets as different
    expressions of the same idea. You couldn't copy the drawings, though.

    > With regards to an ASIC: there's nothing in copyright law preventing you
    > from taking my (L)GPL code, and doing a clean room reverse engineering of
    > said code, but if you use it as direct input for your design process
    > without adhering to the license, you're still in violation of copyright
    > law. Not by distributing the chip, but simply as part of your design process.


    But the whole idea for the LGPL is that it does allow copying.
    Mostly it is for system libraries which get copied into the output
    file by the linker, pretty much (in the copyright sense) unchanged.

    I would say that you could use an LGPL verilog module in your
    design in the same way one uses a C library routine when compiling
    with GCC. The LGPL is needed to allow distribution of GCC compiled
    output. If one modified the LGPL module then one would have
    to release the source for that module, which might be okay.

    For a GPL module, one would have to go through the clean room
    implementation, but not for the LGPL module.

    > In general though, you should also consider what's more costly to
    > your company: designing the (L)GPL code by yourself or using it
    > and adhere to the license. If it's 90% of your design effort,
    > then you should wonder how much you're protecting anyway, and if
    > it's 10% of your design effort, then you should seriously consider
    > writing your own implementation.


    -- glen
    glen herrmannsfeldt, Oct 19, 2009
    #13
  14. glen herrmannsfeldt wrote:
    > I would say that you could use an LGPL verilog module in your
    > design in the same way one uses a C library routine when compiling
    > with GCC. The LGPL is needed to allow distribution of GCC compiled
    > output. If one modified the LGPL module then one would have
    > to release the source for that module, which might be okay.



    The main problem with the LGPL and hardware lies in clause 4d (see
    http://www.gnu.org/copyleft/lesser.html for details). It's a clause
    that makes a lot of sense when applied to software, but none when
    applied to hardware. It's up to the copyright holders how to wish
    to apply this clause when it comes to hardware.

    Kind regards,

    Pieter Hulshoff
    Pieter Hulshoff, Oct 20, 2009
    #14
  15. moogyd

    ajjc Guest

    On Oct 19, 11:48 pm, Pieter Hulshoff <> wrote:
    > glen herrmannsfeldt wrote:
    > > I would say that you could use an LGPL verilog module in your
    > > design in the same way one uses a C library routine when compiling
    > > with GCC.  The LGPL is needed to allow distribution of GCC compiled
    > > output.   If one modified the LGPL module then one would have
    > > to release the source for that module, which might be okay.

    >
    > The main problem with the LGPL and hardware lies in clause 4d (seehttp://www.gnu.org/copyleft/lesser.htmlfor details). It's a clause
    > that makes a lot of sense when applied to software, but none when
    > applied to hardware. It's up to the copyright holders how to wish
    > to apply this clause when it comes to hardware.
    >
    > Kind regards,
    >
    > Pieter Hulshoff


    Yes, that is actually the key point.

    "1) Use a suitable shared library mechanism for linking with the
    Library. A suitable mechanism is one that (a) uses at run time a copy
    of the Library already present on the user's computer system, and (b)
    will operate properly with a modified version of the Library that is
    interface-compatible with the Linked Version. "


    My take on it, and IANAL, is that by having a reasonable library/API
    interface, the intent of
    section 4d is satisfied, through that type of firewall. You should be
    able to replace the LGPL library with any other library that can use
    that interface.
    This will, I believe, effectively give you
    the license firewall desired and implied by the term "library".

    The synthesis step is the compile step, and a "derivative work", the
    mapped netlist is produced
    by a compiler. Up to this step, I believe you can argue that the
    model is the same as the
    software world.

    Where you now do the place and route, bitstream download and run is
    where the machine models and the copyright-based "derivative work" GPL/
    LGPL licensing gets into new territory for hardware described by
    textual models(e.g. HDL code) and many, many transformational programs
    (e.g. place and route, partial reconfiguration, etc.). In fact, I
    believe that multi-core machines will end up having this same
    problem...interpreting the Von Neumann machine model magic of "static
    linking/dynamic linking" with repect to what that means with new
    machine models and modes of operation for the GPL/LGPL license
    hierarchy.

    As one of the other contributors in this thread mentioned, asking the
    creators of the library for
    reasonable permissions can stave off misinterpretations later on.

    alan
    ajjc, Oct 20, 2009
    #15
  16. In comp.lang.verilog ajjc <> wrote:
    (snip of LGPL and hardware discussion)

    > Yes, that is actually the key point.


    > "1) Use a suitable shared library mechanism for linking with the
    > Library. A suitable mechanism is one that (a) uses at run time a copy
    > of the Library already present on the user's computer system, and (b)
    > will operate properly with a modified version of the Library that is
    > interface-compatible with the Linked Version. "


    As before, I am not a lawyer, but this is a computer question.

    This has to do with modified versions of code distributed as
    shared libraries. It was some years ago that I looked into the LGPL
    question, and GNU/GCC does use shared libraries, so it makes some sense.

    Looking at the intent, not the wording, the intent is that if someone
    modifies it and distributes it that previous users can use it.

    Now, this actually does make sense in the hardware sense with
    partial reconfiguration, but I don't think that is where you are
    actually trying to go. You could claim, though, that partial
    reconfiguration corresponds to software dynamic linking. One could
    distribute a .BIT file with a known interface, and allow others
    to interface to it, or to a modified version of it.

    Does LGPL require dynamic libraries, or is one still allowed to
    distribute static linked libraries? The convenience of DLL is
    that the code isn't so comingled, and that one can distribute one
    and expect users (licensees) to keep it separate. Also, as
    that paragraph allows, one can use a new version without recompilation.

    If the original author decides to distribute static linked libraries,
    modifications should be done in such a way that existing code still
    works with the modified library. (after relinking)

    Much of the software/ABI discussion should apply at the module
    level in HDL. If you don't modify the original code, but use it
    as is then many of these problems don't appear.

    -- glen



    > My take on it, and IANAL, is that by having a reasonable library/API
    > interface, the intent of
    > section 4d is satisfied, through that type of firewall. You should be
    > able to replace the LGPL library with any other library that can use
    > that interface.
    > This will, I believe, effectively give you
    > the license firewall desired and implied by the term "library".
    >
    > The synthesis step is the compile step, and a "derivative work", the
    > mapped netlist is produced
    > by a compiler. Up to this step, I believe you can argue that the
    > model is the same as the
    > software world.
    >
    > Where you now do the place and route, bitstream download and run is
    > where the machine models and the copyright-based "derivative work" GPL/
    > LGPL licensing gets into new territory for hardware described by
    > textual models(e.g. HDL code) and many, many transformational programs
    > (e.g. place and route, partial reconfiguration, etc.). In fact, I
    > believe that multi-core machines will end up having this same
    > problem...interpreting the Von Neumann machine model magic of "static
    > linking/dynamic linking" with repect to what that means with new
    > machine models and modes of operation for the GPL/LGPL license
    > hierarchy.
    >
    > As one of the other contributors in this thread mentioned, asking the
    > creators of the library for
    > reasonable permissions can stave off misinterpretations later on.
    >
    > alan
    >
    glen herrmannsfeldt, Oct 20, 2009
    #16
  17. moogyd wrote:

    > Hi,
    >
    > Thanks for all the feedback.
    >
    > This is obviously quite complex :-(, and there seems to be no correct
    > answer.
    >
    > Additional feedback I received was that there is a significant
    > difference between H/W and S/W.
    > - S/W Can be copyrighted
    > - H/W Cannot be copyrighted - it can only be patented.
    >
    > The link is
    >
    > http://www.febo.com/law/Ackermann_Open_Source_Hardware_Article_2009.pdf


    Just FYI, I noticed the link is mentioned in today's article in the IC
    Design and Verification Journal:

    http://www.icjournal.com/articles/2009/20091020_opensource.htm

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
    Paul Uiterlinden, Oct 23, 2009
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Charles A. Lackman
    Replies:
    1
    Views:
    1,330
    smith
    Dec 8, 2004
  2. SpamProof
    Replies:
    0
    Views:
    534
    SpamProof
    Oct 21, 2003
  3. Peter

    1 day gnu, whole life gnu?

    Peter, Jan 10, 2005, in forum: Java
    Replies:
    3
    Views:
    327
    John C. Bollinger
    Jan 10, 2005
  4. Peter
    Replies:
    17
    Views:
    595
    Chris Smith
    Jan 13, 2005
  5. ade0
    Replies:
    1
    Views:
    283
    Gunnar Hjalmarsson
    Apr 6, 2005
Loading...

Share This Page