Serious Legal question - TLB(S)
Lets say I have an open source tool that I can compile with MinGW. That can open a COM DLL extract it's TLB and make an .IDL file out of it. Very similar to #import in msvc++ but to .IDL instead of a .H Let's say I use this tool on a component of a Commercial program Like for example Norton Anti Virus. Or any other product and/or component. Let's say I am a legal user of this component. Now what am I allowed to do with this .idl file: (??) 1. Nothing I must delete it and never do that again. 2. Use this idl to make a program that can interface that component, and I can also distribute such a program, as long as the user has a legal copy for that component. 3. I can use this idl to make my own implementation of that component. As long as I do not violate any patents on the way. And I can distribute that alternative implementation of that component. 4. I can Publish the component form 2 including the idl with an OSS compatible License. 5. I can Publish the component form 3 including the idl with an OSS compatible License What do you guys think. A TLB in a DLL is that making things public? Does any one know if this is at all addressed in EULA(s)? What does the law say if nothing is mentioned? what is the default? can I go up to a car Extract from the manual the size of the wheels and use third party wheels in it stead? Can I make My own cars that use the same wheels? Free Life Boaz
Boaz Harrosh wrote:
Lets say I have an open source tool that I can compile with MinGW. That can open a COM DLL extract it's TLB and make an .IDL file out of it. Very similar to #import in msvc++ but to .IDL instead of a .H
Let's say I use this tool on a component of a Commercial program Like for example Norton Anti Virus. Or any other product and/or component. Let's say I am a legal user of this component.
Now what am I allowed to do with this .idl file: (??)
1. Nothing I must delete it and never do that again.
2. Use this idl to make a program that can interface that component, and I can also distribute such a program, as long as the user has a legal copy for that component.
3. I can use this idl to make my own implementation of that component. As long as I do not violate any patents on the way. And I can distribute that alternative implementation of that component.
4. I can Publish the component form 2 including the idl with an OSS compatible License.
5. I can Publish the component form 3 including the idl with an OSS compatible License
I think the closest is (1). Copyright law in most countries states that you can't copyright an interface, only works based on an interface. However, what complicates the matter for TLB files is that they contain variable names and comments/help strings that could constitute a copyrightable work. Therefore, I would suggest that you could use the generated .idl file to write your own .idl file that has the same interface, but would not be considered a copy or derived work. This is similar to what is often done for Platform SDK header files in Wine. Naturally, once you have your own .idl file that is free of copyright restrictions you can do whatever you want with it, including (4 and 5). -- Rob Shearman
Robert Shearman wrote:
what complicates the matter for TLB files is that they contain variable names and comments/help strings that could constitute a copyrightable work.
What if I do not extract comments/help and regenerate variable names, is it than OK.
Therefore, I would suggest that you could use the generated .idl file to write your own .idl file that has the same interface, but would not be considered a copy or derived work. This is similar to what is often done for Platform SDK header files in Wine. Naturally, once you have your own .idl file that is free of copyright restrictions you can do whatever you want with it, including (4 and 5).
Again, Must it be Human made or can I use a program that does all the above automatically? Is there in the law a distinct separation between Human hand made, or machine generated. Given that the output is the same? Free life Boaz
On Thu, 26 May 2005 20:34, Boaz Harrosh wrote:
Therefore, I would suggest that you could use the generated .idl file to write your own .idl file that has the same interface, but would not be considered a copy or derived work. This is similar to what is often done for Platform SDK header files in Wine. Naturally, once you have your own .idl file that is free of copyright restrictions you can do whatever you want with it, including (4 and 5).
Again, Must it be Human made or can I use a program that does all the above automatically? Is there in the law a distinct separation between Human hand made, or machine generated. Given that the output is the same?
It depends more on what is done than how it is done. If it's OK to do manually, it's OK to do with a program. But the real question is whether the file you create could be regarded as a derivative work of the original file, which means asking if it contains any copyright-protected elements of the original file. It is often convenient to say that the interface is not protected by copyright, but that's not quite true. The elements that are dictated by function are what is not protected. If there's only one way to correctly write something, that thing will not be protected. If there is more than one reasonable way to implement something, then copyright will apply. In most cases that we care about for this purpose, interface is determined by functionality(*). There may be other bits that are determined by functionality, but if you go back to the interface and then develop the rest from that, you will normally be safe, and if you're not a lawyer of any description, that's probably the best approach to take. (*) It is not impossible for an interface to be independent of functionality - for instance an interface that is entirely internal to a GPL program will be protected under the GPL since no other application needs to use that interface for interoperability. Interfaces requiring IDL will normally exist for interoperation with other programs, and so will determine, to that extent, the code implementing it.
participants (3)
-
Boaz Harrosh -
Robert Shearman -
Troy Rollo