There is more to Puzzle Bobble than just function names. Because Puzzle Bobble contains FULL debugging symbols we have access to a truckload of structures, typedefs, enumerations, and possibly function prototypes from the official SDK. Legally.
Well here's my question. From my limited understanding of the law, if a tool were to be written to extract the DWARF2 debugging info from Puzzle Bobble and translate it into header files (or whatever), we would be in our legal right to use this information. This is because a structure name can't be copyrighted. Now if we were to post the DWARF2 sections directly then we'd be asking for it.
Is it Ok to use the information obtained from Puzzle Bobble in our code? I don't see what the difference is between a function name and a structure name, and we've already found hundreds of NIDs through our tools, and we've been using "official" names in PS2 homebrew for years (obtained through the same method I'm proposing).
I say we go for it. Comments?
(Splitting this from the original Puzzle Bobble thread.)
(Split) Legality of extracting names from Puzzle Bobble?
-
Guest
This is a legal question that only a lawyer can answer. Most companies in a position to take advantage of such information have at least one. We have none. Fortunately, neither are we a company nor a centralized bunch of people.
I am not a lawyer, so I am not giving legal advice. Just opinions that mean nothing. ;)
Having said that, I believe you are correct. I do not believe facts can be copyrighted. Databases/collected works can be. If we gather our own facts to make our own database/collection of those facts from a legal source, then it should be legal.
However, the safest course is a true clean room implementation. A clean room implementation insulates the implementation from the specification and ensures what you end up with isn't a mere asm->C code conversion, which can be arguably just a copyrightable by the original code owner as the original source.
So to be on the safest side, whomever is involved in extracting the code needs to stick to variable names and data structures (specification) and it is best to not reverse any actual executable code found along with it. The implementation should be derived from some other means, using the structures/varnames/function protos gleaned as the overall framework.
At least, this is my limited understanding on true clean-room reversing. I haven't picked up a treatise on the subject in many many many years, but since I am not a lawyer and not giving legal advice, I am not obligated to. And neither should any obligation be even perceived to give an ounce of credence to what I am saying :P ;)
I am not a lawyer, so I am not giving legal advice. Just opinions that mean nothing. ;)
Having said that, I believe you are correct. I do not believe facts can be copyrighted. Databases/collected works can be. If we gather our own facts to make our own database/collection of those facts from a legal source, then it should be legal.
However, the safest course is a true clean room implementation. A clean room implementation insulates the implementation from the specification and ensures what you end up with isn't a mere asm->C code conversion, which can be arguably just a copyrightable by the original code owner as the original source.
So to be on the safest side, whomever is involved in extracting the code needs to stick to variable names and data structures (specification) and it is best to not reverse any actual executable code found along with it. The implementation should be derived from some other means, using the structures/varnames/function protos gleaned as the overall framework.
At least, this is my limited understanding on true clean-room reversing. I haven't picked up a treatise on the subject in many many many years, but since I am not a lawyer and not giving legal advice, I am not obligated to. And neither should any obligation be even perceived to give an ounce of credence to what I am saying :P ;)
I have some feedbacks about it.
First, the law concerning this issue vary from country to country. In europe though, this is just fair use. I am not sure about US. I am really convinced all of this falls under the "fair use" clause that we have here in europe: if you buy hardware or software, and for any good reason, you can't do something straight because "you are locked away the necessary information intentionally by the maker of the device or software", you are allowed to process with any kind of reverse engineering you may want to do. But this is right for private use. Now, telling other people chunks extracted from reverse engineering can come to the "distributing copyrighted material" cause.
Search google for the keywords "Guillaume Tena" and/or "antivirus jail":
http://techrepublic.com.com/5100-22-5533336.html
First, the law concerning this issue vary from country to country. In europe though, this is just fair use. I am not sure about US. I am really convinced all of this falls under the "fair use" clause that we have here in europe: if you buy hardware or software, and for any good reason, you can't do something straight because "you are locked away the necessary information intentionally by the maker of the device or software", you are allowed to process with any kind of reverse engineering you may want to do. But this is right for private use. Now, telling other people chunks extracted from reverse engineering can come to the "distributing copyrighted material" cause.
Search google for the keywords "Guillaume Tena" and/or "antivirus jail":
http://techrepublic.com.com/5100-22-5533336.html
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.