Subsonic: questions in open source ethics

So there's a great open-source project out there called Subsonic. It's a streaming media server -- it will stream your music and videos from your home server across the internet/network. It's easy, user-friendly, and has a number of apps for mobile devices.

There's only one problem. You install it, get it configured, then realize that despite being open-source, it's actually shareware. You get the base program, but can't unlock streaming video or mobile access features unless you pay the developer money. And despite him saying "you can donate any amount you want," he only gives you an unlock code if you pay him at least 10 Euro. These locked features are part of the open codebase, but just won't work until you enter an unlock code.

This brings up some interesting ethical questions that I've thought about for awhile. I have no beef with people making money off their software. But the fact that it's open source makes it interesting. Also there's the fact that the website talks about it being free (he doesn't talk about speech vs beer). But then if you read further, you find out that it's not all free (beer). None of those things are problems. But they do make for some interesting questions.

It's open source (GPLv3), so I downloaded the source, and bypassed the registration unlock system. Now I have the full product without donating. What I did was 100% legal. Was it ethical? Does it matter that the author wanted me to donate to unlock it? Does it matter that I felt deceived after I installed it when I realized that these features that the website talked about were actually locked away behind a paywall? Does it matter that the developer had to have purposely chosen the GPL license, so was in effect expressly allowing me to do this?

Let's take it a step farther. Would it be ethical for me to publish a fork that just takes his software and removes the registration requirement? More importantly, would it make me a jerk to do so?

It's interesting, because it's clearly legal, and it's within the general spirit of open-source. But it's also clearly ignoring the developer's request to receive compensation for his work. Is that any different than what CentOS does with Redhat?

.....

Personally, I think Subsonic is great software, so I have no intention of publishing forked code, or even publishing how I bypassed the registration scheme. I figure if the guy keeps getting money, he'll keep making good software. Even if I feel like the donation requirement is poorly worded/explained. But I definitely think it brings up interesting questions.

Maven (cont)

So I finished the book I was reading about Maven. It was amusing paying attention to my own feelings about Maven as I progressed through the book. It went like this:

Introduction and initial explanation: Hmmm, this is interesting, but sounds a bit lame.

Basic tutorials and walkthrough of Maven: Wow, this actually looks really awesome!

Advanced topics, explanations, etc: Seriously, that's how you're supposed to do that? That's awful! And what's up with that weird special case?

Really, it confirms my initial reaction -- if you play the maven way, things are pretty simple. If you try to do something weird, There be Dragons. I'm going to play with it a little more on a hobby project, but I'm not sold on it.

Maven (and Ant, and Make)

For some reason I've had a lot of ramblings in my brain lately, making me want to post. So here I go.

I've been reading up about Maven (thanks, Rob), trying to wrap my brain around it. And I'm torn. I can't decide if I think it's wonderful or if I hate it (most likely, it will resolve to being like most tools, which is "useful but with a handful of caveats").

For some background, most of my experience with automated build systems comes from Make. And let me tell you, other than the syntax (which is one of the worst crimes against humanity), Make is incredible. Make is less about procedurally defining your build, and more about creating a bunch of rules about what files you need, and how to go about generating them. It then recursively looks at the dependencies of those files, and how to generate them, etc. It's a thing of beauty. (Again, other than the syntax). When I was working on Anguna, my makefile did all sorts of crazy nasty things to build my project: converting room definitions, converting sprites and level graphics, using perl scripts to transform certain scripts into C code which then got compiled, etc etc etc. It was a weird, complicated build. And my makefiles were weird and complicated and ugly. But they were great in that Make automatically understood and handled knowing when to rebuild files (based on the sources changing) and when not to. And not just for C source, but for the whole build process.

Then I started doing java development at work. And for a long time, Ant was the defacto build system for java. This felt like a complete downgrade after working with Make. First, Ant is extremely procedural. Sure, there are targets that can depend on each other, but (as far I have found, not being an expert on Ant), the ability to check dependencies to avoid rebuilding only occurs for java source/class files. If I have to run weird commands to convert an image file to the right format, Ant doesn't seem to know how to check the source image file for changes before converting it. (Again, maybe I'm wrong, I rather hope so). And Ant's syntax is only marginally better than Make's. Instead of terse weird symbols and problems with tabs/spaces, everything is xml. Writing procedural code in xml is just dumb. So Ant felt like a step back from Make as far as overall flexibility and utility, but still wasn't terrible, as it still let you wire up weird builds and do whatever odd build steps you needed. I guess the biggest con of using Ant was that it didn't make the easy parts easy. Building and jar'ing a simple java project still required a good amount of xml.

Then along came Maven. I'm not hip and trendy enough to have started using Maven early on, but I haven't been able to avoid it forever. My first experiences with it were awesome, trying to build various existing open source projects -- you check out somebody's code, do "mvn install" and it actually goes and downloads dependencies and the build works the first time. When does that ever happen?

But when I started using Maven for some of my own projects, I started to get a little frustrated. The pom file (the maven equivalent of the makefile or build.xml) specifies almost nothing. What if I want to copy a bunch of files to a different place partway through my build? Or run some weird commands? What's actually going on?

As I'm learning, Maven has a lot of conventions. It's like Steve Jobs and Apple -- if you are happy doing it the way they want you to, it's great. If you try to do something different, beware. In Maven you spend less time specifying the steps you take in your build, instead you're mainly telling it what kind of build you are doing, and Maven assumes you are doing it the same way as everyone else, and then (hopefully) just works. In this case, Maven seems to be making the easy easy (unlike Ant). If you put your code in the right place and are doing a build that matches one of the many standard builds that exist (or that there are plugins for), then it's really easy, and everything just works.

Things get harder when you try to do something different, or weird. Unlike Ant and Make, you can't simply and easily tell it what steps you want to do -- the step definitions are all buried in layers of plugins and defaults. Not that it's not possible, but it requires digging in and mucking about with how maven really works. Unlike Ant (where accomplishing the easy things and the hard things are both a little bit of work), in the Maven the easy is REALLY easy and the hard is pretty hard.

The more I think about it, thinking through this by writing, the more I think Maven is a good thing, especially when you're willing to follow its conventions. But that doesn't always it's the right tool for every job.

Now I just need to read more about calling ant scripts from Maven (which is possible, and might solve some of my issues), and read up on Apache Ivy, which seems to be a useful tool for managing dependencies without living in a world as script as Maven's.

Oh, and why I gave up on Anguna for IPhone

While I'm here posting stuff, I never really explained what happened to Anguna for iPhone.

I gave up and quit.

For a few reasons:

First, I got a bit bored. I was tired of writing the same game for the 3rd time. Most of the interesting parts ported over pretty quickly and easily. The parts that were left were mainly fiddling with asset (graphics and sound) formats. And that was no fun at all. (If I was smarter, I might have figured out a way to automate some of the conversions, but they tended to be really fiddly based on how I handled them on the GBA/DS side).

Second, I got frustrated at Apple. I paid them my $100 for a dev license. And then part way through development, they changed their developers terms with a clause that strongly sounded as if they wouldn't approve any apps that were using the 3rd party toolkit I was using. Their wording was just vague enough that it was hard to be sure. Talk about discouraging. I paid my money, was half-finished developing my game, and suddenly they decided that my game might not pass their terms. A few months later, they changed it again, and this time the game would have been fine. But at that point, I was done with it -- I have no interest in trying to hit a randomly moving target of what's allowed to be published.

Third, which was really a result of the first two reasons: my annual developer license expired. I didn't finish the game in the first year, and had to decide if I wanted to fork over another $100 to try again. I enjoy doing hobby development, but I don't enjoy having to pay a subscription to do so. So that was the end of that.

So there you have it.