"Ian Bell" <itb@yahoo.com> wrote in message
news:2h178nF7og1vU1@uni-berlin.de...
> Ian Bell wrote:
>
> >
> > I still find GPL confusing but:
> >
> > Section 0 says, amongst other things "This License applies to any
program
> > or other work which contains a notice placed by the copyright holder
> > saying it may be distributed under the terms of this General Public
> > License."
> >
> > Section 0 later says "Activities other than copying, distribution and
> > modification are not covered by this License; they are outside its
scope."
> >
> > And then "The act of running the Program is not restricted"
> >
> > Which to me means that *using* the programme e.g a library by linking
> > dynamically to it, is specifically permitted, though I may be wrong.
> >
> > Ian
>
> However, the GPL FAQ makes it clear that linking in any way to a GPL
library
> is legally considered a derivative work so now I see why most libraries
are
> released under the lesser GPL which specifically permits this. As always
> these things are determined by the legal definitions of words which may or
> may not make sense to ordinary folks.
>
> Ian

Most people find such legal documents confusing (me included - my post was
based on the faq rather than the license itself).  I really don't know what
the legal status of documents like the gpl faq is, but they do make the
spirit of the license clear.

"Paul J. Lucas" wrote:
> David Brown <david@no.westcontrol.spam.com> wrote:
> 
>> I assume this is a library that is used by the generated code
>> (i.e., if I were to use CHSM to generate code for an embedded
>> system, I would run the library on the embedded system too).
> 
>         Yes.
> 
>> In that case, it is this license that is critical, since any
>> code using it also has to be gpl'ed.
> 
>         No it doesn't.  If you don't want to GPL your code,
>         buy a commercial license from us.

Which is exactly the sort of conditions I have attached to my own
hashlib package.  You get to try everything out at no cost.  If
all is well you negotiate mutually acceptable conditions, possibly
including the transfer of filthy lucre.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

David Brown <david@no.westcontrol.spam.com> wrote:

> I assume this is a library that is used by the generated code (i.e., if I
> were to use CHSM to generate code for an embedded system, I would run the
> library on the embedded system too).

	Yes.

> In that case, it is this license that is critical, since any code using it
> also has to be gpl'ed.

	No it doesn't.  If you don't want to GPL your code, buy a
	commercial license from us.

> Your post said "might be negotiated", although your site is more concrete.
> However, you haven't made the distinction as to whether it is the CHSM
> program or the runtime library that is avaiable with different licenses.

	It all is.

> Providing the CHSM program with a commercial license will allow other tool
> vendors to integrate it in their closed-source systems, at a cost, which is
> a nice option to offer.

	Thank you.

> But it is the runtime library that is important - the GPL'ed version is only
> of serious use in accademic or hobby (or during testing and internal
> developement, etc.) circles.

	Or other GPL'd programs.

> If there is also a commercial license available for the library, then it is
> useful for almost any application, although your site should make the terms
> clear (i.e., is it a one-off license, or royality based?)

	It's whatever we and the clients find most agreeable.

> That would imply that it is the runtime library that is available with a
> commercial license?

	Yes.  Why is this so hard to understand?

	- Paul

Ian Bell wrote:

> David Brown wrote:
> 
>> 
>> "Ian Bell" <itb@yahoo.com> wrote in message
>> news:2h12rmF7qoj5U1@uni-berlin.de...
>>> David Brown wrote:
>>> snip
>>>
>>> >  Just for the sake of completness, I'll answer
>>> > your points below.
>>> >
>>> >
>>> >> The generated code is under no license whatsoever.  However,
>>> >> the run-time library is still covered by the GPL.
>>> >>
>>> >
>>> > I assume this is a library that is used by the generated code (i.e.,
>>> > if
>> I
>>> > were to use CHSM to generate code for an embedded system, I would run
>> the
>>> > library on the embedded system too).  In that case, it is this license
>>> > that
>>> > is critical, since any code using it also has to be gpl'ed.  That
>>> > means the generated code is implicitly gpl'ed, along with any other
>>> > user code
>> in
>>> > the application.
>>> >
>>>
>>> I have not read all this thread so forgive me if this is out of place,
>>> but it seems to be a common misconception that code that dynamically
>>> links to
>> a
>>> gpl'd library must itself be gpl'd. AFAIK this is not the case.  A good
>>> example is Kylix which links to a whole bunch of standard linux
>>> libraries but is closed source.
>>>
>>> Ian
>> 
>> You are, I think, incorrect here - code that links staticly or dynamicly
>> to
>> a gpl'ed library must itself be gpl'ed.  It is a different matter with
>> lgpl'ed libraries - the LGPL is specifically written for libraries, and
>> allows dynamic linking with code under any license, while static linking
>> (or
>> modifications of the library) must be lgpl'ed or gpl'ed.  The standard
>> linux libraries, along with many other libraries, use the lgpl and thus
>> allow dynamic linking with closed-source software.
>> 
>> Of course, this is almost certainly beside the point - in embedded
>> systems, it is far more common to use static linking, and therefore
>> neither lgpl nor
>> gpl libraries can be used along with other-licenced code.  This is one of
>> the reasons for the existance of newlib - the standard gcc c library is
>> lgpl, and therefore cannot be used in non-open source statically linked
>> code, while newlib uses a BSD-style license which allows such linking.
>> 
>> Disclaimer - IANAL, and I'm sure someone will correct me if I'm wrong...
> 
> I still find GPL confusing but:
> 
> Section 0 says, amongst other things "This License applies to any program
> or other work which contains a notice placed by the copyright holder
> saying it may be distributed under the terms of this General Public
> License."
> 
> Section 0 later says "Activities other than copying, distribution and
> modification are not covered by this License; they are outside its scope."
> 
> And then "The act of running the Program is not restricted"
> 
> Which to me means that *using* the programme e.g a library by linking
> dynamically to it, is specifically permitted, though I may be wrong.
> 
> Ian

However, the GPL FAQ makes it clear that linking in any way to a GPL library
is legally considered a derivative work so now I see why most libraries are
released under the lesser GPL which specifically permits this. As always
these things are determined by the legal definitions of words which may or
may not make sense to ordinary folks.

Ian

David Brown wrote:

> 
> "Ian Bell" <itb@yahoo.com> wrote in message
> news:2h12rmF7qoj5U1@uni-berlin.de...
>> David Brown wrote:
>> snip
>>
>> >  Just for the sake of completness, I'll answer
>> > your points below.
>> >
>> >
>> >> The generated code is under no license whatsoever.  However,
>> >> the run-time library is still covered by the GPL.
>> >>
>> >
>> > I assume this is a library that is used by the generated code (i.e., if
> I
>> > were to use CHSM to generate code for an embedded system, I would run
> the
>> > library on the embedded system too).  In that case, it is this license
>> > that
>> > is critical, since any code using it also has to be gpl'ed.  That means
>> > the generated code is implicitly gpl'ed, along with any other user code
> in
>> > the application.
>> >
>>
>> I have not read all this thread so forgive me if this is out of place,
>> but it seems to be a common misconception that code that dynamically
>> links to
> a
>> gpl'd library must itself be gpl'd. AFAIK this is not the case.  A good
>> example is Kylix which links to a whole bunch of standard linux libraries
>> but is closed source.
>>
>> Ian
> 
> You are, I think, incorrect here - code that links staticly or dynamicly
> to
> a gpl'ed library must itself be gpl'ed.  It is a different matter with
> lgpl'ed libraries - the LGPL is specifically written for libraries, and
> allows dynamic linking with code under any license, while static linking
> (or
> modifications of the library) must be lgpl'ed or gpl'ed.  The standard
> linux libraries, along with many other libraries, use the lgpl and thus
> allow dynamic linking with closed-source software.
> 
> Of course, this is almost certainly beside the point - in embedded
> systems, it is far more common to use static linking, and therefore
> neither lgpl nor
> gpl libraries can be used along with other-licenced code.  This is one of
> the reasons for the existance of newlib - the standard gcc c library is
> lgpl, and therefore cannot be used in non-open source statically linked
> code, while newlib uses a BSD-style license which allows such linking.
> 
> Disclaimer - IANAL, and I'm sure someone will correct me if I'm wrong...

I still find GPL confusing but:

Section 0 says, amongst other things "This License applies to any program or
other work which contains a notice placed by the copyright holder saying it
may be distributed under the terms of this General Public License."

Section 0 later says "Activities other than copying, distribution and
modification are not covered by this License; they are outside its scope."

And then "The act of running the Program is not restricted"

Which to me means that *using* the programme e.g a library by linking
dynamically to it, is specifically permitted, though I may be wrong.

Ian

Ian Bell wrote:
> 
... snip ...
> 
> I have not read all this thread so forgive me if this is out of
> place, but it seems to be a common misconception that code that
> dynamically links to a gpl'd library must itself be gpl'd. AFAIK
> this is not the case.  A good example is Kylix which links to a
> whole bunch of standard linux libraries but is closed source.

or statically linked libraries.  That is what the LGPL license is
for.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

"Ian Bell" <itb@yahoo.com> wrote in message
news:2h12rmF7qoj5U1@uni-berlin.de...
> David Brown wrote:
> snip
>
> >  Just for the sake of completness, I'll answer
> > your points below.
> >
> >
> >> The generated code is under no license whatsoever.  However,
> >> the run-time library is still covered by the GPL.
> >>
> >
> > I assume this is a library that is used by the generated code (i.e., if
I
> > were to use CHSM to generate code for an embedded system, I would run
the
> > library on the embedded system too).  In that case, it is this license
> > that
> > is critical, since any code using it also has to be gpl'ed.  That means
> > the generated code is implicitly gpl'ed, along with any other user code
in
> > the application.
> >
>
> I have not read all this thread so forgive me if this is out of place, but
> it seems to be a common misconception that code that dynamically links to
a
> gpl'd library must itself be gpl'd. AFAIK this is not the case.  A good
> example is Kylix which links to a whole bunch of standard linux libraries
> but is closed source.
>
> Ian

You are, I think, incorrect here - code that links staticly or dynamicly to
a gpl'ed library must itself be gpl'ed.  It is a different matter with
lgpl'ed libraries - the LGPL is specifically written for libraries, and
allows dynamic linking with code under any license, while static linking (or
modifications of the library) must be lgpl'ed or gpl'ed.  The standard linux
libraries, along with many other libraries, use the lgpl and thus allow
dynamic linking with closed-source software.

Of course, this is almost certainly beside the point - in embedded systems,
it is far more common to use static linking, and therefore neither lgpl nor
gpl libraries can be used along with other-licenced code.  This is one of
the reasons for the existance of newlib - the standard gcc c library is
lgpl, and therefore cannot be used in non-open source statically linked
code, while newlib uses a BSD-style license which allows such linking.

Disclaimer - IANAL, and I'm sure someone will correct me if I'm wrong...

David Brown wrote:
snip

>  Just for the sake of completness, I'll answer
> your points below.
> 
> 
>> The generated code is under no license whatsoever.  However,
>> the run-time library is still covered by the GPL.
>>
> 
> I assume this is a library that is used by the generated code (i.e., if I
> were to use CHSM to generate code for an embedded system, I would run the
> library on the embedded system too).  In that case, it is this license
> that
> is critical, since any code using it also has to be gpl'ed.  That means
> the generated code is implicitly gpl'ed, along with any other user code in
> the application.
> 

I have not read all this thread so forgive me if this is out of place, but
it seems to be a common misconception that code that dynamically links to a
gpl'd library must itself be gpl'd. AFAIK this is not the case.  A good
example is Kylix which links to a whole bunch of standard linux libraries
but is closed source.

Ian

"Paul J. Lucas" <pjl.removethis@removethistoo.mac.com> wrote in message
news:Qoqqc.50422$sQ3.24236@newssvr29.news.prodigy.com...
> David Brown <david@no.westcontrol.spam.com> wrote:
>
> > Why are you so concerned about the license the tool is under?  Just as
the
> > GPL is an excellent choice of license for a compiler, it is also an
> > excellent choice for this tool.  The generated code is another matter -
and
> > here most people will agree that the tool will be of little use outside
> > accademic or hobby circles if the genreated C++/Java code is GPL'ed.
>

I think you have missed the point of my post, or I have made myself
unclear - perhaps you thought I was replying to your post, not Mark's.  I
have absolutely no problem with your license for CHSM - I think the
combination of open source and commercial licensing is an excellent
solution, and for many types of software (though by no means all), it offers
the best of both worlds.  Just for the sake of completness, I'll answer your
points below.


> The generated code is under no license whatsoever.  However,
> the run-time library is still covered by the GPL.
>

I assume this is a library that is used by the generated code (i.e., if I
were to use CHSM to generate code for an embedded system, I would run the
library on the embedded system too).  In that case, it is this license that
is critical, since any code using it also has to be gpl'ed.  That means the
generated code is implicitly gpl'ed, along with any other user code in the
application.

> Little use outside accademic or hobby circles?  The site
> clearly says commercial licenses are available.
>

Your post said "might be negotiated", although your site is more concrete.
However, you haven't made the distinction as to whether it is the CHSM
program or the runtime library that is avaiable with different licenses.
Providing the CHSM program with a commercial license will allow other tool
vendors to integrate it in their closed-source systems, at a cost, which is
a nice option to offer.  But it is the runtime library that is important -
the GPL'ed version is only of serious use in accademic or hobby (or during
testing and internal developement, etc.) circles.  If there is also a
commercial license available for the library, then it is useful for almost
any application, although your site should make the terms clear (i.e., is it
a one-off license, or royality based?).  As Mark said in his post, a
BSD-type license would be immediately usable on a wide range of systems -
but it is your product, and you choose the balance between what you charge
for and what you give away.


> That's like saying Microsoft Windows will be of little use
> outside accademic or hobby circles -- and you can't even see
> its source code.
>
> CHSM for commercial use is a commercial product.  CHSM for
> non-commercial use is free.  Just like Sleepycat's Berkeley DB.
> Just like Trolltech's Qt.
>

That would imply that it is the runtime library that is available with a
commercial license?  As I said above, the combination of licenses works well
for many programs.

> If you want to use CHSM commercially, license it.  Or spend
> tens of thousands of person-dollars writing and debugging your
> own.  Do you build your own oscilloscopes too?  Or do you just
> buy them?  If there's a tool you need and it's cheaper to buy or
> license that make in-house, then you buy or license it.  Simple
> economics.  Why some people get into hissy fits about software
> licensing as an apparent special case isn't clear.
>

Note the first line of my earlier post:
> > Why are you so concerned about the license the tool is under?  Just as
the

We are in full agreement here.

> Having our product closed-source with only a commercial license
> would be... better?  Please explain that.
>
> - Paul

David Brown <david@no.westcontrol.spam.com> wrote:

> Why are you so concerned about the license the tool is under?  Just as the
> GPL is an excellent choice of license for a compiler, it is also an
> excellent choice for this tool.  The generated code is another matter - and
> here most people will agree that the tool will be of little use outside
> accademic or hobby circles if the genreated C++/Java code is GPL'ed.

	The generated code is under no license whatsoever.  However,
	the run-time library is still covered by the GPL.

	Little use outside accademic or hobby circles?  The site
	clearly says commercial licenses are available.

	That's like saying Microsoft Windows will be of little use
	outside accademic or hobby circles -- and you can't even see
	its source code.

	CHSM for commercial use is a commercial product.  CHSM for
	non-commercial use is free.  Just like Sleepycat's Berkeley DB.
	Just like Trolltech's Qt.

	If you want to use CHSM commercially, license it.  Or spend
	tens of thousands of person-dollars writing and debugging your
	own.  Do you build your own oscilloscopes too?  Or do you just
	buy them?  If there's a tool you need and it's cheaper to buy or
	license that make in-house, then you buy or license it.  Simple
	economics.  Why some people get into hissy fits about software
	licensing as an apparent special case isn't clear.

	Having our product closed-source with only a commercial license
	would be... better?  Please explain that.

	- Paul