I've worked for product-making companies. It is not that uncommon to not be able to identify the specific source code that a particular build corresponds to. Not all companies use version control; not all companies have processes that assure that they do things in a repeatable way.
Note that the binaries may not have all been built at the same time - you may be pulling libraries from a binary repository. I would consider it highly embarrassing if a project I was involved with got into that situation, but I have absolutely seen projects that did.
[This isn't meant to excuse such errors, but just to say that ineptitude is absolutely as likely an answer as evil intent.
Like many other things, nobody knows for sure. "The lawyers who wrote the GPLv3" are paid to have a particular point of view and have limited value as authorities. They're certainly right that GPLv2 says nothing explicit about how rights are restored after a non-conforming act terminates them.
The language in this part of GPLv2 is somewhat ambiguous - it's not clear whether non-conforming distribution means you lose the right to distribute any GPLed software ("under this license") or only this particular software for which it was violated ("under this license" means the license from this copyright holder for this software). There's nothing that makes it clear whether a subsequent, conforming distribution would be allowed by the license or not. I suspect a court would read it fairly narrowly (remembering that the license is from a particular copyright holder, not from all authors of GPLed software).
Also, beyond that question, is the question of what a court would do with damages. Generally, speaking, damages have to be proven in court. I don't think anyone has a good idea what a court would do with damages stemming from non-conforming distribution of a piece of code that the author allows to be used without charge. Courts really don't like messing with non-substantive questions. My own guess is that a court would go along with an injunction but be reluctant to assess damages (and probably would quash the injunction upon being shown that the defendant was in compliance), but (a) IANAL and (b) judges sometimes do the unexpected.
Note also my previous comment about the difficulty of pursuing damages if the software is not registered with the Copyright registrar.
(a) To begin with, there's no requirement in the license to "release" the code. They just have to offer to provide a physical copy of the code. In fact, just having a site to download it from does not technically satisfy the license. Nor is there any timeliness requirement in the license - they have to provide a copy on request, but any business-like response would satisfy the requirement (think how long it takes to satisfy rebate requests). [I believe that in this case such a request actually was made - my point is just that the website contents are irrelevant under the license terms.]
(b) Second, courts have held that damages cannot be recovered unless the material is registered. My guess is that nobody is paying registration fees on each release of Linux, but that's just my guess and it would be interesting to know if some in fact is registering them. This principle was upheld most recently yesterday, when an appeals court threw out a settlement because in the absence of registration there was no jurisdiction.
(c) Again, under the terms of the license, any violation leads to loss of right to distribute. That can only be restored by the permission of the copyright holders. However, the points in (a) suggest that any eventual provision of the source to all the people who had requested it would mean that no infringement had ever occurred.
Note that I'm not arguing that it's a good thing to push the limits of the letter of the license. I think it's unfortunate that GPLv2 didn't allow net-distribution as an alternative and that it didn't specify timeliness requirements. I wish that GPLv3 had fixed those issues (it makes some progress on net distribution) and not gone off into adding other restrictions.
"This isn't going to keep users away from the program."
Well, I agree with you on that, but isn't it beside the point? I don't think any of the discussion about the anti-TiVo-ization clauses has been on the lines of scaring device manufacturers away.
I don't think that's all that likely, since I think that, as you say, there are plenty of ways to design systems so that the important trust boundaries are outside the GPLed code, and since it appears Linux itself will remain GPLv2.
I go back and forth on this. If there are developers who find these restrictions important to them, it's good that they will have the option to use a license that makes them feel more secure in the post-release life of their work. On the other hand, I don't find such clauses important myself and think that increased adoption is more important and GPLv2 is quite sufficient.
Since both licenses will be available to developers, it's nice that people will have the freedom to choose, but there undoubtedly will be some fragmentation and that fragmentation will reduce the total uptake of FOSS software, even if only a little.
So, how much maintaining does the gcc toolchain need? C isn't changing and the definition of the libc functions isn't changing, so major functionality changes would mostly be for things like new hardware, which might well be done for the hardware vendor or a major customer under contract stipulating GPLv2, for instance. I think there are other issues bigger than maintaining a fork of gcc.
And, of course, if a bunch of device manufacturers are concerned about GPLv3, somebody maintaining such a fork would have a good market for it.
In the US, most phones are sold with subsidies from the carrier, so that the phone is often "free" with a contract for a certain period of service. The manufacturers sell most of hteir phones that way, so they build them to suit the carriers. It's very hard, in the US, to buy a phone for full price.
Many major US carriers use CDMA, rather than GSM, so they don't have SIM cards. Some US CDMA carriers will let you bring a phone you already own in and activate it on their network, but some will only accept phones that were sold for their network. In fairness, this is in large part because their customer service people can only support users on the carrier's phones.
If you have a GSM phone, you can generally put any carrier's SIM into it to use that carrier's network. As you note, some special network features may not be available or may take some reprovisioning of the phone. However, if the phone was bought with a subsidy, it may be locked to the carrier that provided the subsidy, in which case it will not work with other carrier's SIMs.
Some of these conditions also exist in other markets, the US is only unique in the universality of the carrier subsidy model.
Yes, you can assign categories (as well as pictures, ringers, etc.) to numbers in recent Motorola products. You have to be storing the numbers in the phone (not the SIM card) to do so.
The "View: Primary Contact" option groups together numbers that have the same name, so you can just create entries separately with the same name, but there should also be a "More" option when you're creating an entry in the phone book; it will create a new set of attribute lines under the original name.
Not sure what you mean by "menus that SHOUT at you."
If you have a reasonably recent Motorola phone, there should be a "View:" option in the Phone Book Setup menu. Setting it to "Primary contact" will group all the numbers with the same name as a single line that you can scroll left/right in to see the individual numbers.
Motorola makes and has announced a wide range of music-oriented phones, supporting playback of many different kinds of files and many different arrangements for direct or carrier-mediated loading of content.
Most newer Motorola phones will play MP3 and various other formats, if you can get them into the phone. The "Mobile Phone Tools" software will let you load music into the phone from a PC, unless the carrier has specifically blocked it.
In fairness, Motorola phones always had the SEND on the right and the END on the left, and Motorola has been building cell phones longer than anybody. It's Nokia that made the gratuitous change from industry standard.
However, Motorola started switching product lines to the Red-on-the-right model a while ago and it will probably be universal, eventually.
Switching it isn't as easy as changing the key labels - you want the softkey usage to match the hardkeys, so you also have get those reversed so that "positive" is on the left. Some of Motorola's products are caught-in-the-middle on that transition and appear inconsistent.
Numbers on menu entries are a mixed blessing - they take up screen space (a bigger deal a few years ago than now, admittedly) and users end up learning them as shortcuts, which means you can't have dynamic menus that drop inapplicable operations.
I agree, the volume-changing is still not what it should be. Note, however, that you can use shortcuts to set up 2-click changes to a particular style (like Loud or Vibrate).
The "power-off by holding END" model is the standard in large parts of the world.
The external button for the camera is meant to leverage the fact that you can use the external display as a viewfinder. The sidekeys do need something like the keypad lock that candybar phones have.
In the list of most-recent callers, the most-recent SHOULD have the highest number, so you know how many are under it in the list. Every caller ID box I've had does it that way.
Slashdot Mirror
I've worked for product-making companies. It is not that uncommon to not be able to identify the specific source code that a particular build corresponds to. Not all companies use version control; not all companies have processes that assure that they do things in a repeatable way.
Note that the binaries may not have all been built at the same time - you may be pulling libraries from a binary repository. I would consider it highly embarrassing if a project I was involved with got into that situation, but I have absolutely seen projects that did.
[This isn't meant to excuse such errors, but just to say that ineptitude is absolutely as likely an answer as evil intent.
Like many other things, nobody knows for sure. "The lawyers who wrote the GPLv3" are paid to have a particular point of view and have limited value as authorities. They're certainly right that GPLv2 says nothing explicit about how rights are restored after a non-conforming act terminates them.
The language in this part of GPLv2 is somewhat ambiguous - it's not clear whether non-conforming distribution means you lose the right to distribute any GPLed software ("under this license") or only this particular software for which it was violated ("under this license" means the license from this copyright holder for this software). There's nothing that makes it clear whether a subsequent, conforming distribution would be allowed by the license or not. I suspect a court would read it fairly narrowly (remembering that the license is from a particular copyright holder, not from all authors of GPLed software).
Also, beyond that question, is the question of what a court would do with damages. Generally, speaking, damages have to be proven in court. I don't think anyone has a good idea what a court would do with damages stemming from non-conforming distribution of a piece of code that the author allows to be used without charge. Courts really don't like messing with non-substantive questions. My own guess is that a court would go along with an injunction but be reluctant to assess damages (and probably would quash the injunction upon being shown that the defendant was in compliance), but (a) IANAL and (b) judges sometimes do the unexpected.
Note also my previous comment about the difficulty of pursuing damages if the software is not registered with the Copyright registrar.
(a) To begin with, there's no requirement in the license to "release" the code. They just have to offer to provide a physical copy of the code. In fact, just having a site to download it from does not technically satisfy the license. Nor is there any timeliness requirement in the license - they have to provide a copy on request, but any business-like response would satisfy the requirement (think how long it takes to satisfy rebate requests). [I believe that in this case such a request actually was made - my point is just that the website contents are irrelevant under the license terms.]
(b) Second, courts have held that damages cannot be recovered unless the material is registered. My guess is that nobody is paying registration fees on each release of Linux, but that's just my guess and it would be interesting to know if some in fact is registering them. This principle was upheld most recently yesterday, when an appeals court threw out a settlement because in the absence of registration there was no jurisdiction.
(c) Again, under the terms of the license, any violation leads to loss of right to distribute. That can only be restored by the permission of the copyright holders. However, the points in (a) suggest that any eventual provision of the source to all the people who had requested it would mean that no infringement had ever occurred.
Note that I'm not arguing that it's a good thing to push the limits of the letter of the license. I think it's unfortunate that GPLv2 didn't allow net-distribution as an alternative and that it didn't specify timeliness requirements. I wish that GPLv3 had fixed those issues (it makes some progress on net distribution) and not gone off into adding other restrictions.
"This isn't going to keep users away from the program."
Well, I agree with you on that, but isn't it beside the point? I don't think any of the discussion about the anti-TiVo-ization clauses has been on the lines of scaring device manufacturers away.
I don't think that's all that likely, since I think that, as you say, there are plenty of ways to design systems so that the important trust boundaries are outside the GPLed code, and since it appears Linux itself will remain GPLv2.
I go back and forth on this. If there are developers who find these restrictions important to them, it's good that they will have the option to use a license that makes them feel more secure in the post-release life of their work. On the other hand, I don't find such clauses important myself and think that increased adoption is more important and GPLv2 is quite sufficient.
Since both licenses will be available to developers, it's nice that people will have the freedom to choose, but there undoubtedly will be some fragmentation and that fragmentation will reduce the total uptake of FOSS software, even if only a little.
So, how much maintaining does the gcc toolchain need? C isn't changing and the definition of the libc functions isn't changing, so major functionality changes would mostly be for things like new hardware, which might well be done for the hardware vendor or a major customer under contract stipulating GPLv2, for instance. I think there are other issues bigger than maintaining a fork of gcc.
And, of course, if a bunch of device manufacturers are concerned about GPLv3, somebody maintaining such a fork would have a good market for it.
In the US, most phones are sold with subsidies from the carrier, so that the phone is often "free" with a contract for a certain period of service. The manufacturers sell most of hteir phones that way, so they build them to suit the carriers. It's very hard, in the US, to buy a phone for full price.
Many major US carriers use CDMA, rather than GSM, so they don't have SIM cards. Some US CDMA carriers will let you bring a phone you already own in and activate it on their network, but some will only accept phones that were sold for their network. In fairness, this is in large part because their customer service people can only support users on the carrier's phones.
If you have a GSM phone, you can generally put any carrier's SIM into it to use that carrier's network. As you note, some special network features may not be available or may take some reprovisioning of the phone. However, if the phone was bought with a subsidy, it may be locked to the carrier that provided the subsidy, in which case it will not work with other carrier's SIMs.
Some of these conditions also exist in other markets, the US is only unique in the universality of the carrier subsidy model.
Yes, you can assign categories (as well as pictures, ringers, etc.) to numbers in recent Motorola products. You have to be storing the numbers in the phone (not the SIM card) to do so.
The "View: Primary Contact" option groups together numbers that have the same name, so you can just create entries separately with the same name, but there should also be a "More" option when you're creating an entry in the phone book; it will create a new set of attribute lines under the original name.
Not sure what you mean by "menus that SHOUT at you."
If you have a reasonably recent Motorola phone, there should be a "View:" option in the Phone Book Setup menu. Setting it to "Primary contact" will group all the numbers with the same name as a single line that you can scroll left/right in to see the individual numbers.
Why "without Motorola"?
Motorola makes and has announced a wide range of music-oriented phones, supporting playback of many different kinds of files and many different arrangements for direct or carrier-mediated loading of content.
Most newer Motorola phones will play MP3 and various other formats, if you can get them into the phone. The "Mobile Phone Tools" software will let you load music into the phone from a PC, unless the carrier has specifically blocked it.
In fairness, Motorola phones always had the SEND on the right and the END on the left, and Motorola has been building cell phones longer than anybody. It's Nokia that made the gratuitous change from industry standard.
However, Motorola started switching product lines to the Red-on-the-right model a while ago and it will probably be universal, eventually.
Switching it isn't as easy as changing the key labels - you want the softkey usage to match the hardkeys, so you also have get those reversed so that "positive" is on the left. Some of Motorola's products are caught-in-the-middle on that transition and appear inconsistent.
Numbers on menu entries are a mixed blessing - they take up screen space (a bigger deal a few years ago than now, admittedly) and users end up learning them as shortcuts, which means you can't have dynamic menus that drop inapplicable operations.
I agree, the volume-changing is still not what it should be. Note, however, that you can use shortcuts to set up 2-click changes to a particular style (like Loud or Vibrate).
The "power-off by holding END" model is the standard in large parts of the world.
The external button for the camera is meant to leverage the fact that you can use the external display as a viewfinder. The sidekeys do need something like the keypad lock that candybar phones have.
In the list of most-recent callers, the most-recent SHOULD have the highest number, so you know how many are under it in the list. Every caller ID box I've had does it that way.