Showing posts with label apache. Show all posts
Showing posts with label apache. Show all posts

Friday, May 25, 2012

If Google and Oracle made aeroplanes where would your sympathy lie then?


There's been a lot of talk about the Oracle vs Google court case, and I was reading this when it occurred to me that I have a few reservations about the strength of Google's argument, and perhaps you'd like to hear them.

If you know about the technology you might want to skip ahead a bit, but I have to cover off some background, so we all know what we're talking about.

My thinking first took shape when the Apache Software Foundation (ASF), of which I am a member, was making its initial steps towards developing a Java Virtual Machine(JVM). At its most simple abstraction the JVM is the thing that runs on your computer, and in its turn it executes the java programs, they are loaded into it. The JVM "hides" the differences between operating systems from the Java programs. For example Mac's and Windows might have different ways for a program to interact with memory, the JVM provides memory management which is the same for all java programs, to make this happen a Windows JVM will be different "inside" than a Mac one.

So Apache were attempting to create an Open Source JVM called Harmony, and it was during early discussions about the "Java Mail API" which I was involved in that I first ran into the issue which is being tested in court right now. (we will ignore the definition of an API at the moment, because we come to that a bit later, it stands for "Application Program Interface" but you don't need to know what that means)

 I was PMC Chair of Apache James, a 100% Java email application server, and I had got chatting to the Harmony folks about one thing and another when the subject came up about whether an ASF licenced version of the JavaMail API  would have a more natural home amongst the java email fanbois of the James project because it is a framework that allows people to write java programs that handle email more easily.

So I started to think about what this would mean from a code perspective, and began to untangle things in my head, here's where I get to the point, stop skipping!

The thing that we call "JavaMail" is composed of three parts, and this is true for many other Java API's including the ones in the court case, and in fact much of the JVM itself. Those parts are:

i) A specification or definition, this part is the API specification.

b) An internal component which makes one half of the software, This part is the API interface.

2a) An example of the other half that you are free to use, or to replace with an implementation of your own. This part is an implementation of the API, whoever wrote it.
 
If we use an analogy here, to avoid getting bogged down in abstract descriptions of computer science ideas, we can imagine that an airliner manufacturer would manufacture the floor in such a way as a seat manufacturer could manufacture seats which could be installed after the plane is built, without the plane having to be adapted.

In order for this to happen the specification for the floor connections would be published and made available to seat manufacturers, who would then compete their little hearts out to make the best/cheapest/lightest seats on the market compatible with the floor specification, and sell them directly to the owners of the planes to be installed after the plane is delivered.

The airliner manufacturer will make floors and install them in customers planes.

The specification is a piece of intellectual property, it has taken time to produce and does have some intrinsic value.

The situation in the Oracle v Google case would be analogous to the situation in which a rival airline manufacturer has published an identical copy of the specification of the floor, manufactured compatible floors and is wooing customers and seat manufacturers from the originator of the specification with the promise of compatibility for all the seats and tooling and expertise that they have invested in.

What Oracle are contending, or trying to, or failing to, or *ought to be* saying, is that the specification is not in the public domain, it is their intellectual property and they are within their rights to restrict its use to allow people to implement the replaceable parts (the implementations, the seats), and not the internal part (the interfaces, the floor). In other words, not only is it breach of copyright (as the court has recently determined) but it is also probably not "Fair Use" (which they are still to decide upon) for Google to produce an API of their own to Oracle's specification. If it is, then people are going to very quickly stop publishing API's that allow competitors to benefit from years of research and development.

Of course this is then masked by a big shit-storm of FUD and misdirection by both sides, trying to veer off the subject onto other more easily determined areas of IP law where they believe they have an edge, such as:

The "field of use" restrictions, which are important but not directly relevant to the API arguments.

Patent infringement, of course, which is the modern lawyer's soup-of-the-day for the whole decade and IMHO totally irrelevant here.

And the distracting but easy to comprehend copy'n'paste IP crime where code appears to have been copied from somewhere that it couldn't have been legally.

The last one is the worst FUD of the lot because that is copyright infringement, as is the case where the specification is used in contradiction to the terms of its licence, but its a different crime, a separate incident, qualitatively something else altogether .

From this point of view I don't think Google's position is as solid as they might want it to be, or as solid as the judgements may suggest, but the truth of the matter is that Sun caused this whole debacle by vacillating over the legal status of Java, the API's the JVM, the TCK and a raft of other things that they thought morally *ought* to be open source and free for people to use for any purpose but weren't in law, because they never made it clear enough what was being explicitly permitted and what was being benignly tolerated.

And that is why I have mixed feelings about the merit of Google's case, and some grudging understanding of Oracle's position, and a bad taste in the mouth about Sun's failed attempts to be Machiavellian with the IP laws.

And if you're wondering what happened to James and the JavaMail API, we never did take it on, its a very poorly designed API and would have brought us a lot of work with precious little benefit.


Wednesday, September 01, 2010

Facebook, you make me want to cry!


It seems that the way in which facebook chooses an image to show alongside a posted link differs for links posted in different ways.

Oh how fucking hilarious. Not.

On our product page if you "attach" the link, or share it using facebook sharer (http://www.facebook.com/sharer.php) it picks the big product image as the first image in the list for you to choose from. This is a Good Thing, and exactly what we want to achieve.

However if you click the like button, its picking up a random image from sets of smaller images elsewhere on the page.


e.g. Share this dress' page through the sharer, or by "attaching" and you see this image:


but if you use the like button it shows us this image,



which is for this dress.

Arrgghh that's annoying. Get a damn grip facebook, at the very least you could try to be consistent. Read about the principle of least surprise.


Wednesday, November 18, 2009

Apache James is 10 years old too.


Happy Birthday Apache!

I was checking out the 10th anniversary press release

Several Apache projects also celebrated their 10th anniversary
and realised that Apache James is 10 years old this year as well. Way to go James Team, 10 years and we still haven't resorted to physical violence. Check the wayback machine if you don't believe me.

The top level project was established by the Board on January 22, 2003, with these ugly dudes on the 1st PMC:
Serge Knystautas
Danny Angus
Peter Goldstein
Noel Bergman
Charles Bennet

And I read the two documents The ASF was sent, I think I'm going to move to Oakland, or at least adopt their public holidays.

The Mayor of Oakland's proclamation that november 4th is Apache Software Foundation day wierd, but cool.

The Letter from Arnie. Question: Will he be back?


Tuesday, November 17, 2009

What people are saying about Apache James


Here are some links I found for James related things,

Most notably I found this site JavaEye I can find a few mentions of James but the content is in Chinese. This really begs the question how can we encourage Chinese, Japanese, and people from other cultures who are not as likely to communicate in English as Americans, Europeans, and people from India, to engage with our projects?
I would love for the people who are writing on JavaEye to make themselves known to the James community, we'd be happy to help spread the word about James, and are always grateful to people who can help us to get in front of a non English speaking audience.

"James is a very solid and reliable piece of software" Thanks Ant, nice of you to say so.

Niall Commiskey wrote EMAIL notifications with Oracle SOA Suite 11g which illustrates nicely what a useful role James can plan in enterprise systems. Even if it is only used to provide a development or test environment for email, James gives java developers standards compliant protocols *and* full control over the message content and routing, you can create testing stubs, reports, and integrations into other systems that will fully expose the output from your system.

And finally this Yet another email client – Apache James Hupa from Sree Balakrishnan, talking about the latest James sub-project Hupa (IMAP-based Webmail written in GWT) If you're interested in Hupa check out the site first but you may want to read this, if there haven't been any releases yet.


Tuesday, September 15, 2009

Load Balancing Apache httpd 2


Yes.. hear it here last!
I've been telling everyone I meet about JimJag's stupendous presentation at Apachecon US 08, in which he showed us, in glorious detail, how to use mod_proxy properly and mod_proxy_balancer.

I was impressed, and so have those who've also seen the slides.

Now its your chance, I recommend reading Jim's slides here.

If you have real life experience of using mod_proxy_balancer, let us know if he oversold it, or if it rocks your world. I *still* haven't had time to use it in for real yet.


Thursday, June 05, 2008

Another year older... another ASF board elected...


It hardly seems like a year since the ASF elected the board and here we are again.
The new board is a healthy mix of dedicated people from all walks of the foundation and looks like this:

Bertrand Delacretaz
Justin Erenkrantz
J. Aaron Farr
Jim Jagielski
Geir Magnusson Jr.
William A. Rowe, Jr.
Sam Ruby
Henning Schmiedehausen
Greg Stein


Wednesday, January 02, 2008

New Chair for Apache James PMC


Its been a long holiday, and I meant to blog this much sooner, but I've been too busy hanging out with the family.
On December 19th the ASF board passed a motion to recognise the change of the Apache James PMC chair from Serge Knystautas to myself.
This is a big honour for me, and I intend to work hard in 2008 to live up to the example Serge has set.
I haven't much to say about James right now, but I'm sure I will be saying more as the months progress.


Wednesday, November 14, 2007

Today's news..


Just spotted these two in my morning trawl through the blogosphere...

Is Microsoft Building a Flickr Competitor? In which we discover just how much of your plans you can give away in a job description.

And WiFi T-Shirt possibly the geek-most shirt I ever saw. Apache should mod these for a hackathon shirt.

Imagine what a crowd would look like, you'd see the signal fading out as it crossed the room, the inverse square made flesh. Would we, as geeks, congregate round the person with the strongest signal? The Alpha Geek?

Kind of reminds me of Natalie Jeremijenko's feral robots project in which toy robot dogs, you know the things, were fitted with sensors to detect stuff (like bad stuff coming out of landfill) and their movements mapped as they homed in on hotspots.


Monday, November 05, 2007

*How* much mail did I send???


Can't really believe it, but according to this cool new mail search thinggy (via ben) I've so far sent 2751 messages to the James lists since 2001.

That's a lot of email, how the hell have I managed it!


Tuesday, October 16, 2007

Planet Apache AWOL


I don't know what's happened but Sam has put up a temporary replacement here http://people.apache.org/~rubys/planet/apache/ .


Monday, August 20, 2007

Open Source, Spectrum of liberty


I just read Stefano Mazzocchi's post "On Version Control Architectures and the Fear of Displacing Innovation" he paints an eloquent picture of a tension which I'm sure is familiar to most, if not all, contributors to open source projects. How far do we have to constrain what we let each other do in order for our project to have a discrete identity which exceeds the sum of its parts, and at what point towards the libertarian end of the spectrum does our project loose coherence and become equal to or even less than the sum of its parts.

Stefano says "how many potential contributors did we miss because we didn't give them commit access soon enough" and I know exactly what he means. I'd like to broaden the question though, and ask why we choose to encumber ourselves with unweildy processes and centralised infrastructure?

I recently proposed that Apache James could lower the bar to publishing news stories if we used a blog. The ASF doesn't provide any blogging infrastructure, and if we used an off-site service, such as blogger (as used to publish this blog), it would be a "turnkey" operation and not involve Apache infrastructure in any effort. However my proposal has been met by a resounding "Hmmm... I'm not sure..." with most of the reservations being around hosting official content off-site. To me there seem to be many concrete benefits and very few drawbacks with out-sourcing this function and I was surprised that others didn't share my point of view.

So reading Stefano's post made me wonder, why *do* we feel that we have to control the infrastructure in order to "own" the project? Why do we want even to consider expending our limited resources on hosting for ourselves services which we can have for free?

Ok Initially we had to own the infrastructure so that we could operate the services we needed, and, yes, today we could argue that we want to retain full control over certain key services, websites, email, source control. But I always believed that the Apache Way was about community, proven processes and best practice, a brand and some world class products.

Don't take this the wrong way, I know that ASF infrastructure is vital to the ability of the projects to operate, and that it will never be possible for me to repay the people who set it up and who volunteer to maintain it on our behalf, but I never really thought the infrastructure was anything other than the key enabler. We have dozens of people hosting mirrors of our downloads, and no one complains about that, why would they, it benefits everyone.

Using a no-cost off-site service doesn't IMHO automatically compromise your reputation or undermine the moral authority of your message.


Tuesday, June 26, 2007

Jakarta Commons is now Apache Commons TLP


June 20th. (yes I know, I'm not very topical this week.) The Board of the Apache Software foundation voted to create a new top level project (TLP) out of the Jakarta Commons sub-project.

The new project will be known as the "Apache Commons Project" and be "responsible for the creation and maintenance of Java focused reusable libraries and components".

This is another significant step in the history of Jakarta.: "...all responsibility pertaining to the Commons sub-project encumbered upon the Apache Jakarta Project are hereafter discharged"

Well done and good luck to all involved.


Friday, June 22, 2007

New Apache Board


Not exactly hot of the presses (two days ago) but The ASF has a new board.

I'd like to express my own thanks the outgoing board members; Ken Coar, Dirk-Willem van Gulik, Cliff Schmidt and Sander Striker. They worked hard on our behalf, and we appreciate their effort and commitment.

I'd also like to thank the new board members and the continuing ones for being prepared to make the commitment we're asking of them. Without good people prepared to step up to the plate the ASF couldn't survive. The new board looks like this (* = newly elected):

Justin Erenkrantz - President
J Aaron Farr* - Treasurer
Jim Jagielski - Chairman
Geir Magnusson Jr*
William Rowe Jr*
Sam Ruby - Exec VP and Secretary
Henning Schmiedehausen*
Greg Stein
Henri Yandell


Thursday, May 31, 2007

Mime4J version 0.3 released


The Apache JAMES team is pleased to announce the release of Apache
Mime4J version 0.3. Apache Mime4J mime4j provides parsing for e-mail
message streams in plain rfc822 and MIME format.

The 0.3 release is the first official release under The Apache Software
Foundation umbrella.

Distributions are available from the download page here:
* http://james.apache.org/download.cgi

More information on Apache Mime4j can be found at the Apache JAMES
project site:
* http://james.apache.org/mime4j/index.html

The released packages will be also deployed to the central maven
repositories in the next days.


Tuesday, May 15, 2007

What Future for Apache Jakarta?


Apache Jakarta is a project which has spawned many significant landmarks in open source Java; Ant, Tomcat, Jakarta Commons, Maven, and Struts amongst many others.

In years gone by it was a widely known and respected "brand" which working java developers trusted.
I trusted it, I got free stuff to help me with what I was doing but more important than that I knew that I could make Jakarta my first stop if I had a problem that needed solving.

However the world moved on and two things happened:

Firstly the ASF Board indicated three years or so ago that the Members weren't happy that Jakarta should be as large, powerful and autonomous as it was fast becoming, and so after much debate the agreed direction was clear, Jakarta sub-projects would be encouraged and supported in becoming top level projects of Apache, deflating Jakarta and restoring balance and oversight. Most of them have been promoted in the intervening years, and only a few die-hards remain, but this is changing and they are now preparing to leave as well.

Secondly the Java ecology has changed radically in the past few years. Not only through the normal maturing of ideas and the distillation of best practice, but also from the introduction of resources like java.net, the entry of other trusted (often commercial) players into the open source arena, and changes to the JCP which have resulted in JSR's actually completing their life cycle. All of these have significantly enhanced the pool of "trusted sources" that java developers can go to.

So as we now approach the end of the reorganisation of Jakarta we're faced with a big decision, should we consign the brand to the history blogs? Or does it continue to represent something valuable to Java developers?

Successful brands are hard to create and easy to destroy, if we act without thinking about it we might be making a big mistake. On the other hand I am too close to it now to know whether or not this brand still means something to people who are, like I was then, the geek on the street.

So Please let me know whether you think the Apache Jakarta brand is worth preserving, or not worth loosing too much sleep over.


Thursday, May 10, 2007

Apache is Java Community Process Member of the year


The JCP have voted the Apache Software Foundation as "Member of the year 2007".
In the light of the recent waves Apache has been creating around IP restrictions on test kits this is either very ironic, or something of a show of support from the other members. In either case well done to the Apache folks who participate.

Geir Magnusson Jr. told ASF Members,

"It's a combination of our broad and deep participation in
expert groups, our numerous implementations of specifications, and
our activities as a EC member, where in our drive to bring our values
of transparency and openness, we push the JCP out of it's "comfort
zone", in a constructive and progressive manner that is good for the
ecosystem as a whole."


I know nothing, I'm not a fortune teller, and you'd be insane to think that I am. This disclaimer was cribbed from an email footer I once received. It is so ridiculous I had to have it for myself.

Statements in this blog that are not purely historical are forward-looking statements including, without limitation, statements regarding my expectations, objectives, anticipations, plans, hopes, beliefs, intentions or strategies regarding the future. Factors that could cause actual results to differ materially from the forward looking statements include risks and uncertainties such as any unforeseen event or any unforeseen system failures, and other risks. It is important to note that actual outcomes could differ materially from those in such forward-looking statements.

Danny Angus Copyright © 2006-2013 (OMG that's seven years of this nonsense)