[ANNOUNCE] CHSM: Statecharts implementation for C++ and Java

	CHSM (Concurrent Hierarchical State Machine) is a Statecharts
	implementation for C++ and Java that allows one to integrate
	state definitions, event handlers, and transitions seamlessly
	into the host language's object model.

	CHSM allows normal Java or C++ code to be intermixed with the
	Statechart definition promoting a clear and natural programming
	paradigm.  The CHSM is a full implementation of Harel's
	Statecharts and it is compliant with the UML 2.0 specification,
	including mechanisms for Statechart inheritance, event
	inheritance, and generic event dispatching.

	The CHSM system includes compilers for translating the CHSM
	Statecharts language to either C++ or Java, as well as a run-
	time library to support Statechart execution semantics.  The
	generated code and the run-time libraries have been designed
	for safety, efficiency and small footprint size, making it an
	ideal choice for embedded systems, control systems, user
	interfaces, communication protocols, and web service
	applications.

	The CHSM run-time implements the Statechart's Micro Step
	execution semantics that ensures safety and liveness properties
	to state machine specifications, a critical feature for many
	embedded and real-time applications.

	CHSM is distributed as open source software under the GNU
	Public Licensing scheme, although commercial licenses might be
	negotiated with the authors.

	CHSM has a homepage:

		http://homepage.mac.com/pauljlucas/software/chsm/

	- Paul

"> 	CHSM is distributed as open source software under the GNU
> 	Public Licensing scheme, although commercial licenses might be
> 	negotiated with the authors.

     no thanks - this stuff will disappear soon since most embedded
programmers like to eat,  my company wouldn't touch this

     BSD is a true open license, GPL is a very good license for
compilers and other tools that produce freely usable output, it is not
good for libraries and such, try another license or just try selling
it as an inexpensive product

anecdote:
     Everyone uses BSD sockets because of the BSD license, the ATT
equivalent disappeared

Mark <prenom_nomus@yahoo.com> wrote:
>      BSD is a true open license, GPL is a very good license for
> compilers and other tools that produce freely usable output, it is not
> good for libraries and such, try another license or just try selling
> it as an inexpensive product

	If you bothered to read the site, it says, "Other commercially
	oriented licences available."

	As the original authors, we're free to grant as many licences
	as we please each having different terms.

	Berkeley DB, Trolltech Qt, and others, license their roducts
	the very same way.

	- Paul

"Mark" <prenom_nomus@yahoo.com> wrote in message
news:c5b88987.0405161212.2563c0b8@posting.google.com...
> "> CHSM is distributed as open source software under the GNU
> > Public Licensing scheme, although commercial licenses might be
> > negotiated with the authors.
>
>      no thanks - this stuff will disappear soon since most embedded
> programmers like to eat,  my company wouldn't touch this
>
>      BSD is a true open license, GPL is a very good license for
> compilers and other tools that produce freely usable output, it is not
> good for libraries and such, try another license or just try selling
> it as an inexpensive product
>
> anecdote:
>      Everyone uses BSD sockets because of the BSD license, the ATT
> equivalent disappeared

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
don't know whether the CHSM authors have considered this aspect or not,
having not read the website, but they should clarify in writing whether
there are any restrictions on the generated code.  For a similar situation,
look at yacc - the program itself is gpl'ed, but the templates used for code
generation are lgpl'ed (although if the tool is to be used in embedded
systems, then BSD-type licensing is far better for the templates).

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

"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 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

"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...

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!

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