My first release for the Open Source class

We were tasked with implementing a command called `du` in filer. Now, I am already a contributor to filer so I know about how stuff works in there and what would be expected in this assignment.

My first task was to research what `du` actually did. Well, to be honest, I already knew what it did but I did not know it’s “extra” features such as flags, etc. Straight to Google I go. A lot of what I found I didn’t understand. For example, while looking up the `du` docs, I found that it takes flags such as “-a” and “-x”. But I couldn’t make head or tails of it (at least in the context of filer). So I decided to keep it simple.

By keeping it simple, I mean implementing two extra features since it would be unfair for me to do the same assignment as others who have little to no previous experience with NodeJS, javascript and filer itself. The two extra features were to allow symlinks to be treated as links or files(you can get the disk usage with respect to the space taken by the link itself or the file to which it links) and to allow different size formats (kb, mb or gb) to be specified instead of the default bytes.

So I started to code. It wasn’t that hard. My experience working with rsync code (in makedrive) using recursion certainly helped. Overall it took me maybe two hours to write all the code and the tests. Then,

All my tests pass on the first try. Usually, Dave tells me when that happens, there’s definitely something wrong with your tests. Well, that’s where I spent my next hour…combing through each line of both the implementation and the tests to find a problem. Turns out there wasn’t one. So I was relieved.

So I create a PR and leave it to rest 🙂

Meanwhile, I help one of my other classmates out and also work on another bug. The bug I worked on was to disallow `unlink`’s on directories. That didn’t take me long but I did not follow the Node standard of dealing with the error and that was a recommendation in my PR. But unfortunately, before I could change that (I took way too long to do so), my PR was merged into the master repo. Hmm, well that sucked. Oh well, I made the fix in a follow up bug and that was merged in.

Thanks to these events, I ended up with 3 bugs that I fixed for release 1. I am thus a happy man.

r.gideonthomas@gmail.com / September 27, 2014 / Open Source / 0 Comments

Software Licenses and how we as contributors are screwed

It is well known that proprietary licenses offered by companies such as Apple, Microsoft, etc. are designed in such a way that we can’t see how the magic behind the scenes happens (how iOS works, how Visual Studio is able to make code appear out of no where…). Moreover, not only can we not see code, a lot of the time, we cannot even copy the software  or make backups of it.

As a software developer all I can say is…

while they’re like…

So now to get into it…

If you would like to read the actual license (more than 300 pages) and draw your own conclusions, here is the link to the iOS7 license which is what my focus is on: iOS7 license

But here are the cliff notes:

  1. It is >300 pages long (granted in different languages 10 in English). No one in their right mind would want to read that much boring (albeit relevant and important) information before using software. In fact, several companies use this attribute to hide dangerous terms and conditions because they know that you won’t read them. Sneaky eh?
  2. It specifically states that you cannot, and I quote :

    “copy (except as expressly permitted by this License), decompile, reverse engineer, disassemble, attempt to derive the source code of, decrypt, modify, or create derivative works of the iOS Software or any services provided by the iOS Software or any part thereof (except as and only to the extent any foregoing restriction is prohibited by applicable law or by licensing terms governing use of open-source components that may be included with the iOS Software).”

    This basically means that I can only use iOS but not modify or even see how it works. As a developer and student that basically cuts me off from everything. Consequently, if I want to use a part of iOS code, not only can I not access it, even if I can, I cannot use it in anything.

  3. You cannot sublicense the iOS license nor can you re-sell iOS. This ties in to the above point since you cannot access their code. You cannot put iOS under another license, compatible or not. This also implies the obvious – that you cannot modify their license terms.

But there is hope…ok I admit, the title is misleading. We aren’t totally screwed. We can always depend on something more permissive (and there are several such licenses). So here are the ways the BSD 3-clause license comes to our rescue:

  1. It is barely half a page long. Soooo much easier to read and understand. As a programmer, I am willing to read 3 short clauses.
  2. The genius in this license lies in its ambiguity. It does not explicitly specify anything about whether or not we can copy/modify software under this license. However, it says that redistributions (with or without modifications) must include this license in it, which implies that redistributions can occur which implicitly means that copying/modifying, etc. can be done.
  3. Once again, ambiguity is useful. Nothing is mentioned about sublicensing. Simply put, this means that you can sublicense with compatible licenses.

So there it is…we aren’t screwed after all. But it is clear that as a new open-source developer, which license I will prefer…

r.gideonthomas@gmail.com / September 9, 2014 / Open Source / 0 Comments