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 <[email protected]>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 <[email protected]> > To: [email protected] <[email protected]> > 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 > <[email protected]> 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:[email protected]] > > Sent: Friday, Dec 04, 2009 6:10 AM > > To: [email protected] > > 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 <[email protected]> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- --- Daniel Koller Jahnstrasse 20 80469 München * [email protected]
