I dont think where he wrote the code plays a big a role as people think it does. Rather what matters more is whether he was in an employer-employee relationship with them and if this was work that was part of that. Even though it appears he was freelance, if he worked onsite on company equipment for 6 years they may very well be enough to show an employer-employee relationship. Especially if this code was a part of one of their projects. It sucks, but now he knows what he needs to do legally next time.

Depends if he can prove that. "On company time" is not something that has held in court from what I remember. And to show they supported him owning the copyright, he would need a signed legal document (I think). I do agree he should consult a lawyer though if he really thinks he has a shot at this.

However from: http://www.copyright.gov/circs/circ09.pdf (Emphasis mine)

Standard practice when hiring any employee is to write a legal agreement stating that any work you do there is "work for hire" and they own the copyright, not you. I *think* this can even be implied just by the fact that you were an employee, Unless you took specific action before writing this code, such as giving the company a specific license, or requireing them to let you contribute it, I think you are the one in *possible* legal danger here. (I am not a lawyer etc blah blah).

This is unfortunate but you need to get over the fact that work-for-hire does not belong to you and drop this quickly. The more you drum up publicity around this the more danger you could be in.

Chalk it up to a learning experience, and take solace in that you know what to do next time.

At the last company I worked with I asked my boss (a SVP level executive good enough for legal purposes) to sign a small contract with me that would allow me to bring in my own open source libraries I had built up over the years in exchange for letting me take code written on company time and contribute it back to the library or to an OSS project. I of course said this would not include anything proprietary to a client or any program as a whole, but rather utilities such as a date converter class or caching system. And that it was at my sole discretion to determine as best I could in good faith what code qualified to be contributed to open source.

The article mentioned power in the milli and microwatt neighborhood. So I dont think there will be anything like that in the *near* future. However, the article actually seemed a bit sparse when it came explaining the practicle uses. It mentioned a temperature sensor, but what would that sensor do? Would it transmit data? Would it record it? Just "sensing" is mostly useless, no? Admittedly my understanding of this tech is about nil -- but it mentioned charging capacitors with these things. So I gather that's where the power would come from to transmit and/or write to storage. So my question was how much of this power can be stored? How long would the charge take? That would give us the info needed to imagine practical applications I would think.
 
I also find the concept that this is "green" power a bit off considering just printing these things may take more power than they could give back. It surely may have some great logistical, industrial, consumer or other applications, but I'm not sure it's "green" energy in the way most people think about it.

Excellent! I think they should add another layer. Say like when I know what I want to watch 2-14 Buisiness days (M-F) from now, I could tell them and they'd send it to me on some type of disc and I could watch it whenever I got it and send it back when I was done. ;)

I think part of why it works on Slashdot is that there is a community of continually interested people and a focused topic. It's hard to imagine people with that level of interest in "policing" the web at large. I think this is why crowd-sourcing is so easily gamed. While some people will sometimes be interested enough to help police things, the only ones who will be continuously motivated and dedicated are the spammers looking for financial gain.

A lot of NAS appliances offer this too. Some also have dedicated iPhone and Android apps -- though the quality probably varies a lot. Still, I personally find the Google Music app to be subpar on Android. It's gotten a lot better, but worse too in many ways. Some things require too many clicks/taps - and I dont really need a dynamic colored background or the little dropdown context menu. It seems somewhere alone the lines the UI designers forgot they were designing for touchscreens. /endramble

I was going to mod you up but I think a reply is probably better. I absolutely love that Apple is pushing Bluetooth 4, and think it has so many advantages*, (many of which you state) over NFC for local communications. However, NFC is not without merit. While it's being sold on the merits of being contactless payment system, the really cool part of NFC is the auto-configuration and app launching abilities it will open up. The possibilities for how to use that are quite vast and cool. In fact, it could (in theory) be a great way to make Bluetooth pairing easier. Or, it could be a nice way to let a guest or relative visiting your house configure Wi-Fi on their device simply by waving their device next to an NFC sticker. There is much more too, but these are just ideas to get the mind thinking about the possibilities. (Also from what I understand cyrptography is certainly possible with NFC, but may not be built in).

So while you're right, Bluetooth is far superior as a connectivity technology, NFC fills a different need and it's not without advantages.

*(Admittedly I'm a bit biased because I have developed two apps that make heavy use of Bluetooth).

Sure I have, and I said I agree with having more fine grained controls. But it's not that simple. There are downsides to that as well. Let me ask you this: how many applications have you downloaded to your computer that can access the hard drive?

This is unlikely all about permissions though. While I definitely agree with your point, this may very well be the same LogCat leak "uncovered" by lookout at DefCon of last year. Basicly what happens is lazy devs are writing personal info into the debug log. Other apps could read this with an innocous sounding "read logs" permission. It was a reader here at Slashdot who actually pointed it out to me (I write a guide for new users about Android permissions).

Of course, there may be more to it. And certainly part of it will be about companies "leaking" info to ad agencies -- but that isn't much of a "leak" when users agree to it. It's still a shady business, (especially the methodology used), but Android has a limit to what it can protect when a user agrees to give out personal details.

Anyways, here's the video of the lookout presentation:

Video from DefCon (need to login/download):

http://vimeo.com/14980971

And a simple work-around for devs not wanting to leak data.

And got GoogFace.com or FoogleBook.com I think that would be.... um

beca

I think maybe you're missing my point? I dont see where this idea comes from:"Rooting actually has nothing to do with replacing the ROM, kernel or OS." If they require root, then they are related, no? I know they are separate processes but rooting is the "enabler" -- akin to jailbreaking's enabling of non-App Store app installs.

  I only threw in Dalvik because a rooted device can use apps that have su permissions beyond that of typical apps. Another one of the things it enables.

By kernel I mean people have flashed kernels that have been modded, often to allow overclocking the CPU. This was pretty popular with the Droid 1.

Anywho, you dont sound like a smartass or anything, that was a perfectly respectful post :) But I think maybe you're confused about what you're clearing up :)

The difference is Jailbreak an iPhone = install any app. Most Android phones already allow you to install any app. Root=replace the ROM/kernel/OS and get superuser permissions so you can work outside the normal Dalvik sandbox permissions.