The default bug view has changed. See this FAQ.

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

VERIFIED FIXED in mozilla1.9.3a1

Status

()

Core
Widget: Win32
VERIFIED FIXED
7 years ago
7 years ago

People

(Reporter: martin.feger, Assigned: jimm)

Tracking

Trunk
mozilla1.9.3a1
x86
Windows 2000
Points:
---
Bug Flags:
blocking1.9.2 +
blocking1.9.0.19 -

Firefox Tracking Flags

(blocking2.0 alpha1+, status1.9.2 final-fixed, blocking1.9.1 .9+, status1.9.1 .9-fixed)

Details

(URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
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.
(Assignee)

Comment 5

7 years ago
(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)

Updated

7 years ago
Assignee: hecker → jmathies
(Assignee)

Comment 6

7 years ago
Created attachment 418270 [details] [diff] [review]
revamp v.1

First rev, going to throw this at try.
Created attachment 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."
(Assignee)

Comment 8

7 years ago
(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.
(Assignee)

Comment 9

7 years ago
Created attachment 418432 [details] [diff] [review]
revamp v.2
Attachment #418270 - Attachment is obsolete: true
Attachment #418432 - Flags: review?(roc)
(Assignee)

Comment 10

7 years ago
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+
(Assignee)

Comment 12

7 years ago
http://hg.mozilla.org/mozilla-central/rev/34386757d749
Status: NEW → RESOLVED
Last Resolved: 7 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.
(Assignee)

Comment 15

7 years ago
(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.
(Assignee)

Comment 16

7 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/d82ce930bef3
status1.9.2: --- → final-fixed
Whiteboard: [needs 1.9.2 landing]
Depends on: 537414
(Assignee)

Comment 17

7 years ago
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
Created attachment 423692 [details] [diff] [review]
Rollup for 1.9.1

This includes

http://hg.mozilla.org/mozilla-central/rev/34386757d749
http://hg.mozilla.org/mozilla-central/rev/6c1cd8a81f95
http://hg.mozilla.org/mozilla-central/rev/f5fca857c581

I'm going to throw this at try to have it run my DnD tests against it.
status1.9.1: --- → wanted
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 :-)
Attachment #423692 - Flags: review+
I'll try to get to the 1.9.0 patch this weekend.
Created attachment 426868 [details] [diff] [review]
Patch for 1.9.0

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+
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5b43afb4c5dc
status1.9.1: wanted → .9-fixed
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.