Closed Bug 53764 Opened 20 years ago Closed 18 years ago
Netscape Confidential and Proprietary source code in the mozilla source tree
65.14 KB, text/plain
496 bytes, text/plain
10.62 KB, patch
|Details | Diff | Splinter Review|
752.15 KB, patch
|Details | Diff | Splinter Review|
528.89 KB, patch
|Details | Diff | Splinter Review|
2.09 KB, text/plain
25.75 KB, application/x-gzip
23.24 KB, 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.
Reassigning to Dan for license wackage
Assignee: mitchell → dmose
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 :)
Assignee: dmose → endico
Status: ASSIGNED → NEW
Mass reassign of mozilla.org infrastructure bugs, as I'm switching groups to work on LDAP integration in Mozilla full-time.
Dawn, is this really still a problem? I'm worried this is rotting away in the wrong component.
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
mitchell: ping :-) Gerv
I can't image any justification for having Netsape "proprietary" files in the mozilla tree, other than an error at the time of release.
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?
jni and co are easy pick a jni that works from a public jdk
I think we can safely remove the confidential markings from our table layout tests since they are hardly confidential today.
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.
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
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.
Cheers, guv. Gerv
Gerv, have you got this in hand, or would patches help?
Patches would definitely, definitely help :-) Use Patch Maker ;-) Gerv
Ok, i'll redo my patch for the NCSP tests. imajes
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?
Please replace with MPL/GPL/LGPL. Gerv
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 on attachment 76735 [details] [diff] [review] Unconfidentialify 193 table layout tests a=asa (on behalf of drivers) for checkin to the 1.0 trunk
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?
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?
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...
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).
> 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
This should fix all of the problems with the first patch. This patch is meant to be applied immediately after applying the first patch.
Jonas: please post a combined patch, which I will then review. Gerv
jonas: ping? Gerv
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.
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
... and post another patch ;-) I can't review this one, as I can't see what's going on. Gerv
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]?
For some reason patch 76735 refuses to apply :-( Gerv
> 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?
> 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
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
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
> 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.)
This one should get the year right. Needs a quick perl -pli~ -e 's/^M/\n/g' * on the files before it'll work.
The attached script (awful, huh ?) seems to do the job - I got bored. I haven't tested the testcases still work, at all.
Forgot to say, this is only in marvin/, there's a couple of other places in tests/table/ too
What dance do I have to do to get someone to look at the fix here ?
John - the attachment is some sort of binary file; it's certainly not a diff. So I can't apply it. Gerv
It's a gzip-compressed diff (wrong content-type I suppose ...)
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
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.
That's the baby. Thanks! Fixed. Please check that I've got this right :-) Gerv
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
see comment 46 I'll work on a hand patch for the few remaining testcases.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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 ?)
> 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
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
New patch checked in. Gerv
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
sorry to be a pain in the butt, but I don't see the fix for errormap.c in bonsai.
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
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.