Rik van Riel wrote:
> On Fri, 6 Aug 1999, Linus Torvalds wrote:
>
> > It is over. I refuse to see this continue. The ISDN people need to
> > open up, and stop the ridiculous practice of having closed lists and
> > closed releases, and not feeding them back until it's basically too
> > late.
>
> Unfortunately, the phone companies don't allow you to connect to
> the network with uncertified hardware/driver combo's. Opening up
> the ISDN development could bring all sorts of legal trouble with
> it :(
>
> At least, this is what I gathered from various sources. ISDN
> development is just as opaque to me as it seems to be to you
> so I could be very wrong on this one...
This is an issue for ISDN cards, and an even bigger issue with Winmodems, but
it varies a lot from country to country. If you read the telecoms approval
regulations for some countries carefully you cannot get approval for modules
- only for complete systems. That means a modem approval says its approved
for use with a model XYZ computer. Use with any other computer breaks the
approvals. That means almost every user is breaking the approval. Dumb, huh?
For an ISDN card or modem maker to get approval in most countries they need
to comply with three groups of specs. - electrical safety, spectral quality,
and network signalling compatibility.
Electrical safety is generally a pure line interface hardware issue - the
hardware either meets or does not meet the spec., and software plays no part.
Spectral quality is mostly controlled by the line interface hardware and the
DSP software, whether running in a dedicated DSP or on a host's CPU. To get
approval the vendor _cannot_ permit the end user to tamper with the approved
configuration. This ties the arms of the makers of pure software WinModems,
and may affect the Winmodems with a DSP, and ISDN cards too. The vendors are
not just being difficult when they refuse to release code and information,
although I suspect most of them are difficult by nature. If sufficient work
is performed by code embedded in the product the approvals problems go away,
and the host code can be open. The dividing line varies between countries,
though.
The last approval issue is network signalling compatibility, and this often
shows the biggest variance between countries. For example, some countries
still insist a modem may only be allowed to redial a single number up to X
times in Y hours, with no possibility of user override. Giving the end user
source code for even the back end controller section of the modem or ISDN
card would be a problem here. Again, the dividing line between what approvals
bodies require to be fixed, and what can be freely altered varies greatly
between countries, and makes the vendor's life pretty hard.
With both modems and ISDN cards the approvals issues depend a lot on the
design of the card. If sufficient work is done by code embedded in the card
approvals should be OK. If it relies too much on code the end user can change
you have serious problems with any level of openness in most countries. Some
of this is due to pointless regulation. Some has a valid basis. Consider what
happens if someone tampers with the DSP code for a modem. Will they have the
necessary test facilities to check if they have adversely affected the
spectral output of the unit?
The bottom line is don't be too hard on the ISDN and modem people, as
approvals cause them serious difficulties. On the other hand don't be too
soft on them - if they had a genuinely open attitude they would adequately
explain these issues, and try to open up whatever is possible within the
constraints imposed by approvals.
Now, how does this relate to the ISDN4Linux work? I believe the cards they
currently support are approvable at the card level in most countries. In
fact, considering the "anti-tamper" requirements in a number of telecoms
specs., that would appear to be a precondition for freely releasing legal
ISDN4Linux drivers. I, therefore, doubt this issue has anything to do with
the reluctance of the ISDN4Linux people to make timely progressive releases
of their source code.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/