[BBC:OSS] On Kamaelia, Concurrency, Networking, Foundation, Components, Extensions, Messaging, Simplicity, BSD, Python, and My Recent LGPL Epiphany
[NOTE: There’s a reason for choosing to attach such a lengthy title, so please forgive me for blowing up your feed reader of choice if that feed reader of choice doesn’t handle titles that better resemble short stories all that well. ;)]
So instead of attempting to describe the experience I just had, instead, with permission from Sylvain, I am simply going to copy/paste the conversation that just took place that has brought into a whole new light what the Lesser General Public License is all about, and why I think that it flat out ROCKS! (thanks for helping to bring this into a greater understanding for me, Sylvain!)
Firstly, and understanding of what Kamaelia is all about,
A framework providing the nuts and bolts for building components. A library of components built using that framework. Components are implemented at the lowest level as python generators, and communicate by message passing. Components are composed into systems in a manner similar to Unix pipelines, but with some twists that are relevent to modern computer systems rather than just file-like systems.
Secondly, the conversation that lead to my recent epiphany in regards to the greatness (or at least potential greatness) of the LGPL.
Sylvain:
http://www.bbc.co.uk/opensource/projects/chapter_tool/
that sounds very handy
http://www.bbc.co.uk/opensource/projects/kamaelia/
also
http://www.bbc.co.uk/opensource/
OSS backed up by the BBC
you gotta love it :)M:
huh??? whoa! (checking out now…)Sylvain:
the kamaelia stuff seems nice
I haven’t checked how it works though
but the idea is neat
neat as in nice :)M:
yeah, seems like it… need to dig deeper…
(digging)M:
Wow! > http://kamaelia.sourceforge.net/Home < and Wow! > http://kamaelia.sourceforge.net/Licensing.htmlSylvain:
:)
u like it ?M:
You know, until I saw this explanation [ed.: see previous licensing link], I never realized just what the Lesser GPL was all about… Now THAT makes sense!
Is there anything I might be missing that might suggest its not as good as it sounds?Sylvain:
nope
that is how it works :)M:
I mean, the general idea of requiring changes to the underlying foundation to be returned back to the community, while at the same time maintaining the freedom to license your extensions to the platform however you might want –
that ROCKS!!!Sylvain:
that’s the point of the LGPL indeed
but usually LGPL only makes sense for a library
not for an application per se
I still prefer the BSD license
because it is just simpler
the LGPL can be argued
what is a change of the original code?M:
Well, right… there would be no point in licensing extensions under the LGPLSylvain:
so LGPL is very nice but can be a nightmare to interpret in some casesM:
agreed… BSD makes sense for applications that build on top of an underlying foundation
from: http://kamaelia.sourceforge.net/Licensing.htmlPlease note though: since you can choose to accept the LGPL this means that you can use Kamaelia code in any project of your choice without releasing your code, as long as you don’t change any Kamaelia or Axon code. Due to the nature of Python and Python libraries we don’t count simple inheritance (that is class foo(component): … ) as modification to Kamaelia or Axon.
which I guess is why the above text was pulled out and explained further
Sylvain:
yes
and they clarify it really wellM:
yep!
Thirdly, unless both Sylvain and I are missing something, the notion of requiring changes to the underlying system, or foundation, to be given back for the benefit of the community while allowing the extensions and/or components that build on top of this system to be licensed however their creator might see fit…
Now *THAT*, in my own opinion, makes a *TON* of sense!
Anybody care to provide a counter argument as to why this may not make as much sense as I’m suggesting?
So in quick follow-up to this: While I can’t remember the exact quote, paraphrasing a comment that Tim Bray once (well, probably more than once) made regarding the development of a specification…
“As time goes on, a good specification gets smaller, not bigger, with each revision”
As long as I haven’t completely munged up the meaning of the original statement, from a general standpoint, shouldn’t this statement apply to more than just technology specifications, but to the licensing frameworks that relate to technology as well? I mean, if our entire focus in technology is to progress forward by making things less complicated, easier to understand, easier to use, and easier to […] (that is what technology is all about, right?), then why not place this same focus upon the licensing frameworks these same technologies are bound to?
I do recognize that law and technology are two very separate things. I guess I just wish that in the spirit of freedom and progress we could find ways to be more progressive instead of oppressive in regards to both.
A pipe dream? If yes, does it really have to be that way?
Just wondering…
Oh, and by the way… I’m pretty sure that it doesn’t have to be that way.
—
Update: via http://kamaelia.sourceforge.net/Challenges/?tab=2
Moore’s law has ended in terms of raw CPU power(Mhz) this will radically change the way systems we use are built.
Moore’s law has ended in terms of raw CPU power? Does Gordon Moore know about this? Hell, does ANYONE know about this???

Not sure about Gordon Moore, but Intel does and is promoting the fact heavily. They phrase it slightly differently, but the actual meaning is the same: no more free (Hz) upgrades!
@Marcel,
Is this in regards to the actual physical constraints to the medium? I assume yes, and if so, then yeah, I guess I was aware of this. However, from all reports that I have seen, the knowledge of the physical constraints has promoted the development of other medium and methods, and if not mistaken, the result is that of Moore's Law moving forward untouched.
But then again, I have nothing but news reports to base this analysis upon, so for all I know I'm completely in the dark ages of thought in this regard.
Anybody care to help clue me in?
David,
Moore's law is "moving forward untouched" in terms of number shrinking processes and the resulting increase in numbers of transistors on a chip. However, as tbe original quote says, it has 'ended' in terms of the increases in raw speed (in Hz) of those transistors. So what is happening is that any extra power is coming purely from the extra transistors, not from those transistors being faster as used to be the case. We've also pretty much hit the limit for making a single instruction stream go faster by piling more transistors into executing it.
The upshot of this is that our single cores are not getting any faster, we are just getting more cores on the chip. However, this obviously also means that our single-threaded programs will not be automatically getting faster with the next generation of chip, which always used to be the case.
http://www.theregister.co.uk/2006/09/27/intel_terafied/
http://www.theregister.co.uk/2006/08/22/ramp_mit_fix
http://ramp.eecs.berkeley.edu/about.php
David,
Moore's law is "moving forward untouched" in terms of number shrinking processes and the resulting increase in numbers of transistors on a chip. However, as tbe original quote says, it has 'ended' in terms of the increases in raw speed (in Hz) of those transistors. So what is happening is that any extra power is coming purely from the extra transistors, not from those transistors being faster as used to be the case. We've also pretty much hit the limit for making a single instruction stream go faster by piling more transistors into executing it.
The upshot of this is that our single cores are not getting any faster, we are just getting more cores on the chip. However, this obviously also means that our single-threaded programs will not be automatically getting faster with the next generation of chip, which always used to be the case.
http://www.theregister.co.uk/2006/09/27/intel_terafied/
http://www.theregister.co.uk/2006/08/22/ramp_mit_fix
http://ramp.eecs.berkeley.edu/about.php
Ahhh... Okay, cool. I see what you mean now. Thanks for the explanation and the links! Am checking them out now...
Thanks Marcel!
My comment there was heavily qualified there - I specifically mentioned MHz there because people abused Moore's law for some time to mean every 18 months CPU speed as measured in MHz doubles. This held true for a long while, but topped out a few years back. http://kamaelia.sourceforge.net/Challenges/?tab=8 goes into this in more detail, and a nice article that ended up in Dr Dobb's was published last year, but the online version can be found here: http://www.gotw.ca/publications/concurrency-ddj.htm
If you look at the graph of CPU speed vs years, it's clear.
It's why Sun, Intel, AMD, and notably IBM & Sony & co with the CELL are all going multi-core. Why? Whilst the revised formulation - that speed measured in MHz doubles every 18 months, the original formulation (transistor count doubling every 18 months) looks set to continue for a while yet. (At which point I suspect we'll start doubling layers, or some new funky thing :-)
I've always been interested in parallelism, since in many respects you can end up with more natural systems (since the real world is massively parallel!) if you have the right framework (Hence Kamaelia's core approach). However given that the future from hereon appears to be multicore, having tools that make this natural (and easier for the average developer) becomes more and more important. We think we're getting somewhere :)
The main system might be python, but we have a proof of concept in CVS for C++, and ruby should be a trivial conversion.
Finally, I'm glad you found the licensing page clear :-)
My *personal* preference is for the BSD license, but the MPL/GPL/LGPL gives maximum protections for users and interoperability with other libraries, whilst protecting the base code from being closed.
Hi Michael,
Thanks for the follow-up!
I really appreciate you taking the time to provider deeper insite. This makes a TON of sense now. And I agree with you whole heartedly in regards to parallelism.
I'm going to spend some time and research the links you provided, and then follow-up accordingly with anything that seems would provide benefit to those who might read the follow-up. It seems pretty obvious to me that you guys have something pretty spectacular going on here, and I most certainly need to spend some time and really find out what this is all about.
Thanks again for your thoughts! VERY much appreciated!