GPLv3 - The Year in Review

The Year in Review Report is intended to give you a summary of what has happened to the GPLv3 over the past 6 months, and review some of our highlights for the year.

For those curious regarding how the overall adoption is doing, scroll down to my updated numbers. I polished up my crystal ball, and found that the predictions to date are not only accurate, they have been conservative - GPLv3 adoption, lackluster or landslide.

For six months, we have been reminding developers to check those links for the license - Bad links = invalid license?

I added a summary of our hot projects, and I listed my definitive guide to OSS licensing for developers - Ernie's Clear OSS Licensing Guidelines

Happy New Year
We welcome 2008 with open arms as we say goodbye to 2007. Looking back, since the release of the GPL v3, support for the license has grown quickly and consistently. We are ending the year at 1380 GPLv3 projects, which experience a bit of a slow down from the holidays. Over the last half a year, the LGPL v3 list has grown to 135 LGPL v3 projects. Combined, the GPL v3 and LGPL v3 projects account for 1515 projects that support the relatively new FSF license. Aside from my estimates and speculation, no one was quite sure how the Open Source community would react to the adoption of the license, but now that the first 6 months are over and the year is coming to an end, we have enough data to say that the GPLv3 is here to stay. The adoption rates are still changing, with recent news such as Sun releasing code under the GPLv3, and many large players such as MySQL still watching the license closely to see if they will adopt the license. 2008 is sure to bring new news and unexpected events, so we will continue to track the adoption of this license until we can clearly see where it is going and its impact on the community in the long run.

Past 6 months:Adopters and Rejectors

Significant adopters
Samba
From the onset, Samba supported the GPL v3 by announcing that it would adopt the license prior to the release. After the day past, they kept to their word, and Samba was one of the first large projects to adopt the license.
Their lead was no doubt a factor in many smaller projects adopting the license. After these 6 months have passed, they are still under the GPLv3 and a large influence in its adoption.

Sun
Sun has recently announced that they will release a set of VM related management products under the GPLv3. Sun had its optimism with the license from the start, calling it "a strong and market-changing document," but as with everyone else, they wanted to give it some time to develop before completely committing a project to the license. But with this new set of projects being release under the GPLv3, they are showing explicit support for the license, which may build momentum for GPLv3 adoptions.

SugarCRM
SugarCRM was also a relatively early adopter of the license, stating they would use the license in late July, about one month after the release of the GPLv3. The customer relationship management project switched to the GPLv3 because it would make it easier to share code with other GPLed projects. John Roberts, CEO of SugarCRM, stated, "Right now, we are using the GPL version 3, which is one of the best licenses out there."
Such statements and reports are driving the support behind the GPLv3.


Significant rejectors
The Linux Kernel
One of the largest names in Open Source, if not the largest, is the Linux kernel, which has been a large supporter of the GPL v2. However, when the release of the GPL v3 came around, maintainers for the Linux kernel decided not to adopt the license. Even before the license was released Linus Torvald, leader of the Linux kernel project, was against the license mainly because of the DRM provisions. These were not removed from the license and the Linux kernel did not take up the license. Being one of the largest names in Open Source, the Linux kernel is the project slowing the adoption the greatest. If Linux had adopted back in June, the adoption rates would have been much greater than they are and could have caused widespread adoption. There is still a small possibility that maintainers of the Linux kernel will adopt in the future, if more projects take on the license, such as Sun's VM projects perhaps.

Alfresco
Alfresco, the enterprise content management project, decided to switch from the Mozilla Public License to the GPL back in February of this year. But what wasn't sure was which version of the license they would take since their decision came at a pivotal time for the GPLv3. Alfresco showed early interest stating, "We'd really like to go version 3 when it comes out, if it remains as planned." However, Linux not converting played a large part in Alfresco not converting, which goes to show the large impact Linux had on the license. Their current statement regarding the GPLv3 is, "Some other GPL projects, like the Linux projects, use a single version of GPL. We have decided to follow the lead of Linux on this point."

MySQL
In January, MySQL changed their license to GPLv2 only, taking off the "or any later version" part of the license. The move was not made in an explicit rejection of the license, but like many others, they wanted to see how the license would develop before making any commitments. To this day they have still not adopted the license and are still under version 2. The people at MySQL did give the license a warm reception when it was released, stating that they expected the license to be widely adopted, but still wanted to gauge the market before putting code under the GPLv3.


In the News: 2007

GPL v3- The release of the GPL Version 3 was one of the most highly anticipated events of 2007. The GPL after all is the cornerstone license of the Open Source and Free Software world with countless thousands of projects under its license.

http://www.internetnews.com/bus-news/article.php/3717841

Patents and Microsoft- The GPL version 3 process was strongly influenced by Microsoft and its patents. While Microsoft has argued for years that Linux may infringe on Microsoft's intellectual property, it was in 2007 that Microsoft gave the infringements a number. Microsoft alleged that Open Source software infringed on some 235 of its patents. Steve Ballmer himself beat the patent drum telling people that Red Hat and others have an obligation to pay up.
http://www.internetnews.com/bus-news/article.php/3717841

SCO in a Coma- The poster child for Linux lawsuits and patent infringement, also known as SCO somehow managed to survive 2007. In 2006, we had predicted that end of SCO in 2007 due to a trial that was supposed to have happened this year. No trial ever happened. Instead SCO pleaded poverty, declared bankruptcy and tried to sell of its Unix business before creditors like Novell could get a piece of it.
http://www.internetnews.com/bus-news/article.php/3717841

Linux Gets Both Real and Virtual- There were four mainline kernel.org Linux kernel releases in 2007 adding functionality across the whole set of computing requirements. The SuperBowl 2.6.20 kernel was the first of the year, kicking off with some virtualization enhancements. The 2.6.21 kernel was also highlighted by virtualization which was a strong theme overall for Linux in 2007. New memory management and a new wireless stack debuted in the 2.6.22 kernel. The 2.6.23 kernel marked the introduction of the completely fair scheduler which provides some real time capabilities for Linux.
http://www.internetnews.com/bus-news/article.php/3717841

Google's Android- Google (NSDQ: GOOG)'s Android announcement today may be the biggest news story ever for the mobile open source community. To add some perspective, I sat down with Fabrizio Capobianco, CEO of Funambol, a company working with mobile carriers and device manufacturers to offer an open source application server.
http://www.informationweek.com/blog/main/archives/2007/11/what_does_googl.html
Review of 2007 research

GPLv3 adoption, lackluster or landslide -

7/10/07 http://gpl3.blogspot.com/2007/07/opinions-on-gpl-v3-adoption.html

7/16/07 http://gpl3.blogspot.com/2007/07/gplv3-overwhelming-support-if-you-know.html

8/13/07 http://gpl3.blogspot.com/2007/08/gplv3-past-5k-mark-and-going-strong.html

8/22/07 http://www.palamida.com/node/467

10/12/07 http://www.palamida.com/node/492

Total repository based OSS community: 236,049 (SF total 165,234 as of 12/29/07 divided by 70%)
Estimated Total active Projects: 35,407 (total multiplied by 15%)
Total active GPL: 29,388 (total active, multiplied by 77% GPL and 6% LGPL)
Estimated total GPLv3 conversion, including "or later": 21,159 (total active, divided by 77% GPL and 6% LGPL, divided by 72% estimated conversion rate)
Estimated current "or later" impact: 14,694 (50% of GPL)

Therefore:

Or later – 6390 of 14,694 projected – 44%
LGPLv3 – 135 of 1269 projected – 11% (GPL conversion divided by 6%)
GPLv3 – 8127 (GPLv3, LGPLv3 and all "or later') of 19,889 projected – 41% (GPL conversion divided by 94%)
GPL, not converted – 5923 projected (GPLv3 converted projects multiplied by (100% - 72% convert rate))
Active Non GPL license – 6019 projected (Active projects – Active GPL projects)

All this in six months!


Six months have passed since the GPLv3 became final, and despite the debate and public opinion in both directions, time always tells in retrospect. That being said, I made predictions early on based on analysis and observations on my part, and extracted from work by Matt Asay. The result was that I predicted a steady and increasing support for the GPLv3 license due to a number of issues, and I plotted the overall potential scope of what a saturated GPLv3 adoption would look like.

Bad links = invalid license?

7/10/07 http://gpl3.blogspot.com/2007/07/check-your-gplv3-link.html

7/11/07 http://gpl3.blogspot.com/2007/07/more-thoughts-regarding-invalid-gplv3.html

7/11/07 http://gpl3.blogspot.com/2007/07/correct-your-gpl-license-links.html

12/9/07 http://gpl3.blogspot.com/2007/12/crystal-clear-or-clear-as-mud-lack-of.html

12/9/07 http://www.palamida.com/node/511

Our research continues to point out the issue of ambiguous licensing. This is taken from my most current writing, in which I defined my "guidelines". I hope that developers start to adopt these.

Ernie's Clear OSS Licensing Guidelines

1. Project must have a distinct homepage that is not a repository. Domains are cheap and user pages are free in many cases. This provides a place where the maintainer can manage a freeform data exchange with users, and is a site unique from any repository and its goals.

2. Maintainer needs to provide a URL to the license(s) used. I suggest http:///license.html. Under this file, identify the applications, versions and releases, all hyperlinked. Within the hyperlinks, allow a user to follow distinct hyperlinks to the specific license text. Name the URL for the license text using the name of the core license, like http:///licenses/license-Apache_License_Version_2.0.html

3. License text must reference file from which it derived by URL, like http://www.opensource.org/licenses/apache2.0.php

4. Project homepage MUST provide a link called LICENSES that goes to the main license page, described above.

5. Each download file MUST be compressed with a file called license.txt and license-.txt, along with a hash fileof the text license file.

6. License.txt needs to described the licensing hierarchy for licensing per application/version/release .

7. license-.txt includes the explicit text of the license, and includes pointers to where the SAME license can be found on the website, within the source code (by the same name), and in the binary

8. license-.md5 MUST be included to allow absolute verification that the user has the license that was intended to be included with the specific release

9. Unless the maintainer has a Juris Doctorate and specializes in software licensing law, stick with OSI licenses, or use them as the CORE. In the event that the maintainer uses the OSI license, congratulations. In the event that a maintainer chose to reinvent the wheel, identify such. In the license URL, change the URL to read as follows:
- OSI license: license-.txt
- modified OSI license: license-Modified_.txt (this requires identification of the core license that was modified)
- license newly developed by maintainer or third party: license-custom-.txt

10. Finally, a license should be basic, and easy enough to understand that a layperson could understand the idea of it. In the event that a maintainer customizes licenses, or chooses one that is available, make sure it is easy to understand. Think of it this way, if you can't explain this to your mother, you probably can't explain this to a judge any easier.

In the end, a license for the use of open source software is an agreement between a maintainer/developer who created the project, and a user/developer who plans to use it. The agreement represents the rules of a relationship.

Summary

Regarding my GPLv3 adoption predictions, the actual will always trail the predictions by a percentage. As the database of projects that adopt GPLv3 variants grows, and as the community continues to contribute information, we will be able to accurately display information that more closely tracks the predictions in near real time.

5 months ago, the analysis looked speculative and subject to very kind interpretation. Now, with six months behind us, and fresh batteries in my crystal ball, I give credit to the open source community, the Free Software Foundation, and a little intelligent extrapolation of historic data, because it seems that the actual numbers as seen above are only marginally behind the predicted numbers. In all, FSF made a license that fairly reflects the wishes and desires of a significant number of those wishing to author and distribute free software for use. As with its predecessor, the GPLv3 license seems to have slowly and predictably gained acceptance, traction, and widespread adoption in the free software and open source community.

I hope that software developers intent on free distribution of binaries and source consider seriously the ideas behind my licensing guidelines. Clear licensing will ease use and advancement of key projects in the open source software community, and will do much to quiet much of the FUD regarding the scary OSS related licenses.

So what is ahead for the next six months? I have publicly posted my numbers, my sources, and how I estimated them. I anticipate that the new Affero license may end up being the unexpected surprise, representing a new option for licensing free software with a new method of delivery. In conclusion, in regards to the GPLv3 adoption, let me say " I told you so".

Special note -

If you have a need for additional data relevant to GPLv3 and OSS related licensing information, feel free to contact me at rdgroup@palamida.com.

Happy Holidays and Happy New Year!


Ernest Park

Antony Tran

Kevin Howard

Edwin Pahk

Chris Porter

The Research Team

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

GPL Project Watch List for Week of 12/21

The GPL v3 Watch List is intended to give you a snapshot of the GPLv3/LGPLv3 adoption for November 15th through December 21st, 2007.

December Happy Holidays
We would like to wish everyone happy holidays and start a wonderful new year next week. The year is coming to an end and the GPL v3 adoption has made it past 1300 GPL v3 projects. The current count is 1372 GPL v3 projects , up 30 GPL v3 projects from last week. The LGPL v3 count has also increased to 131 LGPL v3 projects, as compared to last weeks number of 125 LGPL v3 projects, and the GPL v2 or later count is at 6389 GPL v2 or later projects. In just a bit over half a year, the GPL v3 adoption has accumulated to over 1,500 projects, including LGPL v3 projects and we expect this to continue to grow through out 2008. Also next week will mark the 6 month anniversary of the GPL v3, as well as our 6 month anniversary of tracking the license. We will release a more in depth analysis, reviewing the data up to the day. We appreciate all the user contributions and look forward to more next year.


























New project conversions this week include:

• DictDefence: DictDefence is program written in Python to stop dictionary attacks of all sorts. The basic idea behind DictDefence is the automated blocking of Script Kiddies that run dictionary based attacks on your servers.
• osSeo: a SEO (Search Engine Optimization) web tool which provides graphical statistics on the position of a website over the time. It consists on a single WAR file ready to be deployed on any Java application server.
• hellaGUI: a GTK/python frontend to the news leecher "hellanzb" providing most functionalities available from the "hellanzb daemon" and Drag and Drop file-enqueuing.

In the News
2007: Open Source, Patents, SCO, And More
2007 is a year that will long be remembered in the open source and Linux communities. It was a year in which the
twin underpinnings of what makes open source successful and what could serve to destroy it made the headlines.
http://www.internetnews.com/bus-news/article.php/3717841


Notable Mention
Palamida actively takes submissions from visitors on updates on new GPL v3/LGPL 3 projects. We are amazed at the number of submissions we have gotten to date, but even more so, we are incredibly grateful to the almost 100 core contributors who have devoted their time and resources at helping us provide up-to-date information.

GPL Project Watch List for Week of 12/14

The GPL v3 Watch List is intended to give you a snapshot of the GPLv3/LGPLv3 adoption for November 30th through December 14th, 2007.

December National Bouillabaisse Day
As of December 14th, 5pm PST, our GPL v3 database contains 1342 GPL v3 projects, a 66 project increase since last week. The LGPL v3 list has also had an increase from last weeks number of 122 LGPL v3 projects to 125 LGPL v3 projects. Lastly, the GPL v2 or later count is currently at 6379 GPL v2 or later projects, as compared to last weeks number of 6356 GPL v2 or later projects.
























New project conversions this week include:

• Sushee: an XML Office Management Framework: a set of application development tools designed to manage contents and activities (companies, institutions, associations, etc.) in a multi-language, multi-channel, multi-format and multi-project context.
• Awakener: an extensible suite of programs solving real world optimization problems using genetic algorithms and showing the possibilities and features of the Sleepwalker library.
• Squidit: an administration-tool for the Squid proxyserver. It configures automatically the .conf files of Squid: you can add, remove and update the information in badDomain.conf and badDomainIP.conf by using just one command.

In the News
Affero: A new GPL for software as a service
The Affero General Public License, a new variation of the seminal General Public License (GPL)
specifically for one situation the regular GPL doesn't address, is now final.
http://www.news.com/8301-13580_3-9820397-39.html?tag=nefd.top


Notable Mention
Palamida actively takes submissions from visitors on updates on new GPL v3/LGPL 3 projects. We are amazed at the number of submissions we have gotten to date, but even more so, we are incredibly grateful to the almost 100 core contributors who have devoted their time and resources at helping us provide up-to-date information.

Crystal clear, or clear as mud: a lack of clarity in OSS licensing

If you want to read the "short form" of the essay below, please go to http://www.palamida.com/node/511.

Within the body of this document, I outline a reasonable set of guidelines that can be implemented to insure reasonable adherance to clear licensing policies for OSS.

In the management of various projects for Palamida, I have had the benefit of reviewing the source code and compiled files for tens of thousands of open source projects. A common issue comes up with great frequency, one which seems to underpin the usability of open source software. A surprisingly high number of open source software projects are unclear or incorrect with their license references. This point has two principle sides. What is the responsibility on the maintainer of a project to make licensing terms clear, and what licensing terms govern a user when such terms are ambiguous, unclear or incorrect?

For the sake of this discussion, any reference to a maintainer refers to the party or parties responsible for the licensing associated with an OSS project. A developer is the user of the same OSS.

From another perspective, a development team works for a year to build a cool project that solves a business problem. They like some ideas of the GPLv3 and choose to support it on the web page. The maintainer of the code repository never put the license in the code tree, but they opened the project up to the world. Third parties now download the code, modify it, and it becomes the core of the next big thing, and starts selling. However, the source never contained a license. Who is correct?

The issue of ambiguous licensing got me thinking of some basic ideas to create clarity with the specific license associations to any given application, version and release for open source software. In the end, software licensing is the way that a maintainer/developer of a given project governs how the project is incorporated into the OSS community. The licensing creates the framework for the evolution and growth of the project, and should reasonably express the wishes of the creator of the project for recognition, financial consideration, and other basic points.

Let's discuss the following OSS licensing conditions:

1. Contradictory
2. Unclear and ambiguous
3. Nonexistent


Contradictory licensing - internal (conflicting language within license file)

Note: A funny situation that I saw was to include the "heading" from the GPLv2 license, or the BSD license, while using the text from yet another license. I am sure that in some way, the developer/maintainer may have considered "reviewing" one license, with the intent of modifying it to become a custom license, or it could have been a mistake. In either case, imagine the situation where, on a quick review of the COPYING file in the source, you see the beginning of the BSD license, and choose to move forward, without realizing that a large part of the GPLv3 license was appended to the bottom.

In the case where someone mistakenly blends both the GPLv3 and the BSD, they may have created a license that is contradictory in terms. It is my belief that when such a situation exists, while the license itself is internally contradictory, if it was clear, then the obligation falls to the user. In the case of contradictory licensing, a user should disallow themselves from using the software in question, since it may be impossible to actually adhere to the contradictory terms of use. Therefore, using software with contradictory licensing terms may represent an intention to not comply with the licensing terms. If it is impossible to comply with the terms, but compliance is mandatory for use, then a developer should avoid such software.

Contradictory licensing presents a real problem for developers. A developer may have already chosen to use a project as core to a proprietary project. A great deal of time and effort may have been invested by the time that the licensing issues arose. The intent to use source governed by impossibly contradictory terms, I would believe, is less to do with intentional circumvention of licensing, and more to do with a lack of understanding of licensing that is poorly crafted and unclear. As such, the user/developer made a choice to use OSS with a vague understanding of the usage terms. The maintainer of the same project may have attempted to modify the license in order to refine his vision for usage of the project. The maintainer probably does not realize that the license legally renders the code unusable. In the spirit of OSS usage, I believe that it is the goal of the community to publicly disclose these licenses, and in the event that a developer has started using such code, it is in the best interest of both the maintainer and the user to get together, rationalize the licensing, and publicly disclose the mistake, just as if it was a bug.


Contradictory licensing - external (multiple license files or references)

I have seen numerous examples of an inconsistency between what is disclosed on the project home page, in the compiled code, and in the source tree. A great deal of these inconsistencies became apparent as the GPLv3 license came out. Some projects intentionally did not want to support the GPLv3, others publicly wanted to release under GPLv3. In researching for GPLv3, links from the project page would take a user to the GPLv3 license page at FSF. The compiled code had the GPLv2 license text in many cases, but contained links to the GPLv3. The source would contain an unpredictable array of references either to explicit license text at the developer's site, the text embedded within a file in the source, or links to third party sites, like FSF. What is interesting is that the license references in many cases deviated from both the stated licensing on the home page, the licensing references in the readme file of the compiled code, and in some cases was even incorrect internally. (Keep in mind that I was looking at versions pending release in cases of unclear licensing - I was not always inspecting the source for the binaries currently available).

A much more common contradiction that we see all the time is the case where the GPLv2 license was included with the source, the GPLv2, "or later" is referenced in the Readme.txt file for the compiled project, and the COPYING file contains the GPLv3 text. In the case that multiple valid references to multiple and valid use licenses exist, which license governs? In the event where there are multiple licenses that by themselves are valid, but compared to one another, are contradictory, which license governs? Whose responsibility is it to deal with externally incompatible licensing, the user or the maintainer? Can the user "selectively" choose to use the license of their preference, since multiple choices are presented in parallel?

I believe that in the event where multiple choices are presented with terms and conditions of use, with no "obvious bias" towards either, the developer has been given the opportunity to select the terms of use from the distinct options given, and the maintainer inadvertently, or intentionally, released software under multiple parallel licenses. Clearly, once this is discovered, this creates issues with the maintenance of distinct code tree, like when a developer started work on the BSD version of a project, made that available, to which someone else distributed changes and so on. At the same time, the developer is trying to maintain what he thought was a single GPLv3 tree.

In this case, the problem lies with the development community, but the fault lies with the maintainer. However, in the spirit of OSS, when we see this situation where multiple parallel licensing choices exist, we must reach out to the maintainer immediately in order to prevent conflicting simultaneous development paths to start within the community. Within OSS, we realize that while a mistake may be the fault of the maintainer, it is the responsibility of the community to keep OSS development clear and on a common path.


Unclear or ambiguous terms -

The fact that terms or provisions are unclear does not necessarily mean they are unenforceable, it just means one cannot have reliable expectations about what rights or restrictions exist as a result of those terms or provisions. The lack of reliable expectations goes against the entire purpose of having written agreements, so presumably written agreements with unclear terms will be weeded out by a natural selection-type of process: the more times the unclear provisions don't do what the drafter wants them to do, the less likely a rational drafter will use similar terms in future agreements.

My personal opinion is that the project maintainer has the ultimate responsibility to: 1) carefully consider which license gives users/developers the desired rights and abilities; 2) choose a license that is easy for users/developers to understand; 3) make sure the project distribution complies with the license requirements; and 4) make the fact that a particular license governs a project obvious.

If a maintainer does not do these things, I don't see how he can complain later if he can't enforce some right in the license that he didn't care enough about to explain clearly.

It was surprising and sometimes quite frustrating to see all of the open source project pages that either had no mention of a license or only referred to a general license, like "GPL."

As an aside, the GPL seems to answer this parallel question. Right from the Terms and Conditions of the GPLv2 (para. 9) and with slight modification, the GPLv3 (para. 14):
"Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation."

Nonexistent license

I think the user has some responsibility in the sense that a user needs to consider whether a project without a license or a license that is not obvious or difficult to interpret makes a product not worth using.

From a business sense, the clearer and more complete a license is, the better. This means rights, responsibilities and remedies are clear and predictable, which is usually what business and investors like. It is interesting that the GPLv2 and now GPLv3 are so popular, because I think some of the provisions are quite confusing, particularly to those unfamiliar with how software and code are actually built and interact. The fact is, though, both of those licenses are fairly exhaustive in terms of what and how they govern, and I think there is enough certainty there for developers and maintainers to choose to use them. So much discussion exists online about the terms and provisions, that even if someone does not understand everything completely, that person can do a search and find endless analysis and comparisons that can lead to a reasonable understanding. This availability of analysis and discussion is a great benefit of Richard Stallman's and the FSF's polarizing evangelism of free software.

Is it fair to assume that because no license exists, the code is free, or public domain? I would reasonably guess that even if a license could not be found, a developer/user could not reasonably assume that code in question was free. This is like walking by a jewelry store whose front door is unlocked, and "assuming" that everything within it is free.

A reasonable user of open source software needs to understand that the understaffed nature of the development of open source software depends on the honor and trust within the community for it to function. We cannot assume because a developer posted code after a long day, but neglected to include a license, that it is free. While the developer may have a difficult argument to make if such code was made available without restriction, in the spirit of OSS, unless a developer/user verified that this "found" code is in fact public domain, the developer/user could be stealing someone's hard work.

From a legal perspective, the nature of copyright in the United States is such that as soon as the creative "work" (code) is "fixed in a tangible medium of expression" (on a disk or storage medium) it is protected by US copyright law. In order for a creative work to be in the public domain it must either be declared so by its author or the creative work's copyright term must be expired. Currently this means the life of the author plus 70 years.

Summary

Going forward, I am sure that the "market" will drive which OSS projects succeed, and which ones become obsolete, due to risks associated with unclear, contradictory and nonexistent licenses. In the interim, I would like to suggest a common sense "rule of thumb" for qualifying if a project is licensed in a way clear enough that it can be used:

Ernie's Clear OSS Licensing Guidelines

1. Project must have a distinct homepage that is not a repository. Domains are cheap and user pages are free in many cases. This provides a place where the maintainer can manage a freeform data exchange with users, and is a site unique from any repository and its goals.

2. Maintainer needs to provide a URL to the license(s) used. I suggest http:///license.html. Under this file, identify the applications, versions and releases, all hyperlinked. Within the hyperlinks, allow a user to follow distinct hyperlinks to the specific license text. Name the URL for the license text using the name of the core license, like http:///licenses/license-Apache_License_Version_2.0.html

3. License text must reference file from which it derived by URL, like http://www.opensource.org/licenses/apache2.0.php

4. Project homepage MUST provide a link called LICENSES that goes to the main license page, described above.

5. Each download file MUST be compressed with a file called license.txt and license-.txt, along with a hash fileof the text license file.

6. License.txt needs to described the licensing hierarchy for licensing per application/version/release .

7. license-.txt includes the explicit text of the license, and includes pointers to where the SAME license can be found on the website, within the source code (by the same name), and in the binary

8. license-.md5 MUST be included to allow absolute verification that the user has the license that was intended to be included with the specific release

9. Unless the maintainer has a Juris Doctorate and specializes in software licensing law, stick with OSI licenses, or use them as the CORE. In the event that the maintainer uses the OSI license, congratulations. In the event that a maintainer chose to reinvent the wheel, identify such. In the license URL, change the URL to read as follows:
- OSI license: license-.txt
- modified OSI license: license-Modified_.txt (this requires identification of the core license that was modified)
- license newly developed by maintainer or third party: license-custom-.txt

10. Finally, a license should be basic, and easy enough to understand that a layperson could understand the idea of it. In the event that a maintainer customizes licenses, or chooses one that is available, make sure it is easy to understand. Think of it this way, if you can't explain this to your mother, you probably can't explain this to a judge any easier.

In the end, a license for the use of open source software is an agreement between a maintainer/developer who created the project, and a user/developer who plans to use it. The agreement represents the rules of a relationship.

- Make it clear and easy to understand.
- Put multiple copies of the same thing in many places
- Register your licensing for a release on your own site (described above), and register your release and its license at http://gpl3.palamida.com:8080/ , even if it is not GPLv3.
- Take responsibility for making your desires for use clear enough that others can comply without prohibiting use
- For user/developers, if you see something that is unclear, contradictory, or not there, communicate, let the maintainer know. Cooperation by the community will ease the creation of simple and easy to understand licensing that can be verified.

Ultimately, it is the strength of the community that makes OSS succeed. If projects don't meet the basic measure of clear licensing as I define above, insist that the maintainer implement changes to support clear licensing, or do not support the OSS project by using it.

Ernest Park

Kevin Howard

The Research Team

GPL Project Watch List for Week of 12/07

The GPL v3 Watch List is intended to give you a snapshot of the GPLv3/LGPLv3 adoption for November 30th through December 7th, 2007.

December Pearl Harbor Day
December is finally here as we all wind down for the years end. The GPL v3 list is currently at 1276 GPL v3 projects, which is 42 new GPL v3 projects from last weeks number of 1234 GPL v3 projects. Our latest push on LGPL v3 projects has brought our database to 122 LGPL v3 projects, an increase of 27 new LGPL v3 projects and breaking the 100 project mark for LGPL v3 projects. The GPL v2 or later figure has also grown to 6356 GPL v2 or later projects, compared to last weeks number of 6286 GPL v2 or later projects.

























New project conversions this week include:

• Another Gallery: Agal is a themable web photo album that supports transparent rollover buttons.
• DrumTrack: An open source software drum machine for Windows that allows the editing, playback, and mixdown of complete drum scores using audio samples in a variety of formats (WAV, OGG, MP3, AIFF, FLAC, MP2, WMA). Mixdown to WAV audio supported.
• Java Graticule 3D: a simple tool to estimate a local geodetical 3d-net by a least-square-adjustment (LSA) called Gauß-Markov-Model (GMM).

In the News
Sun opens war chest for Open Source developers
Sun Microsystems, the U.S.-based technology company whose product range went completely 'open' in recent years, has announced a one million dollar fund to fuel innovation in the Open Source programming arena. And it chose — deliberately — to make this global announcement in Bangalore on Friday, on the sidelines of the annual free and open source software conference — foss.in.
http://www.hindu.com/2007/12/08/stories/2007120854141800.htm



Notable Mention
Palamida actively takes submissions from visitors on updates on new GPL v3/LGPL 3 projects. We are amazed at the number of submissions we have gotten to date, but even more so, we are incredibly grateful to the almost 100 core contributors who have devoted their time and resources at helping us provide up-to-date information.

GPL Project Watch List for the Week of 11/30/07

The GPL v3 Watch List is intended to give you a snapshot of the GPLv3/LGPLv3 adoption for November 24th through November 30th, 2007.



November Cities for Life Day, and Evel Knievel passed away today (http://evelknievel.com)

November has come to an end and the holiday season is in motion. I guess we will get some data on how Thanksgiving and Christmas affect productivity. As of 4:00 pm PST, our database contains 1234 GPL v3 projects, an increase of 62 new GPL v3 projects since last week. The LGPL v3 number is stagnant at 95 LGPL v3 projects. Lastly, the GPLv2 or later count is now at 6286 GPLv2 or later projects, as compared to last weeks number of 6119 GPL v2 or later projects.


New project conversions this week include:
MarcoPolo: MarcoPolo uses fuzzy logic and rule-based matching to make educated guesses as to your current location, and it automatically switches to the correct network location.
YaNuCa: Web-based nutrition calculator for adult intensive care patients
Sliding Puzzle 2x: Sliding Puzzle 2x es la recreación de un juego de puzzle clásico donde cada pieza es un fragmento de una imagen y hay que reconstruir una imagen desplazando piezas sin levantarlas del tablero.

In the News
Google launches open source contest - Google has launched a global competition to encourage young software developers as part of the company's strategy to promote open source. http://www.informationweek.com/news/showArticle.jhtml?articleID=203100965

Notable Mention
Palamida actively takes submissions from visitors on updates on new GPL v3/LGPL 3 projects. We are amazed at the number of submissions we have gotten to date, but even more so, we are incredibly grateful to the almost 100 core contributors who have devoted their time and resources at helping us provide up-to-date information.


For OSS researchers, we track data to more incremental intervals than displayed. If you would like additional information or have suggestions, please feel free to contact us via this blog, or at rdgroup@palamida.com .


Ernest Park
Research Team