Yeah, why not Javascript?

In one point, oriba san's comment is certainly right:
"I can't seem to find one good information resource for javascript. it's scattered all over the web.
javascript is a mess
."
That is true, which is why I believe so strongly that we should make tabula rasa and call the paradigm shift towards modern client/server-side Javascript by its original project name:
Mocha!
That way we will know what we get when we google for information resources.

"So my earlier prediction has become true: JavaScript is gaining
popularity as an all-purpose development language. One thing's for
sure:
there are more and more JavaScript-based frameworks popping up
for all levels of application development."
Well, in the case of OpenMocha and Helma they might be "popping up"
more, but they've been around and have evolved for several years. So,
has Whitebeam. And Trimpath Junction isn't on the server-side (but
could be, using Helma). All these server-side projects' roots go back to the
1998-2000 time frame. In retrospect I must say, neither
me
nor
Hannes
did a very good job at telling people that our projects were "server-side Javascript".

"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.
"

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.

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