Switching alarm system - can I convert my database?

[Pat Coghlan]

We are upgrading our commercial alarm & access control system to one
sold by another vendor. Our current system has a database consisting of
our cardholders, alarm point descriptions, instructions etc. which we'd
like to "mine" and copy to our new system.

The software licence seems to restrict us from doing anything but
operate our current system. Does anyone know of a situation where this
type of data mining has resulted in litigation over infringement of a
software licence?

 

[Tommy]

We are upgrading our commercial alarm & access control system to one
sold by another vendor. Our current system has a database consisting
of our cardholders, alarm point descriptions, instructions etc. which
we'd like to "mine" and copy to our new system.

The software licence seems to restrict us from doing anything but
operate our current system. Does anyone know of a situation where
this type of data mining has resulted in litigation over infringement
of a software licence?

Without knowing any specifics, all we can give is general advice. Does
your current software have have any export functions? if you can export
to excel or to a text file you might be able to cut and paste some of
your information. Does your new software have a conversion utility?

you are probably still looking at some manual entry. No pain no gain

 

[Pat Coghlan]

Without knowing any specifics, all we can give is general advice. Does
your current software have have any export functions? if you can export
to excel or to a text file you might be able to cut and paste some of
your information. Does your new software have a conversion utility?

you are probably still looking at some manual entry. No pain no gain

There is an export function for cardholders only, but we have lots of
other data (alarm point descriptions etc. - thousands of them) that
could be moved over.

Doing the conversion is not the problem. I'm wondering if it can be
done in a way to avoid infringing the EULA - which seems to preclude
this type of data mining.

 

[Tommy]

There is an export function for cardholders only, but we have lots of
other data (alarm point descriptions etc. - thousands of them) that
could be moved over.

Doing the conversion is not the problem. I'm wondering if it can be
done in a way to avoid infringing the EULA - which seems to preclude
this type of data mining.

I really cannot tell you. Though it seems to me that the information to
run your system is yours. as long as you are not using any of their
information, and only mining out waht you had to put in in the first
place you should be OK.

I will add that is my opinion and i could be wrong.

 

[Pat Coghlan]

I really cannot tell you. Though it seems to me that the information to
run your system is yours. as long as you are not using any of their
information, and only mining out waht you had to put in in the first
place you should be OK.

I will add that is my opinion and i could be wrong.

I'd like to know if there has ever been any litigation related to a
company doing this type of data mining.

 

[Crash Gordon]

I would think that any history or zone descriptions or user number would be
your property and as long as your not stealing any of the operating system's
code you'd be ok. Especially since you 'can' output that stuff. You'd need
to Google for some legal stuff though - lots of stuff on the net...finding
it will be another thing.

or...call your attorney as ask...might cost you a few bucks (and he may not
know shit anyway)


| Tommy wrote:
|
| >> Doing the conversion is not the problem. I'm wondering if it can be
| >> done in a way to avoid infringing the EULA - which seems to preclude
| >> this type of data mining.
| >>
| >
| > I really cannot tell you. Though it seems to me that the information to
| > run your system is yours. as long as you are not using any of their
| > information, and only mining out waht you had to put in in the first
| > place you should be OK.
| >
| > I will add that is my opinion and i could be wrong.
|
| I'd like to know if there has ever been any litigation related to a
| company doing this type of data mining.

 

[Pat Coghlan]

There is no EULA that would stop you from keeping your own data.
Do you know what database engine your new system as well as your old system
uses? Hopefully it is not Borland, the king of data corruption in my
opinion. Even without using the data front end of the access application
itself, the data tables can generally be accessed. However, sometimes the
alarm points are dealt with by a third party add on software overlay.
You have not mentioned any badging yet so I don't know if that is a concern
too. If you wish to save yourself the time and trouble of repunching all the
data, you will have to create a table from the data in the old system that
matches the table format the new system uses. Generally those tables have to
match exactly in all aspects (text and text length, dates and date formats,
on and on). If you have not used been trained on databases this can be a
tough assignment. If you mention the brand of the old and new systems the
techniques for doing it could be more easily explained.

Old DB: SQL
New DB: SQL

The conversion could pretty much be operated, but this would require
tools if we want to clone existing cardholder and zone information and
insert into the new system.

Although the "data" belongs to us, it might be hard to extract (short of
cutting/pasting) without infringing on the EULA. The practice is known
as vendor "lock-in", e.g. software systems which manage patient medical
data. If the company/doctor stops paying the fees, the data remains
inaccessible.

 

[Robert L Bass]

There is an export function for cardholders only,

but we have lots of other data (alarm point
descriptions etc. - thousands of them) that could be moved over.

Doing the conversion is not the problem. I'm
wondering if it can be done in a way to avoid
infringing the EULA - which seems to preclude this type of data mining.

Regardless what they wrote in the EULA, if the
data is information you supplied, such as keyholder
names, schedules, access privileges, that data
belongs to you. The people who wrote the software
cannot claim title to it nor can they do anything to
prevent you from "mining" it back from the database.

The copyright associated with a software product is
there to protect the author against unauthorised use
of his product. It doesn not grant him title to your
information, regardless how his product encodes
and stores it.

This is analogous to buying a file cabinet. The
designer of the cabinet has the right not to have
you copy his design and market it. But the files
in it belong to you. Going one step further, if you're
old enough to recall Cardex file systems, you'll
remember the ingenious method used to select
and sort cards using metal rods. The design was
created in the 50's and remained in use into the
early 70's. You could not copy the design or even
make your own cards (though presumably lots of
people did). The cards and the rod sorting system
were patented. But the data on the cards was not
the property of Cardex. That belonged to whoever
typed it onto each card. Modern databases are
far more sophisticated than Cardex. But the legal
principles concerning them and the data they hold
have not changed much in the last 50 years.

--

Regards,
Robert L Bass

=============================>
Bass Home Electronics
941-925-8650
4883 Fallcrest Circle
Sarasota · Florida · 34233
http://www.bassburglaralarms.com
=============================>

 

[Robert L Bass]

The conversion could pretty much be operated, but this would require
tools if we want to clone existing cardholder and zone information and
insert into the new system.

Although the "data" belongs to us, it might be hard to extract (short of

cutting/pasting) without infringing on the EULA. The practice is known
as vendor "lock-in", e.g. software systems which manage patient medical
data. If the company/doctor stops paying the fees, the data remains
inaccessible.

Vendor "lock-in" is a technique which database authors sometimes use to force users to keep paying. It's legal but it doesn't grant
the vendor ownership of the data.

There's discussion of two relevent cases in ECommerce Times which sheds some light on the subject. Here's the URL:
http://www.ecommercetimes.com/story/36296.html. In the first case the issue was ownership of data which the database *users*
compiled. The court found that the data was not the property of the author. The second case was quite different. There the
plaintiffs wanted access to data which another firm (the PGA Tour) had collected and entered. The court rightly found that the
party which entered the data owned the data. The plaintiff was claiming he data was public domain. The court said they no.

As to hacking the database to get your data, there's no law against that. If you were hacking to make use of the software itself it
would be a different story.

--

Regards,
Robert L Bass

=============================>
Bass Home Electronics
941-925-8650
4883 Fallcrest Circle
Sarasota · Florida · 34233
http://www.bassburglaralarms.com
=============================>

 

[Robert L Bass]

The conversion could pretty much be operated, but this would require
tools if we want to clone existing cardholder and zone information and
insert into the new system.

Although the "data" belongs to us, it might be hard to extract (short of

cutting/pasting) without infringing on the EULA. The practice is known
as vendor "lock-in", e.g. software systems which manage patient medical
data. If the company/doctor stops paying the fees, the data remains
inaccessible.

Here's an excerpt from a related case:

"Wiredata sued the municipalities in Wisconsin state court in an attempt to force them to divulge the data; those suits are still
pending. Alarmed by Wiredata's actions, AT brought suit against Wiredata to stop it from demanding that the municipalities give it
access to the data. AT also sought to enforce its copyright, claiming that the data cannot be extracted without infringement of its
copyright or theft of its trade secrets."

"The U.S. District Court for the Eastern District of Wisconsin held for AT and issued a permanent injunction on the basis of AT's
copyright claim alone, without reaching the trade secret claim. On November 25, 2003, however, the U.S. Court of Appeals for the
Seventh Circuit (Judge Richard Posner writing the opinion for the three judge panel), reversed and remanded with instructions to
vacate the injunction and dismiss the copyright claim, holding that extracting the data from the database incorporated does not
constitute copyright infringement."

The appelate court essentially said that the author of the database has no property rights to the data stored in it. In short, go
ahead and extract your data. It's not a problem.

--

Regards,
Robert L Bass

=============================>
Bass Home Electronics
941-925-8650
4883 Fallcrest Circle
Sarasota · Florida · 34233
http://www.bassburglaralarms.com
=============================>

 

[Robert L Bass]

Thanks for the info.

You're most welcome.

I guess the only point in question is whether
one has the right to use the table structure
(field names etc.) to interpret the data and relationships. I mean, there's really no other
way to do this efficiently. It's not practical to
dump out all the tables and start piecing the
information bits back together.

The data structure (relationships between tables,
etc.) is the property of the author of the database.
The data itself is yours since you (or your staff)
created it, entered it into the program and
maintained it.

However, any new database you decide to use
will necessarily have its own relational structure.
If the chosenb software platform can import and
export XML files you'll be much better off. That
will make your data more transportable now and
in the future, should you ever decide to change
again.

We use XML in other security related application
software as it is the most transportable and
configurable of current formats. Not every
developer uses XML though. You might want to
inquire of the vendor you're considering using
before you make a final selection.

One of the nice things about XML is you can
write into the schema the rules, such as
limits, options and relationships between
columns and tables. Once you've got the
schema the way you wabnt it, it's easy to
massage tabular data from any software to fit
the needs of another app.

This is such a fine point, though, so I doubt
any vendor is going to try and stop a customer
from extracting the information.

You don't really need the relationships -- just
the raw data and some knowledge of the way
the new app needs it formatted.

If the job is large enough to merit the cost, you
might consider hiring someone experienced in
database integration to do the project for you.
If that's of interest let me know. I have people
on staff who do that sort of thing on a regular
basis.

--

Regards,
Robert L Bass

=============================>
Bass Home Electronics
941-925-8650
4883 Fallcrest Circle
Sarasota · Florida · 34233
http://www.bassburglaralarms.com
=============================>

 

[Pat Coghlan]

XML training is one thing that I've had in the back of my mind for some
time

I asked the H/W guys to capture some sample data in text form for a
couple of the zones in a building and try to map it to equivalent
objects (intelligent controllers, inputs, relays etc.) on the new
system, with the long-term goal being to automate this somehow (similar
to the XML export/import you were talking about). The exercise was a
real eye-opener, and they realized that a lot more of the new gear will
be required than previously thought. They're leaning towards starting
from scratch (i.e. redo all the data entry), but with tens of thousands
of descriptions for inputs, zone names etc., we really need to automate
this.

-Pat