Menu
▾
▴
mingw-dvlpr
|
From: Keith M. <kei...@us...> - 2017-03-12 09:50:26
|
-----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----- |
|
From: Cesar S. <ces...@gm...> - 2017-03-12 13:26:26
Attachments:
signature.asc
|
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 |
|
From: Earnie <ea...@us...> - 2017-03-12 21:26:51
|
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 |
|
From: David G. <jdg...@ho...> - 2017-03-13 03:27:51
|
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. |
