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)

Product:
mozilla.org
Component:
Miscellaneous
Type:
task

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: wtc, Assigned: endico)

References

(
URL
)

Details

Attachments

(8 files, 2 obsolete files)

\programf\Dev\Java\13002\INCLUDE\JNI.H
65.14 KB, text/plain
Details
programf\Dev\Java\13002\include\win32\jni_md.h
496 bytes, text/plain
Details
fix the problems with the first patch
10.62 KB, patch
Details | Diff | Splinter Review
attempt at a combined patch
752.15 KB, patch
Details | Diff | Splinter Review
Unconfidentialify 193 table layout tests -- second try
528.89 KB, patch
Details | Diff | Splinter Review
Crummiest perl script ever to make the changes
2.09 KB, text/plain
Details
The generated diff from applying the script
25.75 KB, application/x-gzip
Details
fix remaining table tests and ldap errormap.c
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
Status: NEW → ASSIGNED
Blocks: 14532
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 :)
URL: http://lxr.mozilla.org/seamonkey/sear...
Keywords: mozilla1.0
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?
URL: http://lxr.mozilla.org/seamonkey/sear... → http://lxr.mozilla.org/mozilla/search...
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 ...)
Attachment #88314 - Attachment is patch: false
Attachment #88314 - Attachment mime type: text/plain → application/x-gzip
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: 22 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: 22 years ago → 22 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
Depends on: 163534, 163547

    
    

    
  
v
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: