Re: Is this valid 'larger work' using '#include' or API?

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