Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of dakoller@googlemail.com
 designates 209.85.216.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=jJhCx8SF5WoWi9LM0XPgaWPo/flhjDtBmmlN3Qih0dayjyVo56ZLGtW/v6q4qa9x5J
         /mNyvpgKJr0FZ7klpGd7MsRbyW8b8R0Q2I/RQXIXeGXI61505QF4y9rj5Y+0FQAtkAbN
         UQ64PJlUTCyRBBoBiDdBCefEjb6hzQ7g2gZAM=
MIME-Version: 1.0
In-Reply-To: <06802A3D4BE62D449D366CE4A27D614003011714@usphle16.phl.sap.corp>
References: <06802A3D4BE62D449D366CE4A27D614003011714@usphle16.phl.sap.corp>
Date: Sun, 6 Dec 2009 00:29:04 +0100
Message-ID: <2bca8c350912051529p7b799e7ft443b140a4b147932@mail.gmail.com>
Subject: Re: SAP Services in ESME (was: UI widgets for ESME)
From: Daniel Koller <dakoller@googlemail.com>
To: esme-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=000e0cd153a4124fa5047a0397f9

--000e0cd153a4124fa5047a0397f9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Michael,

first of all: many thanks for this very open and honest statement, which
goes in the details of the SAP internal discussion.

Having said that, I believe that licenses are not God-given: enterprises
have to review regularly which level of openness/IP protection if right for
their business.

The following point comes up now: SAP would have to decide which way to go =
-
and hopefully for SAP this is not a decision of lawyers, but from business
people with vision.
My experience from companies opening up their applications/tools is, that
they did get benefit from it.

(Why not allowing usage of ES access code on the provision/usage of "as it
is now"? - For me it is clear that any kind of implementations based on ES
solves reulary 70% of the task, the other 30% are customer-/system-specific=
.
In fact ES will only be usable by licensed customers, so I would focus
license-wise on who uses ES for processes o production systems, not on who
provides a snippet of code, which may speed up the process to adopt ES in
the organization )

Daniel

On Sat, Dec 5, 2009 at 9:38 PM, Bechauf, Michael <michael.bechauf@sap.com>w=
rote:

> Ethan,
>
> it is no wonder that the developer community is asking questions, because
> honestely, sometimes I am not understanding all of our legal agreements,
> particularely where we are "open, but proprietary" - in other words where=
 we
> seemingly share content like WSDLs and field names openly, but in reality
> you are already bound to some license agreement in order to access this
> information.
>
> I would assume that our lawyers have done their jobs. The intent is clear=
,
> and that is to protect Enterprise Services from unauthorized use. The iss=
ue
> is that we are trying to defend ourselves against competitors but in the
> process of doing so also create issues with open source licenses.
>
> As you know, there is a major thaw in our relationship to open source
> communities; we are starting to contribute freely and with little
> bureaucratic overhead - at least in areas that are non-differentiating to
> us. The conclusion is clearly that we have more to benefit by contributin=
g
> back than by locking down the fort.
>
> With Enterprise Services, we are unfortunately still in sort of a dilemma=
.
> On the one side, it would be good that open source software would be clos=
ely
> affialted with SAP software; on the other side, this means that the neatl=
y
> protected ES definitions become subject to OS licenses and thus more open
> than we perhaps are comfortable with.
>
> In the end, it comes down to a business decision, and I think things like
> ESME will help make the case. It don't think there is any doubt that we
> don't want to build an engine like ESME ourselves. ESME also needs to be
> open, and not tied to SAP only. In the world of a borderless enterprise, =
we
> can't assume that everybody has SAP, so an engine that only works for SAP
> does not make sense. Open source is a great way to design the openness fr=
om
> the get-go.
>
> So, I know we have to come clean. As one of our lawyers recently said, it
> is easy to build a completely open company, and a completely closed one -=
 to
> get it right and build something right in the middle is hard. Microsoft h=
as
> done some good work with their Open Specifications Promise where they sai=
d
> exactly where they are open. Perhaps SAP needs to learn from that.
>
> My suggestion is therefore for the ESME team (and for anybody else who
> cares) to help us build a business case why net-net interoperability of S=
AP
> to open source is good, and to help us define how open we need to be. Tha=
t
> is more productive than kind of second guessing the licenses we have in
> place because the openness on SDN can be deceiving. Yes, you can browse t=
he
> ES definitions but once you drill down into the WSDLs you have to registe=
r
> and for that, I believe you have to agree to some license. Trust me, I
> believe our lawyers when they say that in order to build software with ES
> services you must use one of our dev licenses. I would not get into
> questions whether SAP can even protect weird stuff like a field named
> "BUKRS", or whether an API to create a purchase order is patentable or ca=
n
> be protected by copyrights. We need to build the business case that
> innovations like ESME benefit SAP, and higher interoperability is good.
>
> For that, I hope that the demo of ESME at the influencer summit will help=
.
> I would not be shy in saying that right now it's great that the approval
> process to get SAP employees to contribute to ESME is straight forward, b=
ut
> to get SAP software to interoperate with ESME is hard due to licensing.
>
> Best,
> Michael
>
>
> ----- Original Message -----
> From: Ethan Jewett <esjewett@gmail.com>
> To: esme-dev@incubator.apache.org <esme-dev@incubator.apache.org>
> Sent: Sat Dec 05 12:30:36 2009
> Subject: SAP Services in ESME (was: UI widgets for ESME)
>
> I think this topic deserves a separate discussion. It is something we
> probably need to address at some point, and I don't want to derail the
> widgets discussion.
>
> I was wrong to imply that SAP purposefully attempts to spread fear,
> uncertainty, or doubt on this topic. It doesn't. However, there is a
> lot of uncertainty and misalignment between SAP and the developer
> community, which results in doubt and fear.
>
> I disagree with Michael that a widget interfacing with an SAP
> Enterprise Service necessarily falls under any SAP license
> restriction. Such a widget would not need to include Enterprise
> Services in any sense. It would simply need to take a URL pointing to
> an arbitrary WSDL and it would need to make some assumptions about the
> field names and structures of the service. Field names and structures
> are information that SAP provides publicly, with no license
> restrictions (as far as I can tell) at http://esworkplace.sap.com/.
>
> However, as I mentioned, SAP's position on the IP around these
> services is sufficiently uncertain and opaque that I would not be
> comfortable including them in this project until SAP's lawyers
> specifically address this use case. (It is not addressed in the
> Netweaver Developer license agreement linked below, and developers who
> develop against SAP Enterprise Services are not necessarily bound by
> this license agreement.)
>
> Do we have an overall approach or understanding on this issue that has
> already been developed? If not, it might be worth discussing specific
> scenarios and our comfort level with them.
>
> Ethan
>
> On Fri, Dec 4, 2009 at 10:23 PM, Bechauf, Michael
> <michael.bechauf@sap.com> wrote:
> > 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 agreemen=
t
> > here
> > <http://www.sdn.sap.com/irj/scn/shop/developmentpack?rid=3D/webcontent/=
uui
> > d/d07ab93b-1d0e-2b10-ed9e-8d35d34a2fed&refer=3Dsubscriptionsssrl> .
> >
> > 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 lawye=
r
> > 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 th=
e
> > SAP Forge called SDN Code Exchange
> > <http://www.sdn.sap.com/irj/scn/weblogs?blog=3D/pub/wlg/16455> . In oth=
er
> > 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.
> >
> > Best,
> > Michael
> >
> > ________________________________
> >
> > From: Ethan Jewett [mailto:esjewett@gmail.com]
> > Sent: Friday, Dec 04, 2009 6:10 AM
> > To: esme-dev@incubator.apache.org
> > 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 -
> > http://incubator.apache.org/shindig/ ;-)
> >
> > 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 alig=
n
> > 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 righ=
t
> > 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.
> >
> > Ethan
> >
> >
> > On Thu, Dec 3, 2009 at 6:13 PM, Marcelo Pham <marcelo@akibot.com> 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 medi=
a
> > (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 mos=
t
> > 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.)
> >
> >        Details
> >
> >        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=3D"clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"
> > codebase=3D"http://widget.esme.us/?v=3D1.0" width=3D"200" height=3D"400=
"
> > align=3D"middle">
> >           <param name=3D"allowScriptAccess" value=3D"sameDomain" />
> >           <param name=3D"movie" value=3D"widget1.swf" />
> >           <param name=3D"quality" value=3D"high" />
> >           <param name=3D"bgcolor" value=3D"#ffffff" />
> >
> >           <param name=3D"feed_username" value=3D"username" />
> >           <param name=3D"feed_password" value=3D"12345abcd" />
> >
> >           <param name=3D"feed_url" value=3D"http://10.1.1.10/SAPFeed/" =
/>
> >            <embed src=3D"widget1.swf" quality=3D"high" bgcolor=3D"#ffff=
ff"
> > width=3D"200" height=3D"400" name=3D"foo" align=3D"middle"
> > allowScriptAccess=3D"sameDomain" type=3D"application/x-shockwave-flash"
> > pluginspage=3D"http://www.macromedia.com/go/getflashplayer" />
> >        </object>
> >        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 widget=
s
> > 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
> >        Akibot
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>


--=20
---
Daniel Koller
Jahnstrasse 20
80469 M=FCnchen * dakoller@googlemail.com

--000e0cd153a4124fa5047a0397f9--