Re: Java Client : who is using it ?
Re: Java Client : who is using it ?
- Subject: Re: Java Client : who is using it ?
- From: Florijan Stamenkovic <email@hidden>
- Date: Sun, 24 Jun 2007 00:19:29 +0200
Lachlan,
I was trying to find and quote something from the "Java Client WO
Apps" (or something similar) book that used to be a part of Apple's
standard WO documentation. It is not online anymore, and I can not
find a copy of it on my machine, when needed I used to consult a hard
copy that came with the WO 5.2 shelf edition. If anyone has it,
please be so kind to send it to me.
Since I have not found it, I can not quote it, but IIRC it clearly
states which specific .jars from the WO frameworks are allowed to be
distributed within client applications. These are typically located
in the WebServerResources folders of individual frameworks, and
include all the stuff needed to develop EOF clients. These same jars
are distributed with D2JC and the non-direct JC approaches. In the
book I mentioned there even is a half a page passage mentioning the
possibility of using those in a Java Desktop app. Which was
encouraging :)
Again, IIRC, the licensing on these is pretty loose. Free to embed
within your software kind of thing. I don't remember the exact
phrasing or mentioning of a specific license. Anyway, the sum of
these jars is not all what one would hope for, for example all
eoaccess stuff is not there, there are a few bugs in classes that are
common (but slightly different) to both the server and client side,
but it gets the job done.
So, as I saw it, you need a licensed WO server, running full blown WO
and EOF, and your clients get the lightweight version.
I wish I could provide some more concrete info (links, quotes etc),
but my hard copy is currently in a box as I am changing houses, I
don't have it cached, and the WO site does not mention Java Clients
at all anymore (something I prefer not to think about, makes me feel
like I am on a sinking ship). Sorry.
As for the quote you have below, the second clause seems to say that
you may include the JC stuff in your distributed app (which is
permanently residing on the client's machine) as long as you keep the
licensing of your software at least as restrictive as Apple's WO
license. So, you can't bundle the libraries into an app and say "gee,
I allow my app to be decompiled and reverse engineered by anyone who
feels for it". But hey, I am no lawyer, just trying to interpret.
I remember going into this, at some point, and what I have read was
not in conflict with what we are trying to build. That being a
commercial product relying on and embedding WO's JC libraries.
If anyone from Apple is seeing this, could you please verify?
Best regards,
F
Hi there,
On 24/06/2007, at 6:14 AM, Florijan Stamenkovic wrote:
<. snip .>
Are we satsified with this approach, assuming nothing gets
dropped? YES. YES. YES. YES. Swing is getting better and better,
Java in general as well. JFX says it will refresh things up, AND
be compatible Swing. Java 2D and 3D are getting better as well.
The platform is growing in capability. Not even mentioning the
plethora of fantastic third party code that can be found
(printing, graphing, GUI improvements...). And WO provides
enormous data sharing capability for it. Which is AFAIK furthest
down the road in it's line of business, AND provides a way to
output the same data easily in browsers. And yes, there is other
good stuff out there, but am I wrong in seeing this also as an
excellent choice?
Sorry if I am over-advocating. It feels warranted by the current
state of things.
Best regards,
Florijan
p.s. - except for Philippe here, I know of only three or four
other people who use WO this way. I continuously wonder why there
aren't more of us...
Can I ask what you're licensing arrangement is? Last time I
checked, and unless I'm reading it incorrectly... JavaClient
doesn't benefit from the same freedom as non-JavaClient. i.e., the
section below seems to indicate that JavaClient can only be used on
Apple-labelled-and-licenced-systems. This needs to be opened up for
a start.
We've got a large 3-tier Swing server/client app using Cayenne.
When initially deciding on what technologies to use the
aforementioned licence restrictions for 3-tier EOF apps was the
deciding factor on ruling that out. We'd apparently even offered
money to Apple so as to embed eof, but no deal was available.
That's all history now...
with regards,
--
Lachlan Deck
D. WebObjects Software. Subject to the terms and conditions of
this License, you may use, install and permit others to access the
WebObjects deployment software included with the Developer Software
to deploy application programs developed using Apple’s WebObjects
Software. You may also reproduce and distribute: (1) over a
network, components of the WebObjects deployment software for
installation and use by others (“Java Client End Users”) on any
remote computer’s volatile memory (e.g. RAM) to enable Java Client
functionality for the sole purpose of communicating with Apple’s
WebObjects Software that may be installed and executed on the same
Apple-labeled computer on which you have installed the Developer
Software (the "Licensed System"); and (2) both manually and
automatically over a network, components of the WebObjects
deployment software for installation and use by Java Client End
Users on any remote computer’s non-volatile memory (e.g. ROM) to
enable Java Client functionality for the sole purpose of
communicating with Apple’s WebObjects Software that may be
installed and executed on the Licensed System; provided that all
distributions to Java Client End Users are made under terms that
are at least as restrictive as those set forth in this License and
contain the disclaimers and limitations set forth in Sections 6 and
7 of this License. Subject to the terms and conditions of this
License, you may also deploy server applications built with the
WebObjects Software on any platform.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden