I gotta disagree with you there. If you own the equipment, then you own the passwords from day one. Now having to fix "messed with" settings might not be cover by your warranty, which is fine, but having to ask for permission from the dealer to access your own gear is not fine. Passwords are about control, and that dealer had you guys locked up. Get the passwords day one, and then change them if possible.
Don't you just love it when builders change around the designs?
- Thread starterSoxred93
- Start date
I gotta disagree with you there. If you own the equipment, then you own the passwords from day one. Now having to fix "messed with" settings might not be cover by your warranty, which is fine, but having to ask for permission from the dealer to access your own gear is not fine. Passwords are about control, and that dealer had you guys locked up. Get the passwords day one, and then change them if possible.
I think it is important to recognize that there are potentially three separate elements involved; the device itself, the programming software provided by the device manufacturer and the operating program created for each application. The latter element is not part of an equipment purchase, it is a separate service and its own Intellectual Property. Preventing you from being able to install your own program is one thing, protecting access to the programming created for that application is another. Go purchase a DSP or similar device and see if it comes with the programming and adjustments for your system. You do not 'own' that programming by buying the box and that is typically what the Contractor is protecting.
shiben
Well-Known Member
It sounds like the passwords are not to protect the software, but the use of the software. The place I worked last had quite a few DSPs, and we changed settings on them all the time. We didnt mess with the software itself, but with the settings that the software allows us to make. If that functionality is password protected, then do you really own your box? It sounds to me like you would have then bought the contractor an expensive piece of gear that they leave in your space.
What DSP? Some of this depends greatly upon the device. With something like a DriveRack PA there is no real programming, it is mainly making adjustments to the fairly fixed internal programming provided by the manufacturer as an integral part of the device. However, with a MediaMatrix Nion, BSS London Architect BLU, Biamp Audia, Symetrix SymNet, etc. there is no inherent operating program provided with the device, when you buy the box itself you get a box and some software to create and manage programming but the programming is custom created for each application and not part of the box. Thus with some DSP devices the program itself is not a part of the equipment purchase, it is a unique creation and thus protected Intellectual Property.
However, even with something as simple as a DRPA, there is still the issue of the impact of any programming on the system. For example, if you allow someone to access limiters you have lost the ability to control what happens with the related protection for any devices downstream. Just the eventuality of changes that could negatively impact the system represent a risk for someone having to warranty the related components or system.
Perhaps we can look at this another way. Sorry for the long diatribe, but this is an important issue. The argument is that buying a DSP box buys you full access to the software/programming. However, buying a box really buys nothing other than what comes in the box and the manufacturer's standard warranty. No special support, no integration with other components, no setup, no related system documentation, no training, no system warranty, etc., just the box and the default programming. However, chances are that what was purchased was an operating system. In that case you have to look at the 'thing' purchased as being the system and not the individual components. That usually includes integration with other devices, system warranty, etc. And that usually includes the setup of the DSP as necessary to meet the project requirements.
An analogy might be a car. A modern car contains multiple programmable processors. What you get when you purchase a car is those devices as integrated into the vehicle with the user access defined by the party supporting those devices as far as service and warranty. Try asking Honda or Toyota or Ford or whomever for full access to all the processing devices installed in your car and the programming for them because you 'bought' that when you bought the car. You may be able to overwrite the initial programming, but typically with the express condition that this voids all warranties. A sound system is not that much different, you buy the component devices as integrated parts of a larger 'thing' and not as individual, unrelated parts.
And that is where the dilemma lies, the Contractor is responsible for providing a system that meets all the project requirements and typically for warrantying that system for some period. They also have their reputation tied to the system. You can't hold the Contractor responsible for changes made by others and the only reason you would need access to a DSP is to make changes. Thus the difficulty becomes how to balance access to DSP devices with the Contractor's responsibility for the system.
So the concept that you should be able to freely access the programming because you bought the DSP device is false in two potential manners; the programming may not be part of the device and the device is not operating in a vacuum but instead is a component of the system purchased with specific requirements and responsibility placed on the Contractor for that system. I agree that the Owner (which is different than the end user, e.g. the school district probably owns it) should have access to anything necessary to support the system in the future but you also have to somehow balance that with the Contractor's responsibility for the initial system and warranty.
shiben
Well-Known Member
We have some BSS London Architect BLUs, and I checked yesterday. We also bought the ability to access some parts of the programing and whatnot. Its a complicated contract, and my former boss had to go to a special class or something to get allowed access. So i guess we knew about this issue and planned ahead.
If the contract specifies to provide a working system, then that would mean everything that is required to make that system work, including the programming. Purchasing a working system inherently implies purchasing everything necessary to make the system work, hardware, software, and programming (in fact, in many line-item invoices, you will see a fee for device programming).
As a software programmer, when I work a contract, I have no IP rights to anything I do to fulfill that contract obligation. The programming required to make that solution work was commissioned by the company/person that issued the contract. The same works in larger software firms. They have employees write the code. Courts have long upheld that even though the individual wrote the code, if it was in the effort to do that person's job, (for example, say a programmer writes a new game physics engine in order to meet the goals of the game's design specs) then that company owns that code. The same standard applies here to DSP programming.
Passwords are only meant to prevent unauthorized tampering with the equipment. I believe that all passwords should be handed over at the project completion, whether that is at the end of installation, or the end of the warranty period is for the parties involved to decide.
Actually, they seem to be two quite different situations. DSP programming is usually not the primary work contracted by the Owner/End User, it is instead ancillary to the primary work contracted. Also, two critical points in your comments are the programming being either by "employees" or a "commissioned" work, neither of which commonly applies to the programmer's relationship to the Owner/End User when addressing DSP or control system programming.
There are significant differences regarding 'work for hire' by Employees versus by Independent Contractors and unless the Programmer is an Employee of the Owner, then as far as the Owner is concerned the much stricter rules related to Independent Contractors providing the work apply. Those rules severely limit what can even be approached as 'work for hire'. So when talking about a third-party Contractor or Independent Programmer one cannot assume that it is, or that you can necessarily even consider it, 'work for hire'.
That gets into the "commissioned" aspect. A unique, commissioned work is one area where third-party work may be considered 'work for hire'. Most control system and DSP programmers would be happy to create a unique 'commissioned' work for any Client, provided that Client is willing to pay for it. However, as you noted, the Owner/End User is usually purchasing a working system rather than their specifically commissioning a program to be created. So in regards to DSP and control system programming it is rare that someone is actually specifically commissioning a unique work created just for them, the programming is typically more a means to an end and not the contracted work itself. Thus you cannot assume that any programming involved in an audio or AV system is 'work for hire' or 'commissioned', unless otherwise agreed to it will likely be considered more of an 'instrument of service' required by the Contractor in the course of providing a functional system.
I have been in the pro sound and AV industry since before there were processor based control systems and DSP devices and I have personally never run into a Contractor or Programmer that was unwilling to provide the project files provided that both parties were clear up front regarding what is wanted and what is being offered. The problem usually arises from one of two situations. One is when it is a competitive bid and the provision and ownership of DSP and control system files is not clearly defined. In that case some Contractors may see a potential to 'lock in' that Client for future work or to potentially profit more from later selling the related files, thus allowing them to offer a lower initial price. I have seen multiple projects where the firm that was the 'low bid' and was awarded the work would not have been the low bid had the code been properly addressed in the initial bid and Contract. The other situation is when an Owner assumes what is being provided differs from what was actually offered or purchased. One of the most common issues is assuming "ownership" of all programming when that is rarely what would be offered unless specifically requested or what is actually needed.
