Say I have a piece of code, x (which is copyright) which always returns the same output for a given input (e.g. a function that implements a math formula or a function that retrieves some value from an internal data table stored in the dll or whatever) Lets then say that I havent seen this code (either origonal C code or disassembly) Say I was to write a program that calls this function for all valid inputs and prints the inputs and outputs. If I was to take the output of this program and, without refering to the origonal function or the dump program in any way (i.e. using just the "truth table" for the function) generate a function that, for any given input, generates the same output as the original, have I broken the law?
Short answer: In depends on the nature of the output data and in which country you are in.
Long answer: If the output data for each input data is not mearly a pure statement of some facts but an unique expression about something (be it some facts or otherwise) it is not permitted in any country.
Note however that in some cases it might be possible to apply some another function and get rid of the unique expression and merely get the pure fact though... However in some countries it still depends on the nature of the pure facts though.
In the US, it doesn't matter at all, see the "Feist" decision.
In the Commonwealth countries and some other countries including my home country Sweden, each fact in and of itself is not protected either, however large collections of facts have some sort of protection as a whole and to some lesser degree to subsets of the whole collection.
This is in order to protect the effort of collecting the facts and while case laws AFAIR at least in Sweden is a little unclear, it mostly seems to apply to collections of facts that have required a significant effort to collect...
So functions the produce results that are purely algoritmic in nature are not protected.
As far as Wine is concerned though I can't think of any Windows API that: 1. Returns pure facts (not having any unique expression) 2. Would fulfill the requirement of needed a significant effort to collect to collect the fact.
So no I wouldn't worry about it as far as Wine is concerned.
On Fri, 3 Oct 2003 23:07, Patrik Stridvall wrote:
[correct summary of the law deleted]
As far as Wine is concerned though I can't think of any Windows API that:
- Returns pure facts (not having any unique expression)
- Would fulfill the requirement of needed a significant effort to collect to collect the fact.
So no I wouldn't worry about it as far as Wine is concerned.
Unfortunately it appears there may be one: LCMapString. If all the things we have discovered about the tables are correct (and I am by no means assuming that they are), then the Microsoft sort key table meets the industrious collection requirements and returns facts in a way that could not be duplicated without duplicating the table (it returns the table entry in literal form, so it couldn't even be represented as a different table).
This is what is (generally) returned by LCMapString. The actual table is included in an external file under NT (sortkey.nls), so one option (likely the best option) would be to implement LCMapString using a standard table from unicode.org, then provide a facility so that people in the US and Canada can (at their own risk of course) use the Microsoft versions relying on Feist.
"Troy Rollo" wine@troy.rollo.name wrote:
Unfortunately it appears there may be one: LCMapString. If all the things we have discovered about the tables are correct (and I am by no means assuming that they are), then the Microsoft sort key table meets the industrious collection requirements and returns facts in a way that could not be duplicated without duplicating the table (it returns the table entry in literal form, so it couldn't even be represented as a different table).
and another one:
Of course if we can identify a unicode.org version that's much closer to the Microsoft tables so that only minor adjustments are necessary, the industrious collection copyright can be bypassed.
We shouldn't restrict us by an old unicode.org release IMO, newer releases often have major bugfixes and improvements.
All we need is to make sure that any application depending on some API difference is behaving same way under Wine as under Windows. We can do it by writing a comprehensive conformance test case.
There is no need to replicate the whole MS sort weight table, no sane app would depend on it. The real dependence is on result of comparing of the produced sort keys. Since collation table is used by both LCMapString and CompareString I'm fairly sure that fixing any of that APIs simultaneously fixes another one. See the patch I sent to review, it has lots of tests which behave now same way under Wine as under Windows. If we will descover more differences in that area we could easily fix them as well using the same approach.
-
Dmitry Timoshkov -
Patrik Stridvall -
Troy Rollo