|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Daily Coping Tip Spend less time sitting today. Stand, walk, move more. I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate. For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours. |
Open APIs The US Supreme Court ruling in Oracle v Google was released recently, with Google winning and removing, or reducing, copyright protection for APIs. That means if you use the same method names, parameter names, etc. as some other software, it is unlikely that the vendor for that software can sue you or force you to change. I think that makes sense, as in many cases, someone might accidentally copy an API in something like PowerShell. Already I've seen companies and individuals build "Get-ClusterName" calls. I don't know all the ins and outs of this case. It's complex, and I've seen some notes that Google had permission from Sun Microsystems to use Java. After Oracle bought them, apparently things changed, but I'm not sure how this agreement was structured or the legalities of how things evolved. In any case, I'm glad Google won. I think the specification of an API isn't something that should be protected and limited. If a company implements a list of method names and parameters, I don't feel those deserve protection. The actual code that runs should be protected, but the names in the interface shouldn't be. This might mean that if I interfaced with, say a piece of retail software that had "GetOrder", "NewOrder", etc., and I wanted to switch from vendor A to vendor B, I could without modifying my app. This prevents lock-in, which isn't something I want to see enforced in software. In fact, for things like medical software, I'd want the same API for all of them. This is something that I think will encourage interaction of software, and likely reduce costs for many types of COTS systems that allow connections from PowerShell, bash, and other scripting systems. I think this also helps developers that might work across platforms or systems and could use the same code structures to switch from one to the other. This also means that vendors implementing APIS need to do a good job with their software. They can't hold customers hostage with their system over the cost of reworking code the connects with their software. I think that pressure to be better, whether in features, security, or in all ways, is important for software to evolve and improve. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
