Discussions

Caucho Technology, Inc., a Sun Microsystems J2EE licensee, announced that the Hessian protocol has been ported to Microsoft's .NET platform and released as Hessian C#. The aim is to give developers a binary protocol for web services integration.

Press Release

Caucho Technology's Hessian binary protocol makes web services useable without requiring a large framework, and without learning yet another alphabet soup of protocols. Because it is a binary protocol with a small footprint it is well suited to sending digital data such as .MP3 and image files in today's mobile environment.

HessianC# represents the latest implementation of Caucho’s Hessian Binary Web Service Protocol and is being developed under the GPL by the three software engineers: Dimitri Minich, Vitaliy Byelyenkiy and André Voltmann. A diverse team, Dimitri was born in Kazakhstan, Vitaliy is a Ukrainian native and André comes from Germany. They each work for different software companies and in their spare time they aspire to realize their HessianC# vision. The first version of HessianC# has just been released and can now be found at Sourceforge.net or on the project’s website at www.hessiancsharp.org.

HessianC# project spokesman André Voltmann said,“Our goal is to achieve a higher popularity for the Hessian Protocol which is an easier to use and faster alternative to Apache SOAP. We want to show how it can be used for mobile devices as well as for internet applications, and how it can serve as a bridge between different programming environments.” Voltman concludes, “The next steps will include releasing the Hessian Server as well as publishing several articles about Hessian’s range of possibilities in various German computer magazines.”

Steve Montal, Director of Sales and Strategic Partnerships for Caucho Technology, Inc. said “André’s interest in developing the C# implementation of Hessian ensures that a viable binary web service protocol will be available as the technological push toward smaller, faster mobile devices continues into the future.” Montal added, “Caucho fully supports André and his team and looks forward to working with them as they continue to develop HessianC#.”

It's relatively easy to setup ssl between two computers using web services. It's quite another thing to set up an infrastucture that supports 10's or 100's of computer nodes.

I believe one of the goals of web services is to allow multiple computer nodes to communicate with one another using a common interface (web services). If this is to work it needs to implement a 'message level' security mechanism as opposed to a 'transport level' security mechanism like ssl.

One way to implement this would be Hessian with PKI. I haven't quite figured out how this would work though.

What about using PKI?It's relatively easy to setup ssl between two computers using web services. It's quite another thing to set up an infrastucture that supports 10's or 100's of computer nodes. I believe one of the goals of web services is to allow multiple computer nodes to communicate with one another using a common interface (web services). If this is to work it needs to implement a 'message level' security mechanism as opposed to a 'transport level' security mechanism like ssl.One way to implement this would be Hessian with PKI. I haven't quite figured out how this would work though.

It's not one of the current goals of Hessian, although if there really was sufficient interest, that kind of security could be added to the protocol.

One of the design principles of Hessian was to try to concentrate on what was actually needed by 80% of applications wanting a cross-language RPC protocol, while keeping it simple.

Currently, WS-Security looks like it's less than 20% of actual applications which would consider Hessian (and would add considerable complexity), so any implementation is postponed until it proves to be a bigger need.

The transport-level security covered by SSL seems to solve most of the current security needs of Hessian users.

Hessian by itself might not have it, however SOAP itself did not have it, so different solutions where developed.You might try looking after some of them.e.g.:- use HTTPS + PKI + Client Side Certs- Server has a filter which certifies client-signature- good messages get modified automatically and the client's identity is added to the XML message- bad messages are simply not delivered to the backend Hessian engine

Pros:- you don't really need to bother aboutPKI wihtin your app- 'easy' to implementCons:- 'slow' execution: XML must be parsed, modified, serialized- 'weak': if someone manages to get in the middle between the filter and the hessian server he might fake his identity

HessianC# is released as a library. In general, if you link with GPL code, your code must also be GPL. This is the reason we have LGPL (Lesser / Library GPL). This allows dynamic linking (e.g. .so or .dll files) from software released under another license (including commercial).The standard libraries found in systems such as Linux are typically released under the LGPL, which enables commercial applications to link with them.IIRC, there was some noise about 1.5 years ago, regarding some problems with the way Java code was loaded (linked) and the terms of the LGPL. This may have been bogus though, since the topic hasn't been mentioned since.

http://www.gnu.org/licenses/gpl.htmlIn section 2, Is it said I can use it without change it's source code? Whatever what my license or commercial usage.It is right??????Just attach the gpl-license copy when redistribute the program.

Depends. Is your program is distributed outside your organization (commercially or not)? If yes, then you have to license it as GPL.The programs code/text segment in memory plays an important part, when understanding the (L)GPL licenses. You do not need to release your shellscripts as GPL, because they launch the GPL programs in their own code/text segment (separate process). You cannot create an executable linked with object code from a GPL program (e.g. a .o file generated from a compile of a GPL program) and release it under another license.The LGPL is an alternative, which to some degree, allows using LGPL object code in your own executable. You can dynamically (but not statically, in my understanding) link with LGPL'ed object code.

That section also contains what should raise an eyebrow - the headerfiles used to use the library may or may not be enough to require the executable to be released as (L)GPL. Admittedly, I have never heard of any cases where software dynamically linking with LGPL libraries were required to be released as (L)GPL.

This little article, by Richard Stallman, also explains the difference pretty well:

HessianC# is released as a library. In general, if you link with GPL code, your code must also be GPL. This is the reason we have LGPL (Lesser / Library GPL). This allows dynamic linking (e.g. .so or .dll files) from software released under another license (including commercial).The standard libraries found in systems such as Linux are typically released under the LGPL, which enables commercial applications to link with them.

Appluing the logic above: if GNU-Linux Kernel is GPL, then libraries must be GPL and so on and so forth.

It looks like commercial vendors use more sane interpretation: if you change or extend GPL code – then changes must be GPLed. If GPL something is just used then application code does not have to be GPLed.

Well, I guess lawyers could show that Word processor is an extension of a file-reading library…

Appluing the logic above: if GNU-Linux Kernel is GPL, then libraries must be GPL and so on and so forth.It looks like commercial vendors use more sane interpretation: if you change or extend GPL code – then changes must be GPLed. If GPL something is just used then application code does not have to be GPLed

Please see reply above, regarding code/text segments and how they relate to the license.

Yet another argument in favor of abandoning software patents...

? Were did patents come from? We are discussing licenses. There is quite a difference between a patent and a copyright. Think idea vs. product.

Our Java app, which uses Hessian as it's transport, has a .Net client which was using Axis; we talked to the Hessian C# guys about their use of the GPL, and they gave us a commercial license instead. If your company's policy (as ours) is no GPL, ask them for a different license. So far we've been quite pleased.

Its too bad that Hessian C# is released under GPL. Using a more "commercial friendly" license like BSD or Apache undoubtedly would have helped increase adoption of what could turn out to be a great tool for lightweight .Net to Java interop. The original Hessian project uses the Apache license.

Also, releasing this library under the GPL raises some interesting questions: Can you actually use/distribute/link this library in a .Net app without violating either the Windows, .Net, or GPL licenses? If the GPL is viral, wouldn't you have to release the source of the parts of the the app that were linked to this library? Some of those parts could include classes in the .Net framework-- which is licensed under a GPL-in compatible license.

If I create software that is a derivative work of your software, I need a license from you to copy and distribute my derivative work. However, if my work is not a derivative work under copyright laws, you have no right to exclude me from copying and distributing my software, so I do not need a license.

and

Contrary to what some operatives might want us to think, the GPL and other open-source licenses do not have some special magic feature that allows them to infect other software. They have license limitations that apply to derivative works, just like any other copyright license.

So the main question: Is Word processor derivative of 'read file' library or not? :)

So the main question: Is Word processor derivative of 'read file' library or not? :)

Quite simple, if your wordprocessor executable file ships with the readfile.o inside (statically linked), then you have derived. If your executable ships with the original readfile.so (and proper readfile.LICENSE file, and readfile library is LGPL) then you may use your own license. (running 'ldd', on linux, on your wordprocessor executable should show readfile.so in the list).

Quite simple, if your wordprocessor executable file ships with the readfile.o inside (statically linked), then you have derived.If your executable ships with the original readfile.so (and proper readfile.LICENSE file, and readfile library is LGPL) then you may use your own license.

Lets try applying the logic to a car: it is OK for a car manufacturer to have own trade secrets al long as wheels are attached by bolts, but that manufacturer should give up all secrets if he wants to weld them.

Quite simple, if your wordprocessor executable file ships with the readfile.o inside (statically linked), then you have derived.If your executable ships with the original readfile.so (and proper readfile.LICENSE file, and readfile library is LGPL) then you may use your own license.

Lets try applying the logic to a car: it is OK for a car manufacturer to have own trade secrets al long as wheels are attached by bolts, but that manufacturer should give up all secrets if he wants to weld them.Something is not right IMO…

Maybe because cars and software aren't the same. When you buy a car, you buy a license to use it?

I am not that sure if software is much different from cars, but anyway my example was about relationships of a car manufacturer(as user) with parts supplier.

Which doesn't relate to software at all. Software is primarily protected by copyright, cars by property laws.Car's costs are mosty in producing it and are variable (per-unit). Software costs are almost all in development, so they are fixed and per-unit costs are negiligible (CD & documentation prinitng or server hosting). I have excluded sales & marketing costs, as I speculate they are roughly the same (as long as both are branded products, which they usually are).

So such analogies are pretty useless. Unfortunately they are also pretty widespread...

I'm not trying to put words in anyones mouth here as the developers are more than capable of speaking for themselves but...

In December, I found out about this effort and talked to Andre via email about their use of the GPL; specifically that we couldn't use it because of that.

Their response was to provide us with a commercial license instead of the GPL. They were aware of the issues that people had with the GPL and were willing (and I found eager) to make it easy for us to use their work.

While they are more than happy to take donations via PayPal, they've not charged us a dime for their licence. I expect that we'll be contributing things back to them as we make greater use of their library.

If you've got the need, by all means drop them a line and ask for a commercial use license instead of the GPL... I'm sure you'll find them responsive.

Why not simply release it as LGPL ? Caucho's Java & Python are Apache2.When I wrote HessianCPP, I thought I should make it really free, no strings attached - that's what BSD is in my understanding. But on the other hand I wanted people using the library and improving it - like fixing bugs or implementing stuff off the todo list - to contribute things back, help the core code improve. BSD does not enforce this, but LGPL does - again, in my understanding of the licenses. So that's why I chose LGPL for the code.By the way, we also have a Flash implementation we're about to release next month, most likely under LGPL as well ! Unfortunatelly Flash's "binary" limitations require some tweaking of the i/o binary streams, like escaping out zeroes... Good thing we get free/transparent compression of the messages with mod_[gzip|deflate].

For the comments I read here, I find that the licensing model chosen by the guys behind HessianC# might just work.When I was writing HessianPHP one of the top issues I had was the license under which it will be released. I went for GPL too, not because I don't want commercial software to use it but because of two things: Contribution and Market.Yes I wanted people to check the code and contribute back if they find it works for they, that's the easy part. Particularly for PHP, where the available frameworks and libraries spawn like snowflakes in winter, you don't find many having anything to do with commercial software, with well identified exceptions like ADODb for instance. So, for the time being I think HessianPHP is fine regarding licensing, but, if someone has the need to use it in a commercial environment, I will provide a license for them.In any case, one of the advantages of open source is flexibility, so (I think) I can take the licensing scheme to some less restrictive compatible license that doesn't affect current deployments, and/or, propose a license upgrade for people currently using the software. What do you think?

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.