It brews a cup of coffee. Exactly what functionality can they offer that changes that dramatically? The only thing I can think of is the ability to load several kinds of cups and have it programmatically select one. Remotely programming it... kind of pointless if I still have to walk down to get the mug, and if I've got the machine within reach to get the mug why do I need to program it remotely when I can just punch the Brew button? The only functionality I can think of they can add only benefits Keurig, and I'm not buying a brewer just for that.
Warning, Keurig: I'm attached to coffee, not your particular brand of machine.
He's not granting agreement, he's obliged to get her to agree. If she won't, he's obliged not to give her any details that if disclosed would breach his agreement.
Because if you reject a settlement that would've given you what you would've won if you prevailed in court, judges tend to take a very dim view of you wasting their time. And they aren't even very amenable to arguments like "The settlement would've covered my costs, but it doesn't have the plaintiff plainly saying I didn't do what they accused me of. I want that admission. I want my name cleared of the accusations made against me.". You have to show irreparable harm from that lack, and that's hard to do before the harm's actually happened.
You forget #3: The father is a party to the confidentiality agreement, therefore he has a legal duty to insure his daughter agrees to keep it confidential before he lets her know the details.
I do agree that if she found out on her own without her father giving her any details, the school should be out of luck. But even in that case the courts would probably hold that he still had a duty to make the situation clear to her and that once he had she'd be bound to keep information she found confidential.
How about a simpler idea: it's illegal to take your attention off the road and the act of driving. Doesn't matter why, only matters whether you're paying attention to your driving or not. That simplifies enforcement, if the cop sees you looking down inside the car rather than out the windshield at the road he doesn't have to worry about finding the right law for what you were looking at or even figuring out what you were looking at and you can't weasel out of it.
There's a distinction between the currency and the bank or other place you store your currency in. I can trust the currency while not trusting my bank, usually that results in my pulling my money out and putting it somewhere I do trust. That's actually one of the reasons we have the FDIC today in the US: at one point banks proved so untrustworthy that literally 90% of the country was trying to pull their money out to stuff into their mattress. We've been close to that happening again not too long ago. It's no surprise that we're running into the same thing with Bitcoin exchanges. It'll only get solved when, whether by technical or regulatory/legal means, the Bitcoin exchanges have a sufficiently hard time getting out of having to pay account holders their account balance and are required to have sufficient reserves to give confidence in their ability to do so. Right now the only place I'd trust to store Bitcoins is my own computer. Fortunately, that's possible.
As far as the currency goes, right now no I wouldn't trust it to retain it's value. It's spiked too hard and too high. That spike combined with exchange problems says to me it's going to be too volatile to trust until it settles down again.
That would've been my thought, but if you open up the NetBIOS ports through the VPN it still allows access to services that access to is forbidden so they'd have to block those ports over the VPN and we're right back where we started. And I gave up arguing the point with them because I could still get my work done and I had higher-priority things on my to-do list to spend my time on.
Simple: file shares on machines in the data center may not be accessible to users on machines in the office network and vice versa. Personally I consider that a sensible thing, people are going to use weak passwords and vulnerabilities are going to exist (and they're particularly rampant in the Windows services multiplexed over the NetBIOS and related ports) and the best defense is to simply not have those services accessible where access to them isn't needed. If anything, you'll find me arguing that this just highlights the desirability of environments and platforms that have less of an all-or-nothing approach to services and tools so that we don't have the problem in the first place.
Not production. The servers exist in a data center that's separate from the office network the developers work on (it's not even in the same state). The Windows networking ports are blocked because most of the services that use them aren't supposed to cross the boundary between the office network and the data center. The development and test servers aren't supposed to have the build tools on them, to make sure that when we create a build it's not going to accidentally depend on something that won't be present after the development stage. On the Unix side it's never been a problem, it's easy to install the libraries and debugger and editor without installing the header files or Makefiles or lexx/yacc and the like. On the Windows side the IDEs are so monolithic that the admins can't (or won't) figure out how to install just specific bits of them and have it work (installing just bits is easy, but getting the right bits to satisfy all the dependencies without pulling in the bits that we don't want is another matter entirely) and so they're forbidden entirely. It's an utter mess, and I'd be more sympathetic to the idea that it's the process and organization rather than the tooling except for the fact that we can and do do exactly what we want with tooling that's not based around an IDE so it obviously is readily doable.
The problem is that with Windows everything runs over those ports. If you open those ports you don't just allow remote debugging, you allow everything that's multiplexed onto those ports: access to file shares, remote registry access, the works. And that stuff isn't supposed to cross the boundary between the office desktop network and the data center. If it were all separated out with every service running on it's own port we'd be golden, but with all those services multiplexed onto the same few ports it's an all-or-nothing choice and "all" isn't acceptable.
Problem with remote debugging is that it depends on the IDE or at least parts of it being on the server, and having the firewall open. Installing the IDE on the server wasn't possible. Whether you could or not, it was Not Allowed because of administrative dictates. And the firewall could only be opened if you could specify the exact ports, and they couldn't be on the list of forbidden ports (which included the standard DCOM ports and the IPSEC VPN ports, opening those allowed too much through beyond just remote debugging).
TBH all that was why I preferred working on the Unix side of things. SSH was allowed, and once I had an SSH terminal window I could do pretty much anything I needed. Going into the Windows development environment was like walking into a briar patch: always snagging yourself on things that had nothing to do with the job at hand but couldn't be ignored.
And that's also an IDE's greatest weakness: that you have to compile, run and debug in one place. So tell me, what do you do when you're faced with software that you can't install and run on your desktop where your IDE's running? I did that a lot: we had all the libraries to build the software in the project tree, but none of them were installed. The massive database where all the supporting data the software needed also wasn't there, and the database servers that did have it weren't accessible because of firewalls. So you had no choice, you had to debug over on the server where there wasn't an IDE. I had no problems because I was used to a standalone debugger, but a lot of the guys who only knew the IDE were completely lost when they didn't have it (and I ended up being asked to track down their bugs because I was the one who could fire up the debugger and get the information out of the running program).
The Microsoft Office Open XML. That was the mid-2000s. It was particularly galling because the shenanigans MS pulled to avoid having to support a non-MS standard literally resulted in an ISO technical committee being shut down, unable to get a quorum to get any work done, for a year or two afterwards. And technical gaffes like the "lay out document like Word95" flag that was proposed because, when the reasoning was finally pried out of the MS representative, MS didn't know how Word95 laid out documents and they needed a flag to tell them when to switch to the old layout library from Word95.
Windows Genuine Advantage, which caused genuine, legit copies of Windows to shut down because MS was having problems with their servers.
Windows 8. 'nuff said about the UI, but things like the BIOS trusted boot lockdown are even more disturbing.
The reason people don't trust MS isn't the "your pappy killed mah pa" thing. It's that MS keeps demonstrating over and over that they haven't changed their spots. To quote a Scotsman, "Fool me once, shame on you. Fool me twice, shame on me.".
Why would Verizon's routing be any more expensive than Cogent's? If anything Cogent needs the more expensive routers. Router cost is a function of the bandwidth they need to handle and the size of the routing table they need to accommodate. Cogent's routers need larger routing tables because they need to handle the random agglomeration of ASes that is the Internet while Verizon's only need to handle Verizon's network which Verizon can arrange to minimize routing complexity. And Cogent's routers need to handle the entirety of Netflix's traffic all the way out to the edge while Verizon's have the traffic split early so most of them only have to handle that fraction bound for destinations "below" them. Verizon needs more routers, but the number's dependent on how they've organized their network and they'd need that many routers even if Netflix's traffic weren't there.
As for going after Netflix because they have deep pockets, my annoyance isn't about that. It's that Verizon and the rest won't admit that that's why they're doing it. They want to hem and haw and evade the question and make it out like Netflix is arbitrarily shoving this traffic at them because Netflix wants them to carry it, when in reality it's their own customers who requested the traffic and want them to carry it. I don't feel obliged to put up with the deception ISPs like Verizon are trying to pull off.
Same here. The database is encrypted, so the risk is minimal even when it's on my phone. Any malware that could get at the database password as I type it could get at any password I type, and I'd frankly be more worried about malware circulating on the company network.
My response would be that Netflix and Cogent aren't just sending unsolicited traffic to Verizon. It's Verizon's customers who're requesting the traffic by asking to stream video from Netflix. And Verizon's being paid by those customers to deliver the traffic from Netflix. That's what that bill that Verizon sends them each month is for, after all, to pay for that customer's connectivity. If their customers are demanding more traffic than Verizon's connection with Cogent can handle, why is the fact that Verizon isn't charging their customers what the service they're demanding costs Cogent's or Netflix's problem?
I think section 7 would scotch that idea for GPLv3 software at least. Adding your trademark to someone else's code (which you are only allowed to redistribute under the terms of the GPLv3) and then restricting use of that trademark would be imposing an additional restriction not permitted by section 7, at which point you no longer have a license to distribute the software to others.
Something to always bear in mind when dealing with Linux distributions is the distinction between the packages the distributor (eg. Canonical) owns because they wrote them themselves vs. the packages that someone else owns and that the distributor (eg. Canonical) is redistributing under the terms of a license.
That's because Google is open with all the stuff that's based on other people's open-source software. The parts they aren't open about are the parts they wrote themselves without basing them on open-source software. You'll notice the same thing with Canonical: nobody's arguing that Canonical can't restrict access to their own stuff that they wrote themselves or their own trademarks, only the stuff that's not Canonical's and whose licenses may not allow Canonical to impose restrictions on them.
In the case of GPLv3-licensed components, the requirement to recompile the source probably violates section 7 of the license which specifies exactly what additional terms may be applied to copies of a covered work (which includes copies in object form, ie. libraries and executables). Their requirement that you not redistribute the binaries isn't a permissible addition, it's not specified in that list. And such works couldn't contain Ubuntu's trademarks because the terms Ubuntu gives for use of their trademarks isn't compatible with GPLv3, if they included their trademarks in a piece of GPLv3 software they wouldn't be allowed to distribute the result themselves. Of course they cover that in the last sentence, putting them technically within the rules because that last sentence negates everything before it when it comes to GPL-licensed components. It's kind of like they're saying "You have to pay Canonical a daily fee to park anywhere in San Diego. The daily fee is $100 for passenger cars, $200 for light trucks, SUVs and vans, $500 for commercial vehicles. This does not affect your right to park in any part of San Diego not owned by Canonical.". It's just a convoluted, inverted way of saying "You have to pay these fees to park in Canonical's parking lot.".
You don't need a license for the open-source portions of Ubuntu (which is almost everything). In fact, Canonical would probably be in violation of their license if they tried to impose this requirement on the Linux kernel or any GPL-licensed packages (they could impose it on BSD-licensed packages, and I'd have to research other licenses). What you'd need a license for is the Ubuntu logos and name and the like and the software Canonical wrote that isn't under an open-source license. It's the same as with RedHat, you need the license to use their logos and trademarks or you can use Fedora which doesn't have the licensed stuff in it. It's probably non-trivial to strip the trademarked and proprietary stuff out of the actual Ubuntu distribution, it'd probably be easier to go straight back to the Debian base distribution and work from there.
The only problem there is the calculations. For radio, a "spin" is a single broadcast of a song. It may reach a million people, but it's still just one "spin". Services like Pandora, by contrast, pay per stream. That means that on Pandora, if 10 people are listening to a song at a given time it counts as 10 "spins". If Pandora paid the same rates under the same rules as broadcast radio, they'd be paying less than 1% of what they currently are being charged.
Well, if I look at the number of cars in the US (254 million or so) vs. number of car fires per year (152 thousand or so on average), and then look at the number of Telsas sold vs. number of Teslas involved in car fires, the rate for Teslas is a third to a quarter that of gasoline-powered cars. So yes, if a gasoline-powered model had the same fire rates as Teslas and there was detailed coverage of every single fire it was involved in I'd make an accusation of media hype, how else would you explain that focus accompanied by a lack of coverage of models that catch fire 3-4x as often?
Only problem: none of those methods work if the thief's pulled the SIM out and done a factory reset so the phone's no longer associated with your accounts. Pulling the SIM at least will be one of the first things a thief will do if he's looking to fence the phone.
Won't work. The first thing the thief does is pull the SIM so your security provider can't contact/control the phone anymore. Then they do a hard reset and restore to factory defaults so it's no longer tied to your accounts and they have a blank phone to sell and you can't do a thing about it.
The idea behind the mandatory kill-switch functionality is that it'd be cross-carrier and tied to the phone itself, not the SIM, so that the phone would brick itself as soon as it connected to any carrier's network anywhere (at least within the US). That can't be done by an individual, it requires all carriers to support an IMEI blacklist that didn't care what SIM was in the phone when it connected. Doing that requires regulation at the national level.
Doing it securely requires doing it at the carrier level too. If just anyone could submit an IMEI, the potential for abuse is ridiculous. The only way it works is if you report your phone stolen to your carrier, the carrier looks up your phone number and SIM to find the IMEI most recently associated with it (checking first to clear up any confusion if there's several IMEIs recently associated with your SIM) and issues a kill order for that IMEI. It's still possible to abuse it, but now you have to find out your victim's carrier and social-engineer Support into accepting the report from you. I know ways to prevent even that, but they require supplying a landline or other alternate contact phone number and/or e-mail address when getting cel service. Not everybody has those, or has access to them remotely.
One distinct difference: the software developer's being paid a fixed salary, not by the hour. There's no such thing as "on his own time" here, he's going to get paid the same amount no matter how many or how few hours he works. If the manager wants bugs fixed "on the developer's own time", then that manager needs to start paying developers an hourly rate. Which means time-and-a-half when they work more than 40 hours a week trying to get things done because the manager's allowed features to be added but hasn't lengthened the delivery schedule to accommodate them, or because the requirements were changed at the last minute but the manager still expects the project to be delivered on time. Believe me, I'd love it if managers would go for this. I could easily double my paycheck if managers had to pay me my normal hourly rate for every hour I actually put in on a project. Most of the "bugs" I have to fix aren't in fact bugs, they're more often items where the code's working exactly as specified but the business side's changed their minds since the code was written, or where someone else has changed an interface and the code adhering to the old interface specification now isn't compatible with the new interface and has to be changed. Overall I'd gain far more in billable hours than I'd lose to bugfix hours.
Of course the manager probably doesn't want that. What he wants is to continue to pay a fixed salary regardless of hours worked, and then subtract from that for bugfixes. That's not a deal I'd ever take, though. If he wants to pay me a fixed salary to get the job done whatever it takes, then he'll pay me that regardless of what I'm doing as long as I'm delivering on time. If he wants to pay by the hour, then he'll pay by the hour for all the hours I work that're billable. If he wants to treat me as salaried when it comes to billable hours but hourly when it comes to fixing bugs, he can go find another sucker.
Slashdot Mirror
It brews a cup of coffee. Exactly what functionality can they offer that changes that dramatically? The only thing I can think of is the ability to load several kinds of cups and have it programmatically select one. Remotely programming it... kind of pointless if I still have to walk down to get the mug, and if I've got the machine within reach to get the mug why do I need to program it remotely when I can just punch the Brew button? The only functionality I can think of they can add only benefits Keurig, and I'm not buying a brewer just for that.
Warning, Keurig: I'm attached to coffee, not your particular brand of machine.
He's not granting agreement, he's obliged to get her to agree. If she won't, he's obliged not to give her any details that if disclosed would breach his agreement.
Because if you reject a settlement that would've given you what you would've won if you prevailed in court, judges tend to take a very dim view of you wasting their time. And they aren't even very amenable to arguments like "The settlement would've covered my costs, but it doesn't have the plaintiff plainly saying I didn't do what they accused me of. I want that admission. I want my name cleared of the accusations made against me.". You have to show irreparable harm from that lack, and that's hard to do before the harm's actually happened.
You forget #3: The father is a party to the confidentiality agreement, therefore he has a legal duty to insure his daughter agrees to keep it confidential before he lets her know the details.
I do agree that if she found out on her own without her father giving her any details, the school should be out of luck. But even in that case the courts would probably hold that he still had a duty to make the situation clear to her and that once he had she'd be bound to keep information she found confidential.
How about a simpler idea: it's illegal to take your attention off the road and the act of driving. Doesn't matter why, only matters whether you're paying attention to your driving or not. That simplifies enforcement, if the cop sees you looking down inside the car rather than out the windshield at the road he doesn't have to worry about finding the right law for what you were looking at or even figuring out what you were looking at and you can't weasel out of it.
There's a distinction between the currency and the bank or other place you store your currency in. I can trust the currency while not trusting my bank, usually that results in my pulling my money out and putting it somewhere I do trust. That's actually one of the reasons we have the FDIC today in the US: at one point banks proved so untrustworthy that literally 90% of the country was trying to pull their money out to stuff into their mattress. We've been close to that happening again not too long ago. It's no surprise that we're running into the same thing with Bitcoin exchanges. It'll only get solved when, whether by technical or regulatory/legal means, the Bitcoin exchanges have a sufficiently hard time getting out of having to pay account holders their account balance and are required to have sufficient reserves to give confidence in their ability to do so. Right now the only place I'd trust to store Bitcoins is my own computer. Fortunately, that's possible.
As far as the currency goes, right now no I wouldn't trust it to retain it's value. It's spiked too hard and too high. That spike combined with exchange problems says to me it's going to be too volatile to trust until it settles down again.
That would've been my thought, but if you open up the NetBIOS ports through the VPN it still allows access to services that access to is forbidden so they'd have to block those ports over the VPN and we're right back where we started. And I gave up arguing the point with them because I could still get my work done and I had higher-priority things on my to-do list to spend my time on.
Simple: file shares on machines in the data center may not be accessible to users on machines in the office network and vice versa. Personally I consider that a sensible thing, people are going to use weak passwords and vulnerabilities are going to exist (and they're particularly rampant in the Windows services multiplexed over the NetBIOS and related ports) and the best defense is to simply not have those services accessible where access to them isn't needed. If anything, you'll find me arguing that this just highlights the desirability of environments and platforms that have less of an all-or-nothing approach to services and tools so that we don't have the problem in the first place.
Not production. The servers exist in a data center that's separate from the office network the developers work on (it's not even in the same state). The Windows networking ports are blocked because most of the services that use them aren't supposed to cross the boundary between the office network and the data center. The development and test servers aren't supposed to have the build tools on them, to make sure that when we create a build it's not going to accidentally depend on something that won't be present after the development stage. On the Unix side it's never been a problem, it's easy to install the libraries and debugger and editor without installing the header files or Makefiles or lexx/yacc and the like. On the Windows side the IDEs are so monolithic that the admins can't (or won't) figure out how to install just specific bits of them and have it work (installing just bits is easy, but getting the right bits to satisfy all the dependencies without pulling in the bits that we don't want is another matter entirely) and so they're forbidden entirely. It's an utter mess, and I'd be more sympathetic to the idea that it's the process and organization rather than the tooling except for the fact that we can and do do exactly what we want with tooling that's not based around an IDE so it obviously is readily doable.
The problem is that with Windows everything runs over those ports. If you open those ports you don't just allow remote debugging, you allow everything that's multiplexed onto those ports: access to file shares, remote registry access, the works. And that stuff isn't supposed to cross the boundary between the office desktop network and the data center. If it were all separated out with every service running on it's own port we'd be golden, but with all those services multiplexed onto the same few ports it's an all-or-nothing choice and "all" isn't acceptable.
Problem with remote debugging is that it depends on the IDE or at least parts of it being on the server, and having the firewall open. Installing the IDE on the server wasn't possible. Whether you could or not, it was Not Allowed because of administrative dictates. And the firewall could only be opened if you could specify the exact ports, and they couldn't be on the list of forbidden ports (which included the standard DCOM ports and the IPSEC VPN ports, opening those allowed too much through beyond just remote debugging).
TBH all that was why I preferred working on the Unix side of things. SSH was allowed, and once I had an SSH terminal window I could do pretty much anything I needed. Going into the Windows development environment was like walking into a briar patch: always snagging yourself on things that had nothing to do with the job at hand but couldn't be ignored.
And that's also an IDE's greatest weakness: that you have to compile, run and debug in one place. So tell me, what do you do when you're faced with software that you can't install and run on your desktop where your IDE's running? I did that a lot: we had all the libraries to build the software in the project tree, but none of them were installed. The massive database where all the supporting data the software needed also wasn't there, and the database servers that did have it weren't accessible because of firewalls. So you had no choice, you had to debug over on the server where there wasn't an IDE. I had no problems because I was used to a standalone debugger, but a lot of the guys who only knew the IDE were completely lost when they didn't have it (and I ended up being asked to track down their bugs because I was the one who could fire up the debugger and get the information out of the running program).
The Microsoft Office Open XML. That was the mid-2000s. It was particularly galling because the shenanigans MS pulled to avoid having to support a non-MS standard literally resulted in an ISO technical committee being shut down, unable to get a quorum to get any work done, for a year or two afterwards. And technical gaffes like the "lay out document like Word95" flag that was proposed because, when the reasoning was finally pried out of the MS representative, MS didn't know how Word95 laid out documents and they needed a flag to tell them when to switch to the old layout library from Word95.
Windows Genuine Advantage, which caused genuine, legit copies of Windows to shut down because MS was having problems with their servers.
Windows 8. 'nuff said about the UI, but things like the BIOS trusted boot lockdown are even more disturbing.
The reason people don't trust MS isn't the "your pappy killed mah pa" thing. It's that MS keeps demonstrating over and over that they haven't changed their spots. To quote a Scotsman, "Fool me once, shame on you. Fool me twice, shame on me.".
Why would Verizon's routing be any more expensive than Cogent's? If anything Cogent needs the more expensive routers. Router cost is a function of the bandwidth they need to handle and the size of the routing table they need to accommodate. Cogent's routers need larger routing tables because they need to handle the random agglomeration of ASes that is the Internet while Verizon's only need to handle Verizon's network which Verizon can arrange to minimize routing complexity. And Cogent's routers need to handle the entirety of Netflix's traffic all the way out to the edge while Verizon's have the traffic split early so most of them only have to handle that fraction bound for destinations "below" them. Verizon needs more routers, but the number's dependent on how they've organized their network and they'd need that many routers even if Netflix's traffic weren't there.
As for going after Netflix because they have deep pockets, my annoyance isn't about that. It's that Verizon and the rest won't admit that that's why they're doing it. They want to hem and haw and evade the question and make it out like Netflix is arbitrarily shoving this traffic at them because Netflix wants them to carry it, when in reality it's their own customers who requested the traffic and want them to carry it. I don't feel obliged to put up with the deception ISPs like Verizon are trying to pull off.
Same here. The database is encrypted, so the risk is minimal even when it's on my phone. Any malware that could get at the database password as I type it could get at any password I type, and I'd frankly be more worried about malware circulating on the company network.
My response would be that Netflix and Cogent aren't just sending unsolicited traffic to Verizon. It's Verizon's customers who're requesting the traffic by asking to stream video from Netflix. And Verizon's being paid by those customers to deliver the traffic from Netflix. That's what that bill that Verizon sends them each month is for, after all, to pay for that customer's connectivity. If their customers are demanding more traffic than Verizon's connection with Cogent can handle, why is the fact that Verizon isn't charging their customers what the service they're demanding costs Cogent's or Netflix's problem?
I think section 7 would scotch that idea for GPLv3 software at least. Adding your trademark to someone else's code (which you are only allowed to redistribute under the terms of the GPLv3) and then restricting use of that trademark would be imposing an additional restriction not permitted by section 7, at which point you no longer have a license to distribute the software to others.
Something to always bear in mind when dealing with Linux distributions is the distinction between the packages the distributor (eg. Canonical) owns because they wrote them themselves vs. the packages that someone else owns and that the distributor (eg. Canonical) is redistributing under the terms of a license.
That's because Google is open with all the stuff that's based on other people's open-source software. The parts they aren't open about are the parts they wrote themselves without basing them on open-source software. You'll notice the same thing with Canonical: nobody's arguing that Canonical can't restrict access to their own stuff that they wrote themselves or their own trademarks, only the stuff that's not Canonical's and whose licenses may not allow Canonical to impose restrictions on them.
In the case of GPLv3-licensed components, the requirement to recompile the source probably violates section 7 of the license which specifies exactly what additional terms may be applied to copies of a covered work (which includes copies in object form, ie. libraries and executables). Their requirement that you not redistribute the binaries isn't a permissible addition, it's not specified in that list. And such works couldn't contain Ubuntu's trademarks because the terms Ubuntu gives for use of their trademarks isn't compatible with GPLv3, if they included their trademarks in a piece of GPLv3 software they wouldn't be allowed to distribute the result themselves. Of course they cover that in the last sentence, putting them technically within the rules because that last sentence negates everything before it when it comes to GPL-licensed components. It's kind of like they're saying "You have to pay Canonical a daily fee to park anywhere in San Diego. The daily fee is $100 for passenger cars, $200 for light trucks, SUVs and vans, $500 for commercial vehicles. This does not affect your right to park in any part of San Diego not owned by Canonical.". It's just a convoluted, inverted way of saying "You have to pay these fees to park in Canonical's parking lot.".
You don't need a license for the open-source portions of Ubuntu (which is almost everything). In fact, Canonical would probably be in violation of their license if they tried to impose this requirement on the Linux kernel or any GPL-licensed packages (they could impose it on BSD-licensed packages, and I'd have to research other licenses). What you'd need a license for is the Ubuntu logos and name and the like and the software Canonical wrote that isn't under an open-source license. It's the same as with RedHat, you need the license to use their logos and trademarks or you can use Fedora which doesn't have the licensed stuff in it. It's probably non-trivial to strip the trademarked and proprietary stuff out of the actual Ubuntu distribution, it'd probably be easier to go straight back to the Debian base distribution and work from there.
The only problem there is the calculations. For radio, a "spin" is a single broadcast of a song. It may reach a million people, but it's still just one "spin". Services like Pandora, by contrast, pay per stream. That means that on Pandora, if 10 people are listening to a song at a given time it counts as 10 "spins". If Pandora paid the same rates under the same rules as broadcast radio, they'd be paying less than 1% of what they currently are being charged.
Well, if I look at the number of cars in the US (254 million or so) vs. number of car fires per year (152 thousand or so on average), and then look at the number of Telsas sold vs. number of Teslas involved in car fires, the rate for Teslas is a third to a quarter that of gasoline-powered cars. So yes, if a gasoline-powered model had the same fire rates as Teslas and there was detailed coverage of every single fire it was involved in I'd make an accusation of media hype, how else would you explain that focus accompanied by a lack of coverage of models that catch fire 3-4x as often?
Only problem: none of those methods work if the thief's pulled the SIM out and done a factory reset so the phone's no longer associated with your accounts. Pulling the SIM at least will be one of the first things a thief will do if he's looking to fence the phone.
Won't work. The first thing the thief does is pull the SIM so your security provider can't contact/control the phone anymore. Then they do a hard reset and restore to factory defaults so it's no longer tied to your accounts and they have a blank phone to sell and you can't do a thing about it.
The idea behind the mandatory kill-switch functionality is that it'd be cross-carrier and tied to the phone itself, not the SIM, so that the phone would brick itself as soon as it connected to any carrier's network anywhere (at least within the US). That can't be done by an individual, it requires all carriers to support an IMEI blacklist that didn't care what SIM was in the phone when it connected. Doing that requires regulation at the national level.
Doing it securely requires doing it at the carrier level too. If just anyone could submit an IMEI, the potential for abuse is ridiculous. The only way it works is if you report your phone stolen to your carrier, the carrier looks up your phone number and SIM to find the IMEI most recently associated with it (checking first to clear up any confusion if there's several IMEIs recently associated with your SIM) and issues a kill order for that IMEI. It's still possible to abuse it, but now you have to find out your victim's carrier and social-engineer Support into accepting the report from you. I know ways to prevent even that, but they require supplying a landline or other alternate contact phone number and/or e-mail address when getting cel service. Not everybody has those, or has access to them remotely.
One distinct difference: the software developer's being paid a fixed salary, not by the hour. There's no such thing as "on his own time" here, he's going to get paid the same amount no matter how many or how few hours he works. If the manager wants bugs fixed "on the developer's own time", then that manager needs to start paying developers an hourly rate. Which means time-and-a-half when they work more than 40 hours a week trying to get things done because the manager's allowed features to be added but hasn't lengthened the delivery schedule to accommodate them, or because the requirements were changed at the last minute but the manager still expects the project to be delivered on time. Believe me, I'd love it if managers would go for this. I could easily double my paycheck if managers had to pay me my normal hourly rate for every hour I actually put in on a project. Most of the "bugs" I have to fix aren't in fact bugs, they're more often items where the code's working exactly as specified but the business side's changed their minds since the code was written, or where someone else has changed an interface and the code adhering to the old interface specification now isn't compatible with the new interface and has to be changed. Overall I'd gain far more in billable hours than I'd lose to bugfix hours.
Of course the manager probably doesn't want that. What he wants is to continue to pay a fixed salary regardless of hours worked, and then subtract from that for bugfixes. That's not a deal I'd ever take, though. If he wants to pay me a fixed salary to get the job done whatever it takes, then he'll pay me that regardless of what I'm doing as long as I'm delivering on time. If he wants to pay by the hour, then he'll pay by the hour for all the hours I work that're billable. If he wants to treat me as salaried when it comes to billable hours but hourly when it comes to fixing bugs, he can go find another sucker.