Why do we copyright software?
Permalink
Aug 21, 2002
For at least a couple of decades we've been copyrighting software, and now I realize that I don't understand why we do. Talking with Doc Searls last night, who is a master of analogy, we kind of agreed that perhaps there is no suitable analogy for software, that software is a unique thing unto itself.

First: Yes, software is unique. I don't want to go too deeply into that though as that's a very, very long story to do it truly correctly.

Second: Rewriting the question a bit (I believe fairly) to be "Why should we copyright software?", I would observe that there is more to copyright then most people think, some of which is just implicit in the copyright.

Holding a copyright on something means you can enforce the integrity of the work, whatever it may be. It means that nobody can download Radio Userland, rename it, write Userland (and all other attribution) right out of the codebase, and sell it for $20 a pop. "Moral rights" like these are so importent in Europe that you actually can't sell the right of attribution. No matter what else you sell to some company, you retain the credit.

Holding the copyright to the software also ensures that Dave & Userland retain control over Frontier et al. Nobody can pick it up and force it in a direction contrary to the wishes of Userland. Dave has written somewhere about how importent this is to him, but I can't find a reference. (IIRC, he mentioned this in the context of open source and possibly open-sourcing Frontier.)

When you don't treat copyright as a stick to beat people with, but instead as ethics codified into law about how we treat each other's work, there's nothing objectionable about it, and no reason not to apply it to software.

That said, it must be applied differently, and again, explaining that is a long task. (In fact, I've got a currently 70-page "essay" that I've resumed work on that still has only barely explained why this is true; I still need to propose my solution. I wish I could write as quickly as I could think.)


Followup to "Damn DRM!"
Permalink
Aug 21, 2002

A follow-up to Damn DRM!, in which I refused to buy a book explicitly because of DRM issues: Rob Tsuk suggested in a comment that I try the Palm version of "A Fire Upon The Deep", as there is a Windows-(and Mac-)based reader available, which probably wouldn't have the licensing provisions I objected to.

I have tried this, and it worked. I was worried that the PC-based reader might not read encrypted content, but it does. And the EULA was quite standard, so no objections. I ordered A Fire Upon the Deep: Special eBook edition from Peanut Press, and it's working fine. I haven't gotten past the prolog yet, so I don't yet know if it was worth it, but I'll post a follow-up.

Thanks, Rob Tsuk.

It would be worth your time to browse around that site. There are quite a lot of books available, at least in the sci-fi area. I was pleasently surprised by the selection.


tcp.im hints
Permalink
Aug 17, 2002
Jabber

Untitled markpasc post:

Hint for Radio IM: deHTMLize an item with string.htmlToEmail.

A few hints and tips regarding coding and decoding in tcp.im:

Both AIM and Jabber have the ability to send HTML messages on the network, as do many of the other IM systems. (All that I know of can send formatted text, I don't know that they are all HTML as opposed to, say, RTF.) However, they are almost completely different. AIM sends half-assed, crappy HTML without close tags, inconsistent capatalization, etc. Jabber strictly requires compliant XHTML, or you'll ruin the whole connection.

The only solution I could find was to make tcp.im.send only send text; if you try to send HTML, it will actually encode it such that the receiver will see the HTML. Thus, tcp.im can't actually send HTML over the wire. However, the highly beneficial side-effect of this is that it is perfectly possible to reliably send HTML messages, as long as the user manually types the HTML, and that HTML need not be compliant with anything (even in Jabber), because the IM network just sees < (encoded entities). The blog poster and the manila poster both use this to their advantage. Work with this, not against this; do not try to use the IM system's HTML capabilities from within tcp.im.

You can use the drivers directly if you need to for some application.

The corresponding philosophy on the receiving end is to try to receive exactly what the user typed (except that whitespace may be altered by the transport, as AIM does), without any formatting.

This information will be particularly importent to anybody wanting to write a driver for a new IM network, but it will matter to tcp.im developers, so they know what they are getting and what they are not.

So, as markpasc suggest, string.htmlToEmail is a good way to convert any HTML you might want to send into pure text, which you can ship around however you like.

This post may later be altered to just point at the appropriate documentation.


Jabber feed transition
Permalink
Aug 16, 2002
Jabber

With the (impending) release of tcp.im to the general public, this marks a transition of my Jabber only feed.

If you are reading this feed solely to watch the status of the Jabber work as it goes public, you can unsubscribe now; it's done.

I will continue to blog interesting things people do with Jabber in Radio and any further Jabber-specific work I do, if any.


tcp.im!
Permalink
Aug 16, 2002
Jabber
Heads-up, some time in the next few hours (Murphy-willing) we're going to release tcp.im, which allows Radio and Frontier to be an instant messaging client or server (either can be either). It was a collaboration between Eric Soroos, Jeremy Bowers and myself; with Jake Savin doing the close. There may be some bugs and more docs to write over the next few days. Should be final on Monday.

Excellent.

tcp.im essentially exposes a reasonable amount of the intersection of the capabilities of AIM and Jabber, with an eye towards easily incorporating anything else that wants to play. So in technical terms, the framework is not necessarily terribly capable. But because of the cross-IM-platform nature of the code, it's gonna have a lot of juice.

I did some research on the web a while ago; as far as I know, tcp.im is (currently) unique. There is no library available that tries to flatten the differences amongst the various IM networks, to make it easy to write tools that works with all of them. (I may be wrong, of course.)

Underneath tcp.im, there are capable drivers for both AIM and Jabber. Att DJ Adams and Jabber crew, with this release, everybody will have Jabber drivers in their Radio Userland installs. You can look at the Jabber driver documentation now, if you like.

There's a lot of fun to be had, both with the tcp.im framework, and working directly with AIM and Jabber. Let's rock!

As a final note, this officially terminates any usefulness TextResponder may have had. You're not likely to care, but in some abstract way, it should be mentioned here as a form of closure.


<- Future Posts Past Posts ->

 

Site Links

 

RSS
All Posts

 

Blogroll