One understandably might think that proposing alternatives to
the MIT and BSD licenses with just drafting differences would
be the exact opposite of a license non-proliferation effort.

However, it could be the best place to start raising the bar for
what is considered a "reusable license" that also optimizes the
feasibility of "reusable code".

What do you do if you want to merge code from several projects
with MIT and BSD-ish licenses. Currently the only proper way is
to include the entire bunch of licenses, since they will differ ever
so slightly even if just due to the name of the projects and the
intermingling of copyright notices with the license text. Strictly,
you can for example not relicense the entire code base under
a single BSD-ish license. You can only sublicense. Only the
copyright holder can relicense under a different license.

In a perfect world, I think open source software would just
contain the copyright notices in the source code, specifying the
license that applies to that code, but the license itself would not
contain any direct references to that project, copyright holder or
contributor. Instead, the license would refer back to the
copyright notice that referenced the license.

If in addition to the different conditions, licenses also have
different grants and different warranty disclaimers, the troubles
starts to develop to the scope that has been identified as a
concern regarding license proliferation.

The
GPL
already fulfills these requirements for projects that want
to choose a strong-copyleft license. With the
AFL
and
OSL
there would also be such alternatives for projects that prefer a
BSD-ish or a copyleft license, but most projects continue to use
the less verbose MIT and BSD-esque licenses. Why?

The problem is likely one of "marketing" and one of a preference
for the non-verboseness of the traditional licenses. The best way
to overcome the marketing problem would be to rename the AFL
to BSD 3.0 or even "Beastie License 3.0". This might have a
surprising effect in the developer community and could trigger
a much wider adaption of the new licenses.

But the verbosity of the licenses is also a factor that makes dealing
with license proliferation more difficult. More verbose licenses
tend to increase the likelihood of jurisdictional incompatibilities
and I think it would be fair to say that non-verbose licenses have
been a good thing for open source and have not caused trouble
in the courts.

Here is what a redrafted BSD license that
takes the above into account could look like:

***

Beastie License

Redistribution, use, public performance, sublicencing and
selling with or without modification (the "Deployment") of
works (the "Work") referencing this license in their copyright
notices (the "Copyright Notice"), are permitted provided that
the following conditions are met:

1. Deployment must retain any Copyright Notice, the above
grant, this list of conditions and the following disclaimer.

2. The name of the Work must not be used to endorse, promote
or name works derived from the Work without prior written
permission, which may be obtained by contacting the contact
address provided in the Copyright Notice (the "Project").

The Work is provided "as is" and without warranty of any
kind, expressed or implied, to the maximum extent permitted by
applicable law, but with the warranty of being written without
malicious intent or gross negligence; in no event shall the
Project, a distributor, author or contributor be held liable
for any damage, direct, indirect or other, however caused,
arising in any way out of the Deployment of the Work, even if
advised of the possibility of such damage.

***

To optimize code reusability for projects combining source code
that is subject to different conditions, these conditions could be
added or removed and the license name changed so that the
copyright notices can refer to the appropriate version.

By removing clause 2) from the "Beastie License" you get a
"Mighty License", similar to the MIT license.

By adding the following clause 3) instead, you get the "Copyback
License":

3. Reasonable efforts to support the Work must be made by
contributing any modifications and additions, enabling the
Project to easily obtain such contributions and granting
the Project rights for Deployment of such contributions.

By adding the following clause 3) you get the "Copyleft License":

3. Recipients of the Deployment must be enabled to easily and
at no additional charge obtain the deployed work in its
editable form, including any modifications and additions
as well as the permission for their Deployment.

Source code that references the "Copyleft License" in its copyright
notices would still be combinable in a larger work licensed under
any of the previously mentioned licenses.

By adding the following clause 3) you get the "Snowball License":

3. Any work that in whole or in part contains or is derived
from the Work or any part thereof, must be licensed as a
whole at no charge to all third parties under the terms of
this license.

The "Snowball License" of course would be a pointless exercise,
since by definition it and the GPL would be two-way incompatible
with each other. So, in reality the GPL would take that slot.

Having licenses that are so similar and non-verbose also has the
advantage of making it possible for a novice to understand the
concepts of Open Source licensing in 3 Minutes.

Note that these are experimental licenses that are not currently OSI-certified.

As I'm compiling the concept and contents for a brand new gobi
based
helma.org
site, I have repeatedly noticed the same
dividing line going down straight through the middle of Helma
and the entire industry.

Is Helma a Java Application Server or a Javascript Application
Server? No, it is a Javascript-able Java Application Server.

Java is a strictly-typed language, Javascript a dynamically typed
one, and Helma is kind of sitting on a fence between the two
worlds.

This same divide continues through many other topics such as
the embedded database vs the object/relational mapping, the
extent to which coding conventions for Helma apps should be
established and encouraged vs the creative freedom of scripting
with all its pitfalls, etc.

Of course, we do not want to sit on a fence, but getting off the
fence in either direction means not using the full power Helma
has to offer on both sides - and turning away potential users
that might find Helma to be an ideal environment for their
personally preferred coding and development style.

Instead of being split by this divide, Helma could just get rid of it.
So, I'm working on describing Helma in a way that eliminates this
tension. If you recently have come across some articles that you
think I should read,
please let me know
.

Also, what do you expect from a fresh helma.org site? Any
suggestions regarding the structure and content are of course
very appreciated. I'm hoping to time the new site with the
release of Helma 1.5 or soon thereafter, therefore it will be put in
place rather quickly and then grown from there.

In the future, helma.org will have two sites, one for the
development of Helma itself and one for the users developing
with Helma, just like we now have the
helma-user
and
helma-dev
mailing lists.

Last night it was rainy and we didn't go in. But
the whole thing
taking place in our backyard, we heared NOA, the Lovebugs and David Hallyday just fine inside our house, be it with the backdrop of vibrating windows.

Root object is now named "Home" during the first initialisation of an application.

Changed makeSelectOptions to also work with a simple array of options rather than requiring value/string pairs.

Context of "this" in Mocha Objects now refers to the object that the current request resolves to.

Fixed a bug where the original title was replaced by the title specified for the current audience.

The adminEmail specified in the server.properties file is now used as the default contactEmail address.

Various minor/cosmetic bug fixes.

Diving deeper into OpenMocha:

As with version 0.5, simple "hello world" level examples are included in the default installation. They illustrate the general approach, how you would build your projects based on the OpenMocha framework as a "solution template". Basically, any files inside the apps/main directory besides the framework.zip file either override or extend the code contained inside the framework.zip file.

To get a much deeper look at the inside of the framework, and hence the default code that you can override and extend, do the following: Copy apps/main/framework.zip to apps/framework.zip and unzip it. This will create apps/framework as a separate demo application, revealing its example source code. To auto-start the new application and make it available via http://127.0.0.1:8080/framework/ you need to add "framework" on a new line to the apps.properties file and restart OpenMocha.

If you have any questions or if you are hitting a wall then please do not hesitate to ask either via private mail or
the mailing list
.

Your email address:
The "Decentralize" Newsletter
Exchanging ideas for building a
decentralized fabric of society.
Making true democracy work on a larger
scale while decentralizing "everything",
benefiting from local diversity and
global synergies at the same time.
http://tinyletter.com/zumbrunn