After one week of mulling over what license Hardwire will use, I’ve finally decided to use GPL v.3.

Here’s a peek at my comparison matrix:

I didn’t use MIT and LGPL because I thought it was too permissive. I didn’t want others to earn from my work without them contributing to the code base.

LGPL was out of the question because it is mainly used for libraries. Hardwire isn’t a library.

This narrowed down the decision between Apache and GPL. Initially I liked Apache because a lot of users at code.google were using Apache. GWT is licensed under Apache as well. But licensing under Apache would mean allowing Hardwire to be modified and used in commercial closed source software. This is something that is contrary to the goals of free software. I was sold on the idea that free software wasn’t about price but about contribution and making things better. I believe that a collective effort is always better and with many people, many good things can be achieved. In terms of code that means a wide user base and lots of support. This is what I think is behind the success of WordPress and the programming language PHP. PHP isn’t a great and pure a language as Python but there are a lot of PHP users compared to Python which I think makes it more attractive to use (though having said that Python is still better for me! ).

So aside from the issue with commercial closed source software usage, Apache and GPL are pretty much the same.

For the benefit of everyone, I think I’ll post my findings in another blog post soon.

“Published software should be free software. To make it free software, you need to release it under a free software license.”

- http://www.gnu.org/licenses/

by mlinksva

It took a while for the idea of licensing Hardwire to sink. But when it did, I have already made some important discoveries not to mention the sigh of relief I made after weathering a lot of readings about the topic over the past few days.

Free Software !=No Business Model
This would be the jackpot of all discoveries I made. There was a point in my reading where I began to have second thoughts about applying an open source license. I thought by doing that it completely stowed Hardwire as freeware. But as I’ve found out, the Free in Free Software doesn’t have anything to do with price.

The Free in Free software means Freedom and not as wikipedia says, “Free Beer”. It means that the software can be used modified, edited without restriction. Although Free software is “available without charge, it can have a fee”.

So yes we can still apply some sort of gimmick to earn money from the software such as support, customization, distribution and fixing bugs. Whew.

Code.Google has been very helpful in helping me narrow down the list of licenses to choose from. I am now picking from a list of popular licenses with a strong community:

• Apache License, 2.0
• New and Simplified BSD licenses
• GNU General Public License (GPL)
• GNU Library or “Lesser” General Public License (LGPL)
• MIT license
• Mozilla Public License 1.1 (MPL)
• Common Development and Distribution License
• Eclipse Public License

Since Hardwire could be like WordPress, I am inclined to use the GNU license which is the same license that WordPress uses.

1. Diving into Android
2. A Hint of Dependency Injection in Android…or Not

…Android!

(click)

I was dismayed that our paper was pulled out of the PCSC last month because my advisers said our findings were inconclusive. I didn’t know what was wrong. We patterned our paper after a project which is similar to ours. We had all the headings — Introduction, Features, Workflow, Test Methodology, Results, Discussion, Conclusion and Work in Progress. I thought writing and getting the introduction approved so much ahead of time would benefit us and save us time when it came to writing the paper. I also spent a lot of time reading Stephen Downes’ article on the Future of Elearning. I did a review on that. It was very arduous. There were terms I didn’t understand. I had to look them up in Google or read blog posts about them. God knows how many kilometers I’ve paced back and forth in front of my (back then) P.C trying to think about what the concepts meant. Actually starting to write was the worst thing of all.

But after I came back from the hospital Dan gave me a stack of papers about Personal Learning Environments. My first thought was to read some of them so I can compare them with our paper and see what we lacked. I liked the conceptual study on PLEs by B.Taraghi, M. Ebner, G.Till and H. Muhlburger from the Graz University of Technology in Austria so I used that as reference.

Here are the notes I have taken:

1. The Paper is a bit okay…at least the Intro Part.
I have established the grounds for a PLE and ended by saying the objective of the paper, that it is an “implementation of the concepts of personalized learning”

2. Where is Hardwire? and how does it look like?
I kept on saying that Hardwire has been deployed but I didn’t give a link. Furthermore the paper comes of as abstract. I think I need to put screenshots elucidating the work flow so the reader will understand how the features work. On second thought, the Hardwire’s UI is pitch black. I wonder how the screens would look like if it were printed on black and white. Gaaaaaah.

3. Definitions.
I have found that I’ve been assuming all this time that the readers of my paper are like me or understand the technologies I am using. There are so many terms that I left vague such as “POJO” which stands for Plain Old Java Object. I don’t think a lot of people will understand that.

I also use terms that I don’t define even just a little. For example, Web 2.0 doesn’t have an industry standard definition. There are even some people who don’t accept the term and what it stands for. Maybe here I should just enumerate its characteristics.

I am also thinking about whether to include unit testing as part of the test methodology. While writing the paper last January, I’ve found describing this test methodology very hard. Although I’ve already asked help at StackOverflow.

4. Details
Our advisers mentioned this before already and I only understood it after reading my reference. This only means that I should discuss things in my paper even more. Talk about talking. Since the paper is I quote an “implementation of the concepts underlying personalized learning”, I think I should discuss the details of the implementation details. Why did I choose GWT over raw javascript? Why Google App Engine? Why Java over Python (ooooh that’s a hard one to answer given that I have learned to love Python)?

5. Some more tests to come
Finally, I’ve realized why the paper is inconclusive. It still needs to convince where the implementation . But in my first draft, I can only see the paper saying the test failed and we need to move hosts so we can test again. That’s why we’re coming up with more tests to evaluate the project (Usability with Feedback, Web Service Test) and tell where future work should be done.

That’s a lot of points to consider. My notes actually look even more daunting. Am I being to hard on myself? I guess not, it’s good to be your greatest critic.