RFC: Dealing with MSDN errors.

[Keith Marshall-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYxRnaAAoJEMCtNsY0flo/hRIP/A0OtdIVuXnfQHVV4xytt5Ud
gChm3rRiO3NsqvpXn0ym27Ul8mYk1kdkKuykw9iiCCCHSKJVTKZzbhYIxzAuWUxp
+//39fTEIdqUj2iGiWAW0BdPvNPvIv+1w4Y1q8Qcul2FuyWmdnbg5Siqv2kk4r/K
nsLTrUt/iCMIb2PUAkrvrWHoeVG9T7r9k1mhY7+p1EiRm/tdL3xG5LZI8CWgx+t5
syVSzpvDOt4vGUKlQ7UND6VX7piEoIRDms71gI9Udr1uwXtCbrRsHDVyA7uiyzcB
JpW2oVkumTpTkerfBGiYqlJNu4dlYx9jFmYInRJcRrCOb2tVkal0Oie6EOvpkGvA
e+3kuQezPMpuQz/JmmTJ6fyj8ucWBeHzFxW2KJhlpxUMzDjPrGK/hYr9HATtCPwF
B55g9+8fH4VWDONUKNWfL8YmAIERUSXVzz5mQQfuusIN+lid9GoYiXNARn/axqU6
Yz/CX4xODF3VJvmD2A1Mepvwh7Fi6BHYQCXdybrT+mXt4u72DW3CawQ86QLboWnd
rQLD9wh4O85cwNOIyMV2rai3pKWDURecGNTGUi2o/LpVWgwP6jxU6PsgiIIovpzU
Vw204NP6341Nhfy+4nErZDCWHoBhL602/JRm93g600DY6iaoNiRKWfhE5uAnXceE
pApqrZS1CZih3eVoIaU7
=+nCd
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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

[Cesar Strauss-2]

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

Regards,

Cesar


------------------------------------------------------------------------------
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

[Earnie Boyd]

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..

--
Earnie

------------------------------------------------------------------------------
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

[David Gressett-5]

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