Group items tagged

Excellent legal piece explaining the options and methods of how software programs use licensed and copyrighted third party libraries through an API. Finally, some clear thinking about Google Android and the Oracle Java Law Suit.
excerpt: Another option for a developer is to do what Google did when it created Android, and create replacement code libraries that are compatible with the existing code libraries, but which are new copyrighted works. Being "compatible" in this context means that the new libraries are called in the same way that the old libraries are--that is, using the same APIs. But the actual copyrighted code that is being called is a new work. As long as the new developer didn't actually copy code from the original libraries, the new libraries are not infringing. It does not infringe on the copyright of a piece of software to create a new piece of software that works the same way; copyright protects the actual expression (lines of code) but not the functionality of a program. The functionality of a program is protected by patent, or not at all.
In the Oracle/Google case, no one is arguing that code libraries themselves are not copyrightable. Of course they are and this is why the Google/Oracle dispute has no bearing on the enforceability of the GPL. Instead, the argument is about whether the method of using a code library, the APIs, is subject to a copyright that is independent of the copyright of the code itself. If the argument that APIs are not copyrightable prevails, programs that are created by statically-linking GPL'd code libraries will still be considered derivative works of the code libraries and will still have to be released under the GPL.
Though irrelevant to the enforceability of the GPL, the Oracle/Google dispute is still interesting. Oracle is claiming that Google, by creating compatible, replacement code libraries that are "called" in the same way as Oracle's code libraries (that is, using the same APIs), infringed

"HTML5, the latest version of the language of the Web, was designed with Web applications in mind. It contains a slew of new application programming interfaces (APIs) designed to allow the Web developer to access device hardware and software using JavaScript. Some of the more exciting HTML5 specifications include the following: Geolocation API lets the browser know where you are Media Capture API lets the browser access your camera and microphone File API lets the browser access your file system Web Storage API lets Web applications store large amounts of data on your computer DeviceOrientation Event Specification lets Web apps know when your device changes from portrait to landscape Messaging API gives the browser access to a mobile device's messaging systems Contacts Manager API allows access to the contacts stored in a user's contacts database"

"Google's Cloud Platform has long featured Cloud SQL, a zero-maintenance MySQL database that's hosted on Google's cloud platform. What it didn't offer was an API to easily manage these databases without having to use Google's admin interface. Today, however, Google is launching the Cloud SQL API. This new REST API will allow developers to programmatically manage their database instances and open a number of new use cases for Cloud SQL. The API, which Google still deems to be experimental, will allow developers to create their own workflows to easily create and delete instances, restart them and restore them from backup. They will also be able to use it to important and export their databases to and from Google Cloud Storage. For developers, this means using Google's cloud database is now quite a bit easier, especially if they need to regularly manage multiple databases for their customers. Google's launch partner for this API is OrangeScape, which uses it to power parts of KiSSFLOW, its Google Apps workflow SaaS service. "

A video with slide presentation featuring Google's Joshua Bloch. The topic is Java API Summary: A well-written API can be a great asset to the organization that wrote it and to all that use it. Given the importance of good API design, surprisingly little has been written on the subject. In this talk (recorded at Javapolis), Java library designer Joshua Bloch teaches how to design good APIs, with many examples of what good and bad APIs look like.

Google has pretty much given up on developing a JavaScript API for GMail. There was once a Greasemonkey script Google developed for GMail but that broke and Google shows no sign of fixing it. James Yu is now trying to fix that scenario with GMailr, a JavaScript API for GMail. It is made from the code he wrote for 0Boxer, an extension for GMail that turns organizing your inbox into a game. Yu is also a lead developer at Scribd. Yu said developing the API took him on a path fraught with frustrations and dead ends. He writes there is supported official JavaScript API for Gmail. The Greasemonkey script is broken and no one has yet released a frontend API for Gmail. He said he needed access to the various user actions in the UI as the backend APIs were not going to work as he wished. He decided to write his own library from scratch.

Patent application filed on OASIS UOML access by API. 0002]The present invention relates to electronic document processing technologies, and particularly to a method for encapsulating Unstructured Operation Markup Language (UOML) into an Application Programming Interface (API).  BACKGROUND OF THE INVENTION  [0003]The UOML standard includes a series of docbase management system instructions defined according to a format of "action+object" in Extensible Markup Language (XML), which has been explained in detail in an UOML Standard published by of the Organization for the Advancement of Structured Information Standards (OASIS ). Since XML works across different platforms and with different languages, the UOML standard can enable the docbase management system instructions to be exchanged across the different platforms in the different languages. However, in practical applications, operations on a docbase are usually controlled by using programs written in programming languages, hence the programs need to parse and process UOML XML texts. If every application developer designs his/her own way of parsing and processing UOML XML texts in his/her programs, the workload of coding will increase significantly and the efficiency of coding will drop sharply.  SUMMARY OF THE INVENTION  [0004]The objective of the present invention is to provide a method for encapsulating Unstructured Operation Markup Language (UOML) into an Application Programming Interface (API) of a programming language so as to improve the development efficiency of docbase management system application developers.  [0005]The method provided by the present invention for encapsulating UOML into an API includes:  Read more: http://www.faqs.org/patents/app/20090187927#ixzz0xVS2ZUSr

Custom Document Format Interoperability You may have heard that Office 2007 SP2 will now support editing files in the OpenDocument 1.1 (ODF) format. This document format was added to Office's long list of supported documents formats to give customers more choices for the format they use to save their documents. In addition to allowing you to edit the ODF 1.1 format within Office 2007, SP2 also supports a new External File Format API that can be used to edit other document formats as well. With this API, users can choose to save their documents in any format they want. In this post we will explore how to use the API to enable Office 2007 to edit our own custom document format. We will then use Office 2007 to save our custom format as DOCX, ODT and HTML. Our Custom Document Format For the purpose of this article, we have a company who needs to manage their sales pipeline information. The data is available as XML, but they do not want to spend the money to build a custom editor. They just want to let their users edit the pipeline data in Word, as a table. They give these files an extension of SPLX (i.e. Sales PipeLine Xml) The sales pipeline information is made up of a series of SalesItem tags, each with a unique id that represents the index of the item. They track the name of the customer (CustomerName), how much the deal represents (DealValue) and a percent that represents how confident they are that the sales opportunity will close (ConfidencePercent).

FeedHenry provides a cloud Mobile Application Platform that simplifies the development, integration, deployment and management of secure mobile apps for business. This mobile platform-as-a-service (PaaS) allows apps to be developed in HTML5, JavaScript, and CSS and deployed to multiple mobile devices from a single code base. The node.js backend service offers a complete range of APIs designed to simplify and secure the connectivity of mobile apps to backend and third party systems. The platform can be deployed to private, public or hybrid clouds. FeedHenry's PaaS offers developers speed of development, instant scalability, device and cloud independence, and the ability to easily integrate to backend information. ................................ If, say, a company uses both Sharepoint and Salesforce inside a mobile app, to get that data into one app they need multiple levels of API integration. Because of the enormous boom in mobile and tablet apps, so-called 'back-end as a service' (BaaS) platforms like FeedHenry - which solve these problems - are hugely expanding. Thus, today FeedHenry has secured $9M (€7M) in a funding round led by Intel Capital, alongside a "seven figure" investment from existing investor Kernel Capital. Other existing investors VMware Inc., Enterprise Ireland and private investors also participated and were joined by new investment from ACT Venture Capital. The funds will be used on an international roll out. FeedHenry's mobile application platform - built between Ireland and the U.S. - helps businesses build mobile apps that integrate securely to their business through the cloud. This is a competitive market that includes StackMob, Usergrid, Appcelerator, Sencha.io, Applicasa ,Parse, CloudMine , CloudyRec , iKnode, yorAPI, Buddy and ScottyApp.

We can all learn a lot of lessons from the history of DDE/OLE/ OLE3/COM /ActiveX/DCOM /COM+ (you can start reading up on Wikipedia to get some background) and how we went from everyone using best-of-breed standalone apps to one integrated, nearly monolithic Office. It basically all started with copy and paste. People who never spent a lot of time in singletasking, character-mode operating environments like the DOS command line don't recall that simply copying-and-pasting information between apps was difficult at the time. And part of the revelation of Windows for mainstream users (or Mac, for leading-edge tech fans), was being able to easily share data in that way. This was different than what Unix users were used to with the command-line pipe, or from what most applications do with feeds today, in allowing structured information flows between applications. There's a desire to combine data from different sources in an arbitrary way, and to have the user interface display the appropriate tools for whatever context you're in. The dominant model here, probably because of the influence of the early PARC demos, is to have toolbars or UI widgets change depending on what kind of content you're manipulating. Microsoft was really into this in the early 90s with OLE2, where your Word toolbars would morph into Excel toolbars if you double-clicked on an embedded spreadsheet. It was ungainly and ugly and slow, especially if you had less than an exorbitant 8MB of RAM, but the idea was pretty cool. And it still is. People are so focused on data formats and feeds that they're ignoring consensus around UI interoperability. The Atom API and Metaweblog API give me a good-enough interface if I want to treat a discrete chunk of information (like a blog post) as an undifferentiated blob. But all the erstwhile spec work around microformats and structured blogging (I forget which one is for XML and which one's for XHTML) doesn't seem to have addressed user experience or editing behavior

Eucalyptus, an open-source platform that implements "infrastructure as a service" (IaaS) style cloud computing, aims to take open source front and center in the cloud-computing craze. The project, founded by academics at the University of California at Santa Barbara, is now a Benchmark-funded company with an ambitious goal: become the universal cloud platform that everyone from Amazon to Microsoft to Red Hat to VMware ties into. [Eucalyptus] is architected to be compatible with such a wide variety of commonly installed data center technologies, [and hence] provides an easy and low-risk way of building private (i.e. on-premise or internal) clouds...Thus data center operators choosing Eucalyptus are assured of compatibility with the emerging application development and operational cloud ecosystem while attaining the security and IT investment amortization levels they desire without the "fear" of being locked into a single public cloud platform.

Quick LinksGet a TrialEnterprise On DemandEnterprise On PremiseFAQHelpContact UsWhy Adeptol?Document SupportSupport for more than 300 document types out of boxNot a Virtual PrinterMultitenant platform for high end document viewingNo SoftwaresNo need to install any additional softwares on serverNo ActiveX/PluginsNo plugins or active x or applets need to be downloaded on client side.Fully customizableAdvanced API offers full customization and UI changes.Any OS/Any Prog LanguageInstall Adeptol Server on any OS and integrate with any programming language.AwardsAdeptol products receive industry awards and accolades year after year  View a DemoAttend a WebcastContact AdeptolView a Success StoryNo ActiveX, No Plug-in, No Software's to download. Any OS, Any Browser, Any Programming Language. That is the Power of Adeptol. Adeptol can help you retain your customers and streamline your content integration efforts. Leverage Web 2.0 technologies to get a completely scalable content viewer that easily handles any type of content in virtually unlimited volume, with additional capabilities to support high-volume transaction and archive environments. Our enterprise-class infrastructure was built to meet the needs of the world's most demanding global enterprises. Based on AJAX technology you can easily integrate the viewer into your application with complete ease. Support for all Server PlatformsCan be installed on Windows   (32bit/64bit) Server and Linux   (32bit/64bit) Server. Click here to see technical specifications.Integrate with any programming languageWhether you work in .net, c#, php, cold fusion or JSP. Adeptol Viewer can be integrated easily in any programming language using the easy API set. It also comes with sample code for all languages to get you started.Compatibility with more than 99% of the browsersTested & verified for compatibility with 99% of the various browsers on different platforms. Click here to see browser compatibility report.More than 300 Document T

A must-see video if you're interested in the dance of sugar plum documents, what can be done with HTML5-plus, and an outside-the-box approach to online collaboration. Google just may have a winner in Wave.

Excellent discussion and capture of the importance of Cloud-computing!   Guest author Joe Masters Emison is VP of research and development at BuildFax writes for readwriteweb: excerpt:  More and more companies are moving from traditional servers to virtual servers in the cloud, and many new service-based deployments are starting in the cloud. However, despite the overwhelming popularity of the cloud here, deployments in the cloud look a lot like deployments on traditional servers. Companies are not changing their systems architecture to take advantage of some of the unique aspects of being in the cloud. The key difference between remotely-hosted, virtualized, on-demand-by-API servers (the definition of the "cloud" for this post) and any other hardware-based deployment (e.g., dedicated, co-located, or not-on-demand-by-API virtualized servers) is that servers are software on the cloud. Software applications traditionally differ from server environments in several key ways: ..... Traditional servers require humans and hours-if not days-to launch; Software launches automatically and on demand in seconds or minutes ...... Traditional servers are physically limited-companies have a finite number available to them; Software, as a virtual/information resource, has no such physical limitation ..... Traditional servers are designed to serve many functions (often because of the above-mentioned physical limitations); Software is generally designed to serve a single function ...... Traditional servers are not designed to be discarded; Software is built around the idea that it runs ephemerally and can be terminated at any moment On the cloud, these differences can disappear.

Excellent Hadoop/Hive explanation.  Hat tip to Matt Asay for the link.  I eft a comment on Matt's blog questioning the consequences of the Oracle vs. Google Android lawsuit, and the possible enforcement of the Java API copyright claim against Hadoop/Hive.  Based on this explanation of Hadoop/Hive, i'm wondering if Oracle is making a move to claim the entire era of Big Data Cloud Computing?  To understand why, it's first necessary to read Matt the Hadoople's explanation.   kill shot excerpt: "You've built your Hadoop job, and have successfully processed the data. You've generated some structured output, and that resides on HDFS. Naturally you want to run some reports, so you load your data into a MySQL or an Oracle database. Problem is, the data is large. In fact it's so large that when you try to run a query against the table you've just created, your database begins to cry. If you listen to its sobs, you'll probably hear "I was built to process Megabytes, maybe Gigabytes of data. Not Terabytes. Not Perabytes. That's not my job. I was built in the 80's and 90's, back when floppy drives were used. Just leave me alone". "This is where Hive comes to the rescue. Hive lets you run an SQL statement against structured data stored on HDFS. When you issue an SQL query, it parses it, and translates it into a Java Map/Reduce job, which is then executed on your data. Although Hive does some optimizations, in general it just goes record by record against all your data. This means that it's relatively slow - a typical Hive query takes 5 or 10 minutes to complete, depending on how much data you have. However, that's what makes it effective. Unlike a relational database, you don't waste time on query optimization, adding indexes, etc. Instead, what keeps the processing time down is the fact that the query is run on all machines in your Hadoop cluster, and the scalability is taken care of for you." "Hive is extremely useful in data-warehousing kind of scenarios. You would