Group items matching

in title, tags, annotations or url

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

"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. "

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.

Dion Hinchcliffe has an excellent article casting Google Wave as an Enterprise game-changer. He walks through Wave first, and then through some important enterprise features: ".....to fully understand Google Wave, one should appreciate the separation of concerns between the product Google is offering and the protocols and technologies behind it, which are open to the Web community: Google Wave has three layers: the product, the platform, and the protocol: The Google Wave product (available as a developer preview) is the web application people will use to access and edit waves. It's an HTML 5 app, built on Google Web Toolkit. It includes a rich text editor and other functions like desktop drag-and-drop (which, for example, lets you drag a set of photos right into a wave). Google Wave can also be considered a platform with a rich set of open APIs that allow developers to embed waves in other web services, and to build new extensions that work inside waves. The Google Wave protocol is the underlying format for storing and the means of sharing waves, and includes the "live" concurrency control, which allows edits to be reflected instantly across users and services. The protocol is designed for open federation, such that anyone's Wave services can interoperate with each other and with the Google Wave service. To encourage adoption of the protocol, we intend to open source the code behind Google Wave.

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.

Memeo Connect, which my colleague David Worthington tried and liked a few weeks ago, is an app that lets Google Apps users sync their documents and other files to a PC or Mac so they can get access to them even when they're offline. And as of today, it's available in a beta of version 2.0, which lets you get at synced files not only in Memeo's app but in Windows Explorer or the OS X finder, as well as in file open/save dialog boxes. The sync is two-way, so anything you drag or save into this repository gets moved back to Google Apps' storage once you're back online. And as before, Connect can handle files of all sorts and do conversions between Google Docs files and PDF and Microsoft Office formats. This virtual drive shows up in Explorer or Finder labeled as "GDrive"-a playful reference to a Google product that people have been expecting to arrive any day now for at least half a decade. (Don't tell anyone, but I've seen something called Google Web Drive in use at Google's offices; I assume it's undergoing internal testing and will get rolled out to the rest of us someday.) All in all, the new Connect competes more closely with Box.net (which launched its own syncing feature recently) and sync-focused services such as SugarSync. Memeo Connect 2.0′s other major feature is full-text search of the files in your Google Docs collection: Previous versions could only search file names. The Memeo Connect 2.0 beta is free, but the final version will cost $9 per user per year. It requires a $50/year Google Apps Premier account. (I think plenty of users of Google Apps' free version would pay for it, but Google only lets third-party apps and services that access the Apps API work with the paid edition.)

Google throws in the towel on desktop search, just as Microsoft somehow reached into my WinXP Pro (which never runs with automatic updates turned on) and killed the file search functionality, replaced by a message that file search is no longer supported in Explorer 6, with an invitation to upgrade MSIE or use Bing. As though I would ever let MSIE outside my firewall! 

Some good commentary on chrome OS from InformationWeek's Thomas Claburn. Excerpt: With Chrome OS, Google aims to make the Web the primary platform for software development....... The fact that Chrome OS applications will be written using open Web standards like JavaScript, HTML, and CSS might seem like a liability because Web applications still aren't as capable as applications written for specific devices and operating systems. But Google is betting that will change and is working to effect the change on which its bet depends. Within a year or two, Web browsers will gain access to peripherals, through an infrastructure layer above the level of device drivers. Google's work with standards bodies is making that happen..... ..... According to Matt Womer, the "ubiquitous Web activity lead" for W3C, the Web standards consortium, Web protocol groups are working to codify ways to access peripherals like digital cameras, the messaging stack, calendar data, and contact data. There's now a JavaScript API that Web developers can use to get GPS information from mobile phones using the phone's browser, he points out. What that means is that device drivers for Chrome OS will emerge as HTML 5 and related standards mature. Without these, consumers would never use Chrome OS because devices like digital cameras wouldn't be able to transfer data. Womer said the standardization work could move quite quickly, but won't be done until there's an actual implementation. That would be Chrome OS...... ..... Chrome OS will sell itself to developers because, as Google puts it, writing applications for the Web gives "developers the largest user base of any platform."

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

Quick review of different sync-share-store services, starting with DropBox and ending with three Open Source services. Very interesting. Things have progressed since I last worked on the SurDocs project for Sursen. No mention in this review of file formats, conversion or viewing issues. I do know that CrocoDoc is used by near every sync-share-store service to convert documents to either pdf or html formats for viewing. No servie however has been able to hit the "native document" sweet spot. Not even SurDocs - which was the whole purpose behind the project!!! "Native Documents" means that the document is in it's native / original application format. That format is needed for the round tripping and reloading of the document. Although most sync-share-store services work with MSOffice OXML formatted documents, only Microsoft provides a true "native" format viewer (Office 365). Office 365 enables direct edit, view and collaboration on native documents. Which is an enormous advantage given that conversion of any sort is guaranteed to "break" a native document and disrupt any related business processes or round tripping need. It was here that SurDoc was to provide a break-through technology. Sadly, we're still waiting :( excerpt: The availability of cheap, easy-to-use and accessible cloud file-sharing services means users have more freedom and choice than ever before. Dropbox pioneered simplicity and ease of use, and so quickly picked up users inside the enterprise. Similar services have followed Dropbox's lead and now there are dozens, including well-known ones such as Google Drive, SkyDrive and Ubuntu One. cloud.jpg Valdis Filks , research director at analyst firm Gartner explained the appeal of cloud file-sharing services. Filks said: "Enterprise employees use Dropbox and Google because they are consumer products that are simple to use, can be purchased without officially requesting new infrastructure or budget expenditure, and can be installed qu

Odd that the reporter mentions the importance of security near the top of the article but gives that topic such short shrift in his evaluation of the services. For example, "secured by 256-bit AES encryption" is meaningless without discussing other factors such as: [i] who creates the encryption keys and on which side of the server/client divide; and [ii] the service's ability to decrypt the customer's content. Encrypt/decryt must be done on the client side using unique keys that are unknown to the service, else security is broken and if the service does business in the U.S. or any of its territories or possessions, it is subject to gagged orders to turn over the decrypted customer information. My wisdom so far is to avoid file sync services to the extent you can, boycott U.S. services until the spy agencies are encaged, and reward services that provide good security from nations with more respect for digital privacy, to give U.S.-based services an incentive to lobby *effectively* on behalf of their customer's privacy in Congress. The proof that they are not doing so is the complete absence of bills in Congress that would deal effectively with the abuse by U.S. spy agencies. From that standpoint, the Switzerland-based http://wuala.com/ file sync service is looking pretty good so far. I'm using it.

But nobody is saying that the output of this technology can't be combined with the output of facial recognition technology to let them monitor you individually AND track your emotions. Fortunately, others are fighting back with knowledge and tech to block facial recognition. http://goo.gl/JMQM2W

Incredible.  I'm wondering if either Jason or florian has thought about using the Chrome JSON messaging layer to expose docx conversions to OTXML?  Essentially, when Florian breaks a .docx document, he only deals with the objects and how they are positioned (layout) on a page.  Once captured and described, these xObjects could then be converted to JSON.  The Chrome web client/ web server port (9222) could then, theoretically be used to observe the JSON xObjects?  Interesting. intro:  Under the hood, Chrome Developer Tools is a web application written in HTML, JavaScript and CSS. It has a special binding available at JavaScript runtime that allows interacting with chrome pages and instrumenting them. Interaction protocol consists of commands that are sent to the page and events that the page is generating. Although Chrome Developer Tools is the only client of this protocol, there are ways for third parties to bypass it and start instrumenting browser pages explicitly. We will describe the ways it could be done below. Contents Protocol Debugging over the wire Using debugger extension API

Haven't yet explored to see what's beneath the marketing hype. And I'm less than excited about the Skype with its NSA tendrils being the vehicle of audio translations of human languages. But given the progress in: [i] automated translations of human texts; [ii] audio screenreaders; and [iii] voice-to-text transcription, this is one we saw coming. Slap the three technologies together and wait until processing power catches up to what's needed to produce a marketable experience. After all, the StarTrek scriptwriters saw this coming too.   Ray Kurzweil, now at Google, should get a lot of the pioneer credit here. His revolutionary optical character recognition algorithms soon found themselves redeployed in text-to-speech synthesis and speech recognition technology. From Wikipedia: "Kurzweil was the principal inventor of the first CCD flatbed scanner, the first omni-font optical character recognition, the first print-to-speech reading machine for the blind, the first commercial text-to-speech synthesizer, the first music synthesizer Kurzweil K250 capable of recreating the grand piano and other orchestral instruments, and the first commercially marketed large-vocabulary speech recognition." Not bad for a guy the same age as my younger brother. But Microsoft's announcement here may be more vaporware than hardware in production and lines of executable code. Microsoft has a long history of vaporware announcements to persuade potential customers to hold off on riding with the competition.  And the Softies undoubtedly know that Google's human language text translation capabilities are way out in front and that the voice to text and text to speech API methods have already found a comfortable home in Android and Chromebook. What does Microsoft have that's ready to ship if anything? I'll check it out tomorrow. 

Good article with excellent URL references.  Bottom line is that the W3C will support the advance of HTML5 and controversial components such as "canvas", HTML + RDFa, and HTML microdata. excerpt: The key question is: who's going to get their way with HTML5? The companies who want to keep the kitchen sink in? Or those which want it to be a more flexible format which might also be able to displace some rather comfortable organisations that are doing fine with things as they are? Adobe, it turned out, seemed to be trying to slow things down a little. It was accused of trying to put HTML5 "on hold". It strongly denied it. Others said it was using "procedural bullshit". Then Berners-Lee weighed in with a post on the W3 mailing list. First he noted the history: "Some in the community have raised questions recently about whether some work products of the HTML Working Group are within the scope of the Group's charter. Specifically in question were the HTML Canvas 2D API, and the HTML Microdata and HTML+RDFa Working Drafts." (Translation: Adobe seems to have been trying to slow things down on at least one of these points.) And then he pushes: "I agree with the WG [working group] chairs that these items -- data and canvas - are reasonable areas of work for the group. It is appropriate for the group to publish documents in this area." Chop! And that's it. There goes the Gordian Knot. With that simple message, Berners-Lee has probably created a fresh set of headaches for Adobe - but it means that we can also look forward to a web with open standards, rather than proprietary ones, and where commercial interests don't get to push it around.