Closed
Bug 53764
Opened 24 years ago
Closed 22 years ago
Netscape Confidential and Proprietary source code in the mozilla source tree
Categories
(mozilla.org :: Miscellaneous, task, P3)
mozilla.org
Miscellaneous
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: wtc, Assigned: endico)
References
()
Details
Attachments
(8 files, 2 obsolete files)
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details | |
(deleted),
application/x-gzip
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
A lot of files, mostly makefiles, under the mozilla tree still have the wrong license at the top: 1 # 2 # CONFIDENTIAL AND PROPRIETARY SOURCE CODE OF 3 # NETSCAPE COMMUNICATIONS CORPORATION 4 # Copyright (C) 1996 Netscape Communications Corporation. All Rights 5 # Reserved. Use of this Source Code is subject to the terms of the 6 # applicable license agreement from Netscape Communications Corporation. 7 # The copyright notice(s) in this Source Code does not indicate actual or 8 # intended publication of this Source Code. 9 # You can do a search in lxr.mozilla.org for "PROPRIETARY" and it will turn up these files.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Proposing for mozilla1.0, IMHO mozilla 1.0 shouldn't ship with this. Adding URL with some of the files that have this, I found that the majority(if not all) are just tests, but this should be fixed soon better than latter, I don't want to think what could happen if Slashdot find this :)
Keywords: mozilla1.0
Updated•24 years ago
|
Assignee: dmose → endico
Status: ASSIGNED → NEW
Comment 3•24 years ago
|
||
Mass reassign of mozilla.org infrastructure bugs, as I'm switching groups to work on LDAP integration in Mozilla full-time.
Comment 4•24 years ago
|
||
Dawn, is this really still a problem? I'm worried this is rotting away in the wrong component.
Comment 5•24 years ago
|
||
mitchell: I can clean this up reasonably easily, if you can assure me that removing all Netscape-proprietary licenses in the tree and replacing them with the NPL is a reasonable thing to do. You may also want to consider the situations of: http://lxr.mozilla.org/seamonkey/source/sun-java/stubs/include/jni.h and wonder what http://lxr.mozilla.org/seamonkey/source/security/psm/doc/license.txt is doing in the Mozilla tree. Gerv
Comment 7•23 years ago
|
||
I can't image any justification for having Netsape "proprietary" files in the mozilla tree, other than an error at the time of release.
Comment 8•23 years ago
|
||
Currently, the query for "CONFIDENTIAL AND PROPRIETARY" returns the following results: - 3 hits for "* The Java source code is the confidential and proprietary information" in the following files: /embedding/browser/activex/src/pluginhostctrl/pluginsdk_include/jni_md.h /embedding/browser/activex/src/pluginhostctrl/pluginsdk_include/jni.h /sun-java/stubs/include/jni.h - and many, many hits in files in the /layout/html/tests/table/ directory. Is this ok for mozilla1.0, or is there still some work to be done?
Comment 10•23 years ago
|
||
Comment 11•23 years ago
|
||
Comment 12•23 years ago
|
||
I think we can safely remove the confidential markings from our table layout tests since they are hardly confidential today.
Comment 13•23 years ago
|
||
The NS Plugin API headers in directory of the plugin for hosting activex controls are there to allow it to build without the plugin sdk. I suppose with some fixup I could make them work using the Mozilla NPAPI impl, but that pulls in another build dependency.
Comment 14•23 years ago
|
||
We can't remove the markings from the table tests without Netscape's permission. If it's not forthcoming, we'll just CVS remove them, and wait for someone inside Netscape to care enough to relicense them and check them back in :-) Gerv
Comment 15•23 years ago
|
||
I, Chris L. Hofmann, a Sr. Technical Director at said Internet development company (Netscape Division of AOL Time Warner) grant authority to re-licence all table layout tests to serve the needs and desires of the mozilla development community and to provide the maxium assistance in the creation, testing and delivery of the greatest internet browsing software ever created on this planet. Go forth and re-license these files.
Comment 20•23 years ago
|
||
What should happen here? Should the "CONFIDENTIAL AND PROPRIETARY" warnings simply be removed, should they be replaced with the NPL, or should they be replaced with the MPL/GPL/LGPL?
Comment 22•23 years ago
|
||
Comment 23•23 years ago
|
||
There is no way that I am reading that patch to see if you've done all 193 correctly. If you swear that the following things are true: 1) You have changed no files other than HTML testcases 2) You have changed only comments, and no HTML code then r=gerv. Comment changes only have an auto-sr=brendan. So now you need someone to approve this checkin - mail drivers in the appropriate way (see past status reports.) Gerv
Comment 24•23 years ago
|
||
Comment on attachment 76735 [details] [diff] [review] Unconfidentialify 193 table layout tests a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Comment 25•23 years ago
|
||
stop :-) there's at least one case where you made a (c) 1998 file (c) 1999. can you give me 36 hours to analyze this patch?
Comment 26•23 years ago
|
||
Oops... it seems that there's about 12 of those cases. I've also discovered that I removed the Purpose comment from about 12 of the files. Interestingly, about 10 of the 12 cases of these two different accidents overlap with each other. That's weird. Considering the size of the patch, would it perhaps be a good idea to keep this patch as it is and then make another patch to address these issues?
Comment 27•23 years ago
|
||
i don't mind fixing all but the ones where the patch isn't right, and having a second round later, or since you know there are only a few that need fixing, you could attach a new patch for just those files (or a diff against the current patch). thanks for the quick response, and i'm sorry i didn't comment earlier...
Comment 28•23 years ago
|
||
I'll do a diff against the current patch. I'll attach it later today (by Danish time, which probably means tomorrow by Bugzilla time).
Comment 29•23 years ago
|
||
> I'll attach it later today
...I thought. I was wrong. I won't have time to do this until some time next
week, so if someone else wants to do it, feel free to do so. I went through all
the files and found:
* 1 cases where (C) 1999 was turned into (C) 1998 -- this is in
tables_bgcolor_aqua.html.
* 12 cases where (C) 1998 was turned into (C) 1999 -- these are all in
td_valign_*.html, tr_valign_*.html and th_valign_*.html.
* 11 or so cases where the "<!-- Purpose:" comment was removed -- these are also
in td_valign_*.html, tr_valign_*.html and th_valign_*.html.
I am almost 100% certain that these are the only problems with the patch.
/Jonas
Comment 30•23 years ago
|
||
This should fix all of the problems with the first patch. This patch is meant to be applied immediately after applying the first patch.
Comment 33•23 years ago
|
||
Sorry for the delay. This is the best I can do -- for some reason Patch Maker insists on removing and readding all lines of many of the files, and I don't know why. I'm not even sure if this applies cleanly, but let's hope.
Comment 34•23 years ago
|
||
It's almost certainly not Patch Maker's fault - your editor will have saved the file with different line endings. Either reconfigure it, or get a better editor :-) Gerv
Comment 35•23 years ago
|
||
... and post another patch ;-) I can't review this one, as I can't see what's going on. Gerv
Comment 36•23 years ago
|
||
I have tested it, and there doesn't seem to be a problem with file endings. It doesn't feel like a Patch Maker bug either, though. This is strange. Can't we just use attachment 76735 [details] [diff] [review] and attachment 78961 [details] [diff] [review]?
Comment 38•23 years ago
|
||
> For some reason patch 76735 refuses to apply
Is it the entire patch or only certain lines? If the latter, could it be that
those lines are only trying to remove some blank lines from the end of the files?
Comment 39•23 years ago
|
||
> Is it the entire patch or only certain lines? If the latter, could it be that
> those lines are only trying to remove some blank lines from the end of the
> files?
Lots and lots of failures; I didn't investigate closely.
Presumably you did this with a script, right? ;-) Can't you just rerun it?
Gerv
Comment 40•23 years ago
|
||
Does this patch apply? (Note that it still contains the same errors as attachment 76735 [details] [diff] [review], so attachment 78961 [details] [diff] [review] still needs to be applied afterwards)
Attachment #76735 -
Attachment is obsolete: true
Comment 41•23 years ago
|
||
Nope, this one fails completely as well :-( To begin with, the first file in the patch appears not to exist, and then: missing header for unified diff at line 56 of patch ... patch: **** malformed patch at line 960: +++ layout/html/tests/table/marvin/tables_align_left.html Fri Mar 29 14:37:17 2002 If someone could confirm that it's not my tree that's broken, that would be good. One suggestion is to write a script to do this, if you haven't already - I can then run it myself, and check in the results. Gerv
Comment 42•23 years ago
|
||
> If someone could confirm that it's not my tree that's broken, that would be good.
Nothing is wrong with your tree -- I can't even apply this myself after
downloading the tests again. Looks like some of the tools I used screwed up badly.
Unfortunately I won't have the time to take a second stab at this one until a
long time from now, so somebody else will probably have to do it. (IOW, I give
up for now. Sorry for all the comments-which-can-now-be-considered-worthless-spam.)
Comment 43•23 years ago
|
||
This one should get the year right. Needs a quick perl -pli~ -e 's/^M/\n/g' * on the files before it'll work.
Comment 44•23 years ago
|
||
Comment 45•23 years ago
|
||
The attached script (awful, huh ?) seems to do the job - I got bored. I haven't tested the testcases still work, at all.
Comment 46•23 years ago
|
||
Forgot to say, this is only in marvin/, there's a couple of other places in tests/table/ too
Comment 48•23 years ago
|
||
John - the attachment is some sort of binary file; it's certainly not a diff. So I can't apply it. Gerv
Updated•22 years ago
|
Attachment #88314 -
Attachment is patch: false
Attachment #88314 -
Attachment mime type: text/plain → application/x-gzip
Comment 50•22 years ago
|
||
I hate to be the bearer of bad news, but this one doesn't apply either. The sad fact is that I don't have time to fix broken patches (hence the lack of movement on this bug.) I need a patch which fulfils the following criteria: 1) single file, uncompressed, attached to Bugzilla as a "patch" 2) created using cvs diff -u from the "mozilla" directory of a CVS checkout 3) will Just Work if I try to apply it using patch < patch.txt (or comes with other instructions about how to patch it in correctly) This last one fails item 3: [gerv@localhost mozilla]% patch -p0 < /home/gerv/pm/53764.diff can't find file to patch at input line 8 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: body_col.html |=================================================================== |RCS file: /cvsroot/mozilla/layout/html/tests/table/marvin/body_col.html,v |retrieving revision 1.1 |diff -u -r1.1 body_col.html |--- body_col.html 5 Apr 1999 19:55:20 -0000 1.1 |+++ body_col.html 19 Jun 2002 16:14:15 -0000 -------------------------- File to patch: [ ... Trying without -p0 also gives the same error. Gerv
Comment 51•22 years ago
|
||
The patch : http://www.movement.uklinux.net/bug53764.diff (obviously, I cannot attach the patch here - it is 800k+) Tested with : cd ~/src/mozilla/ rm -rf layout/html/tests cvs up layout/html/tests patch -p0 <bug53764.diff If you're still having problems, then it must be on your end.
Comment 52•22 years ago
|
||
That's the baby. Thanks! Fixed. Please check that I've got this right :-) Gerv
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 53•22 years ago
|
||
see comment 46 I'll work on a hand patch for the few remaining testcases.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 54•22 years ago
|
||
Forthcoming patch fixes the remaining table tests. There is also : /directory/c-sdk/ldap/libraries/libssldap/errormap.c, line 26 /modules/libnls/headers/msgstr.h, line 2 /modules/libnls/headers/resbdl.h, line 2 which are not fixed - the first one is NPL-licensed already so I'm not sure if permission is OK. The second seem to be gone (how often is lxr updated ?)
Comment 55•22 years ago
|
||
Comment 56•22 years ago
|
||
> the first one is NPL-licensed already so I'm not sure if permission is OK.
Removing the notice and tri-licensing that file is fine. If you want to roll
this and the others in, I'll review and check in the patch.
Gerv
Comment 57•22 years ago
|
||
apply with patch -p0 <thepatch Still don't know if modules/libnls/ exists - if it does, two files need fixing - how do I check it out ?
Attachment #94775 -
Attachment is obsolete: true
Comment 58•22 years ago
|
||
New patch checked in. Gerv
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Comment 59•22 years ago
|
||
sorry to be a pain in the butt, but I don't see the fix for errormap.c in bonsai.
Comment 60•22 years ago
|
||
Does everything else apart from errormap.c look OK? It could be that I don't have permission to check in to that file. Gerv
Comment 61•22 years ago
|
||
directory is a locked partition, dmose will work on it, however the license change is beyond the scope of this bug, and directory relicensing is stuck so it absolutely can't be changed atm. filed bug 163534 dmose, cldap filed bug 163547 ftang, libnls
You need to log in
before you can comment on or make changes to this bug.
Description
•