[Asterisk-Dev] OT - Regulatory hurdles for Zaptel and Japanese PRI

[Steven Critchfield]

On Wed, 2004-09-08 at 02:55, Benjamin on Asterisk Mailing Lists wrote:

> Japanese PRI is derived from US PRI but the Japanese have the tendency
> to protect their turf by changing specs they borrow just enough to be
> incompatible so as to put up hurdles for foreign vendors to sell their
> gear unmodified in Japan. This allows the Japanese vendors to
> overcharge for most of the stuff they sell domestically and thereby
> subsidise dumping prices on the stuff they sell overseas.

> You can imagine what kind of tsunami effect a Zaptel card would have
> in this environment if it supported J1. However, the technical side of
> making this happen doesn't seem to be the biggest obstacle.
> Apparently, the differences between T1 and J1 are such that it looks
> as if it was possible to adjust for it in the driver software alone.
> The trouble is that nobody wants to sponsor this work to be carried
> out due to the regulatory situation.
> 
> The Japanese type approval authority wants applicants to submit to
> their process and not do anything that puts it into jeopardy. Yet it
> looks as if the way in which the drivers are released via anonymous
> CVS is incompatible with the way the approvals process works.
> 
> Strictly speaking, if Japanese type approval is to be granted, no
> driver updates should be made via anonymous CVS until the updated
> drivers have been submitted to, tested and approved by the approval
> authority. Every such release cycle will cost around 3500 USD in
> application fees plus the fees charged by an accredited testing lab
> for carrying out the compliance testing. If updates or patches to
> drivers are released into the public without going through this
> process, then - going by the book - it could invalidate the type
> approval.

Some thoughts I would have is how much of the code would be required for
the application to be okay. You mention J1 is based on US T1 PRI. For
PRI you have 3 parts, you have the actual zapata driver that controls
the card, then you have libpri that handles D channel work, and then
there is asterisk that ties libpri to the zapata card. 

While I am certain it could be possible to write a asterisk stand in
application to hook up the J1 modified libpri to the zapata card for
testing, would that be sufficient for when you take out the stand in
code and put asterisk back in it's place?

>From the legal/moral side, not having anon CVS access is not close
sourcing the software. Strictly speaking, the GPL doesn't require you to
distribute your software to anyone. The GPL doesn't require you to give
third parties your work. The GPL requires you give the code to anyone
who has the binary. This last part is what usually allows third parties
to get your work though and encourages the author to maintain a publicly
available version.

Please don't say you are close sourceing the software when all you
really are going to do is squirel it away from public eyes while you get
your approval done.   

Just a few cents worth of thoughts/opinions.
-- 
Steven Critchfield <critch at basesys.com>