The problem is the different privacy practices of the WiFi network operator. For example, my company intentionally has open WiFi covering public areas of our office park. But, I don't want my personal calls there because our IT department can monitor this network (and my employment agreement gives my consent). They might be doing traffic analysis and flagging calls to competitors, etc. (maybe I'm setting up a job interview). Conversely, communication with a Verizon tower from my Verizon phone in the parking lot is (in practice) safe from monitoring by my company, and also safe from casual eavesdroppers.
Similarly, I don't want my calls moved from Verizon's CDMA network to the Fred's Cafe WiFi, where Fred happens to be sitting in the kitchen with a VoIP sniffer.
When I set up my home library a few years ago, I used Thokbook from http://thokbook.sourceforge.net/ - it had a simple installation and a fast command-line interface. I finished all forty of my shelves in one day, and that included some unpacking time.
This 16 year old has one of the best insights into what customers actually want. It's too bad that the computer industry arbitrarily excludes under-18 persons from most important events. For example, for the FOSE show today in DC, the literature at http://www.fose.com/index.cfm?fuseaction=Custom.Co ntent&MenuID=1007 says
"No one under 18 is admitted, regardless of affiliation or
circumstance."
Other events seem mostly the same, and yes it might be a venue requirement, but really that's no excuse. We need to let them in and talk with them (especially if it's a school vacation week!)
Yes, of course you needed to sign those for the past 20 years. The issue is that, for a company to remain competitive at attracting the best talent in the future, it needs to realize that home life sometimes extends into the workday and the workplace, just as work life sometimes extends into off hours at home. Home life today may be mostly covered by telephone calls and standard software, but won't be in the future. Employees absolutely will need to use software of their choice while at work. Everyone will expect that the network is ubiquitous and adaptable to their needs. The open question is what is the most cost-effective way to manage the risk - loading the software onto the one company PC on your desk, separate company-provided PCs: one for proprietary data and one for everything else, virtual machines, other data isolation, relying on individually owned devices and cellular data networks for all "personal use," etc., etc.
If he received SMS messages via Google Send to Phone, Google might have the contents, which could be useful in tracking down why they occurred. I didn't see anything saying that Verizon stores the contents of SMS messages, or whether they'd be willing to do this. http://toolbar.google.com/firefox/extensions/sendt ophone/faq.html says
"When you send a message using Google Send to Phone... we
might also log the text of the message you send, in order to
investigate and correct technical problems with the service."
About half of all banks that send legitimate e-mail send it from a host they don't have their domain name on, in my experience. I don't have a bank message in my current inbox but Discover Card, for example, sends e-mail from arm149.bigfootinteractive.com. The bigfootinteractive.com web site (which I believe is legitimate) says it's a "leading provider of strategic, ROI-focused email communications solutions."
Actual banks, credit unions, etc. use similar e-mail outsourcing. The messages that give me short https URLs are useful in some cases. But mostly they give http URLs to the bank's web site, or worse, http URLs to a legitimate but different domain (such as a domain ending in ".m0.net").
Actually my concern was about section 5, not section 1.
The vendor wanted to ship a non-GPL shell script. One small part of the shell script executes Gnu ls. Gnu ls is considered a "Program" that is a "covered work." The combination of the shell script and Gnu ls is a "work based on the Program."
The relevant line in the script uses the -S option to ls, and won't work without Gnu ls (in my scenario 2). Thus, the vendor must be shipping the script "for use in combination with covered works."
This is, I think, a GPLv3 violation.
I suppose this opens the question of whether, for example, the Linux version of Adobe Reader is "for use in combination with covered works" in the sense that it requires the Linux kernel. But I believe this situation is much easier to clarify, if necessary. A non-GPL program that relies on executing a GPL program is the more difficult scenario.
Suppose I develop a closed-source OS that ships the Gnu ls source and a binary (/usr/local/bin/ls). Within my OS, I have a large non-GPL shell script that generates reports about system usage. It has the line:
ls -lS | head -10 | mail -s "largest files" root
(Note that -S is the "sort by file size" option, which Gnu ls has, but many other ls programs don't have.) Consider two scenarios:
(1) My OS has a non-GPL/bin/ls that was developed independently of
Gnu ls but does recognize -S. Therefore the script works regardless
of whether/bin or/usr/local/bin is first in the script's path.
(2) My OS has a non-GPL/bin/ls that does not recognize -S. The script
works only if/usr/local/bin is first in the script's path.
My reading is that scenario (2) is a GPL violation, according to the "But when you distribute the same sections for use in combination with covered works" clause. Scenario (1) is not a GPL violation.
I suspect the GPLv3's intent here is to prohibit a closed-source program that accomplishes the bulk of its work by executing a GPL program and reformatting its outputs (e.g., displaying them within an extensive non-GPL GUI). The actual stipulation is that a non-GPL program cannot rely on the existence of a GPL program for even a very minor task. With GPLv3, GPL software becomes much less useful on a closed-source OS, unless the user would be manually interacting with the GPL program without any vendor-supplied scripting.
Slashdot Mirror
The problem is the different privacy practices of the WiFi network
operator. For example, my company intentionally has open WiFi covering
public areas of our office park. But, I don't want my personal calls
there because our IT department can monitor this network (and my
employment agreement gives my consent). They might be doing traffic
analysis and flagging calls to competitors, etc. (maybe I'm setting
up a job interview). Conversely, communication with a Verizon tower
from my Verizon phone in the parking lot is (in practice) safe from
monitoring by my company, and also safe from casual eavesdroppers.
Similarly, I don't want my calls moved from Verizon's CDMA network to
the Fred's Cafe WiFi, where Fred happens to be sitting in the kitchen
with a VoIP sniffer.
When I set up my home library a few years ago, I used Thokbook from
http://thokbook.sourceforge.net/ - it had a simple installation and a
fast command-line interface. I finished all forty of my shelves in one
day, and that included some unpacking time.
This 16 year old has one of the best insights into what customerso ntent&MenuID=1007
actually want. It's too bad that the computer industry arbitrarily
excludes under-18 persons from most important events. For example, for
the FOSE show today in DC, the literature at
http://www.fose.com/index.cfm?fuseaction=Custom.C
says
"No one under 18 is admitted, regardless of affiliation or
circumstance."
Other events seem mostly the same, and yes it might be a venue
requirement, but really that's no excuse. We need to let them in and
talk with them (especially if it's a school vacation week!)
http://archives.seul.org/or/talk/Mar-2005/msg00018 .html
Yes, of course you needed to sign those for the past 20 years. The
issue is that, for a company to remain competitive at attracting the
best talent in the future, it needs to realize that home life
sometimes extends into the workday and the workplace, just as work
life sometimes extends into off hours at home. Home life today may be
mostly covered by telephone calls and standard software, but won't be
in the future. Employees absolutely will need to use software of their
choice while at work. Everyone will expect that the network is
ubiquitous and adaptable to their needs. The open question is what is
the most cost-effective way to manage the risk - loading the software
onto the one company PC on your desk, separate company-provided PCs:
one for proprietary data and one for everything else, virtual
machines, other data isolation, relying on individually owned devices
and cellular data networks for all "personal use," etc., etc.
If he received SMS messages via Google Send to Phone, Google mightt ophone/faq.html says
... we
have the contents, which could be useful in tracking down why they
occurred. I didn't see anything saying that Verizon stores the
contents of SMS messages, or whether they'd be willing to do this.
http://toolbar.google.com/firefox/extensions/send
"When you send a message using Google Send to Phone
might also log the text of the message you send, in order to
investigate and correct technical problems with the service."
Check your monthly statement to confirm the total cost of $59.99. If
.10 .55
you see something like the following, be sure to question it:
Verizon Wireless surcharges
Fed Universal Service Charge $.50
Regulatory Charge
Administrative Charge
FCC Modem Tax (Bill 602P) 44.95
Subtotal 46.10
Total Verizon Wireless surcharges $46.10
About half of all banks that send legitimate e-mail send it from
a host they don't have their domain name on, in my experience.
I don't have a bank message in my current inbox but Discover Card,
for example, sends e-mail from arm149.bigfootinteractive.com. The
bigfootinteractive.com web site (which I believe is legitimate) says
it's a "leading provider of strategic, ROI-focused email
communications solutions."
Actual banks, credit unions, etc. use similar e-mail outsourcing.
The messages that give me short https URLs are useful in some
cases. But mostly they give http URLs to the bank's web site, or
worse, http URLs to a legitimate but different domain (such as
a domain ending in ".m0.net").
Actually my concern was about section 5, not section 1.
The vendor wanted to ship a non-GPL shell script. One small part of
the shell script executes Gnu ls. Gnu ls is considered a "Program"
that is a "covered work." The combination of the shell script and Gnu
ls is a "work based on the Program."
The relevant line in the script uses the -S option to ls, and won't
work without Gnu ls (in my scenario 2). Thus, the vendor must be
shipping the script "for use in combination with covered works."
This is, I think, a GPLv3 violation.
I suppose this opens the question of whether, for example, the Linux
version of Adobe Reader is "for use in combination with covered works"
in the sense that it requires the Linux kernel. But I believe this
situation is much easier to clarify, if necessary. A non-GPL program
that relies on executing a GPL program is the more difficult scenario.
Suppose I develop a closed-source OS that ships the Gnu ls source and
/bin/ls that was developed independently of /bin or /usr/local/bin is first in the script's path.
/bin/ls that does not recognize -S. The script /usr/local/bin is first in the script's path.
a binary (/usr/local/bin/ls). Within my OS, I have a large non-GPL shell
script that generates reports about system usage. It has the line:
ls -lS | head -10 | mail -s "largest files" root
(Note that -S is the "sort by file size" option, which Gnu ls has, but
many other ls programs don't have.) Consider two scenarios:
(1) My OS has a non-GPL
Gnu ls but does recognize -S. Therefore the script works regardless
of whether
(2) My OS has a non-GPL
works only if
My reading is that scenario (2) is a GPL violation, according to the
"But when you distribute the same sections for use in combination with
covered works" clause. Scenario (1) is not a GPL violation.
I suspect the GPLv3's intent here is to prohibit a closed-source
program that accomplishes the bulk of its work by executing a GPL
program and reformatting its outputs (e.g., displaying them within an
extensive non-GPL GUI). The actual stipulation is that a non-GPL
program cannot rely on the existence of a GPL program for even a very
minor task. With GPLv3, GPL software becomes much less useful on a
closed-source OS, unless the user would be manually interacting with
the GPL program without any vendor-supplied scripting.