Group items tagged

The license must permit modifications

Integrity of the author's source code

No discrimination against persons or groups

No discrimination against fields of endeavor

same license must be passed on to others when the program is redistributed.

License must not be specific to a product

License must not restrict other software

License must be technology-neutral

list of the nine most widely used licenses is

Apache Software License 2.0 (www.apache.org/licenses/LICENSE-2.0.html) New BSD License (www.opensource.org/licenses/bsd-license.php) GNU General Public License (GPL) (www.gnu.org/licenses/gpl.html) GNU Lesser General Public License (LGPL) (www.gnu.org/licenses/lgpl.html) MIT License (www.opensource.org/licenses/mit-license.php) Mozilla Public License 1.1 (MPL) (www.mozilla.org/MPL/MPL-1.1.html) Common Development and Distribution License (www.sun.com/cddl/cddl.html) Common Public License 1.0 (www.ibm.com/developerworks/library/os-cpl.html)  Eclipse Public License (www.eclipse.org/legal/epl-v10.html) [5].

common misconception, alluded to above, is that since the source code is freely distributed without royalty or licensing fee, open source applications are free of cost.

Free and open source software application users, on the other hand, must rely on development communities for support.

The pervasiveness of the World Wide Web guarantees that nearly every information organization is using free or open source software to perform some function.

xCatalog

LibraryFind

Blackligh

iVia,

What makes OSS different from proprietary software is that it is free in every sense of the word: free as in “no cost,” free as in “unencumbered” and free as in “not locked up.”

questioned whether OSS is overall less expensive than its proprietary counterparts and has called for libraries to look hard at cost factors

OSS projects are thriving communities with leaders, followers, contributors, audiences and reputation systems.

Like so many things librarians hold dear – information, books and library buildings themselves – OSS is open, available and visible for all to see

OSS presents important opportunities for libraries

This is the world we want to be in again. It will not always be easy, and there will be a few spectacular failures. But there will also be spectacular successes – and this time, they will happen in the open.

Thomson Reuters OpenCalais

OCLC's WorldCat

Before we began our work on the Commons on Flickr, some museum colleagues were concerned that engaging with the Flickr community would increase workloads greatly. While the monitoring of the site does take some work, the value gained via the users has far outweighed any extra effort. In some cases, users have dated images for us.

In subsequent use of the Flickr API, we appropriated tags users had added to our images, and now include them in our own collection database website (OPAC). We also retrieved geo-location data added to our images for use in third party apps like Sepiatown and Layar.

In our case the purpose of creating an API was to allow others to use our content.

So consider the questions above not in the context of should we or shouldn't we put our data online (via an API or otherwise) but rather in the context of managing expectations of the data's uptake.

Steps to an API

several important things which had to happen before we could provide a public web API. The first was the need to determine the licence status of our content.

The drive to open up the licensing of our content came when, on a tour we conducted of the Museum's collection storage facilities for some Wikipedian

This prompted Seb Chan to make the changes required to make our online collection documentation available under a mix of Creative Commons licences. (Chan, April 2009)

Opening up the licensing had another benefit: it meant that we had already cleared one hurdle in the path to creating an API.

The Government 2.0 Taskforce (http://gov2.net.au/about/) was the driver leading us to take the next step.

"increasing the openness of government through making public sector information more widely available to promote transparency, innovation and value adding to government information"

the first cultural institution in Australia to provided a bulk data dump of any sort.

The great thing about this use is that it exposes the Museum and its collection to the academic sector, enlightening them regarding potential career options in the cultural sector.

I will briefly mention some of the technical aspects of the API now for those interested. In line with industry best practice the Powerhouse Museum is moving more and more to open-source based hosting and so we chose a Linux platform for serving the API

Images are served from the cloud as we had already moved them there for our OPAC, to reduce outgoing bandwidth from the Museum's network.

Once we had the API up and running, we realised it would not be too much work to make a WordPress plug-in which allowed bloggers to add objects from our collection to their blogs or blog posts. Once built, this was tested internally on our own blogs. Then in early 2011 we added it to the WordPress plugin directory: http://wordpress.org/extend/plugins/powerhouse-museum-collection-image-grid/

One of the main advantages the API has over the data dump is the ability to track use.

It is also worth noting that since the API requests usually do not generate pages that are rendered in a browser it is not possible to embed Google Analytics tracking scripts in the API's output.

y requiring people to sign up using a valid email address before requesting an API key we are able to track API use back to individuals or organisations.

Concerns that people would use the API inappropriately were dealt with by adding a limit to the number of requests per hour each key can generate