Here's a comment I got on an email list I belong to (regarding why the individual wouldn't use an mbed)

"Then there's the whole code ownership issue. Sound to me like they now own your source and binaries."

It's a good point.  I don't see anything on mbed.org that addresses who owns the code, or if ARM or anyone else has access or rights to the code.

--steve

Hi Steve,

Steve Ravet wrote:
Here's a comment I got on an email list I belong to (regarding why the individual wouldn't use an mbed) "Then there's the whole code ownership issue. Sound to me like they now own your source and binaries."

This is a really good point to clarify.

The important fact is we definitely do not own your source code or binaries!

The code you write is yours, and the binaries you generate are yours. You retain all copyright etc etc. You do give us the right to store your code, because we need to be able to do that to make it available to you and compile it. And you do also give us rights to analyse the code (in an anonymous way), so we can work out statistical things. For example, we might want to analyse how many projects people generally have or how long files usually are to optimise the way we display projects or code listings.

But the code is still yours. It is not like we can go "oh, that's a nice function/project, i'll have that!". And no other users can see your code (unless you choose to make it available, such as publishing it or putting code in the forum etc - here, it is more about how you choose to license your code; I'd like mbed to provide mechanisms and guidelines to help people license their code appropriately, but it is still your descision. And that is a whole other thread!).

Whilst the legalese t&c's/privacy tell you what you can't do (e.g. give out your password, misuse the website, ...) and what rights you do allow us (e.g. store your data, use cookies, ..), by the nature of these things it doesn't say what hasn't changed (i.e. you still own copyright on your code, ...)

My plan is to work with legal guys to do a "plain english" summary which not only explains the legalese in a more "readable" way, but also covers the things that are unchanged based on the lack of legalese to the converse. Basically, what is the "spirit" of what we are doing, and highlight the position on common queries such as "do you own all my source code?!".

The reality is if you are really concerned about your code being on our servers, or your prototyping work is really confidential, mbed probably isn't for you! There are lots of great tools out there and in many cases they may be more suitable, and we're not really trying to replace them. But obviously we hope that mbed will provide a great way to work with micros when it fits the bill.

I hope that clarifies things,

Simon

I'll forward your response to the list.  There was another comment also, regarding the cloud computing nature of the development environment:

"That's a minus in my book.  Support can be pulled at any time, subscription prices raised, etc.  "

I bring these up because others may have the same concerns and it'd be good to address them right up front on the WWW page.

--steve

Steve Ravet wrote:
"That's a minus in my book.  Support can be pulled at any time, subscription prices raised, etc.  "

Sure. It's not going to be for everyone, in the same way GMail isn't for everyone.

There was a time when "no-one" could understand why anyone would use a web-based mail system (so clunky, how can you read offline? etc), but the opinion was heavily skewed by the fact people using email at the time tended to be the types that had/used email accounts at work, could setup their own mail server, and when companies put up firewalls to stop people accessing their personal mail, could tunnel through it :) For those that couldn't, and more importantly, those that didn't desire to be a sysadmin to use email, Hotmail was a wonderful invention! Now it has come full circle, and GMail is the choice of even the most technical of techies.

I think as engineers we tend to be very quick at finding the problems/disadvantages when comparing two approaches; that's what makes us engineers! It usually takes a little longer for us to digest and see the upsides, or see it from the perspective of other potential users.

So we totally expect some people to really hate what we're trying to do! But that's OK, as long as there are enough people who really like what we're up to. And remember, you never really know until you try :)

Simon