On March 12, 2017 4:26 PM Earnie wrote:
>On 3/12/2017 9:26 AM, Cesar Strauss wrote:
>> On 03-12-2017 06:50, Keith Marshall wrote:
>>> How should we best deal with reports of probable erroneous MSDN content
>>> such as:
https://sourceforge.net/p/mingw/bugs/2248/ ?
>>>
>>> Here, the poster provides an acceptable test case, which demonstrates
>>> that the MSDN information is most likely incorrect, but can refer us
>>> only to known sources of plagiarised Microsoft header file content, to
>>> support his proposed correction. Obviously, we cannot examine those
>>> plagiarised sources, but should we just take his word for it, and
>>> correct our headers, as he suggests?
>>>
>>> Opinions?
>>
>> It would have been best if the reporter had found the correct prototype
>> by trial and error. We cannot do that now, since we already know the answer.
>>
>> You could argue that the correct prototype is now found in "publicly
>> available documentation". Which, in this case, is the text of the bug
>> report itself. We already consider Internet references like blog posts
>> as "publicly available documentation", if I am not mistaken. You could
>> add this on top of your patch:
>>
>> "MSDN is wrong. The correct type for parameter X is Y according to
>>
https://sf.net/..."
>>
>> On the other hand, for such a small change, it could also pass as "fair
>> use" instance, even if the source itself is copyrighted.
>>
>> Maybe make the "documentation or references" requirement more explicit
>> on the bug reporting page. We do link to
>>
http://www.mingw.org/reporting_bugs, but it is a bit buried in there.
>> Maybe write a dedicated page, like the one on
>>
https://wiki.winehq.org/Clean_Room_Guidelines>>
>I think we just take the issue on its word value and make the change. I
>think MS would be fine with it based on their activity in Cygwin. A bug
>report should be filed with MSDN for the invalid documentation by the
>original poster and the MSDN ticket given in the bug report ticket..
The safest (but not very satisfactory) solution to the problem is to wait
for Microsoft's response to a bug report. The official MinGW position
on on Microsoft header snooping is well-documented and making the
change would seem to me to be a violation of that policy
Another solution would be to go directly to Microsoft, show the official
policy to Microsoft (and also how it contrasts with the MinGW-64
philosophy) and try to get some cooperation with Microsoft on
getting information that would otherwise be locked away from MinGW
use by Microsoft licenses.
An interesting situation has developed in Windows 10 that might
cause Microsoft to look at this: the arrival in Windows 10 of Bash
on Ubuntu on Windows. If I start the Ubuntu bash on my Windows
10 computer and do
apt-cache search MinGW
I get a substantial list of MinGW-64 packages. There are cross compilers
in that list which certainly contain headers which have contents which
might cause some cognitive dissonance in the Microsoft legal department,
especially since the headers can be obtained using the Microsoft-supplied
Ubuntu Bash and other Ubuntu tools running on a Microsoft-designed
Linux emulation.
The existence of Bash on Ubuntu on Windows shows that Microsoft
has become much more tolerant of open-source software, and opening
a good communication channel with Microsoft that might solve
license-related problems seems to me to be the best long-term
solution to development problems like this MSDN error.
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Locked
signature.asc (231 bytes)