Closed Bug 533691 Opened 11 years ago Closed 10 years ago

Violation of Microsoft's copyright in IENUMFE.CPP / IENUMFE.H?

Categories

(Core :: Widget: Win32, defect)

x86
Windows 2000
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla1.9.3a1
Tracking Status
blocking2.0 --- alpha1+
status1.9.2 --- final-fixed
blocking1.9.1 --- .9+
status1.9.1 --- .9-fixed

People

(Reporter: martin.feger, Assigned: jimm)

References

()

Details

Attachments

(4 files, 1 obsolete file)

User-Agent:       Agent 99
Build Identifier: 

See the URL. For comparison, the current version has not changed much:
http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/IEnumFE.cpp

Can somebody explain this change? Did Netscape really get Microsoft's permission to make this change, back in 1999, when these two companies were not exactly best buddies? It seems unlikely that MS would allow anybody to just take their sample code and claim to be the initial developer.

Reproducible: Always
From the author's bio (http://www.kraigbrockschmidt.com/about.htm)

" In late 1991 he took a position in Microsoft’s technical evangelism group, Developer Relations, where he remained for the bulk of his career.

In Developer Relations, Kraig used his skills to speed the adoption of Microsoft’s newest technologies by other software companies. He offered papers and sample programs that demonstrated exactly how to incorporate those technologies into a wide variety of applications and regularly spoke at industry conferences. In addition, he continued to publish articles in magazines such as Microsoft Systems Journal and Windows Programming Journal."
Martin: thanks for bringing this to our attention.

roc is the module owner for Widget. roc: is this code still used?

Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can confirm that the code is still used.  It's integral to the implementation of nsDataObj
Ugh. Jim, can you rewrite this code? It's not much code at least.
(In reply to comment #4)
> Ugh. Jim, can you rewrite this code? It's not much code at least.

Sure, I've got another bug related to sample code submission I need to clean up as well. Will get to this next week.
Assignee: hecker → jmathies
Attached patch revamp v.1 (obsolete) — Splinter Review
First rev, going to throw this at try.
For what little it's worth, the code is sample code provided with Inside OLE 2, which I was able to borrow a copy of.  I've attached the license agreement.  Amusingly enough, it's actually really permissive.  Really the only part that's problematic is the agreement to "include the copyright notice ... on your product label and as a part of the sign-on message for your software product."
(In reply to comment #7)
> Created an attachment (id=418300) [details]
> License original code is provided under
> 
> For what little it's worth, the code is sample code provided with Inside OLE 2,
> which I was able to borrow a copy of.  I've attached the license agreement. 
> Amusingly enough, it's actually really permissive.  Really the only part that's
> problematic is the agreement to "include the copyright notice ... on your
> product label and as a part of the sign-on message for your software product."

Probably not something we'll want to do. :) Regardless, that code had shortcomings, it needed to be replaced.
Attached patch revamp v.2Splinter Review
Attachment #418270 - Attachment is obsolete: true
Attachment #418432 - Flags: review?(roc)
The diff is pretty ugly, it's simpler to just apply the patch and look at the source.
Flags: blocking1.9.2?
Component: Licensing → Widget: Win32
Product: mozilla.org → Core
QA Contact: gerv → win32
Version: other → unspecified
blocking1.9.1: --- → ?
blocking2.0: --- → ?
Flags: blocking1.9.0.18?
Comment on attachment 418432 [details] [diff] [review]
revamp v.2

+  PRInt32 count = static_cast<PRInt32>(aMaxToFetch) < left ? static_cast<PRInt32>(aMaxToFetch) : left;

NS_MIN?

+    memset(&mFormat, 0, sizeof(FORMATETC));
+    if (!aSrc)
+        return;

Put the memset inside the if?
Attachment #418432 - Flags: review?(roc) → review+
http://hg.mozilla.org/mozilla-central/rev/34386757d749
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
blocking1.9.1: ? → .8+
Flags: blocking1.9.0.18? → blocking1.9.0.18+
Flags: blocking1.9.2? → blocking1.9.2+
Whiteboard: [needs 1.9.2 landing]
Any reason why this hasn't landed on 1.9.2 yet?
Looked into landing this on 1.9.2, but it looks like bug 528731 has already landed there, in the opposite order that it did on trunk, so the patch doesn't apply.
(In reply to comment #13)
> Any reason why this hasn't landed on 1.9.2 yet?

Sorry, this got blocking status on tuesday which I missed before my break. Will be landing it today.
note to self - idx bug patch should be included in future landings of this on branch.
When you create the branch-merged patches please include the fix for regression bug 537414 as a combined patch for the approval request.
Whiteboard: [needs 1.9.0/1.9.1 roll-up patch for approval]
Marking the 14 bugs that are both:
 * nominated for blocking1.9.3:?
 * fixed on the 1.9.2 branch (according to status1.9.2)
as blocking1.9.3:alpha1, so that we don't have to go through the nominations individually.  They're all fixed already (so there's no work to do), and being fixed on 1.9.2 means they probably do block 1.9.3.
blocking2.0: ? → alpha1
Jim, can you get someone to help you with a roll-up branch patch here? Drivers will approve when it's ready.
blocking1.9.1: .8+ → needed
(In reply to comment #20)
> Jim, can you get someone to help you with a roll-up branch patch here? Drivers
> will approve when it's ready.

I'm willing to do that, but Bug 538891 still needs approval for 1.9.2
Flags: blocking1.9.0.18+ → blocking1.9.0.19?
Comment on attachment 423692 [details] [diff] [review]
Rollup for 1.9.1

I abandoned my attempt to get the DnD tests ported to 1.9.1, the linkage has changed too much to make it worth it IMO.

Nevertheless, the patch just the others combined, there was hardly any merge fuzz and nothing substantive.
Attachment #423692 - Flags: approval1.9.1.9?
Who can review the patch?
Flags: blocking1.9.0.19? → blocking1.9.0.19-
(In reply to comment #24)
> Who can review the patch?

The differences from the three patches it came from are trivial, but if it does need review I'd suggest roc :-)
I'll try to get to the 1.9.0 patch this weekend.
Attached patch Patch for 1.9.0Splinter Review
Rolled up patch for 1.9.0.  There are no real differences between this and the 1.9.1 patch.
Attachment #426868 - Flags: review?(roc)
Attachment #426868 - Flags: approval1.9.0.19?
Comment on attachment 426868 [details] [diff] [review]
Patch for 1.9.0

Thanks a ton!
Attachment #426868 - Flags: review?(roc) → review+
Whiteboard: [needs 1.9.0/1.9.1 roll-up patch for approval] → [needs 1.9.0/1.9.1 approval]
blocking1.9.1: needed → .9+
Attachment #423692 - Flags: approval1.9.1.9? → approval1.9.1.9+
Comment on attachment 423692 [details] [diff] [review]
Rollup for 1.9.1

Approved for 1.9.1.9, a=dveditz for release-drivers
Comment on attachment 426868 [details] [diff] [review]
Patch for 1.9.0

Approved for 1.9.0.19, a=dveditz for release-drivers
Attachment #426868 - Flags: approval1.9.0.19? → approval1.9.0.19+
Whiteboard: [needs 1.9.0/1.9.1 approval]
Target Milestone: --- → mozilla1.9.3a1
Version: unspecified → Trunk
Comment on attachment 426868 [details] [diff] [review]
Patch for 1.9.0

This missed the boat, and now the branch is going to be unsupported, so I'm finding it hard to get worked up about this.
Attachment #426868 - Flags: approval1.9.0.19+ → approval1.9.0.19-
(In reply to comment #32)
> (From update of attachment 426868 [details] [diff] [review])
> This missed the boat, and now the branch is going to be unsupported, so I'm
> finding it hard to get worked up about this.

Woops I meant to find someone to check this into CVS, totally slipped my mind.  I also have a hard time caring about it now that the branch is over.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.