Moving beyond Java

"When Java started, it was easy to write web applications. Now, to build a Java application in the lightweight way, you need to learn servlets, XML, struts, some persistence framework like Hibernate or iBATIS, and Spring to help glue it all together. That's an oppressive learning curve. And three years from now, when the state of the art has changed, you'll have to do it all again. Java's not approachable to the masses like it once was. "

29.10.2005, 10:39
 

Spidermonkey Javascript 1.5 finally final

Release Candidate 1 goes back all the way to March 3rd, 2000. Finally declared final now , this release actually carries a September 2004 version date.

24.10.2005, 21:39

Helma Trivia

Historical trivia of the Helma project, picked up during my vistit in Vienna.

No comment :-) ...or maybe just this: The answer to "Who am I?", asks Helma

13.10.2005, 13:54
 

Finding Java Packages

Hannes has discovered a collection/overview of Java packages which even he considers "ziemlich gut". If we tell people "to leverage the whole wealth of Java libraries out there" then we should also provide them with some pointers where to get such packages. This needs to find its place on helma.org.

Another good source I'm planning to include on that page:  DocJar - Searching 312,112 Java Classes

12.10.2005, 20:02

JSEclipse Javascript plug-in for Eclipse

12.10.2005, 15:54

Catching up to Continuations

Need to do some catching up...

• Jetty 6.0 Continuations
• TSS Asks: How should tutorials be written?
  
• Prototype leaps forward

 ...and then there is this...

• Swiss "yes" baffles Brussels bar-hoppers

26.09.2005, 17:22

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