Kirsle.net
On my many attempts to learn C++ I never actually made anything useful that wasn't a tutorial-like program (with the exception being a single-threaded CyanChat library I was working on but never completed). So this time I decided to just skip the tutorial b/s and dive right in to making a RiveScript C++ library, and Google things as I run into them.
I knew about C++ strings (who doesn't?) which are a big improvement over what C has, but I newly discovered vectors (dynamic resizable arrays) and maps (associative arrays) and among these three, it covers all the basic data types I'm used to in Perl.
I hit a roadblock though when it came to constructing the large data structure that the Perl RiveScript module makes and which I'm familiar with, but looking into C++'s struct solved that pretty quickly.
All this attention to RiveScript lately, though, made me remember the point about how the Perl RiveScript module (the only feature-complete implementation of RiveScript to date) is released under the GNU General Public License, which would demand that any application that uses it also be released under open source.
I was thinking of re-licensing RiveScript under a more open license to see if it could drive up usage of it for non-GPL projects. I was considering something like the LGPL, Apache or BSD license. But, I think I have a better idea!
At work I was using ExtJS for a while and I saw how their licensing scheme works: they dual-license their code; the GPL licensed version is free to use, but being GPL code it demands that your entire application be made open source. They then have a commercial license that allows you to use their library in a non-open application, for a fee.
I think this may be the better way to go. For the open source folks who use RiveScript today nothing changes, but if somebody wants to create a commercial application with RiveScript they wouldn't be able to use the GPL-licensed version. After watching all the news about SmarterChild and its parent company (Colloquis, now owned by Microsoft) over the past decade, with their chatterbot patent and their commercial SDK, giving out free code that can be used in a commercial closed-source product doesn't seem like a very smart move. ;)
The chatterbot patent now owned by Microsoft is groundless anyway, because the Net::AIM module on CPAN released in 1999 ships with an example script for an AIM chatterbot which pre-dates ActiveBuddy's inception in 2000. ActiveBuddy's claim that they invented the AIM chatterbot falls in the face of prior art.
The Android OS project, for example, opted to release the core Android components under the Apache license, rather than the GNU General Public License (GPL) which is usually popular with open source GNU/Linux software.
Using the Apache license was a strategic move for Google, because the Apache license is less restrictive than the GPL; with the GPL, any software you write that incorporates GPL code must also be released, in its entirety, under the GPL license. Just by using GPL code in your application, your whole application must be made open source under the same terms as the GPL'd code you borrowed for it.
To put this in perspective, let's imaging a hypothetical story in which Adobe decides to add a new image format into Photoshop, and they use some code for this image format which is released under the GPL license. Because Photoshop is using GPL'd code--even though they're using only a tiny bit in comparison to the rest of Photoshop's code--Adobe would be forced to release Photoshop in its entirety under the GPL license; they would have to provide all of its source code to its users, and you could therefore just download it and compile your own Photoshop from source code.
Proprietary software companies like Adobe of course wouldn't like this, so they don't generally like to use GPL-licensed code in their products; the GPL is considered viral because it "infects" the entire application and forces it all to become open source just because it is. The GPL is a "copyleft" license.
Android's code is released under the Apache license instead because, that way, individual vendors can make their own modifications and additions to the base Android code, and add proprietary features to keep an edge over their competition. If their contributions to the Android core was forced to be made open source, as the GPL would require, they would be less inclined to spend time and money developing their new features in the first place, because their competitors could easily just take their code for themselves in their own Android devices.
So what does this all mean for RiveScript?
RiveScript has always been released under the GNU General Public License, which would be great if RiveScript was, itself, a complete software application. It isn't. RiveScript is just a library, a Perl module, and it doesn't do anything until you write an actual Perl application that loads the module.
So if somebody wanted to create and sell a closed source "desktop assistant" type application, with a pretty GUI and an animated face and it could speak to you out loud and understand you when you speak to it out loud, and it simply wanted to use my RiveScript module for the artificial intelligence part... they wouldn't be able to release it as a closed source product. The GPL license governing the RiveScript library would force their entire application to be made open source.
This obviously isn't ideal; and so, usually, libraries are released under the GNU Lesser General Public License, which is an ideal license to be used for software libraries.
Under the LGPL, an application would be allowed to use my RiveScript library and still be, overall, a closed source application. The only restriction would be if they wanted to modify RiveScript itself, to add new features to it or extend its functionality in any way; if they touch my RiveScript module itself, their changes would have to be released to the public as open source. But, it wouldn't touch the rest of their product at all; they could still keep their overall product closed source and sell it if they wanted to.
So, I'm thinking I should relicense RiveScript and maybe see if that will help drive more developers to use it in their projects. The LGPL though isn't particularly ideal for a Perl module though since the license deals a lot with terminology like "linking" which only applies to C/C++ code. But maybe the old tried-and-true Artistic License that Perl itself is released under would do just as well.
I'll work out the details later but expect RiveScript 1.22 to be licensed more openly; or, at the very least, dual-licensed to be used in both open and closed source projects.
Now first of all, I'm all for the GNU General Public License. I've been distributing a good majority of my software under that license for years. However, sometimes I pick something that's just a little bit more restrictive. Back around the years of 2002 to 05, I was into programming chatterbots. I originally released them under the GPL license. And then a bunch of jerks had to go and entirely rip off my code, from #!/usr/bin/perl all the way to exit(0). They went through and edited all the source files to find every occurrence of my name and paste their own name in its place. Then, they would zip their new program which they "wrote all by themselves", build a clone of my site and upload their stolen bots and claim that they wrote the bot from scratch all by themselves.
And to make matters worse, when I would find out about this and make a big deal over it, they'd then go and tell their users that I was in fact the one who stole the software from them, and that I tried to set the time stamps on it back to try to prove I wrote the program first. And there was really nothing I could do about it.
So, here's how I divided up my software licensing: Anything that I created and really didn't care about other people stealing it (read: Metacity themes, Tk Calculator), I released under the GNU General Public License, because if somebody wanted to be such a douchebag as to completely rip off my code and stick their own name on it, I would only be a little bit aggravated but leave it at that. But any program that I actually spent a lot of time on and would be thoroughly pissed off to find it plagiarized, I put that under my own proprietary licensing scheme. Now, whether or not anybody actually cared and stole the software anyway, I don't know, but at least I put the license out there in text.
A minor incident came from this on the Gnome-Look.org network. When I first released my Luna theme, I was linking to my site for the download. I hadn't yet created a page for the distribution of GPL-licensed software, so the download page had my own source code license on it. And this of course pisses people off in the Linux world. I fixed it by getting off my lazy butt and making a new download page that followed the GPL. And so divided the licensing scheme site-wide.
So, here's the new licensing deal: all my software will be released under the "I don't give a damn" license, also known as the GPL. That is, if you want to be a dick and steal my software, there's nothing I can do to stop you. Just don't expect any technical support. My technical support for my software extends as far as fixing actual, real bugs in the program, ones that will affect legitimate users just as much as the plagiarists. But don't give me any feature requests. I won't implement them. If the users of "Joe Shmoe's Error Message Generator" wants to have standalone errorbox executables, and Joe Schmoe doesn't know how to make my program do that, he can't ask me to do it for him so that he can rip it off again and offer it to his users. No. Just don't even ask.
So, you see what you shameless code-ripping jerks do? You ruin it for everybody. If you want to rip off my program and then you get stuck when somebody asks you a question that you can't answer, I will not tolerate it in the least if you relay that question to me and expect me to give you an answer that you can tell to your users. I will not put up with it.
0.0020s.
