|
I am going to be releasing some software soon which will require users to run a local database. There is a competitor in the space that is doing the same thing and they have a pretty sophisticated database schema that they use. Their software is commercial but the database schema is completely viewable once installed. What's the legality of basing my product of the same database schema and just potentially renaming columns and tables and maybe removing one or two things? |
|||||||||||||||
|
This is exactly the same case of a commercial product where the code source is viewable. Which is by the way the case of most applications: you can decompile them and have an idea of the source code they use. In the exactly same way, the data used by some applications add value to those apps, but can be easily extracted. For example, textures in a video game add value and are often very expensive to create, but are mostly stored as a set of JPEGs in an archive. You have to understand that in the three cases, the fact that you can view something does not authorize you to use it. Some companies will try to invent some techniques to prevent the users with less technical background from accessing database schema, source code or data by using encryption or obfuscation. Other companies will just say that it is forbidden, and sue people who annoy them the most. In a case of game textures, for example, I don't risk too much if I use some just for me, even if it's prohibited. If, on the other case, I am a large company and will use those textures in my own game with lots of sales, chances are the case will end in a court. So to answer your question:
This is probably illegal, depending on the license of the product you want to copy the schema from. |
|||||||
|
|
Copyright can only protect things that have an infinite number of effectively equally good ways to do it. That is, copyright does not ever protect function. In addition, describing things with their most obvious descriptions is not protectable either. If, for example, a field holds an address, there is no copyright protection in naming the field "address". The crux question is whether there's originality in the database schema beyond what is dictated by its function. Unfortunately, the case law is as clear as mud. Look at the reasoning in cases like Engineering Dynamics v. Structural Systems. I disagree with the 'ethical' arguments made by others here. Copyright law gives and takes, and that give and take is a delicate balance between society and authors. There is nothing wrong with taking what the law allows you to take -- very few people believe the law doesn't give authors enough. The fact that you can easily view the organization without any trickery probably means there are no DMCA issues. However, the law is far from clear. So I think it would be pretty crazy to risk it. IANAL. Law in jurisdictions other than the US is different (and may recognize copyright based on effort). |
|||
|
|
|
The database schema implies significant part of the functionality. So your software will eventually have more or less the same functionality as your competitor. That will in a way weaken your product value. What you could do is to study your competitor's product, see how to make your product better and create a better software. Also, if you use the same schema, your competitor will readily know what you did and if they are serious enough they may take a legal action against you. If you had obtained a legal version, then the legality would depend on the software license agreement you accepted. |
|||||
|
|
Usually, when you choose to compete, it's because you think you can do something better than the other guy. In this case, you're conceding up front that the other guy's solution is better than anything you can come up with. Is that the kind of developer you strive to become? |
|||||||||||||||
|
|
A "clean" way to legally achieve what you want is to do a "cleanroom implementation". In this process, you have one team extract requirements from your competitors implementation, and another (no overlap!) develop your database from the extracted requirements. This is a method that's survived legal testing (Columbia Data Products vs IBM, covering the PC BIOS). You have an artifact (the documented requirements) that you can show in court. Note that your requirements will typically not contains statements like "The adress table shall be named |
|||
|
|
|
Copy a complex database schema!? good luck with that. On the surface it will look simple but once you start trying to program you will waste more and more time trying to understand what their design intentions were and how it is supposed to work. Inserting and querying will be easy, deletes and updates will be much much harder. So while you are spinning your wheels trying to understand their ideas, they will be adding more tables, columns, triggers, constraints or fixing problems in the db for the next release. Plus, copying the schema will help keep the court case short. |
|||
|
|
|
A database schema is only as good as the code that uses it. It is just a way to allow the code to organise its data, there is nothing that great about any particular schema (the inverse is not true - there are lots of ways to create a terrible schema). The fact your competitors have a good schema is probably because they have well designed their product. If you just use their schema then you are only really getting half the picture and you will produce an inferior product. So I would recommend you use the schema for "inspiration", but design your system first and let your schema come out as a natural process of this design. Design your system based on what problem you are trying to solve, not what problem your competitor has already solved. |
|||
|
|
|
Your database schema should be based on your data. I don't see much advantage to reusing one from another application. |
|||
|
|
