Author: JT Smith
See http://www.gnu.org/software/bayonne for general information.
1. Foundation and Empire
2. Audio prompts then and now
3. Call Queue’s and Joined Sessions
4. Card Exchange Program
5. New release of GNU Common C++
Foundation and Empire
~~~~~~~~~~~~~~~~~~~~~
No, I have not been re-reading Asimov recently. While writing this report, I am on the way to Boston to visit the FSF. The FSF should be well known to most people reading this, although I have noted some whom have question it’s relevance today.
Certainly the FSF’s core mission are both vital and as necessary today as at it’s founding. The FSF’s role as being a copyright holder is often overlooked but is one key to the survival and success of the free software community.
Having a copyright holder is of course essential for the GPL to work since it is in essence a copyright contract, not a license. As such, this is necessary, even essential, since a contract can be subject to rights of second sale, although some dirty proprietary vendors wish to strip the public of this long understood right.
In second sale doctrine, one can resell a product in a manner of their choosing. They could do so in ways that deprive the final customer of his rights. By using copyright law to preserve ownership rather than contract law to dissipate it, the reseller (or redistributor, if you will) of course cannot do so except under the same explicit terms as the software received, as per the GPL.
Individual copyright holders become very complex very quickly in a large project. Sometimes it is necessary to dispute a GPL violation, and while possible, it is more difficult proving standing with only one or a small portion of the holders. Surrendering copyright is of course something that can only be done once, but doing so to consolidate ownership can make it possible to enforce the GPL and even to make it possible to modify later if necessary because of some unforeseen legal twist or turn.
Transferring copyright is something that can only be done once. While there are many so called “open source” companies that receive code from the community and expect them to then assign copyright, there is always risk that such companies may later choose to release proprietary products based on contributed code. Indeed this is already happening and I fear will continue to.
With this in mind, the role of the FSF as a trustworthy community copyright holder is something all free software projects need. As far as I know it is the only copyright holder that engenders such trust. The FSF can neither be bought or compromised. One can think of it as the one copyright holder that assumes all of the burdens and exercises none of the so called privileges of copyright.
Even those that contribute code to companies should consider assuring that at least some of the code has copyright held outside the company and the FSF is and ideal for this. Even honest commercial free software companies can and do trust. Companies that may have secret plans to release proprietary code will naturally object to this, and this is one way to better identify such entities.
This is just one role the FSF plays that is still very relevant. There are other roles, including enforcement of the GPL. The latter is interesting in that often the FSF’s goal is to mearly bring about compliance. Compliance with the GPL, unlike that of proprietary licenses, costs nothing, and need to be done only once. One doesn’t need to audit each and every machine to prove full compliance, or have a vendor use such tactics to intimidate businesses to buy more products the way some shamelessly do. The GPL is simple and straightforward, and has no hidden compliance costs.
This is actually the second trip I have made this week. Earlier I was given a chance to speak to some senior policy people in DC. The situation there is most interesting. For years we have ignored the fed, and some have recently been disappointed by the feds response to the monopolist. However, things are changing and at a level we need as a community to address now.
I have dealt with Federal contracting many years before. For people to speak openly of disgust and even specific incidents of vendor intimidation not only in front of their own senior policy people, but, even more amazing, outsiders, this is unheard of, and clearly something significant has happened. Never have I seen this before. Similarly, never have I heard of a vendor selectively targeting individuals for selective intimidation, let alone on the apparent scale and scope this vendor appears to have.
Equally challenging, it is unfortunate how much lack of understanding there is at the most senior levels in government. When a senior administrator looks at GNOME, say, or KDE, he is shocked. For years, his “paid” buddy, his very best “paid” vendor friend, has been telling him that free software is ugly, that it involves command lines, that doing even basic word processing involves emacs (no offense, Richard 🙂 or vi. Show this person Koffice, open office, even abiSuite, and see the look of surprise. Best, is when the full realization dawns and he understands “I have been deceived”.
The enemies of free software require ignorance to sell their products. Therefore, we must enlighten. The enemies of free software use fear and terror. We must make it clear it is they alone that are true terrorists.
I plan to visit DC more often as what resources I have will allow. I have also been contacting people late this week from other projects who may be able to volunteer to provide basic presentations about their projects to an audience of senior govt people. There exists a venue and forum for this to be done, and the key is to find people who can do this without commercial ties or pitching any commercial products. If you have read this, are interested, and wish to learn more, feel free to contact me directly at sugar@gnu.org, and I will take the time to respond and consider how this can be done and when you might be scheduled.
Ah, but what does this have to do with GNU Bayonne exactly, and why am I going to Boston? Well, the answer for that is much simpler and shorter; the FSF will soon be running it for office services.
Audio prompts then and now
~~~~~~~~~~~~~~~~~~~~~~~~~~
Historically the process of using audio prompt libraries have been a bit confusing in GNU Bayonne. There have been odd notations, like *::playrec, or strange constructions like setting variable paths and then applying them in a play script to play a named file path. I have chosen to simplify this entire process and somewhat automate the way audio prompts are selected.
Consider the “simple” case of “play playrec1” in the 1.0 server. In the old server, this might have been collected from /usr/share/aaprompts/UsEngM/dyfet, which, in fact, is incorrect, since it’s a service specific prompt. Using “play *::playrec1” is more clumsy,
In 1.0, search is made, by /usr/share/prompts/UsEng/dyfet/playrec/playrec1.au because this appears in the “playrec” service script. If it’s not found there, a second search is made for it in /usr/share/prompts/UsEng/dyfet/common/playrec1.au. This makes it more natural and easy to group prompts together and avoid peculiar prompt naming conventions in the script files.
Foreign script prompts can still be done with the :: syntax, as in say play debit::enterpin, as before. However, this does not require a special “alt” prefix the way the old server did; this resolves cleanly to /usr/share/prompts/UsEng/dyfet/debit/enterpin.au.
Even better is the use of new keyword options in GNU Bayonne audio commands. For example:
record %session.digits prefix=prompts
This alone replaces what used to be typically written as:
set %var “prompts/%session.digits”
record %var
Also, consider this new syntax:
play press1 forspanish language=”Spanish”
This replaces what might have used to be written as:
set %audio.language “Spanish”
play press1 forspanish
set %audio.language $language # restore…
All of these things will make it much simpler to construct applications compactly, especially when mixing spoken languages in the same call session, both for Bayonne and Olorin.
Call Queue’s and Joined Sessions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
One important change has been for support of call queues for selection and syncrhonization of incoming and outgoing trunks. This will make it possible to do things like have the least busy port of a policy group selected when an outgoing request is made, or to have a limited resource pool of outgoing lines servicing a larger pool of incoming ones. This also ties into making join a standard operation in Bayonne and Olorin, and makes use of the existing ccScript queue symbol infrastructure.
Another possible use for queue control in GNU Bayonne is for ACD groups. I am considering a pure ccScript implimintation of agent queues. To a limited extent this can be simulated now by constructing queues in the global symbol space in the 1.0 server and then just manipulating them between scripts acting as “agent” scripts and those acting on behalf of callers. Ultimately, however, we need more sufistication. We need to be able to monitor average wait time and to provide real call statistics. This will come in time, either as part of the final 1.0 server, or in development after 1.0.
Card Exchange Program
~~~~~~~~~~~~~~~~~~~~~
Several people have asked me about the possibility of sharing telephony cards between free telephony developers. The idea is that sometimes someone has a card they no longer need or use but that might be useful for another developer to test with. Telephony cards are expensive and somewhat uncommon, so it’s hard to find them cheap.
The idea of the exchange program is to put telephony cards in the hands of developers that need them. For this goal we are looking at establishing a web site where people can provide notice of loaner or donated equipment and developers can express their interest and needs.
I have had one person come forward who may be willing to help put such a site together. I would like to see if we could host it either at gnu.org or alternately a site like voxilla. It need not be a very pretty site, it need only be functional to be effective for this mission.
New release of GNU Common C++
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This has not been a month with many releases. However, progress continues on the 1.0 server, and some bug fixes are being accumulated for a new stable server release. What has seen some recent activity is GNU Common C++.
I have been experimenting with cross compiling GNU Common C++ on a GNU/Linux hosted system. This proved quite workable for experimentation, and in fact it is possible to test native Microsoft Windows executables on such a platform with WINE. I am not generally suggesting this should be done, for I would rather see more Microsoft Windows developers choosing to work on free software rather than see more of us doing Microsoft Windows related development, however, it is possible to test some things this way and it may be useful for some to do so.
