Slashdot Mirror

I build a shiny widget, and release it under the GPL. Lots of people use my shiny widget - it becomes the gold standard for shiny widgets. Then some software house cuts a huge deal for software development with [insert name of immense multinational here]. The only trouble is, they need a shiny widget as part of the code. And damn, your one is the standard.

They come to you, and boy, you have them over a barrel. Because you were cunning enough to use the GPL, you can hold them to ransom, and charge them $1M for a limited license that lets them use your shiny widget in their new project. And whats more, you can sell it all over again the next time someone needs your shiny widget in a non-GPL setting.

Great imagination, laddie, shame about your grasp on reality.

The maximum value of any piece of software is what it would cost to do a clean-room reimplementation from scratch. Remember that a lot of the original GNU software was clean-room reimplementations of pre-existing UN*X utilities. On the whole it's always easier to do a clean-room reimplementation than to build the original system, because the re-implementors have a complete functional specification and a working prototype to test against.

In the past I've needed bits of commercial functionality which weren't available open source, so I simply reimplemented them from the specifications. It isn't hard to do - and it isn't hard to do the other way round either. So, sure, if you spent $1.5M equivalent in programmer hours developing your implementation, you might just get your $1M license fee. If it's something you knocked up in a weekend, they'll pay a programmer for a weekend.

I've been a Vodafone customer in the UK for eleven years now. I use a phone they didn't sell me, and have applications on it that I wrote as well as various others

Even on the phones Vodafone do sell you, features are not normally disabled; the last phone I got from them (Sony Ericsson P910i) has a ringtone downloaded direct to it from the net for free, and various applications I installed from places around the net. I don't think you could survive with a 'lock the users in' policy in Europe - there's too much competition.

Last time I was in this situation, back in 1997, I rolled my own. It's served me very well for nine years, but increasingly design commitments I made early have started to seem wrong in terms of subsequent developments. Now I'm thinking of where I go from here; I've been thinking about the features a modern software system should have. And I've got a proof of concept which generates all the elements of a Web application from a single source file.

I haven't yet decided which way I'm going to jump. But I have already ruled out a lot of approaches. Firstly, anything which mixes logic with presentation is clearly wrong. That rules out all the taglib based systems, including PHP, Cold Fusion, JSP, BRL and all the others. Ruby on Rails is sort-of OKish, since the presentation layer ('views') is separateish from the logic. But in practice it seems you can put any logic into the Rails templates. Having the templates in a different, standard language - ideally XSL - seems to me a better solution.

As to the underlying language, after ten years Java is stale for me. I spend too much of my time struggling round its limitations, and primarily, around static typing and baroque libraries. Ten years ago Java had a lot of promise, particularly in strong portability and platform independence. But everything else has caught up, and Java now looks increasingly like the wrong language for general purpose programming. So what's the right language?

Back in the 1980s everyone gave up on LISP because it needed machines which were too expensive. But the sort of horsepower LISP needs is now cheap, and, indeed, LISP is economic of machine resource compared to many modern language systems. The downside of LISP as an implementation language is that while Web hosting companies these days often provide PHP and are reasonably comfortable with Java and Ruby, a toolkit which uses a LISP foundation can only really take off with people who control their own servers. But, that apart, LISP currently looks like the best bet to me.

I distribute my software for free, in the hope that it may be useful - to you, among other people. Consider it a gift. If it breaks it will even send me a bug report, and I'll look at it for you for free. Oh, you want to be able to sue me if it breaks? Then I shan't give it to you.

I distribute my software for free, in the hope that it may be useful - to you, among other people. Consider it a gift. If it breaks it will even send me a bug report, and I'll look at it for you for free. Oh, you want to be able to sue me if it breaks? Then I shan't give it to you.

I'm a fellow lone coder.

<aol> Me too </aol>

...I'd say that the GPL ... generally make it tougher to make a living.

And I'd say that the GPL is the one thing that guarantees we'll continue to be able to make a living. The GPL and keeping software patents out of Europe are the two things... Sorry, I'll come in again.

No-one expects the Polish Opposition!

I'm a fellow lone coder.

<aol> Me too </aol>

...I'd say that the GPL ... generally make it tougher to make a living.

And I'd say that the GPL is the one thing that guarantees we'll continue to be able to make a living. The GPL and keeping software patents out of Europe are the two things... Sorry, I'll come in again.

No-one expects the Polish Opposition!

It seems they've some work to do in ordering their search results.

I make a living writing custom browser based applications, and mostly use JSP/Servlets for the job. . . So I feel that I am part of the "Java user community" and as such I can tell you that I would feel no relief if Sun chose to open source Java.

Microsoft effectively broke Java by extending it to allow the implimention of native windows widgets that wouldn't run cross platform and since Sun owns Java they were able to sue, and win. I think if Java were open source MS would be free to break it again. It's an old argument and one that we have heard over and over again but it has staying power, I believe, because it is true.

Oh, do read the fscking article before posting, just for once!

Yes, I too make my living writing (mainly) servlets. I think this article makes a lot of sense. The whole stack of tools I use for Java is open source. Partially this is necessity: the stuff I write and sell is open source, so it can't depend on for pay components. But it also can't depend on closed source components because my customers need to know that they can still maintain it if I walk under a bus. They need to have the source.

And, frankly, in today's climate, the same applies to Sun. The computer game is too rough and too fast moving for any second-tier player, like Sun, to have any guarantees of surviving. And people aren't going to bet their businesses on a technology which might disappear from under them just because Bill Gates decided to buy Sun with the spare change for a couple of beers.

If Sun choose - as this article suggests - to dual license Java, with one license being entirely closed and proprietary and the other being the GPL, then Microsoft cannot legally poison the well. Any change they make, they have to publish the source.

If Sun GPL Java they still own Java and they can still sue if Microsoft breaks the terms of the GPL. For Sun to adopt the strategy outlined in this article would, in my mind, be a win for all of us - for you and me as software developers, for our customers' security in their business strategies, and for Sun. I really hope (but don't in the least expect) that Sun will follow this advice.

Do you know how to read? Try reading the GPL. It requires any derivative works to also be GPL. That's a restriction, because it means you can never make software that is available for sale from anything that has been opened as GPL.

No, it's not a restriction at all. No-one forces you to make a derivative work. If you don't like the licence the original author used, you can do a clean room reimplementation - something I personally have had to do a number of times.

Pretty serious restriction, if you ask a professional programmer. I am one, I know.

Yes, sonny, we know. Most of us here are; I have been for eighteen years. It doesn't give you the right to steal other people's work.

There are several different builds of IE5 floating about and they are significantly different at least at the HTTP level; I know this to my cost because (at least) one generates incorrect RFC 1967 headers, and this breaks my maybeupload package.

IE 5.5 and IE 6 are much better. While I use Konqi as my browser of choice, there's no doubt that the latest IEs are very good.

Background: I'm a middle aged CTO of a small software company. A year and a half ago we open sourced (BSD license) some of our core components, partly because we thought we might get some more exposure that way, and partly because we use a lot of open source stuff and it felt like time to give some back.

Recently I needed a basic component. I could get it, but it was proprietary, so we couldn't distribute it with the open source stuff we'd already put out. So I developed it from the start as an open source component, and already I've had patches contributed by half a dozen different people who are using it and finding it useful. By making it open, by inviting collaboration, I've had a lot of the work done for me.

And what that made me think about was artificial scarcity.

During the Irish potato famine, Ireland exported record quantities of wheat. During the Ethiopian famine in the Eighties, Ethiopia was exporting water melons to Europe - you could by them in the supermarkets. Food was not scarce, people just couldn't afford to buy it. The scarcity wasn't real. It was artificial scarcity created by 'market economics'. What's this got to do with software? Hang on...

Glaxo (and other pharmacutical companies) are trying to prevent the South African government from allowing cheaper, 'generic', anti-AIDS drugs. 10% of the population of South Africa is HIV positive. In other African states the figures are worse. Over one hundred million africans have HIV or AIDS. They don't have drugs to ease their suffering, because they can't afford them. But the drugs are cheap to make. They're only expensive to buy because the industry is using its patents to create an artificial scarcity. A hundred million people are suffering and dying to enhance the profits of the drug companies. What has this to do with software? Hang on...

Classical economic theory says that the price of a good varies inversely with it's scarcity. Goods which are extremely rare - like caviar, or diamonds - are expensive. Goods which are extremely abundant - like farmed salmon, or sand - are cheap. But digital information goods - computer programs, or digital recordings of music or movies - cost nothing to reproduce. Inherently, they are infinitely abundant.

I can make one copy of Apache for every person on the planet, and it costs (almost) nothing.

I can make one copy of Microsoft Office for every person on the planet, and the copying costs (almost) nothing.

The natural price of software goods, according to classical economics, is near zero.

Just now, people pay a lot of money for a copy of Microsoft Office. Microsoft are able to charge that money because of artificial scarcity, just like Glaxo can charge for their AIDS drugs. But Microsoft can't sell IIS for lots of money, because there isn't artificial scaricty in high-quality Web servers.

As projects like KOffice get better, so there won't be artificial scarcity in quality office software, and Microsoft won't be able to charge so much.

There are real costs in developing software, but the generosity of a community acting together can absorb the costs, and publich the source code for free. Similarly there are real (and larger) costs in developing new drugs. But the principles of common community action and common generosity can, taken over the community with an interest in the cure of diseases, absorb those costs too.

Open Source does not only have to apply to software. It can apply to every product where commercial interests try to create artificial scarcities by controlling access to information. The next revolution may well be open source medicines. Chemists, clinicians and health administrators could collaborate over the net to develop new medicines which anyone could make for no more than the cost of the ingredients.

The point is that many - perhaps most - people are creative. We like to see the things we create being used to help other people. No one individual can afford the time to invent a cure for cancer, any more than any one person can afford the time to create a new operating system. But the net allows people to collaborate and contribute the quanta of time, energy and talent that they can afford to give, and now we've got a free operating system.

Software is an almost pure case of the sorts of things that can be developed by co-operative generosity. It costs relatively little to acquire the tools to co-operate in a software development project. It costs a little more to get into co-operative development of hardware, or medicines, or some kinds of engineering, and so these things will follow more slowly. But the example has been given, and I'm convinced these things will be given.

Taken together, open collaborative projects in different economic areas will inevitably challenge the morality under which it is ethically acceptable to create artificial scarcities which cause suffering. The world will change as a result of what we, as hackers, are doing now, and it will change for the better. We are talking about a revolution here.

Microsoft Question 5: XML has never been core to Java; rather Sun has attempted to bolt it onto the side after the fact. For example... there is no way to generate XML from a JDBC ResultSet.

here's one I prepared earlier.

In short, my conclusion for now for our project (based on the knowledge of our user's abilities) is that Jabber just isn't there yet on the client front, on Linux. Maybe it will be in 6 months or more. For now, AIM is a great alternative, despite the worrys of AOL's control over the protocol.

I really don't agree. I was able to install gabber (the gnome client) by just adding one line to my sources.list and typing apt-get install gabber. I find it works just fine. I've tried to install the Konverse client but haven't yet had success with that. The Java Applet client also works fine on Linux; the pure Java Swagger client works, but isn't (as yet) nearly as polished as gabber or the Windows clients.

But Gabber just works[tm] and is easily up to the standards of the Windows clients. Recommended. The server is also extremely easy to get set up and running. This is often extemely important: if you're setting up a system for communication inside any commercial organisation, you really don't want your messages routed through someone else's server.

Oh, and, re your .sig, if you want to do XML and stylesheets and stuff with Apache or Jigsaw or WebLogic or more or less anything, really, you probably want Jacquard ;-)

Now I need to add file upload capability; there is a file upload component out there, but the license is weird and definitely not compatible with what I'm doing. So I'm going to have to reinvent that wheel, and I'm going to have to do it 'clean room' even though I know that there are a lot of tricky little tweaks which someone else has already sorted out...

There's no doubt that open source licensing is a bit of a mess. I've a great deal of respect for RMS; we wouldn't be anywhere like where we are now without him. But at the same time after a lot of thought I've decided that the BSD-style licence is best for what I'm doing, because I want my work to be useful to the widest possible number of people and that explicitly includes people working in shops where they aren't realistically going to be allowed to publish their mods.

I'm increasingly of the opinion that life would be a lot simpler, and we would get a lot more innovation done, if the Intellectual Property laws (including copyright) were just scrapped. And yes, I do earn my living doing this.

Brief summary of the argument: our customers are not the people who buy toolkits and components, they're people who buy completed applications. But in order to deliver completed applications we need a toolkit to build on. If we try to keep our toolkit proprietary, it will fall behind competing toolkits (such as, e.g., Enhydra) because we don't have, inside the team, enough people to develop it and debug it fast enough.

We could adopt another toolkit (such as Enhydra) but if we do we become just another user of the toolkit, with little control over its direction and no particular reason for people who want things built with it to come to us. By being the core of an Open Source project we get potential for kudos, the ability to steer the project, and, hopefully, a wider user base for the toolkit contributing patches and extensions.

Brief summary of the argument: our customers are not the people who buy toolkits and components, they're people who buy completed applications. But in order to deliver completed applications we need a toolkit to build on. If we try to keep our toolkit proprietary, it will fall behind competing toolkits (such as, e.g., Enhydra) because we don't have, inside the team, enough people to develop it and debug it fast enough.

We could adopt another toolkit (such as Enhydra) but if we do we become just another user of the toolkit, with little control over its direction and no particular reason for people who want things built with it to come to us. By being the core of an Open Source project we get potential for kudos, the ability to steer the project, and, hopefully, a wider user base for the toolkit contributing patches and extensions.

Brief summary of the argument: our customers are not the people who buy toolkits and components, they're people who buy completed applications. But in order to deliver completed applications we need a toolkit to build on. If we try to keep our toolkit proprietary, it will fall behind competing toolkits (such as, e.g., Enhydra) because we don't have, inside the team, enough people to develop it and debug it fast enough.

We could adopt another toolkit (such as Enhydra) but if we do we become just another user of the toolkit, with little control over its direction and no particular reason for people who want things built with it to come to us. By being the core of an Open Source project we get potential for kudos, the ability to steer the project, and, hopefully, a wider user base for the toolkit contributing patches and extensions.

Last summer I wrote a paper advocating to my colleagues that we open source our core Servlet toolkit. After some discussion they agreed, and the toolkit is now available here. The paper is a purely business argument, and you might like to consider whether any part of it would be useful in your case.

The point at which we finally announced it as Open Source on Freshmeat and on the Java newsgroups was only a month ago, so we haven't really much experience yet; we've had some hundreds of downloads, but as yet absolutely no feedback.

Do I regret open sourcing? Not at all. The only regret I have is that we didn't do it much earlier. In some sense our competition is Lutris' Enhydra. We started work on our toolkit before they did on theirs, and were, at the time, a similar sized team. By open sourcing early, and proselytising widely, Lutris have not only gained themselves huge visibility (and apparent success), they've also been able to develop their toolkit a lot further than we have ours, partly because other people have contributed to it but also, I suspect, because they've got a lot of business as a result of their visibility. This isn't sour grapes - I respect those people, they've started from the same place and been more successful than we have.

Last summer I wrote a paper advocating to my colleagues that we open source our core Servlet toolkit. After some discussion they agreed, and the toolkit is now available here. The paper is a purely business argument, and you might like to consider whether any part of it would be useful in your case.

The point at which we finally announced it as Open Source on Freshmeat and on the Java newsgroups was only a month ago, so we haven't really much experience yet; we've had some hundreds of downloads, but as yet absolutely no feedback.

Do I regret open sourcing? Not at all. The only regret I have is that we didn't do it much earlier. In some sense our competition is Lutris' Enhydra. We started work on our toolkit before they did on theirs, and were, at the time, a similar sized team. By open sourcing early, and proselytising widely, Lutris have not only gained themselves huge visibility (and apparent success), they've also been able to develop their toolkit a lot further than we have ours, partly because other people have contributed to it but also, I suspect, because they've got a lot of business as a result of their visibility. This isn't sour grapes - I respect those people, they've started from the same place and been more successful than we have.

This is a field where Linux could be leading the pack, but is instead an example where I think we are lagging behind. (I hope someone can point me to a group that is bringing XML deep into the linux os)

Not so, fortunately. A certain very large telco (which I'm not yet allowed to name) is now running its Intranet directory on an XML/XSL application which I've written. The application was developed on Linux and is currently running on Linux, although the customer intends to move it to Solaris.

My XML intro course is online; it's a little out of date at the moment but will be updated over the next few months.

XML and particularly RDF do have a lot to offer for search engines - see my other note further up this thread.

But the biggest win will come from minimising the proliferation of DTDs. If the community can co-operate on the development of common DTDs then the exchange of data between software agents developed by different projects will be hugely easier. By all means have diffrent projects - both KDE and Gnome have, in my opinion, benefited from the competition between the two - but if that competition develops the sort of bitterness which reduces communiction and co-operation we all lose.

I would strongly urge anyone who is developing a new software agent - whether it's a user-level application or a new daemon - which either stores data or exchanges data with other agents to seriously consider XML as a format, but more importantly should look at the DTDs that already exist to see if any will fit, and should communicate with anyone else working on related tools.

If anyone wants to look at the XML tutorial I gave at INET99 it's here