PC Review


Reply
Thread Tools Rate Thread

what is the best obfuscator to buy

 
 
Jonathan Pierce
Guest
Posts: n/a
 
      18th Jun 2004
>> (If it incorrectly obfuscated a particular error case which had
>>never cropped up, the bug in obfuscation wouldn't have been seen yet.)


The obfuscated code produced by our decompiler is recompiled so incorrectly
generated code would have been seen by the compiler, and it's runtime
behavior would affect that aspect of the product's runtime behavior, since
we ship the recompiled version of our obfuscated code produced by
decompiling the product with itself in obfuscation mode. This is also
evidence that it supports correct COM Interop code generation since COM
Interop code used in the product wouldn't run correctly if the code was
generated incorrectly when the product was decompiled and recompiled prior
to distribution.

> Note that no specific claims were made about *your* obfuscator in the
> passage you quoted - only about *most* new obfuscator products.


It is always better to identify specific reproducable examples and to cite
specific products, rather than making inaccurate general statements implying
that anything new that is less expensive, buggy, and incomplete. I
apologize if the author of the quote was referring to his personal
experience with some other unknown product, but our the only new product
that was recently announced for this market that has made these claims. If
he was referring to our products, I'd appreciate specific examples since
none of our customers have had as bug-related issues and have only expressed
positive feedback to us both directly and in public forums.

Jonathan

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Jonathan Pierce <(E-Mail Removed)> wrote:
>> > > These two have been around for a while and work pretty well.
>> > > Most of the new obfuscator products that claim to be cheaper are
>> > > quite buffy and/or incomplete.

>>
>> This is an absolutely unfounded statement and you would be wise to do
>> your own evaluation. Our obfuscator is new, less expensive, more
>> powerful, easier to configure, and there have been no bugs reported
>> regarding obfuscation. In addition, we obfuscate our product with
>> itself each time we ship it so any bugs would prevent the product from
>> working at all.

>
> No - only bugs that affected obfuscation of your code would prevent the
> product from working at all, and not necessarily all of those bugs
> even. (If it incorrectly obfuscated a particular error case which had
> never cropped up, the bug in obfuscation wouldn't have been seen yet.)
>
>> This is strong evidence that it works extremely well

>
> Well, it's evidence that it works on your own code.
>
>> and our customers are extremely happy with it.

>
> That's certainly more convincing, as it'll cover a wider code base.
>
>> We will be happy to respond to any issues that you encouter using the
>> product. Please attempt to keep these discussions based on facts and
>> real examples, rather than unfounded opinions and inaccurate claims
>> that interfere with developers interested in accurate information in
>> order to make correct choices.

>
> Inaccurate claims such as the implied, "It works with our code
> therefore there can't be any bugs"?
>
> Note that no specific claims were made about *your* obfuscator in the
> passage you quoted - only about *most* new obfuscator products.
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too



 
Reply With Quote
 
 
 
 
Jon Skeet [C# MVP]
Guest
Posts: n/a
 
      18th Jun 2004
Jonathan Pierce <(E-Mail Removed)> wrote:
> >> (If it incorrectly obfuscated a particular error case which had
> >>never cropped up, the bug in obfuscation wouldn't have been seen yet.)

>
> The obfuscated code produced by our decompiler is recompiled so incorrectly
> generated code would have been seen by the compiler, and it's runtime
> behavior would affect that aspect of the product's runtime behavior, since
> we ship the recompiled version of our obfuscated code produced by
> decompiling the product with itself in obfuscation mode. This is also
> evidence that it supports correct COM Interop code generation since COM
> Interop code used in the product wouldn't run correctly if the code was
> generated incorrectly when the product was decompiled and recompiled prior
> to distribution.


I don't see how that argument applies. Not all incorrectly generated
code will fail to compile, and it's possible that the incorrectly
generated code only occurs in one particular execution flow which has
never occurred, or which (say) subtly affects the threading so that a
previously theoretically thread-safe piece of code becomes
theoretically unsafe, even if that lack of safety is never observed.
(It's very easy to write threading code which will work on x86 but
isn't guaranteed to work on all conformant CLRs.)

I'm not saying you have such a bug - just that your reasoning of "Well,
we use our products on themselves, therefore they don't have any bugs"
is seriously flawed.

> > Note that no specific claims were made about *your* obfuscator in the
> > passage you quoted - only about *most* new obfuscator products.

>
> It is always better to identify specific reproducable examples and to cite
> specific products, rather than making inaccurate general statements implying
> that anything new that is less expensive, buggy, and incomplete.


It didn't imply that *anything* new is buggy and incomplete. "Most"
doesn't imply "all".

I agree that it's better to be specific - I just disagree with your
logic as applied to Alan Morgan's post.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
 
Reply With Quote
 
 
 
 
Jonathan Pierce
Guest
Posts: n/a
 
      19th Jun 2004
"Most"
> doesn't imply "all".
>
> I agree that it's better to be specific - I just disagree with your
> logic as applied to Alan Morgan's post.


I understand and appreciate your knowledge and attempts to keep
statements made in these forums honest and based on logical facts. I
am glad that you do respond and challenge any statements made that
can't be substantiated. In this case, you were correct that there was
not enough info in the quote to assume the author was referring to our
product. I may have been reacting to other posts my "Alan Morgan" from
other threads that you were not aware of that support the idea that he
was referring to our products in his statements about new products
that claim to be less expensive.

In another thread regarding our product, "Alan Morgan" wrote:

"i can't find any PDB files. sucks."
"it is bad that you reverse-engineer full source code and make money
with it"

We responded to these statements appropriately in that thread. Thank
you again for taking the time to monitor and contribute to these
discussions and basing your arguments on logic, true facts, and
reproduceable specific examples.

Jonathan


Jon Skeet [C# MVP] <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> Jonathan Pierce <(E-Mail Removed)> wrote:
> > >> (If it incorrectly obfuscated a particular error case which had
> > >>never cropped up, the bug in obfuscation wouldn't have been seen yet.)

> >
> > The obfuscated code produced by our decompiler is recompiled so incorrectly
> > generated code would have been seen by the compiler, and it's runtime
> > behavior would affect that aspect of the product's runtime behavior, since
> > we ship the recompiled version of our obfuscated code produced by
> > decompiling the product with itself in obfuscation mode. This is also
> > evidence that it supports correct COM Interop code generation since COM
> > Interop code used in the product wouldn't run correctly if the code was
> > generated incorrectly when the product was decompiled and recompiled prior
> > to distribution.

>
> I don't see how that argument applies. Not all incorrectly generated
> code will fail to compile, and it's possible that the incorrectly
> generated code only occurs in one particular execution flow which has
> never occurred, or which (say) subtly affects the threading so that a
> previously theoretically thread-safe piece of code becomes
> theoretically unsafe, even if that lack of safety is never observed.
> (It's very easy to write threading code which will work on x86 but
> isn't guaranteed to work on all conformant CLRs.)
>
> I'm not saying you have such a bug - just that your reasoning of "Well,
> we use our products on themselves, therefore they don't have any bugs"
> is seriously flawed.
>
> > > Note that no specific claims were made about *your* obfuscator in the
> > > passage you quoted - only about *most* new obfuscator products.

> >
> > It is always better to identify specific reproducable examples and to cite
> > specific products, rather than making inaccurate general statements implying
> > that anything new that is less expensive, buggy, and incomplete.

>
> It didn't imply that *anything* new is buggy and incomplete. "Most"
> doesn't imply "all".
>
> I agree that it's better to be specific - I just disagree with your
> logic as applied to Alan Morgan's post.

 
Reply With Quote
 
Jonathan Pierce
Guest
Posts: n/a
 
      19th Jun 2004
Jon Skeet [C# MVP] <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> Jonathan Pierce <(E-Mail Removed)> wrote:
>
> <snip>
>
> > I'm not sure whether the same would be true about using the ILMerge
> > tool with GPL assemblies since it merges assemblies into a new dll
> > that directly links them.

>
> That would certainly be a significantly stickier situation.
>
> I'm sure you were fine as you were - but I can quite see how removing
> #ZipLib entirely pre-empts further questions


Jon,

Thanks again for clarifying this. The authors of #ZipLib agreed that
we could have continued to rely on and distribute the unmodified
version of their original binary distribution.

We may want to move this license discussion to a different thread in
another group where other license enforcement authorities might want
to contribute.

Although we no longer require it, I would like to know your opinion
regarding whether this product and other product licenses that allow
distribution of unmodified binary versions would also permit
distribution of obfuscated pr encrypted versions of their original
binary distributions. I would expect that encypted versions should be
allowed since they get unencrypted back to the original version before
being linked, but obfuscated versions or bytecode translated versions
even packages as a seperate files might be considered derivative
works. I ask because the issue may come up again for us regarding
permissions to distributed encrypted binary versions of GPL and LGPL
distributions with our Deploy.NET product output for trusted computing
hardware.

Another example would be the IKVM distribution in Mono of the .NET
translated version of the classpath libraries. The original classpath
license refers to binary distribution of the classes for running on a
java VM, but IKVM compiles the java binaries to MSIL and distributes
the MSIL versions which might be considered a derivative work. They
could always distribute the compiled java distribution and JIT compile
it to MSIL at install time, but I don't think they should have to.

Can you clarify further your view of these licenses regarding
processing of unmodified binary distributions whether in advance, at
install time, or at runtime, and whether their form of distribution
matters, whether as seperate files, as embedded resources, as content
in a database image, merged into a common archive such as a jar with
classes from multiple sources, or even a merged dll like ILMerge would
produce from the original? I think these issues should be clarified
since they will resurface and are not explicitly defined in the
license terms of most licenses including GPL, LGPL, and the one that
classpath uses.

Jonathan
 
Reply With Quote
 
Alan Morgan
Guest
Posts: n/a
 
      20th Jun 2004
I wasn't refering to your product. I just started looking into this recently
and my experience is that Demeanor works great while most newer/cheaper
products fail on C++ stuff.

The problem with your obfuscator seems to be not price or features, more
that some people have not enough thrust: a) the way you argue and exaggerate
b) your claim that your decompiler can decompile and recompile obfuscated
code and c) your product is using code from various sources and you seem to
be unable to handle those partnerships. Most of the things you say about
your partners sound like you never talked to them beforehand and you view
them as enemies.

As a side note: I don't like people decompiling my entire source code into
files. This is already bad enough and you are collecting money for making
things easier.


"Jonathan Pierce" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Most"
> > doesn't imply "all".
> >
> > I agree that it's better to be specific - I just disagree with your
> > logic as applied to Alan Morgan's post.

>
> I understand and appreciate your knowledge and attempts to keep
> statements made in these forums honest and based on logical facts. I
> am glad that you do respond and challenge any statements made that
> can't be substantiated. In this case, you were correct that there was
> not enough info in the quote to assume the author was referring to our
> product. I may have been reacting to other posts my "Alan Morgan" from
> other threads that you were not aware of that support the idea that he
> was referring to our products in his statements about new products
> that claim to be less expensive.
>
> In another thread regarding our product, "Alan Morgan" wrote:
>
> "i can't find any PDB files. sucks."
> "it is bad that you reverse-engineer full source code and make money
> with it"
>
> We responded to these statements appropriately in that thread. Thank
> you again for taking the time to monitor and contribute to these
> discussions and basing your arguments on logic, true facts, and
> reproduceable specific examples.
>
> Jonathan
>
>
> Jon Skeet [C# MVP] <(E-Mail Removed)> wrote in message

news:<(E-Mail Removed)>...
> > Jonathan Pierce <(E-Mail Removed)> wrote:
> > > >> (If it incorrectly obfuscated a particular error case which had
> > > >>never cropped up, the bug in obfuscation wouldn't have been seen

yet.)
> > >
> > > The obfuscated code produced by our decompiler is recompiled so

incorrectly
> > > generated code would have been seen by the compiler, and it's runtime
> > > behavior would affect that aspect of the product's runtime behavior,

since
> > > we ship the recompiled version of our obfuscated code produced by
> > > decompiling the product with itself in obfuscation mode. This is also
> > > evidence that it supports correct COM Interop code generation since

COM
> > > Interop code used in the product wouldn't run correctly if the code

was
> > > generated incorrectly when the product was decompiled and recompiled

prior
> > > to distribution.

> >
> > I don't see how that argument applies. Not all incorrectly generated
> > code will fail to compile, and it's possible that the incorrectly
> > generated code only occurs in one particular execution flow which has
> > never occurred, or which (say) subtly affects the threading so that a
> > previously theoretically thread-safe piece of code becomes
> > theoretically unsafe, even if that lack of safety is never observed.
> > (It's very easy to write threading code which will work on x86 but
> > isn't guaranteed to work on all conformant CLRs.)
> >
> > I'm not saying you have such a bug - just that your reasoning of "Well,
> > we use our products on themselves, therefore they don't have any bugs"
> > is seriously flawed.
> >
> > > > Note that no specific claims were made about *your* obfuscator in

the
> > > > passage you quoted - only about *most* new obfuscator products.
> > >
> > > It is always better to identify specific reproducable examples and to

cite
> > > specific products, rather than making inaccurate general statements

implying
> > > that anything new that is less expensive, buggy, and incomplete.

> >
> > It didn't imply that *anything* new is buggy and incomplete. "Most"
> > doesn't imply "all".
> >
> > I agree that it's better to be specific - I just disagree with your
> > logic as applied to Alan Morgan's post.



 
Reply With Quote
 
Alan Morgan
Guest
Posts: n/a
 
      20th Jun 2004
You should informed all your Deploy.NET customers about this. According to
GPL link terminology their products right now violate the #ZipLib license.
It is unlikely they'll get sued over this but for aquisitions this might be
a show stopper (lawyers hit the breaks on GPL immediatly).

"Jonathan Pierce" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Jon Skeet [C# MVP] <(E-Mail Removed)> wrote in message

news:<(E-Mail Removed)>...
> > Jonathan Pierce <(E-Mail Removed)> wrote:
> >
> > <snip>
> >
> > > I'm not sure whether the same would be true about using the ILMerge
> > > tool with GPL assemblies since it merges assemblies into a new dll
> > > that directly links them.

> >
> > That would certainly be a significantly stickier situation.
> >
> > I'm sure you were fine as you were - but I can quite see how removing
> > #ZipLib entirely pre-empts further questions

>
> Jon,
>
> Thanks again for clarifying this. The authors of #ZipLib agreed that
> we could have continued to rely on and distribute the unmodified
> version of their original binary distribution.
>
> We may want to move this license discussion to a different thread in
> another group where other license enforcement authorities might want
> to contribute.
>
> Although we no longer require it, I would like to know your opinion
> regarding whether this product and other product licenses that allow
> distribution of unmodified binary versions would also permit
> distribution of obfuscated pr encrypted versions of their original
> binary distributions. I would expect that encypted versions should be
> allowed since they get unencrypted back to the original version before
> being linked, but obfuscated versions or bytecode translated versions
> even packages as a seperate files might be considered derivative
> works. I ask because the issue may come up again for us regarding
> permissions to distributed encrypted binary versions of GPL and LGPL
> distributions with our Deploy.NET product output for trusted computing
> hardware.
>
> Another example would be the IKVM distribution in Mono of the .NET
> translated version of the classpath libraries. The original classpath
> license refers to binary distribution of the classes for running on a
> java VM, but IKVM compiles the java binaries to MSIL and distributes
> the MSIL versions which might be considered a derivative work. They
> could always distribute the compiled java distribution and JIT compile
> it to MSIL at install time, but I don't think they should have to.
>
> Can you clarify further your view of these licenses regarding
> processing of unmodified binary distributions whether in advance, at
> install time, or at runtime, and whether their form of distribution
> matters, whether as seperate files, as embedded resources, as content
> in a database image, merged into a common archive such as a jar with
> classes from multiple sources, or even a merged dll like ILMerge would
> produce from the original? I think these issues should be clarified
> since they will resurface and are not explicitly defined in the
> license terms of most licenses including GPL, LGPL, and the one that
> classpath uses.
>
> Jonathan



 
Reply With Quote
 
Jon Skeet [C# MVP]
Guest
Posts: n/a
 
      20th Jun 2004
Alan Morgan <(E-Mail Removed)> wrote:
> You should informed all your Deploy.NET customers about this. According to
> GPL link terminology their products right now violate the #ZipLib license.
> It is unlikely they'll get sued over this but for aquisitions this might be
> a show stopper (lawyers hit the breaks on GPL immediatly).


I don't believe that's true at all, as the #ZipLib has an exception for
linking. As it says on the #ZipLib website: "Bottom line In plain
English this means you can use this library in commercial closed-source
applications."

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
 
Reply With Quote
 
Jon Skeet [C# MVP]
Guest
Posts: n/a
 
      20th Jun 2004
Jonathan Pierce <(E-Mail Removed)> wrote:
> Thanks again for clarifying this. The authors of #ZipLib agreed that
> we could have continued to rely on and distribute the unmodified
> version of their original binary distribution.
>
> We may want to move this license discussion to a different thread in
> another group where other license enforcement authorities might want
> to contribute.


I think it's fine here for the moment - I certainly don't know of any
particular licensing groups (although I admit I haven't looked).

> Although we no longer require it, I would like to know your opinion
> regarding whether this product and other product licenses that allow
> distribution of unmodified binary versions would also permit
> distribution of obfuscated pr encrypted versions of their original
> binary distributions. I would expect that encypted versions should be
> allowed since they get unencrypted back to the original version before
> being linked, but obfuscated versions or bytecode translated versions
> even packages as a seperate files might be considered derivative
> works. I ask because the issue may come up again for us regarding
> permissions to distributed encrypted binary versions of GPL and LGPL
> distributions with our Deploy.NET product output for trusted computing
> hardware.


Right. I think I'd probably agree with your reading of it - encryption
is just another medium, effectively (like providing a zip of the binary
would be). Obfuscation is somewhat different. Of course, there's not
really much point in obfuscating an open source binary, I'd have
thought.

I'm really *not* an expert on these matters though - it's worth asking
a lawyer, unfortunately

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
 
Reply With Quote
 
Jonathan Pierce
Guest
Posts: n/a
 
      20th Jun 2004
"Alan Morgan" <(E-Mail Removed)> wrote in message news:<#(E-Mail Removed)>...
> I wasn't refering to your product. I just started looking into this recently
> and my experience is that Demeanor works great while most newer/cheaper
> products fail on C++ stuff.
>
> The problem with your obfuscator seems to be not price or features, more
> that some people have not enough thrust: a) the way you argue and exaggerate
> b) your claim that your decompiler can decompile and recompile obfuscated
> code and c) your product is using code from various sources and you seem to
> be unable to handle those partnerships. Most of the things you say about
> your partners sound like you never talked to them beforehand and you view
> them as enemies.


Alan,

Thanks for letting us know that you were not referring to our product
in your earlier statement about buggy new obfuscator products. I hope
your experience testing our product continues to be positive.

a) Since are products are brand new, we need to be extremely careful
that the developer community become aware of the full power and
quality that they provide by monitoring statements that could be
perceived to be references to our products in these public forums. We
don't intend to exaggerate any of our claims, and welcome any
reproduceable examples that refute them. The size or age of the
company is less relevant than the merits of the actual products being
offered and we want each developer to spend a few minutes doing the
comparison themselves rather than relying on assumptions or reviews
that may not be available yet.

b)We never claimed that we could reverse obfuscated code created by
other vendor
s obfuscators. Obfuscator tools often intentionally scramble metadata
that the runtime no longer needs by decompilers and debuggers still
require. Our claim is that we recompile obfuscate code produced by our
obfuscator so this ensures that we detect many errors when we
recompile the code that users might not detect until runtime when
using the output of other obfuscator tools. This also minimizes the
need to preconfigure exception cases.

c)I do not view any of our competitors as enemies at all. I view them
as colleagues and respect them very much for their knowledge and the
quality of their work. I'm sorry that you got this impression from my
attempts to compare the quality of our products to theirs. I welcome
any examples from them and head on comparisons to our products, and
attempt whenever possible to help them improve their products to bring
the overall quality of products in this domain to a higher level. I've
suggested to Lutz several times that he consider offering a non-free
version of his tools so that he could justify providing even better
support then he is able to currently provide. We have interacted and
had many positive conversations with the authors of Reflector,
Salamander, and Spices. We regularly provide them with bug reports,
assist them with testing their products, and offered them free copies
of full licenses to our tools which some of them have accepted and
some have reciprocated with free copies of their tools for us.

Here are some email signatures if you don't believe me:

Best regards,
Victor Victorov
9Rays.Net (merger of Imca Systems and Dev4Net) .Net, Delphi, C++
Builder, ActiveX tools, components & controls


Date: Mon, 31 May 2004 14:25:20 -0700
From: Lutz Roeder <(E-Mail Removed)>
Subject: RE: IL Reader bug fix

Date: Fri, 30 Apr 2004 20:50:06 -0700
From: Lutz Roeder <(E-Mail Removed)>
Subject: RE: Reflector CodeModel and Parser

Date: Sun, 29 Feb 2004 12:31:41 -0800
From: Huihong Luo <(E-Mail Removed)>
Subject: Whidbey support

Date: Thu, 11 Dec 2003 08:56:35 -0800
From: Huihong Luo <(E-Mail Removed)>

>
> As a side note: I don't like people decompiling my entire source code into
> files. This is already bad enough and you are collecting money for making
> things easier.


I still don't understand why you object to this capability that
products in the decompiler domain provide. The decompilers also assist
you with translating your code across languages, improving your code
often, and our's also provides you obfuscation capability. Decompilers
should not be thought of any differently than other developer tools
that you use since they have many legal uses and we explicitly ask you
in our license to restrict your use of them to legal purposes. There
are many options available to you to protect your intellectual
property including patents and obfuscator tools offered by the same
decompiler vendors that you can utilize if you are concerned. The
tools provide a valuable use by allowing you to learn from and debug
assemblies whose license doesn't prohibit it by introspecting on their
source code.

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/

>
>
> "Jonathan Pierce" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > "Most"
> > > doesn't imply "all".
> > >
> > > I agree that it's better to be specific - I just disagree with your
> > > logic as applied to Alan Morgan's post.

> >
> > I understand and appreciate your knowledge and attempts to keep
> > statements made in these forums honest and based on logical facts. I
> > am glad that you do respond and challenge any statements made that
> > can't be substantiated. In this case, you were correct that there was
> > not enough info in the quote to assume the author was referring to our
> > product. I may have been reacting to other posts my "Alan Morgan" from
> > other threads that you were not aware of that support the idea that he
> > was referring to our products in his statements about new products
> > that claim to be less expensive.
> >
> > In another thread regarding our product, "Alan Morgan" wrote:
> >
> > "i can't find any PDB files. sucks."
> > "it is bad that you reverse-engineer full source code and make money
> > with it"
> >
> > We responded to these statements appropriately in that thread. Thank
> > you again for taking the time to monitor and contribute to these
> > discussions and basing your arguments on logic, true facts, and
> > reproduceable specific examples.
> >
> > Jonathan
> >
> >
> > Jon Skeet [C# MVP] <(E-Mail Removed)> wrote in message

> news:<(E-Mail Removed)>...
> > > Jonathan Pierce <(E-Mail Removed)> wrote:
> > > > >> (If it incorrectly obfuscated a particular error case which had
> > > > >>never cropped up, the bug in obfuscation wouldn't have been seen

> yet.)
> > > >
> > > > The obfuscated code produced by our decompiler is recompiled so

> incorrectly
> > > > generated code would have been seen by the compiler, and it's runtime
> > > > behavior would affect that aspect of the product's runtime behavior,

> since
> > > > we ship the recompiled version of our obfuscated code produced by
> > > > decompiling the product with itself in obfuscation mode. This is also
> > > > evidence that it supports correct COM Interop code generation since

> COM
> > > > Interop code used in the product wouldn't run correctly if the code

> was
> > > > generated incorrectly when the product was decompiled and recompiled

> prior
> > > > to distribution.
> > >
> > > I don't see how that argument applies. Not all incorrectly generated
> > > code will fail to compile, and it's possible that the incorrectly
> > > generated code only occurs in one particular execution flow which has
> > > never occurred, or which (say) subtly affects the threading so that a
> > > previously theoretically thread-safe piece of code becomes
> > > theoretically unsafe, even if that lack of safety is never observed.
> > > (It's very easy to write threading code which will work on x86 but
> > > isn't guaranteed to work on all conformant CLRs.)
> > >
> > > I'm not saying you have such a bug - just that your reasoning of "Well,
> > > we use our products on themselves, therefore they don't have any bugs"
> > > is seriously flawed.
> > >
> > > > > Note that no specific claims were made about *your* obfuscator in

> the
> > > > > passage you quoted - only about *most* new obfuscator products.
> > > >
> > > > It is always better to identify specific reproducable examples and to

> cite
> > > > specific products, rather than making inaccurate general statements

> implying
> > > > that anything new that is less expensive, buggy, and incomplete.
> > >
> > > It didn't imply that *anything* new is buggy and incomplete. "Most"
> > > doesn't imply "all".
> > >
> > > I agree that it's better to be specific - I just disagree with your
> > > logic as applied to Alan Morgan's post.

 
Reply With Quote
 
Jonathan Pierce
Guest
Posts: n/a
 
      20th Jun 2004
"Alan Morgan" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> You should informed all your Deploy.NET customers about this. According to
> GPL link terminology their products right now violate the #ZipLib license.
> It is unlikely they'll get sued over this but for aquisitions this might be
> a show stopper (lawyers hit the breaks on GPL immediatly).
>


Alan,

As I said earlier, we haven't sold any licensed copies of Deploy.NET
yet. Customers who are considering it are only using it for internal
evaluation at this time. #ZipLib does not use GPL license, it uses the
one that classpath uses which is even less restrictive than the LGPL
one.

"As a special exception, the copyright holders of this library give
you permission to link this library with independent modules to
produce an executable, regardless of the license terms of these
independent modules, and to copy and distribute the resulting
executable under terms of your choice"

Their FAQ says:

Can I use SharpZipLib in my commercial application?
Yes you can, there is an exception in the licensing terms that allows
linking #Zip with any application.

The only additional requirement is that improvements made to the
#ZipLib source be made available to everyone, not the sources of
programs that use it. In our case, we didn't modify the source to
#ZipLib at all, we only processed it and packaged it with our loader
where it gets dynamically linked to our older loader code. We could
have just embedded the original unmodified #ZipLib dll in our loader
as an embedded resource, even encrypted, and processed it at runtime,
but we decided to remove it completely to preempt further licensing
discussions.

Since no customers have purchased Deploy.NET licenses from us, and we
have repackaged all of our products with the newer loader that no
longer even references the binary version, there is no issue, and
there probably never was in the first place. We have also confirmed
that the authors of #ZipLib are satisfied and they had no objection to
us continuing to use their binary unmodified version and
redistributing it with our product as it's license allows. We decided
to avoid pursuing the discussion about how the unmodified binary
version was packaged, since we didn't really need the product anyway
and only used it because we didn't expect any conflict with our
repackaging the unmodified binary version and their license terms
which are not clear on the issue.

Jonathan
 
Reply With Quote
 
 
 
Reply

Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Best obfuscator venky Microsoft C# .NET 3 17th Nov 2011 10:19 AM
CodeVeil seems the best obfuscator for the .NET applications you develop Auto Microsoft C# .NET 3 22nd Jul 2011 10:32 AM
Re: Best Buy The Worst Buy For The Consumer dfld1222 Printers 31 26th Jan 2005 02:50 PM
Re: "Best Buy" Is The Worst Buy For Consumers gilbert Printers 6 24th Aug 2003 09:22 PM
Best Buy No Longer A "Best Buy" - At Least At Brooklyn NYC Store peter Printers 3 10th Aug 2003 03:01 PM


Features
 

Advertising
 

Newsgroups
 


All times are GMT +1. The time now is 10:29 PM.