Lit Review 2: Itunes ToS, Fedora Project Contributor Agreement, and Python Software Foundation CLA

Who:

Itunes TOS was written up by Apple. The Fedora Project Contributor Agreement (FPCA) was written up by the fantastic legal team over at the Red Hat legal department. the Python Software Foundation CLA (PCLA) was written up by the Python Software Foundation

What:

Itunes TOS is just terms and conditions for usage. The FPCA is guidelines for project contribution to any existing Fedora projects. The PCLA is a form for signing your project up for distribution.

Where:

You can find the Itunes TOS here. You can find the FPCA here. You can find the PCLA here.

When:

Apple's TOS was last updated September 17th of 2014. The FPCA was last updated last month on February 3. It is unclear when the PCLA was written and is not easily listed on the site.


The Gist:

The Three documents are essentially just different kinds of usage requirements. Itunes is far more straightforward as it is a general product, while the SPCA is a guideline for contribution. The PCLA is meant for distribution rights.

The Good:


In general, not that long (PCLA)
Serve an important function for the community (SPCA and PCLA)
Kept up-to-date



The Bad:


Very much legalese (Itunes and SPCA)
Not very nicely formatted (Itunes)
A legal document, but not really clear on much (PCLA)



Any Questions?


How can one re-license code without having the copyright?
Why the specific licenses presented in the PCLA?



Final Thoughts and Rating:


Each of the three texts serves an important function. Itunes has a usage agreement due to it being a platform for content distribution. Meanwhile the SPCA and PCLA both are meant for actual content creation and as such have more guidelines following along those details, which aren't really required for the Itunes TOS. Overall, they each have their role and should be judged on their ability to fulfill that role. 8/10 overall.

Literature Review 0: Legal Issues Primer Chapters 1 and 2

Keeping it rolling with a review of the Handbook for the Business and Legal Aspects of FOSS class: A Legal Issues Primer for Open Source and Free Software Projects. Quite a Mouthful. I'm going to go with "The Primer" from this point forward. This will be reviewing the first two chapters in particular.

Who:

The Primer is written by a laundry list of who's who of FOSS: Richard Fontana, Bradley M. Kuhn, Eben Moglen, Matthew Norwood, Daniel B. Ravicher, Karen Sandler, James Vasile, and Aaron Williamson.

What:

The chapters of The Primer we are covering today detail much of the Primer is and some basic details on a couple of the many licenses that you can choose to file your project under.

Where:

You can find a copy of The Primer here.

When:

The Primer hasn't been updated in a while, but the last revision was put out in 2008.

The Gist:

The two chapters of The Primer that I am covering are detailing mainly what The Primer is and is not, as well as going into what certain licenses are meant for and a basic idea of when they should be used.

The Good:

1. Very clearly states that it isn't meant to replace sound legal advice.
2. Fairly easy to ready and clearly explains legal jargon.
3. Broaches several topics that are important for deciding your license.

The Bad:

1. Doesn't go too deep into many different licenses.
2. Slightly outdated.
3. Is a dry read, as expected of legal advice

Any Questions?

1. Why not include license X?
2. Why use the previous version of the GPL as opposed to the most recent?

In Conclusion:

Overall, The Primer was an okay read, but it offers sage advice that anyone who is planning on starting a FOSS project should definitely take a look at, at least to some degree. It will not replace proper legal counsel, but it can at least get you started on your way to knowing what is going on in the legal realm. 9.5 Lawyers/10

Video Review 0: Everything is a Remix

Time to get back into the swing of things with a video review: Everything Is A Remix

Who:

Everything is a Remix was made by Kirby Ferguson.

What:

Everything is a Remix is a 4-part video series detailing how...well...Everything is a remix of something else and how we create.

Where:

You can find Everything is a Remix here. You can also find the author's site, where he is also hosting other work here.

When:

Everything is a Remix was created over the course of 2011, with the last part released in December of that year.

The Gist:

Everything is a remix is a short documentary that is focused on showing how throughout modern history, our major breakthroughs are based on copying and improving upon existing ideas. Each part focuses on a different medium, from music, to movies, to technology.

The Good:

1. Highlights that no idea is entirely original
2. Individual parts are concise
3. Ideas are well formulated

The Bad:

1. Overall short length leaves many topics discussed very minor
2. Doesn't address issues with copyright law until very last part
3. Last part jumps around a large amount

Any Questions?

1. What are some of the more egregious things that have gotten away with being copied?
2. Are there more examples of things that were unfairly tried for their copying?
3. What are some of the ways that we are working to confront these issues?

In Conclusion

Overall, Everything is a Remix is a great conversation starter on the subject of copyright law and what it means to infringe upon the work of others. That said, it doesn't go in very deep detail and will be unlikely to do anything for those that are already invested in the subject. It should serve to enlighten a few more people about some of the dangers that intellectual property faces in the current age though. 8.8 Remixes out of 10.

Business and Legal Aspects of FOSS: First Flight

And so begins another chapter of schooling with the illustrious RemyD. First flight is always pretty easy assignment. I guess it is mostly just looking forward to what this class will have in store for us. It will hopefully be an enjoyable experience. This is a pretty short post overall since this is like the fourth time I've done a "First" flight.

HackProp 2: Paint Partners

Hack Prop Title: Paint Partners

Description:

A collaborative drawing tool made in Python using PyGame as the GUI, and homemade networking code borrowed from Hack1. Ideally would be able to be used as a teaching tool, by limiting the teacher to be the only one able to draw.

Libraries:

The only library we need to be using is PyGame.

Upstream Repository:

pypi.python.org

Hardware:

The only hardware we need is the Raspberry Pi, Display, Input Devices

Team:

I will be working with mstubinis for the project

Project Milestones:

1. Develop non-server side code to modify and display an image, load config data, and prepare text fields
2. Develop server side and networking code to send and process information: pixel data, chat messages, client connecting and disconnecting from server, admin issuing commands through console
3. Finish development tasks, build documentation, distribute upstream.

License:

GNU GPL2.0

Upstream Mentor:

Currently none, but the project isn't really different from our last one in terms of what needs to be done.

Final Thoughts:

This project should be an interesting build off of the work that was done on Hack 1 and should serve as a cool project providing a service.

Adventures in being a Teaching Assistant

This is probably the first in a short series on my perception on being a Teaching assistant. Hopefully this will be a good place to give my thoughts for a few different thoughts I have from being on both sides of taking a class.

I am a teaching assistant for an intro level programming course at RIT. I have been one for almost a year now and I have become accustomed to the way the teacher I help teaches, the kinds of questions the people come up with, and certain pitfalls from of early level programming. That said, the most difficult thing is remembering what a person should be expected to know and what they probably don't know yet. For example, I had a student ask me a question, which I had to stop and think of the answer for a minute or two, because my normal go to method hadn't been covered by the course. I feel like that is probably the biggest issue in teaching in general, and one of the biggest to overcome in becoming a good teacher.

Another interesting thing is seeing the difference in proficiency that you run into across multiple people doing the same thing. I have a few students that I never need to say anything to because they already either know everything or just catch on quickly enough that they don't need help. On the other hand, there are students who don't quite seem to understand anything that the professor just went over and ask questions about everything. Of course there are also plenty that fall in between.

I think the biggest thing I have noticed is the different ways that students attend class. What I am meaning is, how are they handling class time. I can see in every student is different ways that I have been a part of class at one point or another. It really is eye-opening seeing yourself in the people you are working with and realizing that you were there at one point. Overall, I am enjoying my time and I have several students that are fun to interact with from day to day. I hope this continues for a while more.

Tic-Tac-Pi - Final Thoughts

This was the second project that myself and mstubinis did for the ADVFoss class. This one was overall a much simpler project, mostly because it was doing something that we both thought would be fairly simple from the get go. I personally didn't have an overwhelming amount to do since mstubinis took charge right away and knocked out the game code itself in fairly short order. That left me pretty exclusively in charge of getting everything packaged. I originally had the same issues that I did in when it came to packaging up PyTalk, but more on that in a minute.

What I'm most surprised by was the expediency with which mstubinis actually got everything together. He had me write some very simple resolution code and had me do the testing to make sure it was working, but otherwise, he pushed out everything else in the time between classes in the first week. After that, it was fairly slow until we had to package it up because we had already had everything finished.

For some reason, my laptop finds it impossible to build python eggs. This happens to be a fairly large problem when trying to push things up to PyPi. Naturally this means I needed to go elsewhere for my uploading needs, which the first instinct is to go to a lab machine. Problem is that the lab machines are fairly finicky when it comes to actually using python on them. I finally managed to find a work around using my roommates laptop because he has a linix partition on his drive. After moving over the files, the upload and registration was extremely quick.

Overall, I found this project to be a little lackluster since I personally didn't have a lot to do for the project and I hope that changes as we move forward into the third hack for the class.