Thank you for your reply. I used 'encryption' as an example just to describe my question, though it may be an improper design :)
However, I think the "#include" case may violate the original intention of MPL. I think MPL requires all modifications must be public avaiblable because they are useful to others.
For example (just an example), the following modification:
***************
*** 2688,2694 ****
--- 2698,2714 ----
// so how big is it?
presContext->GetVisibleArea(shellArea);
presContext->GetTwipsToPixels(&pixelScale);
+
+ /* WXZ: my way to fix the +1 problem
width = PRInt32((float)shellArea.width*pixelScale);
+ */
+ float tempWidth = (float)shellArea.width * pixelScale;
+ width = PRInt32(tempWidth);
+ if (tempWidth - width > 0.001)
+ {
+ // to let the extra 1 pixel when it is required
+ width ++;
+ }
height = PRInt32((float)shellArea.height*pixelScale);nsCOMPtr<nsIDocShellTreeOwner> treeOwner; ***************
can be converted to the following modification:
*** 2688,2694 ****
// so how big is it?
presContext->GetVisibleArea(shellArea);
presContext->GetTwipsToPixels(&pixelScale);
! width = PRInt32((float)shellArea.width*pixelScale);
height = PRInt32((float)shellArea.height*pixelScale); nsCOMPtr<nsIDocShellTreeOwner> treeOwner;
--- 2698,2704 ----
// so how big is it?
presContext->GetVisibleArea(shellArea);
presContext->GetTwipsToPixels(&pixelScale);
! #include "largerWork1.inc" // WXZ: put the added lines into it
height = PRInt32((float)shellArea.height*pixelScale);nsCOMPtr<nsIDocShellTreeOwner> treeOwner;
Although the latter modification might be made publicly available (while keeping largerWork1.inc private), it is useless to others.
I think MPL should add restrictions on this, requiring that all published modifications should be useful, at least can be successfully compiled.
Wang Xianzhu
Wang Xianzhu wrote:
For example, I want to compress and encrypt the chrome .jar files, to protect my own proprietory chrome source code.
But you'll need to unencrypt it to use it, won't you? I'm not sure this'll actually help very much...
1. add a function 'encrypt' directly in netwerk/protocol/jar/src/nsJARChannel.cpp, and call it from the same source file;
2. place the function 'encrypt' in MyEncrypt.cpp file, include this MyEncrypt.cpp file in original nsJARChannel.cpp, and call 'encrypt' from nsJARChannel.cpp;
3. place the function 'encrypt' in MyEncrypt.cpp file, export the function prototype in MyEncrypt.h, include MyEncrypt.h file in original nsJARChannel.cpp, and call 'encrypt' from nsJARChannel.cpp.
I know that what I do in choice 1 is 'modification'. My question is: is MyEncrypt.cpp in choice 2 and 3 valid 'larger works'?
In both cases 2) and 3), the code in MyEncrypt.cpp is _not_ a Modification under the terms of the MPL.
However, if you are relying on keeping your encryption algorithm a secret, then there's something else wrong there as well :-)
If it is, one can always convert the essence of 'modifications' to 'larger works' in this way. Is this true?
To an extent, yes. The Mozilla license was designed to allow people to combine Mozilla code with proprietary code.
Gerv
_______________________________________________ mozilla-license mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-license
