incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bechauf, Michael" <michael.bech...@sap.com>
Subject RE: SAP Services in ESME (was: UI widgets for ESME)
Date Mon, 07 Dec 2009 06:30:17 GMT
+1 on everything's that said here. Good analysis. 

I agree that the compatibility of vendor-specific connectivity licenses with ESME is not a
ESME-specific problem. I just found that in our company it's better to have a concrete use
case rather than discussing in the abstract. ESME is getting a good amount of attention, so
the ESME use case is a good one (next to others like PHP, Open Office etc). ESME would IMHO
require specific business interfaces whereas PHP would suffice with better technical connectivity,
and Open Office is not integrating on the business level (of course unless SAP would do a
Duet look-alike with Open Office, but I have zero information and zero influence in this regard,
so it's a purely theorectial comment). 

-----Original Message-----
From: Richard Hirsch [mailto:hirsch.dick@gmail.com] 
Sent: Sunday, Dec 06, 2009 4:46 PM
To: esme-dev@incubator.apache.org
Subject: Re: SAP Services in ESME (was: UI widgets for ESME)

Sorry, I'm getting involved so late in this thread. That's what you
get from being away from the list for a few days...

I think there are two related but distinct issues being discussed
here:(1) the necessity of having code that can be licensed with the
Apache 2.0 license in our code base at Apache and (2) the desire to
utilize SAP technology in open-sources projects.

As David mentioned, the code base at Apache should not have any
IP-related issues and must be provided under the Apache 2 license.  In
my various journeys through the code base, I haven't found anything
that might not fit this description. This necessity is the reason that
we didn't move everything from the old Google Code repository to the
new one at Apache.  Currently - and I emphasize currently-, SAP's
Enterprise Services are not provided under a license that is
compatible with the Apache 2.0 license. Therefore, irregardless of the
technology involved and the level of abstraction, such interfaces
can't be included in the Apache code base.  However,  (1) this doesn't
prohibit individuals from developing such components and integrating
them with ESME and (2) this doesn't imply that such SAP-provided
interfaces should not be available under more open-source friendly
licensing agreements (by the way, this is a discussion that has been
going on in various circles within the SAP community for about a year
now. We've discussed it in the ESME community as well at various times
of our evolution).

ESME is platform in which various integration possibilities are
present.  Through our various APIs, individuals within and outside of
the ESME community can take the functionality and apply it to use
cases that are relevant to them.  If someone wants to build a widget
that displays ES information in the ESME UI, they can do this (with
the assumption that we had a UI that supported this :>). If they want
their code to be open-source, they can't host it under the Apache 2.0
license - either within the ESME code base at Apache or anywhere else.

>As far as integration goes, the question is whether the open source part of ESME is supposed
to offer pre-integrated >modules with SAP, SalesForce, Oracle or whatever other enterprise
systems are available.

@Michael: We would be overjoyed to offer such pre-integrated modules
as part of the ESME source. But we are also restricted by the
licensing agreement in the Apache community.  The question is how can
we work together to convince enterprise software vendors (not only
SAP!) to provide such interfaces in a manner that fits into our
existing license? Of course, functionality based on SAP-IP might be
hosted in another environment (such as CodeX) in the form of a plug-in
which is then integrated into ESME by the end-user who has the right
to use the SAP-IP.

>So, the question for the ESME team must be whether they are willing to build the business
model for convincing the >proprietary enterprise vendors to open up certain interfaces
to the open source.

I think we should discuss this point in more detail but it must also
be clear that this isn't an ESME-specific problem - although we can
surely use ESME as an initial stepping stone to achieve broader
acceptance for tighter interaction between proprietary enterprise
environments and the open source community.

I hope this email acts as a reconciliation between the various
participants. This discussion is one that ESME must have in order to
be successful; the passions involved are understandable; therefore,
let's continue this debate and find that business model

D.


On Sun, Dec 6, 2009 at 7:57 PM, Bechauf, Michael
<michael.bechauf@sap.com> wrote:
> Hi Markus,
>
> no question, there are ways to technically solve this easily. I guess the question is
what the overall business model for ESME is supposed to be. As a Twitter clone, I think we
all agree that there is a pretty shaky value proposition. It may be a good scalable behind-firewall
Twitter, but without integration of some sort to enterprise systems, to receive events and
trigger processes, it may not be not enough. You may have already had discussions about this,
so I apologize for coming into this late.
>
> As far as integration goes, the question is whether the open source part of ESME is supposed
to offer pre-integrated modules with SAP, SalesForce, Oracle or whatever other enterprise
systems are available. Honestely, I have no idea why David has chosen to react so abrupt to
my message. I doubt that it is only SAP that has proprietary license terms associated with
access to their systems.
>
> So, the question for the ESME team must be weather they are willing to build the business
model for convincing the proprietary enterprise vendors to open up certain interfaces to the
open source. Reading David's sternly worded email, I would believe that there is no interest,
but I don't know whether David speaks for the group.
>
> I am simply trying to offer a dialogue because I was under the impression that there
is a win-win for both ESME and SAP, but if there is no interest, I'm happy to shut up and
leave the strategy completely up to this team.
>
> As far as participation of SAP employees in ESME are concerned, you know what to do.
I am under the impression that under currect conditions no SAP employee is authorized to sign
an individual contributor agreement. SAP as a company has signed the Apache contributor agreement,
but that still means that we would have to get internal approval for contributing to ESME.
I don't think that's hard at all, and if the ESME team is interested to build a business case
for pre-integration that's even better. For the time being, I don't think performance tests
without code contributions are IP critical at all.
>
> Alternative, if pre-integration is not important, then there are way to still collaborate
either through CodeX or to simply keep the  ESME SAP integration widgets out of open source
and develop them under a SAP partner agreement.
>
> Sorry for so much business lingo, but I really do hope that more transparency will help.
I'm happy to continue this dialogue if you are interested as a team.
>
> Best,
> Michael
>
>
>
> ----- Original Message -----
> From: Markus Kohler <markus.kohler@gmail.com>
> To: esme-dev@incubator.apache.org <esme-dev@incubator.apache.org>
> Sent: Sun Dec 06 07:27:22 2009
> Subject: Re: SAP Services in ESME (was: UI widgets for ESME)
>
> Hi Michael,
> Thanks for your post here!
> a few comments from my side.
>
> I think the issue is that the term "usesEnterprise Service" is not clearly
> defined.
> Actually someone could build a piece of code that wouldn't really use any
> code of SAP and not even the wsdl's.  Would that be a "use" of Enterprise
> Services? I guess SAP would argue that in order to do so you had access to
> the wsdl at some point in time or you did reverse engineering, which I guess
> is not permitted either.
>
> But since "almost every problem in computer science can be solved by another
> level of indirection", One could build a generic adapter that would not be
> released under the Apache license( or any other open source license) and
> release it on Source Exchange. But even then it would not be 100% clear
> whether an adapter that is  exposing Enterprise services would be legal.
> Exposing an enterprise service 1:1 would probably not be legal, but exposing
> only portions of it in more abstract way could be legal (and useful),
> wouldn't it?
>
> At the end I think ESME could just implement against abstract interfaces.
> Those abstract interfaces could be implemented by adapters for the various
> ERP vendors and this code would not have to be licensed under the Apache
> license.
>
>
>
> Regards,
> Markus
> "The best way to predict the future is to invent it" -- Alan Kay
>
>
> On Sat, Dec 5, 2009 at 9:38 PM, Bechauf, Michael <michael.bechauf@sap.com>wrote:
>
>> 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 issue
>> 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 contributing
>> 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 closely
>> affialted with SAP software; on the other side, this means that the neatly
>> 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 from
>> 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 has
>> done some good work with their Open Specifications Promise where they said
>> 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 SAP
>> to open source is good, and to help us define how open we need to be. That
>> 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 the
>> ES definitions but once you drill down into the WSDLs you have to register
>> 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 can
>> 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, but
>> 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 agreement
>> > here
>> > <http://www.sdn.sap.com/irj/scn/shop/developmentpack?rid=/webcontent/uui
>> > 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
>> > <http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16455> . 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.
>> >
>> > 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 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.
>> >
>> > 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 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.)
>> >
>> >        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="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"
>> > codebase="http://widget.esme.us/?v=1.0" width="200" height="400"
>> > align="middle">
>> >           <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="http://10.1.1.10/SAPFeed/" />
>> >            <embed src="widget1.swf" quality="high" bgcolor="#ffffff"
>> > width="200" height="400" name="foo" align="middle"
>> > allowScriptAccess="sameDomain" type="application/x-shockwave-flash"
>> > pluginspage="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 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
>> >        Akibot
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>

Mime
View raw message