All, of course, imho:
Were something dreadful to happen to Larry and his estate chose to
change the licensing terms of the current *implementation*
Well they can only do that to a copy of their own, not
existing copies. While the law isn't clear on a lot of
nuances related to more complex open source
licenses, perl's is clear enough that it is implausible
that A) a non-corrupt modern judicial system is going
to interpret it in a way that allows license changes to
apply retroactively to existing copies and B) they can
then enforce this in a manner that truly stops a fork.
(And guess which version the book authors and gurus
would follow? Consider Borland's Interbase, which had
a far more restrictive license, not even remotely as
open as perl. Borland mucked about, so the community
forked. All the gurus immediately backed the fork and
the new direction was established in less than a week.
Now Borland seeks to merge its fork (the original
set of sources, since further developed a little) back
with the community fork. This will happen, and the
pragmatic strength of freedom over self-serving
manipulation will have asserted itself.)
Try writing a second Perl implementation from
scratch.
Indeed, Perl 6 is, afaik, a rewrite, from scratch.
All you need is a community willing and able to do it.
Perl's great blessing is also it's great curse; there's a single
implementation and that *implementation* happens to be
OpenSource.
If anyone concludes that a particular language with a clear
spec that stands free of any given implementation is a
lesser strategic risk than perl, then I think they should adopt
that other language. I very much doubt they will have much
success convincing those working on perl that a commitment
to a spec that stands free of the current implementation would
be a good use of their time, because the license is sufficiently
free, and a stand alone spec that kept up with a continuously
evolving and pragmatically driven thing like perl would take
an inordinate amount of effort.
