While there hasn’t been a huge amount of public discussion about it, we’ve been working on a license change for web2project. At present, web2project is available under the GNU Public License v2 (or GPLv2). While there’s quite a bit of fear, uncertainty, and doubt surrounding its use, there are a few concerns that result from the various interpretations and legal analyses:

• There are numerous conclusions on if there even can be non-GPL-compliant components that are wholly dependent on GPL’d software. The majority opinion – according to projects like WordPress, Drupal, and Joomla – is that these components are derivative works and therefore also must be GPL.
• To protect against this, there’s the concept of a “shim” which is a small piece of code that sits between the GPL application and your module that would allow more flexible licensing, but that concept is also an area of contention.
• On the plus side, including one line of GPL code in a non-GPL project is unlikely to cause a problem because Fair Use is still Fair Use. More specifically, one of the factors assessed in Fair Use determination is “the quantity or percentage of the original copyrighted work that has been imported into the new work. In general, the less that is used in relation to the whole, e.g., a few sentences of a text for a book review, the more likely that the sample will be considered fair use.” [Source: Wikipedia]

So what does this mean for Web2project?

Under this reasoning, all web2project modules would have to be and remain GPL. If this module interacts with or is wholly dependent on web2project and differently licensed systems, it has to be GPL.. but we’re not sure what that means for the other systems. What we know, as far as web2project is concerned, is that the license may place infeasible restrictions and rules on your code.

The GPL puts rules on the code of our contributors that are against our vision of Freedom and the spirit of Open Source. It attaches strings – both seen and understood and implied and unclear – that we aren’t willing to deal with any further. We won’t let our users to get tied down by the same unclear rules that have plagued other communities.

Therefore, to protect the integrity of the project, the work of our community, and the growing integrations being built on web2project, we’re changing from the current GPLv2 back to the original BSD license.

There are really only two ways to change licenses legitimately:

Get all contributors to agree to the change.

OR

Remove the code of any contributor who doesn’t authorize the change.

For the past few months, we’ve been working on exactly that. Digging into the ancient past of web2project and dotProject, we found the details of something we all knew: dotProject itself changed from BSD to GPL between v1.0 and v2.0. Unfortunately, there are no records to who made this decision, how, when, or any discussion, etc, but based on SVN records, the license changed on March 10, 2005. From the beginning of dotProject through the date of our fork (November 2, 2007) and then into web2project, we have a total of 33 contributors:

• There are four individuals who contributed 4 lines of code or less, we’ve excluded them.
• There are seventeen individuals who contributed exclusively to dotProject 1.x (aka prior to March 10 2005). Since they were contributing to a BSD project, we assume that they agreed to the BSD license.
• Of the remaining twelve:
  • One is contributing exclusively to web2project and agrees.
  • Four individuals contributed to both dotProject 2.x and web2project and all agree.
  • Three individuals contributed exclusively to dotProject and all agree.
  • This leaves a total of four individuals, two of whom are unresponsive, two oppose.

Of the combined history of the projects, this gives us 888 SVN commits which are not approved. Of those, we’ve reviewed 365 commits which were merges of already approved code or code we’ve since deleted (not replaced, deleted). This leaves us a total of 523 commits that are still under review and/or need work. To put this in context, this is approximately 7% of the 7000 total commits between the two projects.

Whew.

At our present rate, we will finalize the license change well in time for web2project v3.0.

Going forward, all web2project development should be considered licensed under the Modified BSD. Anyone contributing more than a line or three of code will be expected to agree to a simple Contributor License Agreement.

In my regular web browsing, I came across a great post from Sara J Chipps entitled “Your Code Sucks.” As she talks about deleting code that sucks and restarting from nothing, something sounded amazingly familiar:

After some growth I encountered code that I thought sucked ever so often. At this point I wasn’t decimating things all together, I would find specific parts of code that I found intolerable and rewrite it. About 9 times out of 10, when I got more than halfway there I’d run into an issue that made me say “Ooooh, that’s why they did it that way” and revert it or use the same “sucky” logic with my syntax.

It was familiar because this is how web2project started.

In late 2007, when the dotProject leadership announced a rewrite from the ground up, we were faced with a choice: a) we could work on the complete rebuild and lose the lessons learned from the past 7 years of development OR b) we could attempt to refactor and cleanup the system to make it stable and useful.

We chose the latter and in the nearly three years since, we’ve worked to do just that.

Yes, we’ve found lots of code that “sucked” and usually we’ve been able to remove and replace it without negative repercussions. This has closed dozens of bugs, eliminated numerous behavior oddities, and has often given us significant performance improvement. More importantly, we’ve been able to maintain a fully functional system throughout. Unfortunately, we’re nowhere near complete. There are places – like the infamous projects_list_data function in the CProjects class – where replacing the logic has proved difficult and seemingly impossible at times.

Regardless, to find and track down these problem areas, we use three different strategies that could work on any project:

1. First, we use various PHP quality assurance tools. Each gives us a different look at the system and can identify potentially problematic areas.
2. Next, we actively encourage external Code Reviews. Sometimes questions from someone who doesn’t know our history and reasoning can offer a new and useful perspective.
3. Finally – and most importantly – we take an active role in our Support Forums to determine who is having problems where and work to determine why.

Do we find them all? No, but we’re regularly working and exploring to find and eliminate more.

Can we use help? Yes, because none of us have all the answers or even necessarily the best strategy to combat the issue.

Can you help? Yes... just remember the Ten Commandments of Open Source.

Great question. The answer is best considered in stages:

• The earliest versions were basically dotProject with a new theme, some performance improvements due to some database fixes, and a permissions caching layer.
• By the time version 1.0 rolled around (June 2009), we had removed old/irrelevant code, added dozens of new features, added a module to core, and closed more issues than we care to consider.
• By the time we reached version 1.2 (December 2009), the differences were more obvious: We had removed 35% of the codebase (~65,000 lines of code), added extensive Unit Testing, improved performance by 20-50x on many screens, and began a complete refactoring of the core API to make it uniform and more easily extensible.
• More recently with the version 2.0 release (June 2010), the differences have grown further: Adding user-based timezone support, detailed subprojects functionality with data roll-ups, and extensive audit logging and security checking.
• By the version 2.4 release (August 2011), task dependencies – including subprojects – auto-update as task end dates shift. Further, less than 10% of the web2project code is carried from dotProject.
• In the coming version 3.0 release (est: November 2011), we have a full event-driven hook system to allow for modules to use pre/post- (create, update, load, and delete) actions. More importantly, we will support task/costcode-based budgeting and reporting. Finally, our GPL -> BSD license change will be complete.

So, is web2project just dotProject with a new theme?

We were… but now we’re something else entirely.

Late last month, I received some bad news about web2project…

It turns out that web2project was vulnerable to a handful of select Cross Site Scripting (XSS: definition) vulnerabilities. While the attack vector was pretty specific to being an already authenticated user, it had the potential to be a major problem in a poorly configured system.

On the positive side, I say “was” because within 10 days of being notified of the problem – and the same day the vulnerability became public – we had a patched release out the door and available to users. We’ve spent the past month since encouraging them to upgrade. Of course, we further benefit from the fact that although the vulnerability does affect us, we’re not named in the report.

On the negative side, it did take us 10 days to close the vulnerability. The patch itself was available a few days earlier via Subversion but it might not have been enough. Further, we didn’t explicitly notify our users of a need to upgrade but since it was rolled with a handful of other major fixes, it appears that many people have upgraded already. Once again, we benefit from the very specific attack vector.

To make this process easier and faster in the future, as of v1.3, we can already detect if upgrades have been uploaded but not applied. For an upcoming release, we’re implementing a Drupal/WordPress-style means of notifying existing administrators thatan upgrade is available. In the meantime, watch this space or web2project’s page on Sourceforge.