esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bechauf, Michael" <>
Subject RE: UI widgets for ESME
Date Sat, 05 Dec 2009 04:23:33 GMT
There is no FUD about it; I think we've been quite transparent (or so I
hope) about our IP positions. 
SAP Enterprise Services need to be licensed, and there are a number of
provisions in those licenses that would restrict the free distribution
of code. Currently, there is no standalone license for SAP Enterprise
Services, but you only get them with SAP customer agreements, SAP
partner agreements, SAP NetWeaver developer subscriptions or the free
SAP NetWeaver Developer License. You can check out the license agreement
d/d07ab93b-1d0e-2b10-ed9e-8d35d34a2fed&refer=subscriptionsssrl> .
If you put SAP Enterprise Services into Apache code, a developer may
create a derivative work that is incompatible with the SAP Enterprise
Service license. For exampe, if they create commercial products (i.e.
for sale), they have to buy a license from SAP. I talked to Geir
Magnusson about it, and his opinion (and I don't think you need a lawyer
to confirm this) was that this was incompatible with the Apache license.
So, in other words, Ethan is right. I would not put code that contains
SAP Enterprise Services into the Apache distribution. If you want to
work together on a widget that contains SAP code, you can do this on the
SAP Forge called SDN Code Exchange
<> . In other
words, you can safely develop a widget framework in Apache, but for the
concrete widget instance that interfaces with SAP, I would not put it
into Apache.


From: Ethan Jewett [] 
Sent: Friday, Dec 04, 2009 6:10 AM
Subject: Re: UI widgets for ESME

That looks very interesting and I think it's a great idea. A couple
comments (sorry, it's been a busy week, so this is a bit off-the-cuff): 

1. I'd like to echo Daniel's suggestion to pursue an existing widget
container/standard if we do this. To offer another option: Shindig is a
pretty mature implementation of the OpenSocial widget container
standard. (Oh, and it's an Apache project - ;-)

2. I wonder if we might want to consider embedding *ESME* into a widget
platform (via the APIs) rather than embedding *widgets* into ESME. My
impression is that this might be a lot easier and may more closely align
with how ESME will be deployed (in the Enterprise) with a UI wrapper.

3. I'm skittish about putting code into ESME that interfaces with SAP
modules. My understanding of SAP's IP position is that code that
interfaces with SAP Enterprise Services contains SAP IP and cannot be
licensed under an Apache 2.0 license (or at least SAP reserves the right
to spread FUD on the topic). I'm not comfortable working on code that
does this or committing it to an Apache project until SAP clarifies its
position publicly and unequivocally. Because of this, I think we can
provide a framework and examples, but I think we should think twice
before providing an actual widget that interfaces with SAP as part of
the distribution.


On Thu, Dec 3, 2009 at 6:13 PM, Marcelo Pham <> wrote:

	Hi there, 

	I had a chat with Dick and he thought it would be good to share
this idea we had for Akibot with the ESME community:

	General concept

	1. The idea is to include a "widget" area to ESME front end.
These widgets would be plug & play components that help users from a
same group or department to see real time info, such as financials,
inventory maps, sales, etc. etc. 
	In brief, we would be marrying business intelligence (widgets
showing relevant, summarized information in real time) with social media
(microblog), this would give the whole group a sense of total business
awareness (they would know exactly what's going on, what employees are
chatting about, issues (microblog), what's the most named item, the most
mentioned customer (tags), figures for sales, inventory (widgets))

	2. For example, the executive and sales groups would have a
widget in their microblog that would show real time information for
today's and YTD orders:


	This widget would read data from the SD module and inform
everybody how sales are doing.

	3. We would start with widgets that read from SAP modules (SD,
FI, MM, etc.) and maybe after we could extend it to other ERP's (JD
Edwards, Mas500, Navision, etc) or other groupware apps (Salesforce,
Exchange, etc.)


	4. If ESME can be skinnable (meaning to allow users to change
around the HTML of the front end) these widgets could be embeddable in
the form of an object, like:
	<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"
codebase="" width="200" height="400"
	   <param name="allowScriptAccess" value="sameDomain" /> 
	   <param name="movie" value="widget1.swf" /> 
	   <param name="quality" value="high" />
	   <param name="bgcolor" value="#ffffff" />
	   <param name="feed_username" value="username" />
	   <param name="feed_password" value="12345abcd" />
	   <param name="feed_url" value="" />
	    <embed src="widget1.swf" quality="high" bgcolor="#ffffff"
width="200" height="400" name="foo" align="middle"
allowScriptAccess="sameDomain" type="application/x-shockwave-flash"
pluginspage="" />
	Or something like this but using JS.

	5. Widgets would be available to download from common open
repositories such as ESME website, Google code, etc. A widget would be
composed by a Flash or JS file to download, and a sample code to embed
into the HTML front end with instructions on how to customize it. We
will contribute with all the widgets we do and also help develop widgets
made by other members.   

	6. Since these will be all behind-the-firewall installations,
there should not be many security issues, although we would include a
username/password to authenticate to the SAP feed 
	Open for discussion

	7. Embeddable code / format: we haven't decided what formats
will be the best (JS, Flash, both...) 

	8. Connection / authentication: how to connect to the SAP feed
and how to authenticate to it

	9. Widget permissions: how to allow/hide widgets for different
groups (for example the sales widget should not be shown to the
purchasing group, etc.) 

	What do you guys think?

	Good night,


	Marcelo Pham
	Head Developer

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message