1. It's one of only 3 OSS licenses that take the "network" into account
(CPAL, OSL, AGPL) whereby usage can be considered distribution.
2. It doesn't require that code be given back
3. It enforces the brand of the developer (in this case Reddit) which actually has some benefits.

With enough projects licensed in practice, it would be good to prove out that none of the negative theory has come true.

This is a free software license. It is based on
the Mozilla Public License, and is incompatible
with the GPL for the same reasons: it has several requirements for
modified versions that do not exist in the GPL. It also requires
you to publish the source of the program if you allow others to
use it.

The license that closes the ASP loophole is now recognized by both OSI and FSF and was recently adopted by Facebook.

June 03, 2008

The CPAL was initially developed by social enterprise wiki company Socialtext,
and approved by the OSI last year. Since then it has not seen wide
adoption, although it is used by several prominent open-source
projects, including the xTuple ERP applications and the Mule ESB. It's based on the familiar Mozilla Public License (used by Firefox, among other high-profile pieces of software) with two key modifications.

And here he go into the weeds again, because while Google, MySpace and Yahoo have won headlines for their OpenSocial initiative, they have yet to choose a license for the code, and Google is notoriously against closing the SaaS loophole.

Matt Asay takes the populist position, condemns their choice, questions intent, but offers no new rationale. The intent seems to be reasonable and we could be more welcoming:

The goal of this release is to help you as developers better understand
Facebook Platform as a whole and more easily build applications,
whether it’s by running your own test servers, building tools, or
optimizing your applications on this technology. We’ve built in
extensibility points, so you can add functionality to Facebook Open
Platform like your own tags and API methods. We’re also hoping you use
Facebook Open Platform in ways we’ve never thought of – just as you
showed off your creativity with Facebook Platform, we hope this lets
you be creative with the foundation of the platform itself.

Facebook also cited CPAL, which requires attribution, as a better match
for network deployment and how software works today. This makes sense,
but it also makes me wonder why not the Affero GPL?

Distributing the software over a network is an act of redistribution. If you make modifications, you should contribute them back to the community, as is the case with almost every other Open Source license. I'll also point out that CPAL only asks for equal attribution, which for practically all needs is no burden. 451 gets this, just trying to be clear, and I also found their post on how Google is suppressing APGL worth a read.

But the one thing you must read is my friend Chris Messina's post. He comes out negative on CPAL, but the real point is there is a real transition here. One that I know for a fact is difficult for many great and reasonable developers. One that is real for the community. One that may be less about the license options than the topology of code and our interesting times.

Furthermore, in light of my recentposts,
it occurs to me that the nature of open source is changing (or being
changed) by the accelerating move to cloud computing architectures
(where the source code is no longer necessarily a strategic asset, but
where durable and ongoing access to data is the primary concern
(harkening to Tim O’Reilly’s frequent “Data is the Intel Inside” quip) and how Facebook is the first of a new class of enterprises that’s growing up after open source.

I hope to expand on this line of thinking, but I’m starting to
wonder — with regards to open source becoming essentially passé
nowadays — did we win? Are we on top? Hurray? Or, did we bet on the
wrong horse? Or, did the goalposts just move on us (again)? Or, is this
just the next stage in an ongoing, ever-volatile struggle to balance
the needs of business models that tend towards centralization against
those more free-form and freedom seeking and expanding models where
information and knowledge must diffuse, and must seek out growth and
new hosts in order to continue to become more valuable. Again, pointing
to Tim’s
contention that Web 2.0 is also at least partly about harnessing
collective intelligence, and that data sources that grow richer as more
people use them is a facet of the landscape, what does openness mean now?
What barriers do we need to dissemble next? If it’s no longer the
propriety of software code, then is it time that we began, in earnest,
to scale the walls of the propriety data horders and collectors and
take back (or re-federate) what might be rightfully ours? Or that we
should at least be given permanent access to? Hmm?

Microsoft should be commended for participation and engagement with the community. Matt Asay notes this is within a finite scope:

I never doubted that these would be approved,
but am glad to see the studied manner in which the process was (mostly)
carried out. To me, this shows Microsoft the correct way to engage in
open source: through the front door, rather than through back-door
patent FUD...

In short, Microsoft played by open source's rules on this one and so
was treated as a full open-source participant. In other contexts, with
different behavior, Microsoft will be treated much differently.

The 451 Group highlights that the licenses passes the current test, but OSI is a position to evolve as conditions change:

“If, as some fear, the approval of these licenses ends up damaging
open source, perhaps we will learn of some 11th condition or some
change to the 10 that must be made to better preserve the integrity of
what we call open source,” he [Tiemann] writes.

“Neither the First Amendment alone, nor the original 10 Amendments
known as the Bill Of Rights were sufficient to establish a government
truly of the people, by the people, for the people (and some would say
we still have a ways to go), so why should we expect that after less
than 10 years, the OSD will contain everything there is to know about
promoting and protecting open source?”

For now though it’s all eyes on Microsoft to see what the company
will do next, and in many ways this will be more interesting than
whether or not the OSI approved the licenses. For reasons that were
never fully explained, Microsoft wanted open source licenses.

Now that it’s got them, will it use them to release significant code to the community?

Good question. Now that they are, in part, playing by the rules, lets give them a chance to play the game.

September 17, 2007

Yahoo acquired open source email (complete with Ajax pixie dust) company Zimbra for $350 in cash. My most sincere congratulations Scott and Satish, as well as Brad Garlinghouse on the other side of the table. Good move.

This isn't just about competing with Google's Gmail. It builds upon Yahoo's native email development plus acquisitions such as Oddpost and Stata Labs to build a credible web-native alternative to Outlook and Exchange. At Socialtext we are moving to Zimbra for at least shared calendaring. It will be interesting to see Google's offline moves as it will now need to play catch up.

But this isn't just about email and calendaring. This is another significant commercial open source acquisition. This also raises a time honored question when it comes to Yahoo, and how it relates to the enterprise. Both Satish and Brad's posts highlight their partner network (mostly ISPs). Selling and servicing enterprises is not the competency of Yahoo, but as Google has VARs for Appliances so to does this XYZ combination. If this is a direction for Yahoo, their number of acronyms will exponentially expand.

July 30, 2007

Web 2.0 companies are largely built upon Open Source software. But how many of them do you consider significant contributors to Open Source? In general, there is an open ethic, and communities demand (and reward) it. But somewhere along the way, the focus shifted to APIs and Open Source wasn't rationalized as part of the business model. Some call them Open APIs or Open Data, but until there is a legal framework adhered to as community standard (word is OSI will work to address this), they are just APIs with unilateral rights. And with the focus on APIs, instead of contributing code back to the projects you leverage, or contributing your own projects, cooperation has been limited (save a handful of great standards efforts like Atom) Business models have also been held back by the gradual evolution of Open Source licensing, until now.

Web 2.0 companies seriously considering what portions of their codebase could be Open Source licensed for their own benefit. As well as taking an inventory of what they use for the purpose of what they should give back.

MPL+Attribution companies adopting CPAL because they want to be Open Source and part of the community

Enterprise 2.0 SaaS providers reconsidering their business model with the one Open Source license that closes the SaaS loophole

Enterprises considering what portion of their erstwhile custom in-house codebase could now be made available under CPAL

Portal companies thinking beyond how they have the coding power to write around attribution and consider which of their projects could be licensed with it

New Commercial Open Source ventures

Native Open Source projects address the SaaS loophole and bring attribution back to their community because of the positive incentives it provides for innovation

I should say my first paragraph is a generalization. There are lots of Web 2.0 companies that are great citizens of Open Source and some make it part of their business model, like Wordpress and recently Six Apart. Some Portals make great contributions, but again, my impression is that they have played into the API parlay. To defeat this generalization, there is almost a need for a wiki that lets people openly inventory the open source products leveraged, licenses used and contributions back.

I'm not sure the Open Source thing is such a big issue anymore. I see
many Open Source platforms being managed by service providers and
whether they are Open Source or not won't be as important - it will be
whether there are open API's. Underneath it could be anything...

This is precisely my point. Yes, it is great that you can develop upon an API, from say, Flickr. And look at all that innovation around the Flickr API. But what makes it Open? Because it is public? With a unilateral non-standard license, explicitly forbidding commercial use in some cases, that can be changed at the whim of Yahoo, any development or use is at the whim of Yahoo. API standards like Atom Publishing Protocol or what we are doing with Amo are different. But even on top of standards you need a legal framework to foster a real commons.

July 25, 2007

The Common Public Attribution License (CPAL) that Socialtext submitted was approved today by The Open Source Initiative (OSI). As an OSI Certified license, CPAL should provide a solution for commercial open source application projects and companies. I expect many of the 40+ companies using MPL+Attribution licenses not approved by OSI to apply the license to their products to meet both their commercial and community needs. Keep in mind there is more to it than Attribution, but it covers network use required to close the SaaS loophole in Open Source.

For Socialtext, this marks the end of a very long process where we paved the way for others. I'm happy with the final result, which should be posted at opensource.org soon, and I'll update this post accordingly. For now, an unofficial version of the final text is here.

July 12, 2007

Open Source came before, if not provided a platform for, Software as a Service. Open Source Licenses have a big loophole for the most common method of software distribution today. Tim O'Reilly addresses this while making yet another argument for open data.

The article describes how during the GPL v3 discussions, there was a
move to close the "SaaS loophole" by including some of the provisions
of the Affero General Public License or AGPL:

the FSF supported the creation of the Affero GPL and attempted to
integrate it into the early drafts of the GPL3. However, that plan
backfired and the FSF not only struck the text that would extend the
GPL to software delivered as a service but clarified just what "to
'convey' a work" actually means.

Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

In other words, software delivered as service is now officially not covered by the GPL.

...the community forced the provision out as indicated in the FSF's 61-page rationale document [pdf] that accompanies this latest draft.

We have made this decision in the face of
irreconcilable views from different parts of our community. While we
had known that many commercial users of free software were opposed to
the inclusion of a mandatory Affero-like requirement in the body of
GPLv3 itself, we were surprised at their opposition to its availability
through section 7. Free software vendors allied to these users joined
in their objections, as did a number of free software developers
arguing on ethical as well as practical grounds.

The article concludes that while this is the right decision, it places
real limits on the long-term significance of the GPL: "The future is
networked. The GPL isn't."

Bryan Richard's article is a great analysis and the implications of keeping the loophole open for SaaS are significant. There are both practical and philosophical reasons to close this loophole with a network use clause:

If you're unfamiliar with the SaaS loophole, it's probably best
described by a license that actually covers it. Fabrizio Capobianco,
who created the Honest Public License describes it as such:

Some people interpret distribution of software as a service not as
distribution of software (because GPL v2 was created before web
services were on the horizon and therefore did not address them in the
license). They believe that they can use open source software to offer
services to the public, without returning anything to the community.

We believe that certain software can extend the bounderies
[sic] of a person, and therefore should not be out of the control of
the individual. We believe that people's freedom should be protected.
We believe that this includes their digital interface to others.

Affero and the Common Public Attribution License (CPAL)

Many OSI Certified licenses were developed before the web became a common method
of distributing an application to users. Making an application
available for use over a computer network, such as an email service
accessed and used like GMail, should be treated the same as compiling
it, burning it on a CD-ROM, and mailed out that CD-ROM. We sought to address this issue when developing the Common Public Attribution License (CPAL). Some licenses
use the Affero Network Use clause to this effect, but we chose the
External Deployment clause from the Open Source License (OSL) because it is more technology-neutral (OSD #10) and future proof, and is clearer about the philosophy behind the requirement.

The other issue is the Affero license, while widely known and used, is not OSI Certified, whereas OSL is. My hope is that CPAL, an MPL plus APL plus OSL license, is approved by the OSI at their next board meeting at OSCON at the end of the month and I can write sentences with less acronyms. But my other hope is that there is a license accepted by the community that provides Attribution like GPLv3, but also closes the SaaS loophole.

June 25, 2007

Tonight I posted the following on the Socialtext Blog. It may seem like a bit of inside baseball, but it could be a very big deal:

Today Socialtext submitted the Common Public Attribution License (CPAL) to the Open Source Initiative (OSI). OSI is a community appointed body responsible for open source licensing. OSI is the creator of the Open Source Definition (OSD), certifies licenses as OSI Certified, guards against license proliferation and gives meaning to the term open source. Socialtext is the first an only company with a Mozilla Public License (MPL) plus Attribution license (amongst 40+ commercial open source businesses) to seek OSI Certification. We do not, however, consider ourselves open source until all our licenses are OSI Certified.
We have been working through this process for some time. Today the submitted CPAL can be found here and we look forward to the open conversation on OSI's license-discuss mailing list. For those interested in a summary of our submission, here it is:

1. The Common Public Attribution License ("CPAL") is based on the MPL which has been approved and all of the new provisions are in Sections 14 and 15 (and Exhibit B) and adding "Original Developer" to certain disclaimers ("Original Developer" is a term defined in the new provisions for those who originally created the program who may be different from the "Initial Developer"). Section 14 provides for an attribution notice based on the Adaptive Public License and Section 15 provides for a network use provision based on the commonly used provision on "External Deployment" found in the Apple Public License, Real Network Public License and the Open Software License. We have used the Adaptive Public License, which is virtually the sames as the prior attribution provision which was in Exhibit B of the proposed Socialtext Public License, as the basis for the attribution provision because it was approved after OSD 10 was adopted. We have limited the placement requirement for attribution notice to "prominent" rather than a specified size or location. We have also permitted the use of splash screens. The term "prominent" is frequently used in other OSI approved licenses such as the GPL and NASA Public License. Socialtext believes that the application software has special needs as comparedto operating systems because of the application software can be used anonymously in large distributions and can be used to provide servicesthrough an ASP which does not provide modifications back to the community. None of the approved OSI approved licenses include both a network use provision and an attribution provision. We have limited the new provisions to those which are either the same or very close to provisions from existing licenses (see above).

2. The license can be used with any software which is licensed under the MPL and licenses compatible with the MPL. The CPAL will take precedence for combined works. Some licenses such as the GPL which are incompatible with the MPL are also incompatible to the CPAL.

The above is a summary of how CPAL is OSD Compliant, but you can also explore this points one through ten. If the license is deemed compliant with OSD by the OSI Board, it should be OSI Certified, a mark that carries great meaning on both the community and market.
Socialtext also uses other OSI-Certified Licenses within its products. Primarily, Perl Modules licensed under the Perl Artistic License, some originated by others, some by Socialtext employees in an act of giving back to the community.
While working on CPAL, we developed a new strategy for open source licensing. Some core components will be licensed under both CPAL and the Perl Artistic License (PAL, I like to call it because of the nice ring and rhyme, although it is commonly referred to as the Artistic License). With CPAL and PAL together we gain something in a greater community and commercial interest.
Dan Bricklin highlights this aspect I'm not supposed to call triple-licensing in his post SocialCalc 1.1 released -- we now have a real Open Source project:

The SocialCalc Engine code is being released under the Artistic License 2.0. This license, written by the Perl Foundation, is basically the same as the Artistic License used for years for Perl and was apparently just approved as "Open Source" by the OSI. (Perl also has the option of being used under the GPL.) I understand that this is a pretty liberal license which allows proprietary modifications but also allows code licensed under it to be included in projects licensed under GPL. This should hopefully help this spreadsheet engine code become part of a wide variety of projects and get a large number of developers contributing to its maintenance and advancement.

Tomorrow we will post to the wiki an expanded FAQ and guide for applying the CPAL to your own project or product. We don't recommend doing so until OSI approves it, as a disclaimer, and provide it for broad understanding of the potential of this license to serve community and commercial needs. If not, heal a growing rift in the community overall.