Distributing closed source modules

Discussion in 'Python' started by Jiri Barton, Mar 24, 2005.

  1. Jiri Barton

    Jiri Barton Guest

    Hi,

    I'd like to be able to distribute some python modules of my system (plugins)
    without the source. So far, I have done this by including only the *.pyc
    files. However, I have recently found they are platform dependent and
    python version dependent.

    This approach has been very convenient because I don't have to mess up with
    __import__ and the like - which seem to be kind of a pain when inter-module
    dependencies are introduced.

    Can some one point me in another direction of protecting the code? I know
    and this whole thing just does not sound right to me either but I am forced
    to do so.

    TIA, jbar
    Jiri Barton, Mar 24, 2005
    #1
    1. Advertising

  2. Jiri Barton

    Dave Brueck Guest

    Jiri Barton wrote:
    > I'd like to be able to distribute some python modules of my system (plugins)
    > without the source. So far, I have done this by including only the *.pyc
    > files. However, I have recently found they are platform dependent and
    > python version dependent.
    >
    > This approach has been very convenient because I don't have to mess up with
    > __import__ and the like - which seem to be kind of a pain when inter-module
    > dependencies are introduced.
    >
    > Can some one point me in another direction of protecting the code? I know
    > and this whole thing just does not sound right to me either but I am forced
    > to do so.


    Protecting code in any language is pretty tough and/or futile, but you can
    Google the archives if you're interested in reading more on that.

    Anyway, you can create a module on the fly like this (untested):

    import new, sys
    name = 'MyModule'
    m = sys.modules[name] = new.module(name)
    exec codeStr in m.__dict__

    where codeStr is a string that contains the source code of your module (e.g.
    from file('somemodule.py').read() ).

    You can combine the above with whatever mechanism you come up with for
    distributing the code itself. You could store it in an encrypted archive file,
    you could download it on the fly from a remote server over a secure connection, etc.

    -Dave
    Dave Brueck, Mar 24, 2005
    #2
    1. Advertising

  3. Jiri Barton

    Fuzzyman Guest

    Dave Brueck wrote:
    > Jiri Barton wrote:

    [snip..]

    Hello Dave,

    >
    > Protecting code in any language is pretty tough and/or futile, but

    you can
    > Google the archives if you're interested in reading more on that.
    >


    It's certainly something lot's of people are interested in. I guess it
    depends who your audience is. If ytour code isn't for *mass*
    distribution - the chances of people putting a lot of effort into
    breaking it are greatly reduced. I don't htink it's necessarily futile.

    > Anyway, you can create a module on the fly like this (untested):
    >
    > import new, sys
    > name = 'MyModule'
    > m = sys.modules[name] = new.module(name)
    > exec codeStr in m.__dict__
    >
    > where codeStr is a string that contains the source code of your

    module (e.g.
    > from file('somemodule.py').read() ).
    >


    This is one of the better solutions I've seen. (Probably because it's
    *not* very complex). The stored modules can be well encrypted.
    Obviously the decryption code will be in the main code - but I guess it
    can be obfuscated pretty well.

    I like it.

    Regards,

    Fuzzy
    http://www.voidspace.org.uk/python

    > You can combine the above with whatever mechanism you come up with

    for
    > distributing the code itself. You could store it in an encrypted

    archive file,
    > you could download it on the fly from a remote server over a secure

    connection, etc.
    >
    > -Dave
    Fuzzyman, Mar 25, 2005
    #3
  4. Jiri Barton

    Dave Brueck Guest

    Fuzzyman wrote:
    > Dave Brueck wrote:
    > It's certainly something lot's of people are interested in. I guess it
    > depends who your audience is. If ytour code isn't for *mass*
    > distribution - the chances of people putting a lot of effort into
    > breaking it are greatly reduced. I don't htink it's necessarily futile.


    By "futile" I meant that, if the code ends up running on a user's machine, then
    a sufficiently motivated person could crack it wide open, regardless of
    implementation language - the only way to truly protect the code is to never let
    it out of your hands (i.e. it's accessible just via a web service).

    -Dave
    Dave Brueck, Mar 25, 2005
    #4
  5. Jiri Barton

    Fuzzyman Guest

    Dave Brueck wrote:
    > Fuzzyman wrote:
    > > Dave Brueck wrote:
    > > It's certainly something lot's of people are interested in. I

    guess it
    > > depends who your audience is. If ytour code isn't for *mass*
    > > distribution - the chances of people putting a lot of effort into
    > > breaking it are greatly reduced. I don't htink it's necessarily

    futile.
    >
    > By "futile" I meant that, if the code ends up running on a user's

    machine, then
    > a sufficiently motivated person could crack it wide open, regardless

    of
    > implementation language - the only way to truly protect the code is

    to never let
    > it out of your hands (i.e. it's accessible just via a web service).
    >


    Hello Dave,

    I understand what you are saying - using hte word 'futilew' implies
    that code is *likely* to be broken, not that it is *theoretically
    possible* for it to be broken. If code has a small user base it is
    probable that there is plenty that can be done to make breaking the
    code a lot harder. There are also legitimate reasons why someone would
    want to do this. 'Futile' is definitely a misleading response :)3

    It's a question that often comes up on comp.lang.python - and the reply
    is often "don't bother, it's not possible - and why do you want to do
    that anyway". This is a response that is likely to turn people towards
    other languages....

    Best Regards,

    Fuzzy
    http://www.voidspace.org.uk/python

    > -Dave
    Fuzzyman, Mar 29, 2005
    #5
  6. Jiri Barton

    Dave Brueck Guest

    Fuzzyman wrote:
    > Dave Brueck wrote:
    >> By "futile" I meant that, if the code ends up running on a user's
    >> machine, then
    >> a sufficiently motivated person could crack it wide open, regardless
    >> of
    >>implementation language - the only way to truly protect the code is
    >> to never let
    >>it out of your hands (i.e. it's accessible just via a web service).
    >>

    >


    > I understand what you are saying - using hte word 'futilew' implies
    > that code is *likely* to be broken, not that it is *theoretically
    > possible* for it to be broken. If code has a small user base it is
    > probable that there is plenty that can be done to make breaking the
    > code a lot harder. There are also legitimate reasons why someone would
    > want to do this. 'Futile' is definitely a misleading response :)3


    Not really. For all practical purposes, shipping .pyc files is probably
    sufficient for most of the software out there: (1) it's a high enough "fence"
    for almost all users, (2) for most programs, getting the source code and being
    able to do something with it are two very different things, and (3) for most
    programs, there really is no proprietary magic worth protecting.

    So, when somebody says it's not good enough, and they need something better, I
    have to admit I'm initially skeptical of their perceived need for "better"
    protection of the source code (there _are_ some cases where it should be
    protected, but they are much less common than people seem to think). One of two
    things is probably true in these cases:

    1) The value of the source code is overestimated - yes, it's a nice program, but
    there's not really anything in there to warrant the higher
    development/deployment/debugging costs associated with more security. As such,
    nobody is really going to care enough to crack the code. And if anybody does,
    it's unlikely that they'll actually do anything with the code. Thus, the effort
    to secure the code more is futile - it's ineffective because the effort will
    never provide any benefit.

    OR

    2) The code really does have some innovative, proprietary algorithm, like a
    video codec with wildly improved compression (that for some reason you've
    implemented in pure Python ;-) ). If the value of the code is really high, then
    no amount of security is going to prevent people from getting at it - trying to
    protect your code is futile because no matter how high a wall you create,
    sufficiently determined people will climb over it. Plus, protecting the source
    code may be the least of your worries (if they're willing to steal your code,
    they may just as well be willing to use your library illegally, etc.).

    > It's a question that often comes up on comp.lang.python - and the reply
    > is often "don't bother, it's not possible - and why do you want to do
    > that anyway". This is a response that is likely to turn people towards
    > other languages....


    Perhaps the response could be framed better, but at the same time it _is_ a
    pretty honest response, and maybe Python really _isn't_ the language for such
    people. It's just like people who ask for curly braces - Python is not the
    language for them. So if I asked for braces, a lot of the c.l.py responses would
    be geared towards helping me understand that they aren't really needed, but if I
    insist that I have to have them, then maybe Python isn't for me. :)

    So, when the question comes up, I don't mind offering some suggestions, but the
    suggestions will always include the disclaimer that it's probably a waste of
    time & effort - IMO leaving that part out would be misleading.

    -Dave
    Dave Brueck, Mar 29, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. r1pp3r
    Replies:
    1
    Views:
    254
    Fredrik Lundh
    Aug 29, 2006
  2. Tina I
    Replies:
    11
    Views:
    404
    Tina I
    May 17, 2007
  3. eliben
    Replies:
    9
    Views:
    325
    eliben
    Jun 9, 2008
  4. mathieu
    Replies:
    1
    Views:
    256
    Diez B. Roggisch
    Jun 4, 2008
  5. Alec Taylor
    Replies:
    0
    Views:
    80
    Alec Taylor
    Aug 13, 2013
Loading...

Share This Page