Mighty and Beastie Licenses

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.

Tasting the OpenMocha Console

A taste of working with the OpenMocha Console... 

makeDigestEncoder  = function(kind) {
    return function(str) {
        if (methodOf(this)) str = this;
        var algorithm = java.security.MessageDigest.getInstance(kind);
        var digest = algorithm.digest(new java.lang.String(str).getBytes());
        var hexdigest = '';
        for (var i = 0; i < digest.length; i++) {
            var b = digest[i] & 0xff;
            if (b < 0x10) hexdigest += "0";
            hexdigest += java.lang.Integer.toHexString(b);
        }
        return hexdigest;
    }
}

makeDigestEncoder('SHA-512')('hello world'); 

If you dig this screenshot, you'll get a glimpse of OpenMocha under the hood. If you have not discovered the OpenMocha Console yet then this might inspire you to explore it .

04.09.2005, 11:59

"Who am I?", asks Helma

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.

Freedom Languages vs Safety Languages
Can’t we all just get along?
http://www.journalhome.com/codecraft/9003/

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.

30.08.2005, 13:24

Savety vs Freedom and other recent ramblings

• Freedom languages
• Choosing The Platform
• Assembling The Platform
• JavaServer Faces vs Tapestry - A Head-to-Head Comparison
• Why Good Programmers Are Lazy and Dumb >
• ECMAScript Shells
• Basic webstandards Workshop

29.08.2005, 12:50

Mont-Soleil Open Air Lineup

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.

The Lineup for today and tomorrow:

Here two pictures from the aftermath last year:

Update 06.09.2005: Official Photos of the 2005 Mont-Soleil Open Air

26.08.2005, 16:26

Rhinola - Mocha reduced to the minimum

Rhinola is a very thin server-side JavaScript execution framework based on Rhino running on top of mod_gcj . Serving Gnu-compiled Rhino with Apache.  Projects that you do not want to reduce to the maximum , you can now reduce to the minimum .

10.08.2005, 12:51

OpenMocha 0.6 available for download

• Replaced individual Mocha Object macros with generic mocha object macro calls.
• Fixed an encoding bug relating to Mocha Object skins and the Wysiwyg-Editor for Content Objects.
• Added "editing" and "adding" Mocha Objects that extend the default "edit" and "add" page actions.
• Creation and modification dates are now tracked by default.
• Added loop and collect functions.
• 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.

>>> E4X presentation by Brendan Eich