Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #15557 > unrolled thread

Local vs. network file

Back to article view | Back to comp.lang.java.programmer

Contents

  Local vs. network file "Qu0ll" <Qu0llSixFour@gmail.com> - 2012-06-25 02:18 +1000
    Re: Local vs. network file Robert Klemme <shortcutter@googlemail.com> - 2012-06-24 18:57 +0200
      Re: Local vs. network file "Qu0ll" <Qu0llSixFour@gmail.com> - 2012-06-25 03:24 +1000
        Re: Local vs. network file Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-06-24 10:49 -0700
          Re: Local vs. network file "Qu0ll" <Qu0llSixFour@gmail.com> - 2012-06-25 04:01 +1000
            Re: Local vs. network file Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-24 14:12 -0400
            Re: Local vs. network file Robert Klemme <shortcutter@googlemail.com> - 2012-06-24 20:20 +0200
            Re: Local vs. network file Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-06-24 14:26 -0500
          Re: Local vs. network file Robert Klemme <shortcutter@googlemail.com> - 2012-06-24 20:14 +0200
            Re: Local vs. network file Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-06-24 13:10 -0700
              Re: Local vs. network file "Qu0ll" <Qu0llSixFour@gmail.com> - 2012-06-28 19:10 +1000
                Re: Local vs. network file Silvio Bierman <silvio@moc.com> - 2012-06-28 11:39 +0200
                Re: Local vs. network file Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-06-28 07:31 -0700
                Re: Local vs. network file Robert Klemme <shortcutter@googlemail.com> - 2012-07-02 19:33 +0200
                  Re: Local vs. network file Joerg Meier <joergmmeier@arcor.de> - 2012-07-02 21:49 +0200
                  Re: Local vs. network file Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-02 16:18 -0400
                    Re: Local vs. network file Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-07-02 13:32 -0700
                      Re: Local vs. network file Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-02 18:32 -0400
                        Re: Local vs. network file Lew <lewbloch@gmail.com> - 2012-07-02 16:25 -0700
                        Re: Local vs. network file Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-07-02 17:35 -0700
                          Re: Local vs. network file Nine of Seventeen <n9seventeen17@gmail.com> - 2012-07-02 21:10 -0400
                            Re: Local vs. network file uBend <d0b@d1b.d1b.null> - 2012-07-02 22:45 -0400
                              Re: Local vs. network file j00sUck <j00-s.U-c_k@gmail.com> - 2012-07-02 22:59 -0400

Page 1 of 2  [1] 2  Next page →

#15557 — Local vs. network file

Is it possible to determine if a given String contains the path of a file on 
a network drive (versus a local file) in Java 7?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me] 

[toc] | [next] | [standalone]

#15559

On 24.06.2012 18:18, Qu0ll wrote:
> Is it possible to determine if a given String contains the path of a
> file on a network drive (versus a local file) in Java 7?

Yes.

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#15560

"Robert Klemme"  wrote in message news:a4ov8oF930U1@mid.individual.net... 

On 24.06.2012 18:18, Qu0ll wrote:
>> Is it possible to determine if a given String contains the path of a
>> file on a network drive (versus a local file) in Java 7?
>
> Yes.

OK, thanks for the confirmation.  How is it done?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me]

[toc] | [prev] | [next] | [standalone]

#15561

On Mon, 25 Jun 2012 03:24:22 +1000, Qu0ll wrote:

> "Robert Klemme"  wrote in message news:a4ov8oF930U1@mid.individual.net... 
> 
> On 24.06.2012 18:18, Qu0ll wrote:
>>> Is it possible to determine if a given String contains the path of a
>>> file on a network drive (versus a local file) in Java 7?
>>
>> Yes.
> 
> OK, thanks for the confirmation.  How is it done?

Actually, I doubt you can do this in a platform-independent way. Even on
Windows, a UNC path (which is normally used to specify a network path) can
refer to a local drive and a drive-letter path can refer to a network
location. You need to use platform-specific calls to tell the difference.

I'm less familiar with the *nix family, but my recollection is that because
of its even-more-generalized file system implementation, the path itself is
of no use. You'd also have to use lower-level OS-specific calls to get that
information.

That said, while it's true that there can be somewhat different i/o
characteristics between local and network files, I'm not convinced a
program should attempt to concern itself with them. As networks become
faster and faster, and more and more reliable, network-specific
restrictions in a program are much less appropriate, and at the same time
while delays and errors on local drives are rare, they can and do occur and
a program should handle them correctly.

Perhaps if you explain why it is you believe you need to know the
difference between a local and a network path, you can get better advice
that addresses your _actual_ problem, rather than does or does not solve
some specific method you've already selected to deal with that problem.

Pete

[toc] | [prev] | [next] | [standalone]

#15562

Sorry about the lack of indentation, reply at the end...

"Peter Duniho"  wrote in message 
news:nb1dv4z3gq48.15acrjvtu4vh2.dlg@40tude.net...

On Mon, 25 Jun 2012 03:24:22 +1000, Qu0ll wrote:

> "Robert Klemme"  wrote in message news:a4ov8oF930U1@mid.individual.net...
>
> On 24.06.2012 18:18, Qu0ll wrote:
>>> Is it possible to determine if a given String contains the path of a
>>> file on a network drive (versus a local file) in Java 7?
>>
>> Yes.
>
> OK, thanks for the confirmation.  How is it done?

Actually, I doubt you can do this in a platform-independent way. Even on
Windows, a UNC path (which is normally used to specify a network path) can
refer to a local drive and a drive-letter path can refer to a network
location. You need to use platform-specific calls to tell the difference.

I'm less familiar with the *nix family, but my recollection is that because
of its even-more-generalized file system implementation, the path itself is
of no use. You'd also have to use lower-level OS-specific calls to get that
information.

That said, while it's true that there can be somewhat different i/o
characteristics between local and network files, I'm not convinced a
program should attempt to concern itself with them. As networks become
faster and faster, and more and more reliable, network-specific
restrictions in a program are much less appropriate, and at the same time
while delays and errors on local drives are rare, they can and do occur and
a program should handle them correctly.

Perhaps if you explain why it is you believe you need to know the
difference between a local and a network path, you can get better advice
that addresses your _actual_ problem, rather than does or does not solve
some specific method you've already selected to deal with that problem.

----------------------------------

Thanks Peter.

I have a requirement to limit a program which is licensed as "stand alone" 
to not be run from a network location so I figured if I could tell whether 
the launch directory was a network share then I could block it.  Is there 
another way I could implement this?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me] 

[toc] | [prev] | [next] | [standalone]

#15563

On 6/24/2012 2:01 PM, Qu0ll wrote:
>[...]
> I have a requirement to limit a program which is licensed as "stand
> alone" to not be run from a network location so I figured if I could
> tell whether the launch directory was a network share then I could block
> it.  Is there another way I could implement this?

     I think you need to go back to the people who imposed the
requirement, and get them to supply a precise definition of
"network share."  Does a NAS count?  It's certainly on a network
but not necessarily shared.  What about iSCSI?  What about
InfiniBand, for that matter?  What about today's favorite
buzzphrase, "the Cloud?"

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15565

On 24.06.2012 20:01, Qu0ll wrote:

> I have a requirement to limit a program which is licensed as "stand
> alone" to not be run from a network location so I figured if I could
> tell whether the launch directory was a network share then I could block
> it.  Is there another way I could implement this?

Ah, now we're cooking!  I am afraid you need to implement a solution for 
every platform your software could be used on.  On *nix you could 
evaluate the output of "mount" to find out, on Windows you probably need 
to look at "net use" etc.  Maybe on POSIX OS there is a system call that 
will help so you could write a JNI extension.

This method certainly helps:
http://docs.oracle.com/javase/6/docs/api/java/io/File.html#getCanonicalFile%28%29

If you want to prevent multiple instances running concurrently from one 
installation you could use a file in the installation location. 
However, proper file locking in a platform independent way is another 
tricky task in Java.

Btw, I don't see how the installation location actually makes a 
difference.  You could still install the program on each system and run 
it multiple times.  Why do you need to prevent running from a network drive?

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#15566

Qu0ll <Qu0llSixFour@gmail.com> wrote:
> 
> Thanks Peter.
> 
> I have a requirement to limit a program which is licensed as "stand alone" 
> to not be run from a network location so I figured if I could tell whether 
> the launch directory was a network share then I could block it.  Is there 
> another way I could implement this?

I'd say that this requirement is a good example of why one should not
dictate a technical solution in the requirements. To require a local
installation is something that made some amount of sense fifteen years
ago or so, but today it's a badly outdated concept. Not only do people
and businesses not use network shares in quite the same way as they
did fiteen years ago, they no longer think of them the same either. 

If politically possible, backtrack to the actual business requirement
and see if you can solve that in a better way.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#15564

On 24.06.2012 19:49, Peter Duniho wrote:

> Actually, I doubt you can do this in a platform-independent way. Even on
> Windows, a UNC path (which is normally used to specify a network path) can
> refer to a local drive and a drive-letter path can refer to a network
> location. You need to use platform-specific calls to tell the difference.

How would an UNC path look that points to a local file / directory?  Or 
did you think of \\local_server_name\any\path ?  AFAIK that would still 
be a network path even though the share would be local.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#15567

On Sun, 24 Jun 2012 20:14:44 +0200, Robert Klemme wrote:

> On 24.06.2012 19:49, Peter Duniho wrote:
> 
>> Actually, I doubt you can do this in a platform-independent way. Even on
>> Windows, a UNC path (which is normally used to specify a network path) can
>> refer to a local drive and a drive-letter path can refer to a network
>> location. You need to use platform-specific calls to tell the difference.
> 
> How would an UNC path look that points to a local file / directory?  Or 
> did you think of \\local_server_name\any\path ?  AFAIK that would still 
> be a network path even though the share would be local.

But that's the problem. Windows isn't under any obligation to route traffic
referencing a local drive over the network, just because a UNC path was
used (i.e. the path looks like a network path).

As Eric and Leif have pointed out, the real issue here is a poor
specification.  It's not really clear why the requirement to not run from a
network drive has been imposed in the first place, but depending on the
motivation for the requirement, it may not be possible to tell simply by
the format of the path whether the requirement has been met or not anyway.

Just as in my original reply, I suggested that Qu0ll explain what goal he's
trying to achieve rather than ask about the specific method for achieving
it, there is a need to backtrack even further.

He's been given a requirement that on the face of it has no obvious
explanation (i.e. not running from a network share does not in and of
itself serve any useful purpose); the author of the requirement needs to
explain what ultimate goal the author is trying to achieve, so that Qu0ll
can then help them achieve _that_ goal in the most sensible way (which most
likely won't involve needing to know whether a given path refers to a local
or network location).

Pete

[toc] | [prev] | [next] | [standalone]

#15710

Reply at the end...

"Peter Duniho"  wrote in message 
news:rbayhr9vyq8c.1csy82qnfcmz3$.dlg@40tude.net...

On Sun, 24 Jun 2012 20:14:44 +0200, Robert Klemme wrote:

> On 24.06.2012 19:49, Peter Duniho wrote:
>
>> Actually, I doubt you can do this in a platform-independent way. Even on
>> Windows, a UNC path (which is normally used to specify a network path) 
>> can
>> refer to a local drive and a drive-letter path can refer to a network
>> location. You need to use platform-specific calls to tell the difference.
>
> How would an UNC path look that points to a local file / directory?  Or
> did you think of \\local_server_name\any\path ?  AFAIK that would still
> be a network path even though the share would be local.

But that's the problem. Windows isn't under any obligation to route traffic
referencing a local drive over the network, just because a UNC path was
used (i.e. the path looks like a network path).

As Eric and Leif have pointed out, the real issue here is a poor
specification.  It's not really clear why the requirement to not run from a
network drive has been imposed in the first place, but depending on the
motivation for the requirement, it may not be possible to tell simply by
the format of the path whether the requirement has been met or not anyway.

Just as in my original reply, I suggested that Qu0ll explain what goal he's
trying to achieve rather than ask about the specific method for achieving
it, there is a need to backtrack even further.

He's been given a requirement that on the face of it has no obvious
explanation (i.e. not running from a network share does not in and of
itself serve any useful purpose); the author of the requirement needs to
explain what ultimate goal the author is trying to achieve, so that Qu0ll
can then help them achieve _that_ goal in the most sensible way (which most
likely won't involve needing to know whether a given path refers to a local
or network location).

--------------------------------------------------------

Sorry for the delay in replying.

The situation is that I have developed some software which the client wishes 
to license as either a stand-alone product or with a network model.  The 
network license permits a fixed maximum number of concurrent users to load 
the software from a single network share.  The stand-alone license permits a 
fixed maximum number of concurrent users to run the software on their local 
machine (the maximum controls the number of concurrent machines on which it 
is running).  It's a pricing and marketing thing; the network license is 
more expensive but doesn't really offer any extra functionality or benefit.

I have implemented a system of license key management where the customer 
name, software version, type of license and max number of concurrent users 
are embedded in a key and that works really well.  Now I have to implement 
some control over the use of the software with a particular license.  I have 
posted in a previous thread about my issues with getting the concurrent user 
control working and it in itself presents quite a challenge, especially 
since the sites that will use this software often have no internet access 
and also have restrictions and security policies on their networks which 
prevent one instance communicating with other instances to verify the number 
concurrently running.

The limited number of responses to the post about network license control 
have not allowed me to resolve that particular issue and now I am trying to 
resolve the other issue of ensuring that the stand alone version is only run 
from a local drive.  I agree this restriction makes little sense but it is 
the requirement I have been given.

If anyone has any further ideas about implementing either network license 
control or control over where the software is launched from I would love to 
hear about them.  Perhaps as an alternative someone could suggest some other 
form of license model that is easier to implement but which also provides 
the ability to ensure that the software is not abused by users running more 
copies than they have paid for.

For network license control I thought about managing a file on the 
installation directory that records the machine names or IP addresses of the 
machines the client is running on and using that to work out how many are 
concurrently running but I couldn't get this to work as the end user does 
not usually have write permission on the directory from where the software 
is launched (i.e. on a network share).  Maybe there is some way to write to 
a writeable location on the launch machine that would be common for all 
users of the software on other machines?  Perhaps I could write to the 
registry on the launch machine if that didn't require admin privileges?

For the issue of control where the software is launched from for the 
stand-alone version I have implemented a system whereby the directory from 
which the software is launched for the first time is recorded in a file on 
the client machine and then checked against for all subsequent launches. 
This means the software can only be run on the client machine when launched 
from its original location which is possibly enough control.

I have to say I am really struggling with these requirements and would very 
much appreciate some input.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me] 

[toc] | [prev] | [next] | [standalone]

#15711

On 06/28/2012 11:10 AM, Qu0ll wrote:
> Reply at the end...

SNIP

>
> The situation is that I have developed some software which the client
> wishes to license as either a stand-alone product or with a network
> model.  The network license permits a fixed maximum number of concurrent
> users to load the software from a single network share.  The stand-alone
> license permits a fixed maximum number of concurrent users to run the
> software on their local machine (the maximum controls the number of
> concurrent machines on which it is running).  It's a pricing and
> marketing thing; the network license is more expensive but doesn't
> really offer any extra functionality or benefit.

That is a strange license scheme that might have sounded reasonable in 
the 19xx years. Why make the distinction at all?

On common OS-es like Windows and *nix a path to a resource on what you 
call a "network share" can take the exact same form as one that is 
located on what you call the "local machine". I do not think you will 
have any luck working on paths only.

You could setup some file locking scheme, akin to what H2SQL does with 
embedded database connections. This disallows accessing the same 
resource (which in the H2 case is a database) from more than one running 
process at the same time.
However, this simply limits the number of concurrent uses of a single 
installation to 1. It does not prevent running from a remote location 
and it does not prevent running the same installation from different 
locations at different points in time. In fact, this would simply 
implement a network license for N=1.

[toc] | [prev] | [next] | [standalone]

#15718

On Thu, 28 Jun 2012 19:10:02 +1000, Qu0ll wrote:

> The situation is that I have developed some software which the client wishes 
> to license as either a stand-alone product or with a network model.  The 
> network license permits a fixed maximum number of concurrent users to load 
> the software from a single network share.  The stand-alone license permits a 
> fixed maximum number of concurrent users to run the software on their local 
> machine (the maximum controls the number of concurrent machines on which it 
> is running).  It's a pricing and marketing thing; the network license is 
> more expensive but doesn't really offer any extra functionality or benefit.

So why would any customer even opt for that license?  Spend more money to
gain no extra functionality or benefit?


If your client told you that they needed for the software to support
flights to the moon, you'd be perfectly justified in explaining that
software alone can't accomplish that.

Likewise, at some point you need to be able to draw a line with your
client.  The client is not _always_ right, and they need a professional who
can help them see the boundary between useful and feasible functionality,
and silly wastes of time.

> I have implemented a system of license key management where the customer 
> name, software version, type of license and max number of concurrent users 
> are embedded in a key and that works really well.  Now I have to implement 
> some control over the use of the software with a particular license.  I have 
> posted in a previous thread about my issues with getting the concurrent user 
> control working and it in itself presents quite a challenge, especially 
> since the sites that will use this software often have no internet access 
> and also have restrictions and security policies on their networks which 
> prevent one instance communicating with other instances to verify the number 
> concurrently running.

For what it's worth, I haven't seen any follow-up from you to your original
network-based license scheme thread that discusses those things.  Are you
sure your post made it through?

> The limited number of responses to the post about network license control 
> have not allowed me to resolve that particular issue and now I am trying to 
> resolve the other issue of ensuring that the stand alone version is only run 
> from a local drive.  I agree this restriction makes little sense but it is 
> the requirement I have been given.

I believe that I or someone else did point out that the network-based
license scheme is limited to identifying program instances running within a
specific LAN. There's nothing to stop someone from installing the program
on different subnets between which broadcasts/multicasts aren't routed, and
of course for sure it won't work between different Internet endpoints.

Furthermore, without a huge amount of extra work on your part, it's not
very difficult for someone to bypass any licensing enforcement altogether.
It doesn't matter what you implement, if a determined person can simply
disable that part of your code.

You can invest that huge amount of extra work if you like, but that still
won't stop a _skilled_, determined person.  It's simply not possible to do
that.  The best you can hope for is to invest far too much time and effort
in protecting your software than is economically rational, so that the
protection on the software exceeds whatever value someone else might gain
from bypassing the protection.

In other words, the only way to ensure the program won't be used without a
license is to spend far more money on that protection than is actually
justified by whatever economic loss might be at risk.  It's an arms race of
sorts, and the hackers have the inherent economic advantage.

I realize that for you, as the contractor assigned the task, more work is
more income.  But a good professional knows when to advise their client to
stop throwing their money away.  IMHO, you have reached that point here and
should be putting your effort in explaining to your client why what they
ask for is not practical.

Pete

[toc] | [prev] | [next] | [standalone]

#15787

On 28.06.2012 11:10, Qu0ll wrote:

> The situation is that I have developed some software which the client
> wishes to license as either a stand-alone product or with a network
> model.  The network license permits a fixed maximum number of concurrent
> users to load the software from a single network share.  The stand-alone
> license permits a fixed maximum number of concurrent users to run the
> software on their local machine (the maximum controls the number of
> concurrent machines on which it is running).  It's a pricing and
> marketing thing; the network license is more expensive but doesn't
> really offer any extra functionality or benefit.

Err, why would anyone want to pay more for the network share license? 
Maybe I am missing something but I don't understand the business case here.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#15788

On Mon, 02 Jul 2012 19:33:54 +0200, Robert Klemme wrote:

> On 28.06.2012 11:10, Qu0ll wrote:
>> The situation is that I have developed some software which the client
>> wishes to license as either a stand-alone product or with a network
>> model.  The network license permits a fixed maximum number of concurrent
>> users to load the software from a single network share.  The stand-alone
>> license permits a fixed maximum number of concurrent users to run the
>> software on their local machine (the maximum controls the number of
>> concurrent machines on which it is running).  It's a pricing and
>> marketing thing; the network license is more expensive but doesn't
>> really offer any extra functionality or benefit.
> Err, why would anyone want to pay more for the network share license? 
> Maybe I am missing something but I don't understand the business case here.

Collusion ?

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#15789

On 7/2/2012 1:33 PM, Robert Klemme wrote:
> On 28.06.2012 11:10, Qu0ll wrote:
>
>> The situation is that I have developed some software which the client
>> wishes to license as either a stand-alone product or with a network
>> model.  The network license permits a fixed maximum number of concurrent
>> users to load the software from a single network share.  The stand-alone
>> license permits a fixed maximum number of concurrent users to run the
>> software on their local machine (the maximum controls the number of
>> concurrent machines on which it is running).  It's a pricing and
>> marketing thing; the network license is more expensive but doesn't
>> really offer any extra functionality or benefit.
>
> Err, why would anyone want to pay more for the network share license?
> Maybe I am missing something but I don't understand the business case here.

     It might be more economical to support N occasional users with
M << N expensive "floating" licenses than to buy N cheaper dedicated
licenses and see them sit unused most of the time.

http://lmgtfy.com/?q=floating+license

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15790

On Mon, 02 Jul 2012 16:18:59 -0400, Eric Sosman wrote:

>>> [...] The stand-alone
>>> license permits a fixed maximum number of concurrent users to run the
>>> software on their local machine (the maximum controls the number of
>>> concurrent machines on which it is running).  It's a pricing and
>>> marketing thing; the network license is more expensive but doesn't
>>> really offer any extra functionality or benefit.
>>
>> Err, why would anyone want to pay more for the network share license?
>> Maybe I am missing something but I don't understand the business case here.
> 
>      It might be more economical to support N occasional users with
> M << N expensive "floating" licenses than to buy N cheaper dedicated
> licenses and see them sit unused most of the time.

Except that the OP has already stated that the license covers _concurrently
running instances_ and not installed machines.  In that scenario, the
licensee has no real reason to pay more for a "network" license than a
"standalone" one, because they only need to license standalone instances
that are running either way (i.e. they don't need more licenses than would
actually be running at a given time).

> http://lmgtfy.com/?q=floating+license

Because the phrase "floating license" was used by the OP and so of course
someone would know to use that phrase for a web search, right?

Oh, right...the OP didn't ever use that phrase.

Come on...I know it's fun to use "lmgtfy.com" but it just comes across as
you being petty when a) your point doesn't apply and b) you use a phrase
the person wouldn't have any reason to know to use in the first place.

Pete

[toc] | [prev] | [next] | [standalone]

#15791

On 7/2/2012 4:32 PM, Peter Duniho wrote:
> On Mon, 02 Jul 2012 16:18:59 -0400, Eric Sosman wrote:
>
>>>> [...] The stand-alone
>>>> license permits a fixed maximum number of concurrent users to run the
>>>> software on their local machine (the maximum controls the number of
>>>> concurrent machines on which it is running).  It's a pricing and
>>>> marketing thing; the network license is more expensive but doesn't
>>>> really offer any extra functionality or benefit.
>>>
>>> Err, why would anyone want to pay more for the network share license?
>>> Maybe I am missing something but I don't understand the business case here.
>>
>>       It might be more economical to support N occasional users with
>> M << N expensive "floating" licenses than to buy N cheaper dedicated
>> licenses and see them sit unused most of the time.
>
> Except that the OP has already stated that the license covers _concurrently
> running instances_ and not installed machines.  In that scenario, the
> licensee has no real reason to pay more for a "network" license than a
> "standalone" one, because they only need to license standalone instances
> that are running either way (i.e. they don't need more licenses than would
> actually be running at a given time).

     One of the things the O.P. actually wrote was

	"The network license permits a fixed maximum number of
	concurrent users to load the software from a single network
	share.  The stand-alone license permits a fixed maximum number
	of concurrent users to run the software on their local machine
	(the maximum controls the number of concurrent machines on
	which it is running)."

     Okay, the description is not exactly clear.  But one thing that
*is* clear is that two kinds of licenses are contemplated.  As I read
it (and/or guess at it), a "stand-alone" license is tied to a specific
machine, and allows up to N concurrent usages on that machine.  For
a workstation, N is probably 1.  For a server, N may be greater.  But
if machine X is using all N licenses while machine Y is using none,
Y can't lend a license to X.

     The "network" license, on the other hand, allows up to N concurrent
usages across the entire "network" (however that's defined).  It doesn't
matter which machine(s) are being used, so if Y hasn't claimed a license
X can do so.

     Fine, lots of guesswork from an incomplete description.  But IMHO
the guesswork is plausible, and answers Robert Klemme's question.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15792

On Monday, July 2, 2012 3:32:40 PM UTC-7, Eric Sosman wrote:
> ... [snip] ...
>      One of the things the O.P. actually wrote was
> 
> 	"The network license permits a fixed maximum number of
> 	concurrent users to load the software from a single network
> 	share.  The stand-alone license permits a fixed maximum number
> 	of concurrent users to run the software on their local machine
> 	(the maximum controls the number of concurrent machines on
> 	which it is running)."
> 
>      Okay, the description is not exactly clear.  But one thing that
> *is* clear is that two kinds of licenses are contemplated.  As I read
> it (and/or guess at it), a "stand-alone" license is tied to a specific
> machine, and allows up to N concurrent usages on that machine.  For
> a workstation, N is probably 1.  For a server, N may be greater.  But
> if machine X is using all N licenses while machine Y is using none,
> Y can't lend a license to X.
> 
>      The "network" license, on the other hand, allows up to N concurrent
> usages across the entire "network" (however that's defined).  It doesn't
> matter which machine(s) are being used, so if Y hasn't claimed a license
> X can do so.
> 
>      Fine, lots of guesswork from an incomplete description.  But IMHO
> the guesswork is plausible, and answers Robert Klemme's question.

Let's say for the sake of argument that your description doesn't yet
match what the OP is doing. You have in the last few posts introduced 
new ideas (floating vs. fixed license, for example) that the OP should 
find extremely helpful. Ditto future readers of this thread, including me.

One thing is clear and unequivocal - if the OP's employer is no better at 
explaining the value proposition of the "network" license than is the OP, 
their customers will not be able to suss it out either.

I agree with earlier posters that the license scheme as described, even if 
it adopts the refinements you describe, sucks.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15794

On Mon, 02 Jul 2012 18:32:40 -0400, Eric Sosman wrote:

>      One of the things the O.P. actually wrote was
> 
> 	"The network license permits a fixed maximum number of
> 	concurrent users to load the software from a single network
> 	share.  The stand-alone license permits a fixed maximum number
> 	of concurrent users to run the software on their local machine
> 	(the maximum controls the number of concurrent machines on
> 	which it is running)."
> 
>      Okay, the description is not exactly clear.  But one thing that
> *is* clear is that two kinds of licenses are contemplated.  As I read
> it (and/or guess at it), a "stand-alone" license is tied to a specific
> machine, and allows up to N concurrent usages on that machine.

Since he wrote "on THEIR machine" [emphasis mine], why would you then
assume he meant "on THAT machine"?

His original question involved separate installed instances of the program,
limited in concurrency to a given number on a given LAN.  His follow-up
discussion of the "network license" pertains to instances of the program
run from a network share.

At the very least, you might want to simply consider apologizing for the
petty nature of your previous reply, instead of putting in more effort
rationalizing it.  Even if your interpretation is correct (and I think
that's debatable), by your own admission there is certainly some ambiguity
justifying Robert's take on the question.

I'll readily grant that some people are in need of a condescending "Let Me
Google That For You", but I really don't see how that was called for here,
especially since the phrase you expected Robert to search for had never
been mentioned in the entire discussion.

Pete

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web