Robert Latest <[EMAIL PROTECTED]> writes:
> And, contrary to the advice I gave elsethread, unfortunately it's
> impossible to just drop uncooperative customers when you develop GPL
> software ;-)
On the contrary. The GPL includes a big fat "NO WARRANTY" clause. If
you're not selling warranties to
On Mon, 14 Jan 2008 12:46:48 +, Robert Latest wrote:
> And, contrary to the advice I gave elsethread, unfortunately it's
> impossible to just drop uncooperative customers when you develop GPL
> software ;-)
Just because you are writing GPLed code doesn't mean you are permanently
linked to an
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:python-
> [EMAIL PROTECTED] On Behalf Of Paul Sijben
> Sent: Friday, January 11, 2008 4:45 AM
> To: python-list@python.org
> Subject: encrypting python modules
>
>
> The problem: I have a client-server app written in python. I want to
Steven D'Aprano wrote:
> No, it's a serious question. You distribute Python code, and you're
> worried that your users will modify the source code and then neglect to
> mention it when they report bugs which they introduced.
>
> Before you build an elephant-proof fence around your house, it is q
Paul Sijben wrote:
>>
>> You could check the MD5 hashes of your files.
>
> indeed but I still need to hook into import to do that reliably, right?
Depends. In a job I once had I just supplied a shell script that spat out
the MD5 sums of my sources. When I got a support request I had the customer
On Mon, 14 Jan 2008 09:49:49 +0100, Paul Sijben wrote:
>> How often do these things *actually* happen?
>>
>> Of those that actually do it, how many are clueless enough that when
>> they run into problems they blame you for it? (And remember that you
>> won't even find out about the non-clueless o
Robert Latest wrote:
> Paul Sijben wrote:
>
>> The problem: I have a client-server app written in python. I want to
>> make sure that the client is not:
>> 1) destabilized by users accidentally or on purpose dropping python
>> files in the path (after which calling the helpdesk will not be useful)
Paul Sijben wrote:
> The problem: I have a client-server app written in python. I want to
> make sure that the client is not:
> 1) destabilized by users accidentally or on purpose dropping python
> files in the path (after which calling the helpdesk will not be useful)
> 2) extended with "new feat
Mike,
thanks for the constructive feedback.Indeed i probably need to patch
import in some way. Looks like there is no standard way to get this
done. So I guess I have do it myself...
In the famous last words department: how hard can that be? ;-)
Paul
Mike Meyer wrote:
> On Sat, 12 Jan 2008 09
> How often do these things *actually* happen?
>
> Of those that actually do it, how many are clueless enough that when they
> run into problems they blame you for it? (And remember that you won't
> even find out about the non-clueless ones.)
>
>
This is a rethorical question, right?
--
http
Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> writes:
> On Sat, 12 Jan 2008 09:47:26 +1100, Ben Finney wrote:
>
> > Trying to make bits uncopyable and unmodifiable is like trying to
> > make water not wet.
>
> Certainly not. I can put water into the freezer
Turning it into ice, and making it no
On Sat, 12 Jan 2008 09:47:26 +1100, Ben Finney wrote:
> Trying to make bits uncopyable and unmodifiable is like trying to make
> water not wet.
Certainly not. I can put water into the freezer, but I have no idea how
to make bits uncopyable and unmodifiable while still delivering them to
the clie
On Fri, 11 Jan 2008 10:44:36 +0100, Paul Sijben wrote:
> Hello,
>
> this question has come by repeatedly in several guises over the past
> years but has never been solved in this forum as far as I have been able
> to Google.
>
> However since so many people are asking the question, I hope someon
On Sat, 12 Jan 2008 09:47:26 +1100 Ben Finney <[EMAIL PROTECTED]> wrote:
> Paul Sijben <[EMAIL PROTECTED]> writes:
> > I know that I can not stop a dedicated hacker deconstructing my code.
> A direct consequence of this is that you can not stop *anyone* from
> deconstructing your code if it's in t
Paul Sijben <[EMAIL PROTECTED]> writes:
> I know that I can not stop a dedicated hacker deconstructing my code.
A direct consequence of this is that you can not stop *anyone* from
deconstructing your code if it's in their possession. It takes only
one dedicated, skilled person to crack your obfus
15 matches
Mail list logo
