Planet Sakai

Angela's back...

It's been a month. Remember when I said I would update the blog every two weeks? Oh, well... I've been a bit (actually a lot) under the weather for the past 2-3 weeks and my poor blog is suffering from lack of attention. Easily resolved - today I return!

Since my last post, I have been familiarizing myself with the kind of documentation that Sakai needs. I started working on documentation for the Assignments tool, but due to my background in training end users, the documentation was focused too much toward them and not enough to the QA tester. I've made the adjustment - in the process of regression testing the Assignments tool (on QA3-US), I saw exactly what was needed and set to work. There are many areas where the test conditions exist but need to be fleshed out, and I've been eagerly ceating Excel spreadsheets listing the test conditions for various tools. After I attend to this blog, my next step will be to update my Wiki page with the documentation I've created.

For the past month, I have worked on the following:

• Documentation - Assignments and Resources
• Regression Testing - Assignments (create, submit, grade, full regression suite)
• Regression Testing - Resources (full test conditions)
• Testing - Samigo Tool (SAK-13930)
• Testing - The win demo version of Sakai 2.5.3

I'm currently working on testing the win binary version of Sakai 2.5.3

See you again in two weeks...

Angela on Sakai

• Samigo, Assignments Tools - Documentation
• Installation of Windows Binary Version of Sakai 2.5.3 using Vista (ongoing)
• Updating version 2.6 tasks on Confluence (ongoing)(http://bugs.sakaiproject.org/confluence/display/QA/2.6.0+Changes)
• Testing - SAK-13994 and SAK-13913

I've also been following up on the distribution list emails. Immersing myself in them is helping me to get a good overall picture of the project (it's big :-)

Best,

Angela on Sakai

It’s only now that I looked at a schedule and realized Bill McGlaughlin is on every day!! Bill McGlaughlin is unstoppable! He’s so excited about classical music in a really nerdy and intense, yet contained way. I discovered Saint Paul Sunday when I was living in Minnesota during summers in college, but didn’t realize he had a regular show too.

WFMT Feeds:
http://www.wfmt.com/main.taf?p=4

Exploring Music with Bill McGlaughlin:
http://www.wfmt.com/main.taf?p=1,1,41,7

I just created a few screencasts about the Open Source Portfolio. Hopefully this documentation (funded by Weber State University) will help others understand how to use the OSP tools in Sakai.

I start by introducing how to setup a worksite in Sakai, how to import data structures from the community library and how to recreate a teaching "Best Practice" from another university as a way to jump start the portfolio discussion in just three screencasts.

See the complete docs here

Setup a demo site

Import and export a form

Recreate an Existing Portfolio Best Practice from the Community Library

News Item edited by Nathan Pearson

Stephen Downes and Scott Leslie have both expressed concern that my original post regarding the Zotero lawsuit was possibly too charitable toward Thomson Reuters. Sadly, as more information comes in, it’s beginning to look like they were right.

(...)
Read the rest of Thomson Suing Zotero: More Info and More Thoughts (886 words)

?? michael.feldstein for e-Literate, 2008. | Permalink | 3 comments | Add to del.icio.us
Post tags: edunomics, EndNote, George Mason University, Thomson Reuters, Zotero

OSGi version resolution looks great, but there is a problem that I am encountering. I can deploy more than one version of a jar as seperate OSGi bundles, but unless the consuming bundle was explicity written to specify a range of versions that bundle will not start.

Bundle A was built with a dependency on package org.apache.commons.useful;version=1.0.2, which means any version > 1.0.2.

I deploy bundle B with org.apache.commons.useful version 1.0.4, great no problem.

Bundle C depends on org.apache.commons.usefull;version=1.0.8,

So I deploy bundle D with 1.0.8, great for Bundle C, but now Bundle A can see 1.0.4 and 1.0.8 and wont start, due to a constraint violation.(at least in Felix).

To make this work I have to go back to bundle A, and rebuild it with version=”[1.0.2,1.0.8)” meaning “I depend on any version >= 1.0.2 and < 1.0.8|. Thats all fine, but, now every time I add a second version of a jar to OSGi, I have to go back and repackage all the bundles that dont have precise enough version numbers.

You might argue 1.0.4 and 1.0.8 are equivalent so dont deploy bundle B anymore, but the same problem happens when you try and deploy bundles container 2.0.6 and 2.5.5 when 2.5.5 is not fully backwards compatable.

Worse, this also means if I took any 3rd party bundles without precise version ranges, I will have to work out how to rebuild them. Not exactly and inviting task when you have > 100 bundles in a container. Makes me wonder if its worth all the hassle.

In a recent article about the Jacobsen v. Katzer case Bruce Parens, the creator of the Open Source Definition (OSD), warns that "taking adversary action against an Open Source project is like boxing with a beehive."

I think he's right. In my own experience with the Sakai project I've seen boxers like Blackboard stung repeatedly as the education market, led by the education open source community, swarmed against them for their predatory behavior using bogus patents. Recently we're seeing signs of a similar swarm related to the Thomson-Zotero suit.

Yet the stinging power of the open source community (at least legally) has been uncertain--until recently. In August the Court of Appeals for the Federal Circuit issued it's ruling in the Jacobsen v. Katzer case. This was the first substantial legal test of the open source license in a reasonably high US court. The ruling sounds to me like the most important legal victory for open source--ever.

The Jacobsen v. Katzer case is between a model train hobbyist and open source software developer named Bob Jacobsen and Matthew Katzer, the owner of a proprietary model train software company. The district court hearing the case issued a potentially disastrous ruling that the open source license terms were contractual covenents. Based on that ruling Jacobsen may be entitled to monetary damages for breach of contract, if in fact there was a legitimate contract. He would not, however, be entitled to more substantial copyright infringement remedies like injunctive relief (court enforced compliance with the license terms).

As I understand it, the substance of this ruling has to do with whether a judge interprets the terms of an open source license as a contract that requires both parties to agree, or a license that does not have such a requirement. This determination between contract and license determines the extent to which the license can be enforced, and the kind of remedies available when the terms are violated.

In August, the Court of Appeals for the Federal Circuit reversed the lower court's earlier decision. We're very fortunate that legal experts and others seized this opportunity and donated their time and money to help defend Jacobsen and set a precedent for all open source communities. Without such help it may have been cost prohibitive. According to Mark Radcliffe the decision sets forth the basic rule very clearly:

“Copyright licenses are designed to support the right to exclude: monetary damages alone do not support or enforce that right. The choice to exact consideration in the form of compliance with the open source requirements of disclosure and explanation of changes rather than as a dollar-denominated fee, is entitled to no less legal recognition.”

One effect of this ruling is that our communities can be confident in the terms of our licenses and in our ability to defend them. Because the ruling interpreted the open source license terms as conditions on the scope of the copyright license, copyright law remedies such as injunctive releif, attorneys fees, actual damages, and statutory damages may be applicable.

Boxing with a beehive doesn't seem like a good idea in the first place but the new ruling makes it even more reckless and dangerous for the would-be boxer. The open source bees have been africanized!