As a point of fact, the GPL does not "specifically allow[]" you to make the source code available only to users who pay for a binary version. GPLv2 offers three choices when distributing a binary work covered by its terms: 3(a) accompany the binary version with the source code; 3(b) accompany the binary version with an offer to provide the source code to anyone, at no more than your cost to distribute the source; or 3(c) -- for non-commercial redistribution of binary forms -- with the same offer that one received according to 3(b).
What is "actual instantaneous amortized cost" supposed to mean? $3.99 is certainly not his marginal cost -- and I am confident it's more than his overall amortized cost for the resources involved -- and requiring someone to pay for a binary version before you fulfill their request for source code is certainly not compliant with the wording of the GPL.
Okay, I spent the $3.99. As far as I can tell, the binary install does not include source code; the only related file I can find is an 8.5 MB binary blob, apparently encrypted (it's in an ".android_secure" directory and "strings" doesn't show any apparent English text). When the application runs, it does not appear to provide any link to the corresponding source code, or any contact information to request the source code. The only way I found to contact the distributor is to go through Google Play. So: Do you still think this turkey complies with the GPL?
So, I did pay the $3.99 for DOSBox Turbo, installed it on my phone, and moved it to the SD card. When mounting that as a disk drive, the only thing I can see related to "dosbox" is.../.android_secure/com.fishstix.dosbox-1.asec, an 8.5 MB binary file that is apparently encrypted. When I run the application itself, it does not include anything that looks like a link or other offer to the corresponding source code. My conclusion: This is a clear and blatant violation of both the letter and the spirit of the GPL. Now will you admit that you're wrong?
I have never claimed that a link is the source code -- a link is also not the binary form. Debian provides equivalent access to the source and binary packages; for convenience, the installer software only accesses the binary packages, but that does not affect their compliance.
The DOSBox Turbo distributor provides neither source code, nor a written offer to provide the source code, for the work that he distributes. That work is derived from a GPLv2-licensed work, and his failure to comply with the terms of the GPLv2 is the violation.
I would rather say that the GPL draws a distinction between "free as in beer" and "free as in freedom", explicitly recognizing the importance of the latter. The DOSBox Turbo web site's explanation of why it is "not free" does not even mention the freedom aspect, which is why I think it is inconsistent with the spirit of the GPL (in addition to being apparently in violation of the letter of the GPL). Stop with the apologetics for GPL violations!
A distributor of a binary using GPLv2 section 3(b) only has to provide the written offer (for source code) when they distribute the binary -- but that offer must allow any third party, whether the third party received a copy of the binary or not, to get complete machine-readable source code corresponding to the binary at the "cost of physically performing source distribution". It is flatly incorrect to say "only when you receive the binary you are legally entitled to also get the source code".
A link is not the source code; it is more like an offer to provide source code later. One must do something more than provide a URL to satisfy section 3(a) of the GPLv2. For example, Debian handles it by having source packages on the same servers as the corresponding binary packages -- this satisfies Debian that the source and binary packages are on the same "medium customarily used for software interchange", and that the user has a sufficient chance to download the source code for any binary they get. For something like Google Play, it does not seem feasible for a user to find source code for a given app package unless the source code gets installed at the same time as the binary (and it is later reasonably easy for the user to read that source code).
The DOSBox Turbo web page says that it is licensed under the GPL, and also has a FAQ explaining why it is "not free". That does not seem like compliance with the spirit of the GPL. If you think he does complying with either the spirit or the letter of the GPL, why don't you pay $3.99 to confirm your guess?
I don't want to spend $3.99 because it seems too likely -- based on what others have done in similar situations in the past -- that he would not provide complete corresponding source code for his version and/or he would claim that some of his extensions are under GPL-incompatible licenses (such as "all rights reserved"); whether that is the case or not, I would not get $3.99 worth of value (to me) from either the binary or the source code of the app.
GPLv2 says that it must be in a machine-readable form on a medium customarily used for software interchange, and that the cost charged for a copy of the source code must not exceed the "cost of physically performing source distribution". This prohibits additional considerations such as the diamond-encrusted USB key or employing a large number of Vatican virgins.
The company's probable legal reasoning would be that it merely provides the employee with access to a company-owned system that includes the software, which would mean that the company has not distributed the software within the meaning of the GPLv2. This kind of claim is only tenable where the company owns the system (or perhaps in some other cases where the individual in question is acting as an agent of the company, under the usual laws of agency); it would not hold if a copyright owner wanted to press a case against a "private members area", regardless of how the latter tried to constitute or describe itself.
The GPLv2 is not deficient in the manner you claim, at least in this case. This is a commercial distribution in a binary form, which means section 3(c) cannot apply. If installing the binary form also installs the complete corresponding source code, then the distributor satisfies section 3(a). If it does not, he must comply with section 3(b), which allows any third party to request the (complete corresponding) source code. The implication from the article summary is that 3(b) does apply, and that $3.99 is more than the "cost of physically performing source distribution" -- a blank CD plus US postage for same is certainly less than that.
I, for one, am not willing to pay $3.99 for an experiment where the outcome seems so likely to be unrewarding. I would guess that the source code would be incomplete and/or would not correspond to the version that one can get through Google Play, and that the distributor would also claim a GPLv2-incompatible license for some of the Android-specific bits. Because I do not hold a copyright that would be infringed in such a case, it is not worth my time or money to confirm my guess. Even if that guess were wrong, I would not get $3.99 worth of value from either the source or binary form of the app.
Your position is that the DOSBox Turbo app installs its source code along with the binaries? If so, where? If not, how does the source code accompany the binary form?
3(b) says the binary-form distributor must include "a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code". The "any third party" directly rebuts your claim about only having to give source code to the people he gave binaries to. The qualifier "physically" is apparently to preclude charges for the associated labor and to prevent overcharges for the medium or shipping. (Similarly, the GPL demands that the medium must be "customarily used for software interchange" -- which means the distributor has some limits on his choice there.) I do not expect to ever argue that in court, so you will probably be disappointed there as well, but you are free to ask a lawyer whether your interpretation or mine is more defensible.
Google's agency and role in these exchanges are an interesting but separate question.
The AC had it right -- one must choose one of 3(a), 3(b) or 3(c) when one distributes a binary form of the work. It seems clear that the "DOSBox Turbo" distributor is not using 3(a) and is not eligible to use 3(c). If he wishes to comply with GPLv2, then, he must choose 3(b), and his written offer to provide source code must be valid for any third party. $3.99 is clearly not the distributor's cost to perform source distribution.
Sure -- but there are a bunch of hiring managers who haven't realized that yet. And a lot of the rest can hire the dime-a-dozen types to offload work from the better-compensated competent people.
I would say that you're the one who needs to get the point. Major components that crash will still generally leave the system in a state that is difficult or impractical to diagnose or recover. If your disk driver or filesystem daemon crashes, you don't have many ways to log in or start a replacement instance. If your network card driver or TCP/IP stack crashes, you still need a remote management console to fix that web server. In the mean time, people with modern kernels have figured out how to make those monolithic kernels still fairly usable in spite of panics or other corruption. The only reason that microkernels look better on the metrics you claim is that they support less hardware and use less of the hardware's complex (high-performance) features.
Microkernels are long on the "security and accountability" hype and somewhat short on reality. Sure, the services provided by the microkernel are less likely to have bugs or holes than a monolithic kernel -- but that's because the microkernel doesn't provide most of the monolithic kernel's functionality. Once you roll in all the device drivers, network stack, and the rest, the microkernel-based system is generally at least as bloated and typically less performant.
The US has defaulted on sovereign debt a number of times in the past. However, it's not likely that the government would do something default-like regarding the "trust fund" bonds. Among other not-default mechanisms, the government could cut or even eliminate benefits in those programs so that SSA and CMS never need to redeem them; that was the point of Flemming v. Nestor.
As a side note, you could eliminate all US military spending from the budget and still leave a sizable deficit. Social Security is getting close to the size of the military budget, as is Medicare. Those slices of the budget are growing rapidly -- and with no real end in sight, which is why entitlement reform is critical to controlling the deficit.
Your -UK suffix is showing. In the US, Social Security is collected by the federal (central) government. That government writes contracts for approximately none of the "basic infrastructure" you describe. Yes, it subsidizes road construction by the states, but things like power generation and delivery are mostly performed by private companies with oversight by state regulators; private rail freight companies subsidize the national passenger rail company; and so forth. States (and localities such as counties, towns and cities) collect taxes independently of the federal government, and the federal government has no real ability to collect money directly from state or local governments.
"Hollywood accounting methods"? Are you talking about the Social Security and Medicare "trust fund" gimmick? If so, that supports Solandri's point: Because people were willing to pretend that FICA are not ordinary taxes, and that payroll taxes went into some special pool of money, it was easier to use FICA surpluses to subsidize deficits in the rest of the budget. If you're talking about something else, perhaps you should be more specific.
If you think that Social Security or Medicare are "earned benefits", that boat sailed 50 years ago; the Supreme Court disagreed with you in 1960 (Flemming v. Nestor). Recently, President (George W.) Bush wanted to give each worker a real retirement account where the worker would have ownership, but your side threw an epic fit over the proposal (for transparently bad reasons).
If you think 1950's-style tax rates would be an effective solution, you've been reading too much Paul Krugman without engaging your brain. If you think bringing one or two hundred thousand deployed servicemen and servicewomen back home -- given the general economic climate, with the likely effect of dumping either them or others into unemployment -- would solve the budget deficit, you again haven't given the matter enough thought.
Usually a meeting of the minds is indicated by explicit compromises -- or at least negotiation. Ambiguity in contracts of adherence (also called standard form contracts or boilerplate contracts), where one party has no realistic option to negotiate terms, is supposed to be construed against the interests of the party who offered the contract.
AT&T most certainly care about the structure of the data on their network. They designed the thing -- including deciding what encapsulation to use inside their network. The user has neither insight into nor control over what is going on, so AT&T should have to describe their metering methodology, make it roughly consistent with what an end user can measure, or both. Anything else is tantamount to AT&T saying "trust us -- we have a track record of screwing up customer bills, but yours are juuuust fine".
If AT&T were honest about bandwidth costs, potential customers would at least be able to compare competing services. Customers can't do that if AT&T comes along and secretly gooses the bandwidth consumption in order to inflate the bill.
Including ATM overhead, and probably even just the AAL5 overhead, would probably be grounds for a lawsuit because that overhead is an artifact of AT&T's network design that is invisible to the user and out of the user's control. What would you do if a shipper charged you by the pound to ship a box and then also billed you for the weight of a hand truck that they decided to send along for their own convenience in handling your package?
Unless someone is sending an awful lot of really small packets, the 40+ bytes of TCP/IP headers per packet are not going to add 20-30% to the data that is being sent. For example, the "Simple IMIX" as defined on WIkipedia has 58% of packets being 40 bytes long (they are common because they represent data acknowledgments with no data going in the other direction), probably significantly underweights the number of 1500-byte MTUs, and still only has ~12% TCP/IP overhead. It would be grossly inappropriate for AT&T to include any packet overhead beyond TCP/IP because any lower level overhead is an artifact of AT&T's network design that is outside the control of, and opaque to, the end user.
Slashdot Mirror
As a point of fact, the GPL does not "specifically allow[]" you to make the source code available only to users who pay for a binary version. GPLv2 offers three choices when distributing a binary work covered by its terms: 3(a) accompany the binary version with the source code; 3(b) accompany the binary version with an offer to provide the source code to anyone, at no more than your cost to distribute the source; or 3(c) -- for non-commercial redistribution of binary forms -- with the same offer that one received according to 3(b).
What is "actual instantaneous amortized cost" supposed to mean? $3.99 is certainly not his marginal cost -- and I am confident it's more than his overall amortized cost for the resources involved -- and requiring someone to pay for a binary version before you fulfill their request for source code is certainly not compliant with the wording of the GPL.
Okay, I spent the $3.99. As far as I can tell, the binary install does not include source code; the only related file I can find is an 8.5 MB binary blob, apparently encrypted (it's in an ".android_secure" directory and "strings" doesn't show any apparent English text). When the application runs, it does not appear to provide any link to the corresponding source code, or any contact information to request the source code. The only way I found to contact the distributor is to go through Google Play. So: Do you still think this turkey complies with the GPL?
So, I did pay the $3.99 for DOSBox Turbo, installed it on my phone, and moved it to the SD card. When mounting that as a disk drive, the only thing I can see related to "dosbox" is .../.android_secure/com.fishstix.dosbox-1.asec, an 8.5 MB binary file that is apparently encrypted. When I run the application itself, it does not include anything that looks like a link or other offer to the corresponding source code. My conclusion: This is a clear and blatant violation of both the letter and the spirit of the GPL. Now will you admit that you're wrong?
I have never claimed that a link is the source code -- a link is also not the binary form. Debian provides equivalent access to the source and binary packages; for convenience, the installer software only accesses the binary packages, but that does not affect their compliance.
The DOSBox Turbo distributor provides neither source code, nor a written offer to provide the source code, for the work that he distributes. That work is derived from a GPLv2-licensed work, and his failure to comply with the terms of the GPLv2 is the violation.
I would rather say that the GPL draws a distinction between "free as in beer" and "free as in freedom", explicitly recognizing the importance of the latter. The DOSBox Turbo web site's explanation of why it is "not free" does not even mention the freedom aspect, which is why I think it is inconsistent with the spirit of the GPL (in addition to being apparently in violation of the letter of the GPL). Stop with the apologetics for GPL violations!
A distributor of a binary using GPLv2 section 3(b) only has to provide the written offer (for source code) when they distribute the binary -- but that offer must allow any third party, whether the third party received a copy of the binary or not, to get complete machine-readable source code corresponding to the binary at the "cost of physically performing source distribution". It is flatly incorrect to say "only when you receive the binary you are legally entitled to also get the source code".
A link is not the source code; it is more like an offer to provide source code later. One must do something more than provide a URL to satisfy section 3(a) of the GPLv2. For example, Debian handles it by having source packages on the same servers as the corresponding binary packages -- this satisfies Debian that the source and binary packages are on the same "medium customarily used for software interchange", and that the user has a sufficient chance to download the source code for any binary they get. For something like Google Play, it does not seem feasible for a user to find source code for a given app package unless the source code gets installed at the same time as the binary (and it is later reasonably easy for the user to read that source code).
The DOSBox Turbo web page says that it is licensed under the GPL, and also has a FAQ explaining why it is "not free". That does not seem like compliance with the spirit of the GPL. If you think he does complying with either the spirit or the letter of the GPL, why don't you pay $3.99 to confirm your guess?
I don't want to spend $3.99 because it seems too likely -- based on what others have done in similar situations in the past -- that he would not provide complete corresponding source code for his version and/or he would claim that some of his extensions are under GPL-incompatible licenses (such as "all rights reserved"); whether that is the case or not, I would not get $3.99 worth of value (to me) from either the binary or the source code of the app.
GPLv2 says that it must be in a machine-readable form on a medium customarily used for software interchange, and that the cost charged for a copy of the source code must not exceed the "cost of physically performing source distribution". This prohibits additional considerations such as the diamond-encrusted USB key or employing a large number of Vatican virgins.
The company's probable legal reasoning would be that it merely provides the employee with access to a company-owned system that includes the software, which would mean that the company has not distributed the software within the meaning of the GPLv2. This kind of claim is only tenable where the company owns the system (or perhaps in some other cases where the individual in question is acting as an agent of the company, under the usual laws of agency); it would not hold if a copyright owner wanted to press a case against a "private members area", regardless of how the latter tried to constitute or describe itself.
The GPLv2 is not deficient in the manner you claim, at least in this case. This is a commercial distribution in a binary form, which means section 3(c) cannot apply. If installing the binary form also installs the complete corresponding source code, then the distributor satisfies section 3(a). If it does not, he must comply with section 3(b), which allows any third party to request the (complete corresponding) source code. The implication from the article summary is that 3(b) does apply, and that $3.99 is more than the "cost of physically performing source distribution" -- a blank CD plus US postage for same is certainly less than that.
I, for one, am not willing to pay $3.99 for an experiment where the outcome seems so likely to be unrewarding. I would guess that the source code would be incomplete and/or would not correspond to the version that one can get through Google Play, and that the distributor would also claim a GPLv2-incompatible license for some of the Android-specific bits. Because I do not hold a copyright that would be infringed in such a case, it is not worth my time or money to confirm my guess. Even if that guess were wrong, I would not get $3.99 worth of value from either the source or binary form of the app.
Your position is that the DOSBox Turbo app installs its source code along with the binaries? If so, where? If not, how does the source code accompany the binary form?
3(b) says the binary-form distributor must include "a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code". The "any third party" directly rebuts your claim about only having to give source code to the people he gave binaries to. The qualifier "physically" is apparently to preclude charges for the associated labor and to prevent overcharges for the medium or shipping. (Similarly, the GPL demands that the medium must be "customarily used for software interchange" -- which means the distributor has some limits on his choice there.) I do not expect to ever argue that in court, so you will probably be disappointed there as well, but you are free to ask a lawyer whether your interpretation or mine is more defensible.
Google's agency and role in these exchanges are an interesting but separate question.
The AC had it right -- one must choose one of 3(a), 3(b) or 3(c) when one distributes a binary form of the work. It seems clear that the "DOSBox Turbo" distributor is not using 3(a) and is not eligible to use 3(c). If he wishes to comply with GPLv2, then, he must choose 3(b), and his written offer to provide source code must be valid for any third party. $3.99 is clearly not the distributor's cost to perform source distribution.
Sure -- but there are a bunch of hiring managers who haven't realized that yet. And a lot of the rest can hire the dime-a-dozen types to offload work from the better-compensated competent people.
I would say that you're the one who needs to get the point. Major components that crash will still generally leave the system in a state that is difficult or impractical to diagnose or recover. If your disk driver or filesystem daemon crashes, you don't have many ways to log in or start a replacement instance. If your network card driver or TCP/IP stack crashes, you still need a remote management console to fix that web server. In the mean time, people with modern kernels have figured out how to make those monolithic kernels still fairly usable in spite of panics or other corruption. The only reason that microkernels look better on the metrics you claim is that they support less hardware and use less of the hardware's complex (high-performance) features.
Microkernels are long on the "security and accountability" hype and somewhat short on reality. Sure, the services provided by the microkernel are less likely to have bugs or holes than a monolithic kernel -- but that's because the microkernel doesn't provide most of the monolithic kernel's functionality. Once you roll in all the device drivers, network stack, and the rest, the microkernel-based system is generally at least as bloated and typically less performant.
The US has defaulted on sovereign debt a number of times in the past. However, it's not likely that the government would do something default-like regarding the "trust fund" bonds. Among other not-default mechanisms, the government could cut or even eliminate benefits in those programs so that SSA and CMS never need to redeem them; that was the point of Flemming v. Nestor.
As a side note, you could eliminate all US military spending from the budget and still leave a sizable deficit. Social Security is getting close to the size of the military budget, as is Medicare. Those slices of the budget are growing rapidly -- and with no real end in sight, which is why entitlement reform is critical to controlling the deficit.
Your -UK suffix is showing. In the US, Social Security is collected by the federal (central) government. That government writes contracts for approximately none of the "basic infrastructure" you describe. Yes, it subsidizes road construction by the states, but things like power generation and delivery are mostly performed by private companies with oversight by state regulators; private rail freight companies subsidize the national passenger rail company; and so forth. States (and localities such as counties, towns and cities) collect taxes independently of the federal government, and the federal government has no real ability to collect money directly from state or local governments.
"Hollywood accounting methods"? Are you talking about the Social Security and Medicare "trust fund" gimmick? If so, that supports Solandri's point: Because people were willing to pretend that FICA are not ordinary taxes, and that payroll taxes went into some special pool of money, it was easier to use FICA surpluses to subsidize deficits in the rest of the budget. If you're talking about something else, perhaps you should be more specific.
If you think that Social Security or Medicare are "earned benefits", that boat sailed 50 years ago; the Supreme Court disagreed with you in 1960 (Flemming v. Nestor). Recently, President (George W.) Bush wanted to give each worker a real retirement account where the worker would have ownership, but your side threw an epic fit over the proposal (for transparently bad reasons).
If you think 1950's-style tax rates would be an effective solution, you've been reading too much Paul Krugman without engaging your brain. If you think bringing one or two hundred thousand deployed servicemen and servicewomen back home -- given the general economic climate, with the likely effect of dumping either them or others into unemployment -- would solve the budget deficit, you again haven't given the matter enough thought.
Usually a meeting of the minds is indicated by explicit compromises -- or at least negotiation. Ambiguity in contracts of adherence (also called standard form contracts or boilerplate contracts), where one party has no realistic option to negotiate terms, is supposed to be construed against the interests of the party who offered the contract.
AT&T most certainly care about the structure of the data on their network. They designed the thing -- including deciding what encapsulation to use inside their network. The user has neither insight into nor control over what is going on, so AT&T should have to describe their metering methodology, make it roughly consistent with what an end user can measure, or both. Anything else is tantamount to AT&T saying "trust us -- we have a track record of screwing up customer bills, but yours are juuuust fine".
If AT&T were honest about bandwidth costs, potential customers would at least be able to compare competing services. Customers can't do that if AT&T comes along and secretly gooses the bandwidth consumption in order to inflate the bill.
Including ATM overhead, and probably even just the AAL5 overhead, would probably be grounds for a lawsuit because that overhead is an artifact of AT&T's network design that is invisible to the user and out of the user's control. What would you do if a shipper charged you by the pound to ship a box and then also billed you for the weight of a hand truck that they decided to send along for their own convenience in handling your package?
Unless someone is sending an awful lot of really small packets, the 40+ bytes of TCP/IP headers per packet are not going to add 20-30% to the data that is being sent. For example, the "Simple IMIX" as defined on WIkipedia has 58% of packets being 40 bytes long (they are common because they represent data acknowledgments with no data going in the other direction), probably significantly underweights the number of 1500-byte MTUs, and still only has ~12% TCP/IP overhead. It would be grossly inappropriate for AT&T to include any packet overhead beyond TCP/IP because any lower level overhead is an artifact of AT&T's network design that is outside the control of, and opaque to, the end user.