Commercial file-server software

Discussion in 'Linux Networking' started by sutil83, Sep 13, 2005.

  1. sutil83

    sutil83 Guest

    Wow, I go to sleep for a night and I get a bunch of responses. Thanks
    people. Unfortunately it seems as if my fears are realized that there
    is no commercial products and that any that used to exist are now
    defunct.

    But in response to other posts, this will be re-distributed out of our
    company and if used, Samba will be included, incorporated and used.
    Whether or not it is modified now is irrelevant, the lifespan of this
    product is intended to be decades. The real fear that the legal
    department here has (and other out of company entities that I can't
    name), is that sometime in the life of the product, updates, upgrades
    or whatever might occur. Basically there is a possibility that
    something might happen that would require a change in source code, in
    this case the GPL code.

    So either a restriction is placed or we just don't use open-source at
    all. The decision was made to generally avoid open-source since who
    knows the implications of a restriction of that sort, a decade from now
    when the product needs a slight tune-up. Also, a change might need to
    be made right off the bat, even before distribution. All these
    "maybe's" don't sit well and the more of those there are, the more
    likely the client boots us.

    The situation is a hard one since what will be done to Samba, or
    anything of the sort, is unknown at this point. Which is why I was
    looking for alternatives to avoid this whole fiasco. All the points
    you guys bring up are true and I realized there are work arounds. All
    I attempted to do by this thread is possibly find an alternative.
    Dealing with legal over here is one matter that's hard enough as it is.
    Convincing the client is impossible. The possibility that any of
    their information becomes freely distributed is unnacceptable. Not
    even that it is, even just the POSSIBILITY.

    Now before you try and tell me to talk to the client about it, don't
    bother. Just trust me when I say it can't be done.
    Anyway you guys did help out by confirming what I already knew: no
    commercial alternatives to Samba. So it looks like this mini-task will
    have to be continued in some other form.

    Thanks a lot for all the responses.

    Best Regards to All,
    Sutil83
     
    sutil83, Sep 14, 2005
    #41
    1. Advertisements

  2. But in response to other posts, this will be re-distributed out of our
    I find it extremely surprising that you imagine that "open-source" is
    different from other forms of software in any meaningful fashion here.

    If you had been looking at this five years ago, Digital PathWorks
    might have appeared 'more viable,' and you would, today, be in the
    situation where Digital kind of doesn't exist anymore.

    Under the circumstances you are describing, I can't see there being
    any satisfactory approach other than for your organization to develop
    its very own server software. The guarantees you seem to find lacking
    in "open-source" software don't seem to me to be any more attainable
    from vendors selling under more traditional "commercial/proprietary"
    licenses.

    No other answer than internal development keeps the choices as clearly
    controlled in your hands.
    Then you're toast. There are no alternatives to offer, and a "more
    proprietary" world wouldn't help. Supposing PathWorks had remained
    commercially viable, the multiplicity of buyouts would probably still
    leave it in a questionable state as a choice.
     
    Christopher Browne, Sep 14, 2005
    #42
    1. Advertisements

  3. sutil83

    gretchen Guest

    You think that you're going to be doing "anything of the sort" to some
    proprietary software then? Your presentation grows more absurd with each
    post you make.
     
    gretchen, Sep 14, 2005
    #43
  4. I am having trouble understanding this. Am I right in thinking
    that they are afraid that they MIGHT, one day, want to make
    proprietary modifications to the file system they use, and
    distribute it while keeping the modifications secret?

    If that is the case, then you are right, they can't use GPL'd
    code to do that with. Check the Samba license - it just might be
    BSD or some other licence that does allow such parasitic behaviour.

    How about if they go for Samba now, and reconsider the FS type if
    they ever DO choose to ship a secret proprietary one instead?
    You're right - I don't think there are any proprietary network
    filesystems for Linux. Except, just maybe, Novell Netware,
    although I doubt they'd support it on a Mac platform. And I doubt
    they'd let you modify it and distribute those modifications.

    The final solution would be to write or commission their own
    network file protocol from the ground up. If they want to play
    secret squirrel, let them. Except I'm not sure about linking it
    to the Linux kernel - it may have to remain a user-space
    implementation. So perhaps they should write their own O/S to run
    it on.

    Steve
     
    Steve Horsley, Sep 14, 2005
    #44
  5. If the Linux distro is commercially supported, then surely, the
    Samba that comes with it is, too?

    Steve
     
    Steve Horsley, Sep 14, 2005
    #45
  6. It is my understanding that mere aggregation, such as shipping
    your code on the same CD as Samba, is not creating a "combined
    work". However, if you modified the Samba source, I think you
    would have to open source those modifications. The rest of the
    project that merely used the modified Samba could still be
    private. Unless the main thrust of your project is the file
    system, I don't think this should be a big deal.

    Steve
     
    Steve Horsley, Sep 14, 2005
    #46
  7. sutil83

    sutil83 Guest

    The suggestions to write an in-house fileserver is one I haven't
    thought of. Not sure if there is available manpower/money to do that
    though but it is noted.
    I mentioned in a previous post that Linux isn't actually being used but
    something similar. I just named Linux because if the software is
    compatible with Linux, it will be compatible with this system.
    You can't even imagine!
    Agreements are made with the vendor, and they are asked to make slight
    changes to make their software fit. These aren't big changes but very
    small ones. Nothing ever fits perfectly into project. The closest
    solution is picked and any necessary augmenting is requested. I
    entered in an agreement not long ago and had to do slight modifications
    myself to some proprietary code. Wasn't big, had to change some
    constants here and there in the source. Don't imagine something like
    that having to be done to Samba but its just an example that these
    things happen. With a supplier, these requests can be easily made and
    we can enter into such an agreement and all information is kept between
    the two parties. Can't do that if we need to mod open-source stuff.
     
    sutil83, Sep 14, 2005
    #47
  8. sutil83

    sutil83 Guest

    It is my understanding that mere aggregation, such as shipping
    Well if you use the open-source stuff and mod it a bit and use it as
    part of a bigger program, the entire program becomes open source is
    what I understand from the license. Either way, like I said, its not a
    matter of whether or not I can do it, its that legal/corporate won't
    really allow it plus it would be a big negative in the eyes of the
    client. Having to convince them otherwise is a step back from what I
    am trying to achieve
     
    sutil83, Sep 14, 2005
    #48
  9. So get an open source product and buy commercial support for it. That
    way, if you have any problems with the support company or they go out of
    business, you can still find support for the same product from another
    vendor.
    Well then gosh, you *can't* pick a proprietary product because you
    aren't allowed to re-distribute them. You aren't allowed to modify them
    either.
    Okay, now imagine if you had picked a commercial solution. If a change
    was needed, you'd pretty much be in trouble. If the company refused to do it
    or charged more than you could afford, you'd again just be screwed.
    And commercial software comes with no restrictions, right? Come on.
    If it's commercial and a tune up is needed a decade from now, it may
    well be *impossible*. The product may not be maintained that far and may not
    be compilable anymore. The source code could be lost. The company might not
    have the resources to make it. It's almost totally clear that open source is
    a better choice here.
    What does that mean? If you don't like any changes to Samba, just freeze
    it where it is now. You're no worse off than if you picked a proprietary
    solution that didn't go the direction you wanted it to, and as a plus you'd
    have the option to modify it in the direction you want or at least be able
    to continue to compile the code you liked on new platforms.
    You seem to be insistent on heading right for a fiasco where only the
    original vendor can support you and the original vendor may or may not
    exist, be able to do what you want, or be willing to do it at a price you
    can afford.
    Then for the love of god don't pick a proprietary vendor! What happens
    if they make changes for you, then decide to open source the product. Then
    the changes made for you would become freely distributed! The mere
    possibility is unaccapbled.
    It doesn't work that way. If you want people to accept your word even
    when it's absolutely nonsensical, you'll have to pay them to do it.
    Best of luck. But if you're a consultant of some kind, you have a duty
    IMO to convince the client to be reasonable. It is professional negligence
    to give the client what they say they want when it doesn't make sense, or
    worse, to be unable to spot the obvious flaws in their arguments for what
    they thing they want.

    DS
     
    David Schwartz, Sep 14, 2005
    #49
  10. Yes, but you aren't using it as part of a bigger program. You are using
    it together with other programs.
    Your first job is to make sure the client really knows what they want
    and knows how to get what they really want. If you think it's more important
    to get the client what they think they want, you're a crappy consultant in
    my book. (Assuming you are a consultant.)

    Can you be a bit more specific? Are you intending to provide both the
    server code and the client code? Or do you need to interoperate with an
    existing client? If so, what protocol does it speak?

    Linux has FUSE. And the company I work for has a remote FUSE package
    that we wrote to test some other software of ours. It may be what you need,
    and it's proprietary. It just wraps FUSE requests into simple objects, sends
    them over TCP, performs the FUSE request against a remote filesystem,
    packages the results into simple objects, and sends them back over TCP. It's
    not exactly high-performance, but it works fine. The client requires FUSE,
    the server is fully portable.

    DS
     
    David Schwartz, Sep 14, 2005
    #50
  11. Only if you give it away/sell/etc, as long as you just use it
    inside your corporation you can do whatever you like. Even if,
    it's a good idea to contribute your code back, imagine now you
    could get improvements/bug fixing for your part. Free of course
    just because others are using your software now. ;-)

    This is one of the strongest part of GNU GPL, making it
    impossible to turn it into distributed closed software.

    You could look for *BSD stuff, which hasn't this "limitation".
     
    Michael Heiming, Sep 14, 2005
    #51
  12. sutil83

    sutil83 Guest

    In response to Davide Schwartz:

    In regard to modifying and redistributing the commercial product, its
    not as you think. We use the product and incorporate the code within
    our own. Like I mentioned, there are possible workarounds and it could
    be that we end up using Samba, but for now, I was searching for
    alternatives in case it wasn't. This is a totally different type of
    system than you think for a totally different client. The supplier
    would not be able to open-source any changes because they would break
    an agreement that is entered between us and them.

    And no I'm not a consultant, I'm an engineer in the development phase
    of a project. Which is why I can't provide any further information,
    partly because it's proprietary and partly because it doesn't exist
    yet. All this was meant to do was further a list of options so when
    that information does exist, a choice can be made. Instead of catering
    those choices to this software, we will cater this software to those
    choices.

    Anyway, its time to end this thread, its getting out of hand. I
    realize now that this was the wrong place to look for answers. Not
    intended as an insult or anything to the people here, just we're from
    two different industries. Sadly this just turned out to be a thread
    demonstrating how badly I can communiate my thoughts when I have no
    time and no sleep.

    Thanks
     
    sutil83, Sep 14, 2005
    #52
  13. sutil83

    Keith Keller Guest

    I think that's part of the problem: it seems that the OP may have looked
    for software similar to Samba that's not under the GPL. I don't know of
    any SMB/CIFS servers that are not either proprietary or GPL; if I'm
    right (a medium if), and if the OP's software really is a derivative
    work of the fileserver as defined by the GPL (still, ISTM, a big if),
    then the OP is more or less screwed. NFS is a possibility, but it
    doesn't work the same way SMB/CIFS does.

    --keith
     
    Keith Keller, Sep 15, 2005
    #53
  14. But in response to other posts, this will be re-distributed out of our
    I find it extremely surprising that you imagine that "open-source" is
    different from other forms of software in any meaningful fashion here.

    If you had been looking at this five years ago, Digital PathWorks
    might have appeared 'more viable,' and you would, today, be in the
    situation where Digital kind of doesn't exist anymore.

    Under the circumstances you are describing, I can't see there being
    any satisfactory approach other than for your organization to develop
    its very own server software. The guarantees you seem to find lacking
    in "open-source" software don't seem to me to be any more attainable
    from vendors selling under more traditional "commercial/proprietary"
    licenses.

    No other answer than internal development keeps the choices as clearly
    controlled in your hands.
    Then you're toast. There are no alternatives to offer, and a "more
    proprietary" world wouldn't help. Supposing PathWorks had remained
    commercially viable, the multiplicity of buyouts would probably still
    leave it in a questionable state as a choice.
     
    Christopher Browne, Sep 16, 2005
    #54
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.