Has anyone made any expriences with Allegro ORBlink? Is there a Linux
version for the latter? Franz Inc. doesn't answer on this one (again),
so I have to ask you.
I have seen a posting from somebody saying that he had made good
experiences with Xerox PARCs ILU. Is ILU preferable to ORBlink? My major
concern is the stability of ILU, since we would have to rely on it.

Joachim

Cheers

So I think I'll avoid using CORBA as long as possible, and for my own
distributed applications I'm much more happy inventing my own little
tcp protocols with lisp syntax.

(a side note: AFAIK, the CORBA guys have just _started_ thinking
 about security, and I saw the first major security hole on BUGTRAQ
 some weeks ago.  Expect to see more!)

--

Anyway, I have to connect LISP, C/C++ and Java processes. And I don't
want to write this stuff, when there already are solutions for this.
Sure, the ACL-C connectivity via foreign-function-calls is sufficent for
our purposes, been there, done that. But LISP-Java would be ACL ffcing
to C and then to Java. If I had much more time at hand I'd go that way.

ORBLink is in final and is supported on any Allegro CL 5.0 platform
including Linux.

For more detailed information, contact i...@franz.com or orbl...@franz.com.

As one of the main developers of ORBLink and as an employee of the company
that vends it,  I am not qualified to comment in a disinterested manner on
the stability or quality of the product or of competing products. Like any
software product, it presumably is appropriate for some applications and
inappropriate for others; we encourage customers to try it risk free on an
evaluation basis in order more accurately to determine its suitability for
their needs.

Rainer Joswig <jos...@lavielle.com> wrote in article
<joswig-0209981502370...@pbg3.lavielle.com>...

Even with a ratified binding document, there's more to writing a CORBA
server than the parsing of the IDL - for example, we support the POA in our
ORB (I don't know about OrbLink), and the ORBs are likely to offer
configuration parameters specific to their designs, as well as
infrastructure functions for closing connections and setting timeouts.

(how-compatible-is-the-idl-binding-with-ilu)

what are the criteria the omg uses for refuting specs submitted by independant
parties?

I'd like to say that at least Harlequin has a very good record of pub-
lishing manuals in this manner.  Franz more than compensates for this
with the free version (documentation included) of ACL/Linux.  It would
be nice if it were a systematic habit (good for the education of the
youth and handy when porting code).

At the very least, it is not an agressive licens as the GPL so that
you can actually use it in bigger projects (together with modules
under different licenses).

And even with source code being available you don't *have* to fix it
yourself, you have always the option to wait until it is fixed by
others, or to pay others to fix it for you depending on how important
the bug is for you. Just because source code is available doesn't mean
you are somehow forced to mess with it. It gives you additional
freedoms and removes dependency on a vendor, thereby reducing your
risk.

Joachim

  one could argue that "free", as in Free Software Foundation, is not free
  at all.  freedom usually means the absence of means of coercion to make
  one do something other than what one wishes to do.  where there are means
  of coercion, the acceptable restrictions on freedom usually involve
  averting some form of actual harm to some party.  the GNU Public License
  prohibits a number of reasonable courses of action (which it is of course
  free to do), but without any reasonable explanation of the actual harm
  that is averted by the restriction on people's freedom.  in this sense,
  it is NO MORE FREE than any other license agreement one enters, since the
  freedom that comes from _agreeing_ with whoever has the power is not
  worth all that much.

  I'm strongly in favor of the availability of source code, yet recognize
  that it will _always_ have a price.  the question is which price to pay,
  and whether GPL is actually more expensive and restrictive than entering
  an agreement with the owner of the source that basically says they retain
  all rights of ownership to the source and to derivative works.

  unlike what many seem to believe, the license agreement that comes with
  software in the absence of any other agreements is _not_ the final word.
  reasonable people will enter other agreements as they see their value,
  and often those values can transcend monetary exchanges, which I regard
  as the least common denominator in otherwise incompatible value systems
  -- meaning that other forms of compatibility will yield other forms of
  exchangable values.

  the GPL is basically incompatible with the exchange of monetary values,
  which means it enforces compatibility on other values or value systems.
  the end result is that you cannot use GPL _unless_ you agree with the
  underlying value system.  given that that was the intent behind the GPL,
  one must applaud the execution of the idea, but it still does not mean
  that it is actually "free" for any normal interpretation of the word.
  while people everywhere may free themselves from other agreements by
  exchanging money and/or signing new agreements, this is expressly _not_
  an option for GPL'ed software.  in this sense, "free software" is LESS
  FREE than source code guarded by non-disclosure agreements which again
  guard monetary investments.

  to some, the value systems required of GPL users is not a problem.  for
  those for whom it is, GPL offers no alternatives but to abandon GPL'ed
  software.  I think this is quite tragic, but we need to look for new ways
  to ensure the availability of source code when the GPL is so hostile to
  those who do not share its values and money is no longer a common ground.

  Unlimited use, reproduction, and distribution of this software is
  permitted.  Any copy of this software must include both the above
  copyright notice of Xerox Corporation and this paragraph.  Any
  distribution of this software must comply with all applicable United
  States export control laws.  This software is made available AS IS,
  and XEROX CORPORATION DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
  INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY
  AND FITNESS FOR A PARTICULAR PURPOSE, AND NOTWITHSTANDING ANY OTHER
  PROVISION CONTAINED HEREIN, ANY LIABILITY FOR DAMAGES RESULTING FROM
  THE SOFTWARE OR ITS USE IS EXPRESSLY DISCLAIMED, WHETHER ARISING IN
  CONTRACT, TORT (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, EVEN IF
  XEROX CORPORATION IS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

There was a long discussion about this on the ILU mailing list
(archived are at www.findmail.com) back in December 1997. Richard
Stallman had consulted a laywer, Professor Eben Moglen. He pointed out
that there is no explicit mention of "modification" or "derivative
works" and, therefore, one cannot necessarily conclude that it is
allowed. However, neither can one conclude that modification is
prohibited, it would depend on what Xerox's intent was (said the
lawyer).

The response from Xerox was by one of the developers, Bill Janssen
(not a lawyer):

  The current license is certainly intended to allow modification of
  the code. We are sorry if Richard's interpretation of the licence
  differs from ours; I've talked with him about this topic, but
  (unfortunately) changing the copyright notice on ILU involves
  opening a can of Xerox legal worms that I'm not eager to encounter.

In my opionion, to claim that distribution of ILU modifications is
prohibited is a wild misrepresentation of the facts. I accept Richard
Stallman's position to insist on wording that is 100% water-tight,
especially regarding possible use in Gnome which only exists because
of licensing issues with KDE/Qt in the first place. But to turn around
and say the ILU source is for viewing only is preposterous.

Joachim

PS: I am neither employed by for nor do I speak for Xerox.

There are a number of specific orthogonally controlled rights (see 17
USC Sec. 106), such as: reproduction, derivative works, distribution
of copies, interpretive performance of a scripted work, display, and
public performance of a recorded work.  The absence of an explicit
statement is not equivalent to a vaguery; it reserves the right.
Indeed, all works "fixed in a medium" are automatically copyrighted,
regardless of statement, and all rights therein are automatically
reserved.  So it may be that Xerox intends you not to modify this work
(i.e., not to create a derivative work) and didn't mention it because
they didn't think they needed to, or it may be they intended to allow
it and failed to mention it, but I bet is very unlikely that some
lawyer omitted it thinking it would go without saying that you could
modify it.  And I bet it's also very unlikely that you'll find a
lawyer who will tell you you're save in modifying it if this is the
statement.  Further, as I understand it, copyright is conveyed using a
written instrument, not orally, so anything anyone at Xerox tells you
to reassure you is not worth anything if they don't put it in writing.

It may be that the confusion centers on the use of the term "use"
is used.  To my knowledge, "use" is not a term of art and does not
unambiguously express the particular mode of use.  (I don't know
that there are good terms to use, but I'd recommend more verbiage in
English to clarify.)  "Unlimited use" might mean "no limit on when
and where and how many times the code is executed" and does not
unambiguously imply "no limit on rights to modify"--especially since
there IS a term of art ("create a derivative work") for expressing
that concept if it needs to be expressed.  17 USC Sec 117 on the
limitations of exclusive rights for computer programs doesn't
mention this for example, and uses the noun "adaptation" to apparently
refer to using a modified copy.

It is certainly plain that 17 USC Sec 6 neesd a clause 7 to enumerate
the specific issues involved in use of a computer program text, but
absent such you're in a bind.

If unsure, get a lawyer to tell you for sure--and insist on a
copyright lawyer, since in my experience general legal practioners not
having studied copyrights specially are often as confused about
copyright law as any lay person.

Earlier Joachim had said:

An employee of Xerox who is one of the principal developers of ILU,
and who represents Xerox at the OMG, stated that this was indeed the
intention. One can argue whether or not he had suffient authority in
these matters, or whether email is sufficient or not for legal
purposes. But all indications are that Xerox's interpretation of the
term "unlimited use" did cover modification of source code. I have no
problem if people insist on a more definitive legal statement from
Xerox, but to state flat out that the license prohibits modifications
is not supported by facts, IMHO.

Joachim

Certainly in the end, all legal situations come down to a matter of
aspiration and intimidation.  If it is not the aspiration of Xerox to
sue you, then the legalese has no operational effect no matter how
strong it might be.  If you are adequately intimidated, then no matter
how liberal the wording is, it doesn't matter.  So to some degree your
task is to reliably assess your risk within the bounds these
establish.  (Just to keep this on topic: Programming languages are
really no different.  Sometimes we'll tell you a behavior is undefined
but you may find it works fine for you.  For some people, that's
enough.  For others, it's not.)

In general, I think the default assumption is that you are always at
legal risk, certainly in the US, and that all lawyers are ever really
capable of doing is working with you to take steps to have that legal
risk be at a comfortable point. :-)

I'm not a lawyer either!

As someone who actually had to digg into the C parts of ILU code I
assume you there is nothing in it that supports your claim, except for
people who are write-only coders.

It is sad that the Lisp part of ILU doesn't get more contributors and
I have to touch my own nose here, but I currently have other goals
than Lisp or Corba.

I don't think the situation of Lisp in projects like ILU is not as bad
as it seems. From my observation, the Lisp community is just a little
behind other languages when it comes to support free software.

Although there are many free Lisp packages, multi-person
Internet-based maintainance just had begone.

CL-HTTP, CMUCL and CLISP are Lisp projects powered by a kind of
community that made this now called "OpenSource" projects happen. On
the contrary, languages like Python and Perl grew up in such a
community from start.

It's only a question of time when other Lisp software joins it,
creating a snowball effect. MK:DEFSYSTEM, (by the athour answering
license questions again or by reimplementation), a GUI toolkit (CLIM
if some free source shows up, Garnet when not) and people improving
Lisp support for free ORBs are upcoming.

  (I have started to respond to this several times, never finishing because
  it seems like such an obviously counter-productive attitude, and the
  arguments against it so obvious, but let's give it a shot.)

  first, I have been working with other people's code as a firefighting
  consultant for the past 15 years.  projects have failed or are close to
  failing or are unmaintainable when I get called in.  still, I'd rate only
  10% of the code I have not only "browsed", but thoroughly analyzed, as "a
  horror".  let me give you an example of horrible string comparison in C.
  yes, this is _actual_ code from a past project.  comments are redundant.

    if (( Buffer[ 0] | 0x20) == 'f' &&
        ( Buffer[ 1] | 0x20) == 'l' &&
        ( Buffer[ 1] | 0x20) == 'o' &&
        ( Buffer[ 2] | 0x20) == 'w') {
      Flow = 1;
      Buffer+=4;
    }

  while not very accurate numbers, I could rate 20% as "uncomfortable", 30%
  as "comfortable", and 40% as "a breeze".  of the _free_ source I have
  looked at, _nothing_ has come close to the shitware produced by huge
  outfits like Anderson Insulting.  programmers who actually have to
  maintain their own code also make a huge effort to keep it maintainable,
  compared to the drones who code for the big consulting firms -- they know
  they will _never_ see their own code again, and only the low-lives (fresh
  out of school) will maintain such code, thus learning only bad habits
  from "real" code they are exposed to, and probably learning to hate other
  people's code in general, too.  (this is why I want good source code to
  be available for everybody to learn from and the author to be proud of.)

  second, the ability to read and understand code in a language well enough
  to acquire an intuition that works is _essential_.  that is, when you
  think _in_ the language, as opposed to think in some other language and
  then translating into the programming language, it doesn't really matter
  how ugly the code is, you still see _what_ it does, even if it takes a
  little more effort to read than well-written code.

  third, it's the _why_ that needs documenting, and if the general plan is
  well enough explained, comments most often just get in the way.  Lisp has
  documentation as part of the language, and they should be used to convey
  proper documentation of the interface and intended use.  that's all you
  should need if the implementation is solid, and if it isn't, you either
  fix it so it is or drop it entirely.  in any case, the contract with your
  callers is what matters.  if it is spelled out and fully obeyed, the code
  can look like shit or be exploiting undefined or implementation dependent
  features or system internals all it wants.

  fourth, I have never found a language easier to understand than Common
  Lisp, documented, undocumented, commented, uncommented, whatever.  while
  there are a lot of ways to do most things in Common Lisp, I have yet to
  stumble on a disingenious exploitation of cryptic side effects, such as
  are frequently the _rule_ in the Unix languages.

  so, in summary, I _KNOW_ what working with other people's code means and
  what effort and concentration it takes, yet I don't recognize the pain
  and suffering that some people impute to _all_ code they have not written
  themselves (which kind of tells me _they_ write really bad code).
  however, I must admit to having stopped using the phrase "the worst code
  I have ever seen" after I had spent a few months with 25,000 lines of
  mind-boggling stupidity in the project I showed a small piece of above.